20.4 How Winbind Works

The Winbind system is designed around a client/server architecture. A long running winbindd daemon listens on a UNIX domain socket waiting for requests to arrive . These requests are generated by the NSS and PAM clients and is processed sequentially.

The technologies used to implement Winbind are described in detail below.

20.4.1 Microsoft Remote Procedure Calls

Over the last few years , efforts have been underway by various Samba Team members to decode various aspects of the Microsoft Remote Procedure Call (MSRPC) system. This system is used for most network- related operations between Windows NT machines including remote management, user authentication and print spooling. Although initially this work was done to aid the implementation of Primary Domain Controller (PDC) functionality in Samba, it has also yielded a body of code that can be used for other purposes.

Winbind uses various MSRPC calls to enumerate domain users and groups and to obtain detailed information about individual users or groups. Other MSRPC calls can be used to authenticate NT domain users and to change user passwords. By directly querying a Windows PDC for user and group information, Winbind maps the NT account information onto UNIX user and group names .

20.4.2 Microsoft Active Directory Services

Since late 2001, Samba has gained the ability to interact with Microsoft Windows 2000 using its " Native Mode " protocols, rather than the NT4 RPC services. Using LDAP and Kerberos, a Domain Member running Winbind can enumerate users and groups in exactly the same way as a Windows 200x client would, and in so doing provide a much more efficient and effective Winbind implementation.

20.4.3 Name Service Switch

The Name Service Switch, or NSS, is a feature that is present in many UNIX operating systems. It allows system information such as hostnames, mail aliases and user information to be resolved from different sources. For example, a standalone UNIX workstation may resolve system information from a series of flat files stored on the local filesystem. A networked workstation may first attempt to resolve system information from local files, and then consult an NIS database for user information or a DNS server for hostname information.

The NSS application programming interface allows Winbind to present itself as a source of system information when resolving UNIX usernames and groups. Winbind uses this interface, and information obtained from a Windows NT server using MSRPC calls to provide a new source of account enumeration. Using standard UNIX library calls, one can enumerate the users and groups on a UNIX machine running Winbind and see all users and groups in a NT domain plus any trusted domain as though they were local users and groups.

The primary control file for NSS is /etc/nsswitch.conf . When a UNIX application makes a request to do a lookup, the C library looks in /etc/nsswitch.conf for a line that matches the service type being requested , for example the " passwd " service type is used when user or group names are looked up. This config line specifies which implementations of that service should be tried and in what order. If the passwd config line is:

 passwd: files example 

then the C library will first load a module called /lib/libnss_files.so followed by the module /lib/libnss_example.so . The C library will dynamically load each of these module in turn and call resolver functions within the modules to try to resolve the request. Once the request is resolved, the C library returns the result to the application.

This NSS interface provides an easy way for Winbind to hook into the operating system. All that needs to be done is to put libnss_winbind.so in /lib/ then add " winbind " into /etc/nsswitch.conf at the appropriate place. The C library will then call Winbind to resolve user and group names.

20.4.4 Pluggable Authentication Modules

Pluggable Authentication Modules, also known as PAM, is a system for abstracting authentication and authorization technologies. With a PAM module it is possible to specify different authentication methods for different system applications without having to recompile these applications. PAM is also useful for implementing a particular policy for authorization. For example, a system administrator may only allow console logins from users stored in the local password file but only allow users resolved from a NIS database to log in over the network.

Winbind uses the authentication management and password management PAM interface to integrate Windows NT users into a UNIX system. This allows Windows NT users to log in to a UNIX machine and be authenticated against a suitable Primary Domain Controller. These users can also change their passwords and have this change take effect directly on the Primary Domain Controller.

PAM is configured by providing control files in the directory /etc/pam.d/ for each of the services that require authentication. When an authentication request is made by an application, the PAM code in the C library looks up this control file to determine what modules to load to do the authentication check and in what order. This interface makes adding a new authentication service for Winbind very easy. All that needs to be done is that the pam_winbind.so module is copied to /lib/security/ and the PAM control files for relevant services are updated to allow authentication via Winbind. See the PAM documentation in Chapter 24, PAM-Based Distributed Authentication for more information.

20.4.5 User and Group ID Allocation

When a user or group is created under Windows NT/200x it is allocated a numerical relative identifier (RID). This is slightly different from UNIX which has a range of numbers that are used to identify users, and the same range in which to identify groups. It is Winbind's job to convert RIDs to UNIX ID numbers and vice versa. When Winbind is configured, it is given part of the UNIX user ID space and a part of the UNIX group ID space in which to store Windows NT users and groups. If a Windows NT user is resolved for the first time, it is allocated the next UNIX ID from the range. The same process applies for Windows NT groups. Over time, Winbind will have mapped all Windows NT users and groups to UNIX user IDs and group IDs.

The results of this mapping are stored persistently in an ID mapping database held in a tdb database). This ensures that RIDs are mapped to UNIX IDs in a consistent way.

20.4.6 Result Caching

An active system can generate a lot of user and group name lookups. To reduce the network cost of these lookups, Winbind uses a caching scheme based on the SAM sequence number supplied by NT Domain Controllers. User or group information returned by a PDC is cached by Winbind along with a sequence number also returned by the PDC. This sequence number is incremented by Windows NT whenever any user or group information is modified. If a cached entry has expired , the sequence number is requested from the PDC and compared against the sequence number of the cached entry. If the sequence numbers do not match, then the cached information is discarded and up-to-date information is requested directly from the PDC.