samba的安全級别是4個還是5個

   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 <code>smb.conf</code> parameter that sets user-level security is:

security = user

This is the default setting since Samba-2.2.x.

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.

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 <code>/etc/passwd</code> database. On NSS enabled systems, the lookup will go to the libraries that have been specified in the <code>nsswitch.conf</code> file. The entries in that file in which the libraries are specified are:

In the example shown here (not likely to be used in practice) the lookup will check <code>/etc/passwd</code> and <code>/etc/group</code>, if not found it will check NIS, then LDAP.

The <code>smb.conf</code> parameter that sets share-level security is:

security = share

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.

#我的了解是：當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。

Samba as a Domain Member Server

This method involves addition of the following parameters in the <code>smb.conf</code> 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上執行以下指令

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:

It is not necessary with Samba-3 to specify the <code>DOMAIN_NAME</code> or the <code>PDC_NAME</code>, as it figures this out from the <code>smb.conf</code> 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 <code>/etc/passwd</code> entry. The best way to allocate an invalid shell to a user account is to set the shell to the file <code>/bin/false</code>.

#在samba 成員伺服器上給windows 使用者如何配置設定UID，可以參考winbind的配置。此時就要結合winbind。samba伺服器加入到windows 的域中要解決windows server 上的賬号與samba上使用者賬号對應關系，就離不了winbind。比如：要通路samba伺服器時通過windows 2003 server 的DC進行使用者驗證，就要配置winbind。因為要通路samba就必需在samba伺服器上有賬号，此時就需要把windows 2003 server 上使用者給映射過來。

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: <code>native mode</code> and <code>mixed mode</code> ADS operation. The term <code>realm</code> 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 純模式或混合模式的域中，成為域成員伺服器。

realm = your.kerberos.REALM

security = ADS

The following parameter may be required:

password server = your.kerberos.server

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.

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.

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.

Using MS Windows NT as an Authentication Server

This method involves the additions of the following parameters in the <code>smb.conf</code> 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.

本文轉自xcjgutong 51CTO部落格，原文連結:http://blog.51cto.com/xuchengji/411058