S 4.333 Secure configuration of Winbind under Samba

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

The secure configuration of Windbind plays an important role when Samba is operated in the "domain" or "ads" security mode (see S 4.328 Secure basic configuration of a Samba server). In this case, there is a whole series of recommendations that need to be taken into consideration.

When it joins a domain, smbd is able to authenticate users on the domain controller (DC). Depending on the security mode and client, authentication is performed by evaluating the Kerberos ticket or by querying the DC. The latter is particularly time-consuming, because smbd must first find a DC and then log in to it before it can authenticate the user. This generates at least 30 network packets, only two of which are actually relevant to the authentication process.

Windows operates differently. The Local Security Authority (LSA) establishes a connection to the DC once when the domain member is started and authenticates itself as a machine. In this case, users are only authenticated using this connection. This concept does not work with smbd alone, because there is a separate smbd process for each client and network connections cannot simply be used simultaneously by several different processes.

For this reason, winbindd can be used as a proxy for the connection to the DC. It offers functionality comparable to that offered by LSA when run in Windows. In particular, it opens and maintains a connection to the DC and offers its services to all processes in the system using a Unix domain socket located in /tmp/winbindd/pipe. The smbd processes try to connect to this socket first when attempting to authenticate themselves. The smbd processes only attempt to establish a connection to a DC when authentication via the socket fails.

In addition to successful authentication, Samba also needs extra information on the users. It is necessary for each user to have one Windows and one Unix user account on the Samba server. The Unix user account is needed so that Samba can allow the kernel to control access in the file system, amongst other reasons (see also S 4.332 Secure configuration of the access controls for a Samba server).

This means that every domain user must exist in the Unix operating system together with all their group memberships. It is possible theoretically to manage all domain users manually in Unix. However, this approach should not be used and Winbind should be used instead.

Winbind is able to dynamically create appropriate Unix users and groups matching the Windows users and Windows groups when these users and groups do not yet exist in Unix. In this case, the "nss_winbind" module is used and it can be added by entering it in the file /etc/nsswitch.conf. This entry could be as follows, for example:

passwd: files winbind

group: files winbind

With these settings, the operating system searches for user names in the file /etc/passwd first. If it does not find the right user in this file, it contacts winbindd. In order for winbindd to be able to dynamically create all necessary Unix user attributes (for example the user ID, home directory, or login shell) for a user name, the daemon needs to take two steps. First, Winbind queries the DC for the security identifier (SID) of the user name. After that, Winbind must find a Unix user ID that matches the SID because the DC does not know the Unix user ID of a user. Winbind proceeds in different ways depending on the ID mapping backend configured:

• tdb:
  This is the default setting for the ID mapping backend. When a user who does yet not have a Unix user ID assigned to him/her logs in, Winbind assigns the user the next Unix user ID available in a prescribed range and stores the ID mapping locally in a tdb file. The ID mappings are stored in the file winbindd_idmap.tdb.
  
  Losing this file will lead to the loss of all rights and authorisations assigned in the file system. This may lead to serious security gaps. The following example illustrates this fact:
  
  The user "User1" logs in to the Samba server for the first time using his Windows user name BERLIN\user1. In the Windows domain, the user BERLIN\user1 has the SID S-1-5-12-7623811015-3361044348-030300820-1013. Winbind reserves a free Unix user ID and assigns the Unix user ID 2000 to the SID. This mapping is then stored in the file winbindd_idmap.tdb.
  
  After logging on successfully, the user BERLIN\user1 saves some files on the Samba server. These files are stored under the Unix user ID 2000. Since the file winbindd_idmap.tdb was backed up incorrectly, some of the mappings stored in it are lost. Shortly thereafter, the user "User2" logs in to the Samba server using her Windows user name BERLIN\user2. In the Windows domain, the user BERLIN\user2 has the SID S-1-5-12-7623811015-3361044348-030300820-1017. Since the information that Unix user ID 2000 has already been assigned has been lost due to the loss of data, Winbind assigns this Unix user ID to the SID of User2.
  
  The user "User2" can now access every file that user User1 originally stored using the Unix user ID 2000.
  
  For this reason, the file winbindd_idmap.tdb must be backed up regularly. In addition to the explanations and recommendations for backups provided in safeguard S 6.135 Regular backup of important system components of a Samba server, the ID mapping can also be backed up in the following manner. The command "net idmap dump" generates a plain text file that can be restored when necessary using the command "net idmap restore".
• rid:
  
  This backend uses the Relative Identifier (RID), which is the string of characters behind the last hyphen of the Windows SID, to calculate the Unix user ID using a certain algorithm. This backend does not need a database, because mapping is deterministic.
