The Samba security levels


                                     Introduction  -  Security = share  - Security = user  -  Security = server  -  Security = domain 


There are four security levels which can be used by Samba. Choosing one of these levels affect the way Samba handles the client authentication. 
 When a SMB (NetBIOS)  server receives a connection from a client, he first tells what is his security level. It's the job of the client to adapt his behaviour to the
 security level of the server. 

The four security levels are : share, user, server and domain. It can be set by using the parameter security of the global section of the smb.conf file. 

 Before the Samba version 2.0.0, the default value for security was share, now with the first 2.0.0 release this has became user.

Introduction 

 Fist of all, some words about the way Samba works to access files and directories when a user connect to it. 

 When you do a connection to the Samba server, you'll pass to it, by some means (see after), a username. This is the Windows username. Samba will lookup for
 the same username in the Unix password database, so habitually the /etc/passwd file. If found, the Samba server will use this entry to, at least, have a valid Unix
 user id to access files and directories. He can also use the /etc/passwd file to check the received password. But only if it is not configured to use encrypted
 passwords. In which case, he will check the password in another file, the /usr/local/samba/private/smbpasswd file. 

 So the conclusion is simple, for each Windows user, you need to have a Unix user having the same name. 

 But there are some ways to get rid of this necessity. See the share-level security mode  or the  mapping of usernames .

Security = share 

 In share level security, the client must authenticate itself separately for each share he wants to connect. He will send at least a password with each demand of
 connection to a share. He won't send any username with this operation because he is expecting that the server has a password associated with each share. 
 It's just like the standard comportement of Windows 95 or Windows 98. When you create a share with one of them, you can associate a password with it. 
 But Samba uses the Unix authentication where a pair username/password is authenticated and not a pair share/password. So Samba has to find out what
 username is associated with the password the client sent. 

 The way Samba follows to find a username to check the password is the following  (taken from the smb.conf manual page ) : 

 Step 0 : If the service is marked "guest only = yes" then steps 1 to 5 are skipped. 
                
 Step 1 : If the client has passed a username/password pair and that username/password pair is validated by the UNIX system's password programs or by
 checking the SMB encrypted passwords database (smbpasswd) then the connection is made as that username. Note that this includes the
 \\server\service%username method of passing a username. 
                
 Step 2 : If the client has previously registered a username with the system and now supplies a correct password for that username then the connection is
 allowed. 
                
Step 3 : The client's netbios name and any previously used user names are checked against the supplied password, if they match then the connection is
allowed as the  corresponding user. 
                
Step 4 : If the client has previously validated a username/password pair with the server and the client has passed the validation token then that username
is used. This step is skipped if "revalidate = yes" for this service. 
                
 Step 5 : If a "user = " field is given in the smb.conf file for the service and the client has supplied a password, and that password matches (according to
 the UNIX system's password checking) with one of the usernames from the user field then the connection is made as the username in the user line. 
                
 Step 6: If the service is a guest service (guest ok = Yes or guest only = Yes) then a connection is made as the username given in the "guest account ="
 for the service, irrespective of the supplied password. 

 One consequence of this security mode is that you are not required to make a Unix account for each Windows account you expect to connect to your Samba
 server.

Security = user 

 This is a simpler mode as the previous one. When the server tells the client that he runs in user level security, the client will first send a command containing a
username and a password. At this stage of the connection negociation, the server has no idea about which service the client wants to access. So he has to base
 his authentication procedure only on the pair username/password or on the machine name. 
Once the access has been granted to the client, this one can connect to any share without re-supplying a password or a username/password pair. With Windows
NT, you can send multiple pair username/password : you have to fill the "Connect as" field on any network connection dialog box, then you will be able to send a
new pair of username/password. 

 To validate the username/password pair, Samba will use the standard Unix authentication mechanisms (/etc/passwd, /etc/shadow or whatever system you may
 have enable on your server). If you run Samba in encryption mode (encrypt password = Yes), then he will use the smbpasswd file to check the username and
the password, but you still need a Unix account with the same name of the Windows account to allow files and directories access.

Security = server 

 In server level, the Samba machine is still reporting to the clients that she's running in user level security. The client make thus a connection the same way as
described above. The only difference resides in the fact that to perform the username/password pair validation, the Samba server will use this pair to try to login
to an external server, called the password server. If the login succeed for the Samba server against the password server, then the client is allowed by Samba to
connect. 
The password server must be a SMB server which runs in user level security mode. It can thus be another Samba server, a Windows NT server or any other
implementation of SMB like Pathworks, LanManager, .... Which server should Samba connects to do this is specified with the global parameter password server
 = SERVERNAME, where server name is the Netbios name of a SMB machine.

Security = domain 

 The domain level security is very similar to the server level security. 
 The Samba server tells the connecting client that is runnng in user level and pass all the username/password pair to an existing password server, which must be a
 Domain Controller. The difference from the previous security level is that in this mode Samba fully uses the domain capabilities. He behaves like another NT
 Server or Windows 9x do by participating in domain trust relationships. 
 Another advantage of this kind of authentication is that the Samba server don't need to maintain a connection to the authentication server more longer than the
 time needed by the authentication. This is not the case in server level security, the connection remains open after the authentication until the daemon who makes
 it dies. This could drain connections ressources on a Windows NT server (licenses in use, ... ). 

 To configure it the right way (in this case your Samba need to become a member of the Domain where the authentication server is located), check my page about
 the  server and domain level security . 
         
         

                                    Introduction - Security = share  - Security = user  -  Security = server  -  Security = domain


                                                               (c) May 2000, by Benoit Gerrienne