Security Mode Settings In Samba

Samba offers several Security Mode settings, which are configurable for different Samba roles in the network. The Security Mode settings determine whether Samba will accept anonymous connections, authenticate against a local password database, authenticate against a domain or authenticate against an active directory. These settings are in the global section of smb.conf, the main Samba configuration file. smb.conf is typically located in /etc/samba in popular software packages like Yum/RPM on Centos and Redhat, and Aptitude on Ubuntu. In Samba source code distributions compiled wiht the default path, it is likely to be found in /usr/local/samba/lib or /usr/local/samba/etc. You can specify the path of smb.conf in the Samba startup script.

security = user

User mode security is the simplest amd most straightforward to administer. Samba passwords for Unix/Linux user accounts are stored on the Samba server in a local password database. This precludes the need for backend encryption, user and group matching in Kerberos or LDAP password server connections like Active Directory. Samba is also pretty much foolproof assigning correct permissions to files in shared folders when user security is used. The down sides of user security are the lack of association between the Windows and Linux user accounts, and the fact that a separate password database must be maintained.

security = share

With share security mode, the client authenticates individually for each share. It sends a password along with each share connection request, but does not explicitly send a username. The client expects a password to be associated with each share, separate from the username. Windows examples of this process are shared folders set to read-only or full access, with or without a password in Windows ME and Windows 98.

Windows 7 or 8 clients with default security settings are likely to reject connections to Samba servers running share security, as it looks like anonymous access to them. There are specific situations where share security mode may be useful, particularly for using Unix password authentication for Samba, but generally user or ads authentication is desirable with Windows clients newer than XP.

security = domain

Domain mode security enables the Samba server to be a domain member, domain controller or backup domain controller. When functioning as a DC, the administrator must maintain user and computer credentials databases, internal dns and dhcp on the Samba server. As a domain member, the Samba server must be a domain member computer. As a domain member, Samba can connect to the Windows password server to authenticate users with their Windows accounts.

security = ads

ADS security is similar to domain security, but allows the Samba server to utilize the more current Kerberos realm architure used by Microsoft Active Directory. When joining a domain or active directory, different flags, either "domain" or "ads" are used with the net join process. In my experience I have had better results joining domains and active directories when I have already added a computer account for the Samba server.

For both domain and ads member Samba servers, a username cross reference must be maintained in Samba. This is specified with the username map = option, and is usually set to username map = /etc/samba/smbusers. It is a set of name value pairs associating the Linux accounts with the Windows accounts. Here is an example:

john = DOMAIN\john

This example hightlights a challenge Samba faces. Unix user accounts do not look exactly like Windows user accounts. Samba's job is to match them up, but there are times when that matchup doesn't work flawlessly. For example, users who can authenticate fine from their Windows client to the Samba server might find that permissions on the files created on the Samba share don't exactly match what was expected, or perhaps don't allow the user to modify the file later. It is suggested to add matching group names on Linux and Windows and set the desirable permissions at the group level to help with these issues. If the systems are in a pretty secure environment like a local lan, or the data is not sensitive, it is possible to work around permissions problems with group or world writable files, but when push comes to shove, security = user might be the best answer. With user security, Samba doesn't need to match all the Windows user account properties.

Samba and Windows also must agree on encryption when a Windows client authenticates to Samba, when Samba Client connects to a Windows computer or when Samba attempts to authenticate a domain or ads login to a password server. If everything looks right in your setup, but logins continually fail, particularly with the message "connection reset by peer", research the compatibility between your Samba and Windows versions. Samba regularly offers upgrades, which are pretty easy to compile and install.

security = server

Server security exists for backward compatibility with old Samba versions prior to the availability of domain security. It is deprecated and should not be used unless absolutely necessary

Related commands: smbpasswd, smbclient, smbprint, smbspool, net, pdbedit