Sponsor

I'd like to welcome a special guest author, Ned Gnitchel, who has written an excellent 2 part article on integrating AD Authentication with Linux/Unix using Samba WinBind. Ned works for a large software company and is a specialist in OS Internals, Directory Services and Collaboration. This is 2 part article will be published today and tomorrow and there will be a downloadable version of the document at the end. Today will focus on how WinBind works and how to coinfigure WinBinds supporting components.

Introduction Samba is a set of Unix/Linux native components designed to provide Microsoft Windows authentication, file and print services. Samba, combined with its sub components, allows a Unix/Linux system to act much like a Windows Server, including the ability to natively join a Windows Active Directory domain, provide legacy NT 4 style domain services and fully integrated SMB file and printer sharing. These articles will provide information for configuring the Winbind component of Samba, including the necessary supporting subcomponents used by Winbind. Winbind is a Unix/Linux daemon (service) that provides unified authentication against Windows Server security providers (Domain Controllers). Winbind can be configured to authenticate against either legacy Windows NT SAM domains or against Microsoft Windows Server Active Directory. This document will address AD based authentication only.

How Winbind Works Winbind provides a Unix native view of Active Directory domain accounts and groups through a set of modules that leverage standard Unix components. Specifically, Winbind Name Services Switch (NSS) support and Pluggable Authentication Modules are used to pass requests to the Winbind Daemon which in turn queries the Active Directory (and supporting services, such as LDAP and Kerberos) to obtain the requested information, parse the information and reply to the calling components with the appropriate data. As Winbind interacts with several layers of Unix type authentication subsystem components it is necessary to briefly discuss each of these components.

Name Service Switch (NSS) 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 server using MSRPC and LDAP calls (to AD) 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 an AD domain plus any trusted domains as though they were local Unix 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 modules 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.

Pluggable Authentication Modules (PAM) 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 Server AD users into a UNIX system. This allows Windows Server AD users to log in to a UNIX machine and be authenticated against a suitable Domain Controller. These users can also change their passwords and have this change take effect directly on the 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.

Kerberos Kerberos is a network authentication protocol designed to provide strong authentication for client/server applications by using secret-key cryptography. Kerberos is the core authentication protocol used by all native Active Directory clients including Samba Winbind. User and Group Mappings (IDMAP) 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 users and groups. If a Windows user is resolved for the first time, it is allocated the next UNIX ID from the range. The same process applies for Windows groups. Over time, Winbind will have mapped all Windows users and groups, in a given domain or forest, to UNIX user IDs and group IDs. The results of this mapping are stored persistently in an ID mapping database held in either a locally (host) stored TDB engine database or in a specified LDAP backend. This ensures that RIDs are mapped to UNIX IDs in a consistent way.

Winbind IDMAP Options There are several options for configuring IDMAP information storage; local TDB Database, OpenLDAP based ldap store or Windows Server 2003 AD Application Partition (additional IDMAP and ldap options exist, but are not covered in this document).

Local TDB Database The easiest IDMAP configuration is to use the default TDB database, which is locally stored on the host running Winbind. This configuration, however, has one significant draw-back: each host running Winbind will store IDMAP information in a unique sequence, preventing common UID and GID mappings between multiple hosts running Winbind. This option is the preferred solution for large numbers of client Unix/Linux hosts that will never need common UID/GID to AD RID mappings. This solution works well for desktop Linux hosts that simply need access to AD for authentication purposes and will not be interacting with NFS based file sharing or will not be presenting Samba file and print shares.

OpenLDAP as an IDMAP Backend OpenLDAP (slapd) is a GNU Open-Source LDAP version 3 compliant stand-alone directory service. Winbind can be configured to store IDMAP data in any LDAP V3 compliant directory server, however OpenLDAP is the most supported solution from an official Samba project standpoint. If Winbind is to be used in conjunction with other Unix services, such as NFS, or common UID/GID to Windows AD RID mappings are desirable or necessary, it is recommended that an OpenLDAP server be configured to host IDMAP data.

