在网上搜samba安全级别，能看到很多都是写share,user,server,domain这四个，很少写share,user,server,domain，ads这五个，所以我就想到底是四种还是五种，官方http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/ServerType.html必较可靠，以下引用官方说法。
（1）User Level Security
We describe user-level security first because its simpler. In user-level security, the client sends a session setup request directly following protocol negotiation. This request provides a username and password. The server can either accept or reject that username/password combination. At this stage the server has no idea what share the client will eventually try to connect to, so it can't base the accept/reject on anything other than:
-
the username/password.
-
the name of the client machine.
If the server accepts the username/password credentials, the client expects to be able to mount shares (using a tree connection) without further specifying a password. It expects that all access rights will be as the username/password credentials set that was specified in the initial session setup.
It is also possible for a client to send multiple session setup requests. When the server responds, it gives the client a uid to use as an authentication tag for that username/password. The client can maintain multiple authentication contexts in this way (WinDD is an example of an application that does this).
Windows networking user account names are case-insensitive, meaning that upper-case and lower-case characters in the account name are considered equivalent. They are said to be case-preserving, but not case significant. Windows and LanManager systems previous to Windows NT version 3.10 have case-insensitive passwords that were not necessarily case-preserving. All Windows NT family systems treat passwords as case-preserving and case-sensitive.
Example Configuration
The smb.conf parameter that sets user-level security is:
security = user
This is the default setting since Samba-2.2.x.
（2）Share-Level Security
In share-level security, the client authenticates itself separately for each share. It sends a password along with each tree connection request (share mount), but it does not explicitly send a username with this operation. The client expects a password to be associated with each share, independent of the user. This means that Samba has to work out what username the client probably wants to use, because the username is not explicitly sent to the SMB server. Some commercial SMB servers such as NT actually associate passwords directly with shares in share-level security, but Samba always uses the UNIX authentication scheme where it is a username/password pair that is authenticated, not a share/password pair.
To understand the MS Windows networking parallels, think in terms of MS Windows 9x/Me where you can create a shared folder that provides read-only or full access, with or without a password.
Many clients send a session setup request even if the server is in share-level security. They normally send a valid username but no password. Samba records this username in a list of possible usernames. When the client then issues a tree connection request, it also adds to this list the name of the share they try to connect to (useful for home directories) and any users listed in the user parameter in the smb.conf file. The password is then checked in turn against these possible usernames. If a match is found, then the client is authenticated as that user.
Where the list of possible user names is not provided, Samba makes a UNIX system call to find the user account that has a password that matches the one provided from the standard account database. On a system that has no name service switch (NSS) facility, such lookups will be from the /etc/passwd database. On NSS enabled systems, the lookup will go to the libraries that have been specified in the nsswitch.conf file. The entries in that file in which the libraries are specified are:
passwd: files nis ldap shadow: files nis ldap group: files nis ldap
In the example shown here (not likely to be used in practice) the lookup will check /etc/passwd and /etc/group, if not found it will check NIS, then LDAP.
Example Configuration
The smb.conf parameter that sets share-level security is:
security = share
（3）Domain Security Mode (User-Level Security)
Domain security provides a mechanism for storing all user and group accounts in a central, shared, account repository. The centralized account repository is shared between domain (security) controllers. Servers that act as domain controllers provide authentication and validation services to all machines that participate in the security context for the domain. A primary domain controller (PDC) is a server that is responsible for maintaining the integrity of the security account database. Backup domain controllers (BDCs) provide only domain logon and authentication services. Usually, BDCs will answer network logon requests more responsively than will a PDC.
When Samba is operating in security = domain mode, the Samba server has a domain security trust account (a machine account) and causes all authentication requests to be passed through to the domain controllers. In other words, this configuration makes the Samba server a domain member server, even when it is in fact acting as a domain controller. All machines that participate in domain security must have a machine account in the security database.
#我的理解是：当samba的安全级别为domain时，所有的用户认证请求就是通过DC（域控制器）认证的。换句话说，这个配置使samba服务器成为域成员服务器，或成为DC。在域内的机器必须要有一个计算机账号。
Within the domain security environment, the underlying security architecture uses user-level security. Even machines that are domain members must authenticate on startup. The machine account consists of an account entry in the accounts database, the name of which is the NetBIOS name of the machine and of which the password is randomly generated and known to both the domain controllers and the member machine. If the machine account cannot be validated during startup, users will not be able to log on to the domain using this machine because it cannot be trusted. The machine account is referred to as a machine trust account.
#计算机的账号就是NetBIOS名，密码是随机产生的。如果计算机在启动过程中认证没通过，用户就不能在这台机器上登录到域内，因为计算机不能被信任。
There are three possible domain member configurations:
-
Primary domain controller (PDC) - of which there is one per domain.
-
Backup domain controller (BDC) - of which there can be any number per domain.
-
Domain member server (DMS) - of which there can be any number per domain.
We will discuss each of these in separate chapters. For now, we are most interested in basic DMS configuration.
#samba服务能配置成主域控制器（PDC），备份域控制器（BDC）及成员服务器（DMS）。
从widows 2003 server 开始就没有PDC与BDC 的区别了，可是这里还提到了PDC，BDC。
Example Configuration
Samba as a Domain Member Server
This method involves addition of the following parameters in the smb.conf file:
security = domain
workgroup = MIDEARTH
In order for this method to work, the Samba server needs to join the MS Windows NT security domain. This is done as follows:
-
On the MS Windows NT domain controller, using the Server Manager, add a machine account for the Samba server.
-
On the UNIX/Linux system execute:
#以上是把samba配置成成员服务器的例子。1，先在windows 的DC上在开始----管理工具---”Active Directory 用户和计算机“中添加samba服务器的计算机账号（NetBIOS名）；2，在UNIX/Linux上执行以下命令
Note
Samba-2.2.4 and later Samba 2.2.x series releases can autojoin a Windows NT4-style domain just by executing:
Samba-3 can do the same by executing:
root# net rpc join -U Administrator%password It is not necessary with Samba-3 to specify the DOMAIN_NAME or the PDC_NAME, as it figures this out from the smb.conf file settings.
Use of this mode of authentication requires there to be a standard UNIX account for each user in order to assign a UID once the account has been authenticated by the Windows domain controller. This account can be blocked to prevent logons by clients other than MS Windows through means such as setting an invalid shell in the /etc/passwd entry. The best way to allocate an invalid shell to a user account is to set the shell to the file /bin/false.
Domain controllers can be located anywhere that is convenient. The best advice is to have a BDC on every physical network segment, and if the PDC is on a remote network segment the use of WINS (see Network Browsing for more information) is almost essential.
An alternative to assigning UIDs to Windows users on a Samba member server is presented in Winbind, Winbind: Use of Domain Accounts.
#在samba 成员服务器上给windows 用户如何分配UID，可以参考winbind的配置。此时就要结合winbind。samba服务器加入到windows 的域中要解决windows server 上的账号与samba上用户账号对应关系，就离不了winbind。比如：要访问samba服务器时通过windows 2003 server 的DC进行用户验证，就要配置winbind。因为要访问samba就必需在samba服务器上有账号，此时就需要把windows 2003 server 上用户给映射过来。
For more information regarding domain membership, Domain Membership.
（4）ADS Security Mode (User-Level Security)
Both Samba-2.2, and Samba-3 can join an Active Directory domain using NT4 style RPC based security. This is possible if the domain is run in native mode. Active Directory in native mode perfectly allows NT4-style domain members. This is contrary to popular belief.
If you are using Active Directory, starting with Samba-3 you can join as a native AD member. Why would you want to do that? Your security policy might prohibit the use of NT-compatible authentication protocols. All your machines are running Windows 2000 and above and all use Kerberos. In this case, Samba, as an NT4-style domain, would still require NT-compatible authentication data. Samba in AD-member mode can accept Kerberos tickets.
Sites that use Microsoft Windows active directory services (ADS) should be aware of the significance of the terms: native mode and mixed mode ADS operation. The term realm is used to describe a Kerberos-based security architecture (such as is used by Microsoft ADS).
#在windows 2003 server 中域功能级别有三种：
(1)windows 2000 混合模式（windows 2000 mixed mode ），这个级别内的域控制器可以是server 2003,server 2000和NT 4.0 server。
（2）windows 2000 纯模式（windows native mode)，这个级别内的域控制器可以是server 2003,server 2000，不可以有NT 4.0 server。
（3）windows 2003 ,这个级别内的域控制器只能是 server 2003 。
根据我的理解，Samba 服务器可以做为NT 4.0类型的域服务器加入到域功能级别为windows 2000 纯模式或混合模式的域中，成为域成员服务器。
Example Configuration
realm = your.kerberos.REALM
security = ADS
The following parameter may be required:
password server = your.kerberos.server
Please refer to Domain Membership, and Samba ADS Domain Membership for more information regarding this configuration option.
（5）Server Security (User Level Security)
Server security mode is left over from the time when Samba was not capable of acting as a domain member server. It is highly recommended not to use this feature. Server security mode has many drawbacks that include:
１，Potential account lockout on MS Windows NT4/200x password servers.
２，Lack of assurance that the password server is the one specified.
３，Does not work with Winbind, which is particularly needed when storing profiles remotely.
４，This mode may open connections to the password server and keep them open for extended periods.
５，Security on the Samba server breaks badly when the remote password server suddenly shuts down.
６，With this mode there is NO security account in the domain that the password server belongs to for the Samba server.
In server security mode the Samba server reports to the client that it is in user-level security. The client then does a session setup as described earlier. The Samba server takes the username/password that the client sends and attempts to log into the password server by sending exactly the same username/password that it got from the client. If that server is in user-level security and accepts the password, then Samba accepts the client's connection. This parameter allows the Samba server to use another SMB server as the password server.
You should also note that at the start of all this, when the server tells the client what security level it is in, it also tells the client if it supports encryption. If it does, it supplies the client with a random cryptkey. The client will then send all passwords in encrypted form. Samba supports this type of encryption by default.
The parameter security = server means that Samba reports to clients that it is running in user mode but actually passes off all authentication requests to another user mode server. This requires an additional parameter password server that points to the real authentication server. The real authentication server can be another Samba server, or it can be a Windows NT server, the latter being natively capable of encrypted password support.
Note
When Samba is running in server security mode, it is essential that the parameter password server is set to the precise NetBIOS machine name of the target authentication server. Samba cannot determine this from NetBIOS name lookups because the choice of the target authentication server is arbitrary and cannot be determined from a domain name. In essence, a Samba server that is in server security mode is operating in what used to be known as workgroup mode.
Example Configuration
Using MS Windows NT as an Authentication Server
This method involves the additions of the following parameters in the smb.conf file:
encrypt passwords = Yes
security = server
password server = "NetBIOS_name_of_a_DC"
There are two ways of identifying whether or not a username and password pair is valid. One uses the reply information provided as part of the authentication messaging process, the other uses just an error code.
The downside of this mode of configuration is that for security reasons Samba will send the password server a bogus username and a bogus password, and if the remote server fails to reject the bogus username and password pair, then an alternative mode of identification or validation is used. Where a site uses password lockout, after a certain number of failed authentication attempts, this will result in user lockouts.
Use of this mode of authentication requires a standard UNIX account for the user. This account can be blocked to prevent logons by non-SMB/CIFS clients.
所以说，samba的安全模式应该是五个。
-
root#net rpc join -U administrator%password