Security Modes/Type in Samba Setup in Linux

If you have read any of the Samba content  you probably will have noticed that within the smb.conf configuration file a line that begins with security =. This is a very important part of Samba setup and generally the section that gives users the most problems. Although the security mode would seem fairly straight-forward, it is certainly worth explaining.

In this article I will discuss what the security mode feature does and what the different modes are. By the end of this article there should be no confusion as to which mode your Samba setup should use.

What are security modes?

I like to think of security modes as a means to inform the server just how a client will authenticate. You know about authentication from many sources. You can authenticate at a local level, as part of a domain, using Active Directory, and more. How you authenticate is generally dictated by your IT department (or by yourself if you are personal or home user). Because of the different types of authentication, Samba needs a way to know how this authentication is going to happen.

Now, from a Windows perspective (and the reason why Samba exists) there are only two types of security level: Share level and User level. But because Windows has multiple ways of authentication Samba needs to break the user level down further. So, as far as Samba is concerned, these levels are called modes and there are five modes: user, share, domain, ADS, and server. Let's take a look at each of these.

user

The security = user mode is really the easiest to understand. From the Samba server perspective, the only things that matter (with regard to user mode) is username/password and the name of the client machine. This mode works very simply: If the Samba server accepts the username/password of the client then that client is able to mount shares on the server.

share

The security = share mode the client will authenticate itself against a share on the Samba server. Unlike user, when security = shareauthenticates against a share, that means that client only has access to that share. When using this mode the client sends a password along with each share request. If the password authenticates, the client has access to the share. If not, no access is granted. The authentication process is like this:

1.    The client sends a session setup request that includes a valid username.

2.    Samba records this username.

3.    Client issues a tree connection request and the share the client wishes to connect with.

4.    The users password is the then checked against the username. If password matches, the client is given access.

domain

The security = domain provides a means for storing all username/passwords in a centralized, shared account. This account is then shared between domain controllers. So when Samba uses this mode of security it has a domain security trust account and forces all authentication requests to be passed through the domain controller. When using this mode the configuration requires a second parameter. So the configuration will look like:

security = domain

workgroup = DOMAIN_NAME

You also have to join the domain using the net rpc join -U ADMINISTRATOR%PASSWORD command. Where ADMINISTRATOR is the name of the administrator account and PASSWORD is the password for that account.

ads

As you might expect, this is the Active Directory mode. Samba added ADS functionality at release 3. Using ADS mode is only possible if the Active Directory server is run in native mode. When running in ADS mode Samba will need NT-compatible authentication data - in other words Kerberos. So your Samba server will need to have a working Kerberos system installed. When using ADS mode, your Samba configuration adds another line like so:

realm = YOUR.KERBEROS.REALM

security = ADS

server

The last mode is security = server. This mode is generally not used any more because it basically sends username/password authentication to another machine. If this other machine is down, there will be no authentication. This mode presents numerous problems, which is why it is often not used. One of the more serious problems is that once a connection to the password server is made, that connection can be left open for extended periods of time - thus a severe security issue.