• ad:
  
  This backend can be used when the extensions for the Services For Unix (SFU) are implemented in the Active Directory and Samba is operated in the "ads" security mode. When this extension is used, the administrator can assign Unix user IDs explicitly in the Active Directory. When this backend is used, Winbind only reads the ID mappings. Winbind does not create new ID mappings or change existing ID mappings.
  
  Furthermore, this backend is the only backend that Winbind can use to obtain additional Unix user attributes (for example the home directory or login shell of a user). When any of the other backends are used, other mechanisms must be used for this purpose, for example the "template shell" and "template homedir" configuration parameters in the configuration file smb.conf.
• ldap:
  
  This backend stores ID mappings (which it generates by itself) in a Lightweight Directory Access Protocol (LDAP) directory.
• nss:
  
  This backend does not map the IDs based on the SIDs and instead assumes that the domain controller and domain members synchronise the /etc/passwd information using other resources, for example using nss_ldap. If a system nevertheless requests a mapping from Winbind, Winbind returns a name-based mapping. This means that it first converts an SID to the corresponding user name and then looks for the name in the file /etc/passwd. This backend substitutes the Winbind parameter "winbind trusted domains only".

Additional information on the different backends used for ID mapping can be found on their man pages. These man pages are named according to the naming scheme "idmap_<name of the backend>". Entering "man idmap_nss" displays additional information on the nss backend. Every ID mapping backend has its own individual configuration parameters. The "wbinfo" program should be used for troubleshooting.

In addition to the Unix user ID, Winbind generally also needs to assign additional Unix user attributes to each user, for example a home directory. This can be controlled using parameters such as "template homedir" or "template shell". As stated above, another mechanism is only available for the "ad" ID mapping backend.

If only one Samba server is a member of the domain and the Unix user IDs do not need to be synchronised between servers, the "tdb" ID mapping backend can be used.

If several Samba servers are members of the domain and the Unix user IDs need to be synchronised among the servers for this reason, one of the other ID mapping backends must be used.

If there are trust relationships between some of the domains in the information system, the recommendations in the following section "Trust relationships between domains" must be implemented.

Trust relationships between domains

A trust relationship is a relationship between domains that allows the users in one domain to be authenticated by a domain controller located in another domain.

Even if there are no trust relationships between domains in the information system at the moment, it still makes sense to implement the safeguards in this section, because they may be necessary in the future.

Unix user IDs

Windows assigns each user and each group a unique ID, the SID (Security Identifier). The SID contains a 96-bit long domain part and an RID (Relative Identifier) that is unique in the domain. As long as there is only one domain in the information system, Unix can use the RID to calculate a unique Unix user ID. If the information system contains several domains that trust each other mutually, this approach will not work any more. If the domain in which the Samba server is a member trusts another domain, the RID will not be unique any more. RID "500" is generally assigned to the administrator, RID "513" is assigned to the group of domain users, and every domain assigns RIDs sequentially starting with the RID "1000".

The parameter "idmap domains" is available in Samba Version 3.0.25 and higher. This parameter allows configuration of the ID Mapping based on the name of the domain.

[global]

idmap domains = BONN BERLIN

idmap config BONN:backend = rid

idmap config BONN:range = 10000 - 49999

idmap config BERLIN:backend = rid

idmap config BERLIN:range = 50000 - 99999

In the example shown above, the user BONN\administrator was assigned the Unix user ID 10500, while the user BERLIN\administrator would then be assigned the Unix user ID 50500 by Winbind.

If there are trust relationships between domains in the information system, one of the following ID mapping backends must be used:

• rid backend with idmap domains configuration.
• ldap backend with idmap domains configuration.
• ad backend.
• nss backend.

Unix home directory

The domain of the user should be added to the path of the user's home directory. This prevents name collisions when trust relationships exist. The user "User1" in the BERLIN domain must be assigned a different home directory than "User1" in the BONN domain. This can be realised by entering the following in the smb.conf configuration file:

template homedir = /home/%D/%u

As an alternative, it is also possible to manage the home directories of the users in the Active Directory (AD) when Winbind uses the "ad" ID mapping backend. In the example shown above, the user BERLIN\user1 would be assigned /home/BERLIN/user1 as his Unix home directory.

The home directories are not created automatically by Winbind. However, this is not desirable anyway when the Samba server is used as a file server, for example.

Unix user name

To guarantee the uniqueness of the user names, the Windows user names must be converted in the following manner to Unix user names. The Unix user name of the Windows user BONN\user1 is BONN<winbind separator>user1. By default, the "winbind separator" parameter is set to the ¿\¿ character. If the default separator character setting causes problems on the Unix systems (for example, the character ¿\¿ has a special meaning when entered in a Unix command line prompt), another character can be specified in the configuration file smb.conf.

When changing the character specified in the "winbind separator" parameter, it must first be checked where the domain users and groups are entered or specified (e.g. in the configuration file smb.conf). All of these locations must be modified after changing the parameter.

Review questions:

• Has Winbind been configured in such a way that Unix user IDs cannot collide?
• Has Winbind been configured in such a way that there will be no collisions between the user directories in domains with trust relationships?
• Does Winbind convert the Windows user names to unique Unix user names?
• Are the ID mappings backed up regularly?