Active Directory Application Partition as an IDMAP Backend Windows Server 2003 Active Directory supports independent, manually configurable naming contexts, also referred to as Application Partitions. An application directory partition can contain a hierarchy of any type of objects, except security principals (AD Users, Groups and Computer account objects), and can be configured to replicate to any set of domain controllers in the forest. Unlike a domain partition (AD Domain), an application directory partition is not required to replicate to all domain controllers in a domain and the partition can replicate to domain controllers in different domains in the same forest. By extending the AD Schema with the necessary NIS/Posix Account and Samba schema extensions, and creating an AD application partition, it is possible to unobtrusively store Winbind IDMAP data entries in the AD using one or more Domain controllers as IDMAP ldap backend servers. It is also possible to replicate this information in a simple and controlled manner to a subset of AD Domain Controllers located within either the same domain or in different domains in the same forest. Note: Currently, AD Application Partition support as an IDMAP backend for Samba Winbind is still experimental and should not be implemented as a production solution without careful environment specific testing.

Configuring Winbind Supporting Components Most modern distributions of Unix type operating systems have pre-compiled packages for installing the core Samba components. It is necessary to verify that the latest installed versions of MIT Kerberos, PAM and the latest supporting libraries for NSS are installed on the host. Installation of Samba and its supporting components is beyond the scope of this document due to the nuances of each supported platform. However, due to the popularity of Samba, installation documentation for the various flavors of Unix and Linux are well documented and most current releases of Unix / Linux have Samba, and its supporting components, as available options during installation (Appendix A. contains a list of sites for further information on each of the mentioned components and is included in the downloadable version of this article). The following sections describe how to configure Samba Winbind and supporting components.

Configuring Kerberos To configure Kerberos it is necessary to edit the “krb5.conf” configuration file. This file is usually located in the “/etc” directory. Edit the file as shown below to include your AD fully qualified domain name (FQDN) as the “realm” under the “libdefaults” section and make sure to set DNS lookups for realm and KDC to true as this will allow DNS to be used to resolve both services. Also edit the “domain realm” section, replacing the place holder entries with the AD domain name mapping (the first entry with a “period” preceding the domain name is not a typo). Note: An AD domain is also a Kerberos realm and the names are used interchangeably in this document.

Configuring the Name Service Switch The name service switch (NSS) configuration is held in the “nsswitch.conf” configuration file, which is normally located in the “/etc” directory. The following Winbind entries, as shown in figure 2, should be present to instruct the NSS subsystem to use Winbind for the necessary name related services.

Configuring the PAM Subsystem Depending on the flavor Unix or Linux being configured, PAM configuration differs slightly. This is due to certain configurations using the pam-stack (“pam_stack.so”) configuration. Traditionally, each service that uses PAM has its own PAM configuration. For example, the “login” service (text mode TTY login) has a file named “login” located in the “/etc/pam.d” directory. Inside this file would be a series of entries defining the PAM modules to be used for the various authentication steps needed by the login service. However, if a system is setup to use a stackable configuration, the “pam_stack.so” module might be used to allow the login service to call outside its own “stack”, or configuration file, to other services’ PAM stacks or a central file. When using a centrally configured PAM implementation, the single file commonly used for configuring all services stacks is the “system-auth” file located in “etc/pam.d” The following example PAM stack configuration is valid for either a single service or for systems using “pam_stack.so” and a “system-auth” stack configuration file. If it is noted that a service specific PAM configuration file, such as “/etc/pam.d/login” contains a “pam_stack.so service=system-auth” entry (or similar pam_stack.so entry), then the “system-auth” file should be the only file modified to include the necessary Winbind entries. The following illustrates a working example of a PAM stack configuration file. It should be possible to cut and paste (from the downloadable version) this directly into the “system-auth” PAM stack configuration file.

The Kerberos and Winbind specific entries that need to added to a PAM configuration file for Winbind are as follows:

 

Note: For automatic home directory creation, it is necessary to have the “pam_mkhomedir.so” module present with “skel=etc/skel/ umask=0022” parameters set. If a user authenticates and no home directory exists, the home directory is created in /home. The umask=0022 parameter causes the directory permission to be set to 755. Use the umask permissions mask flag to strengthen or weaken permissions as needed (this follows standard umask convention). The home directory is constructed from the skeletal files found in the /etc/skel directory. If may be necessary to install “pam_mkhomedir.so” if the system being configured is an older distribution of Linux or Unix (see Appendix A. in the downloadable documentation for reference locations).

For more information see:

MSDN - About Application Directory Partitions