Ned Gnitchel finishes off his article on integrating AD Authentication with Linux/Unix using Samba WinBind. Today will describe the steps required to configure WinBind. A downloadable version of this article is available at the end of this article which includes links to more information.

Configuring Winbind The following sections describe the necessary global settings for the “smb.conf” configuration file located in “etc/samba”. The sections are separated only by the IDMAP configuration options and each example demonstrates a working configuration. Samba Winbind Standard (local IDMAP) Configuration The following smb.conf configuration file, shown in figure 4, is configured to support a local, non-centralized, Winbind IDMAP database. Only the “global” section is included as this is the only section required for Winbind configuration.

Note: For additional Samba “smb.conf” reference the support sites listed in Appendix A of the downloadable document.

For the “workgroup” entry, enter the legacy NetBIOS name of the AD domain the host will be participating in. For the “netbiosname” entry, set this value to the computer name the host should be known by in AD (e.g. the computer account name). For the “realm” entry, set the value to the FQDN of the Active Directory domain this host will be joined to.

Note: In an AD domain containing large numbers of user and group objects (over 3000), it is recommended that the “winbind enum users” and “winbind enum groups” option be set to a “no” value. While this will impact certain user interface elements from presenting all available AD security principals, it may dramatically improve system response time for certain actions and will significantly reduce LDAP traffic.

Once Winbind and the supporting components are configured, issue the following command at a shell (logged in as root) to finalize the Winbind setup: “net ads join -U administrator” This command will join the host to the AD domain (supplement “administrator” with any account granted the necessary rights to join computers to the AD). To start and test Winbind, type “winbindd” at the shell prompt (as root). To validate that Winbind is correctly seeing the domain, type “wbinfo –g” at the shell prompt; this should enumerate and print to screen all the groups in the AD domain (for further “wbinfo” options, type “wbinfo” at the shell). To validate authentication is functioning correctly, test logons through several different services including “ssh” and local login. Once testing is complete, and the configuration has been validated as working, add the Winbind daemon (winbindd) to the appropriate Unix/Linux run-level configuration (consult the OS specific documentation for assistance with this step).

Winbind using LDAP IDMAP Back-End In order to configure Winbind to use an LDAP directory server, it is necessary to configure an LDAP back-end. This document specifically references using OpenLDAP as the LDAP provider for this configuration; however other stand-alone LDAP v3 compliant directory services will also suffice but are not within the scope of this document.

Configuring OpenLDAP to support Winbind IDMAP Installation of OpenLDAP is not covered in this document; please reference the official OpenLDAP documentation located at http://www.openldap.org. Once OpenLDAP is installed, configure the “slapd.conf”, located in “/etc/slapd” as shown in figure 5. To generate the “rootdn” password for OpenLDAP, use the “slappasswd” command to generate a password hash, then paste the hash into the “rootpw” value. Be sure to validate the file is set to mode 700 for permissions.

Note: As with all example configurations, replace placeholder name references, such as “dc=domainname,dc=com”, with appropriate names. In the case of OpenLDAP, this name need not match the Active Directory naming conventions as the two are entirely independent.

Prior to starting the OpenLDAP server, validate the “samba.schema” schema file is located in the “etc/ldap/schema” directory. The latest version of the schema can be found in the samba distribution files available from www.samba.org. Once the OpenLDAP configuration is complete, start the OpenLDAP server by typing “slapd” at the shell prompt. Validate that the LDAP server is functioning by using an LDAP tool, such as LDP, to connect and bind to the server (using the cn=Manager,dc=domainname,dc=com account and the password entered in slapd.conf). Create and object named “cn=Manager, dc=domainname, dc=com” with an object class type of “organizationalRole” and a description of “Directory Manager”. The above example does not include SSL support. It is absolutely critical that once a working configuration is achieved and tested, that SSL be enabled for LDAP connections. This is to prevent the “rootdn” password from being compromised during a simple LDAP bind from the Winbind host.

For additional information on enabling SSL for LDAP connections in OpenLDAP see: http://www.openldap.org/pub/ksoper/OpenLDAP_TLS_howto.html#4.0

Once testing is complete, and the configuration has been validated as working, add the OpenLDAP daemon (slapd) to the appropriate Unix/Linux run-level configuration (consult the OS specific documentation for assistance with this step).

Winbind IDMAP LDAP configuration Configuring the smb.conf to instruct Winbind to use an LDAP backend for IDMAP data storage is fairly straight forward. Add the following lines to a working “smb.conf” configuration file:

The “ldap admin dn” value should match the rootdn value set during the configuration of the OpenLDAP server. The “ldap idmap suffix” should be set to “ou=idmap”. The ldap suffix should match the “suffix” value set in the “slapd.conf” configuration file. The “idmap backend” value should be the IP address or fully qualified DNS name of the server running OpenLDAP. Once the above settings are present, type the following command at the shell prompt: “smbpassword -w [password_of_Directory_Manager]” Where “password_of_Directory_Manager” would be the password set for the OpenLDAP rootdn account (use the human readable form submitted to the “slappasswd” command). The password will be stored in the Samba “secrets.ldb” database, which hashes the password and is only readable by the “root” account. Once Winbind and the supporting components are configured, issue the following command at a shell (logged in as root) to finalize the Winbind setup: “net ads join -U administrator” This command will join the host to the AD domain (supplement “administrator” with any account granted the necessary rights to join computers to the AD). To start and test Winbind, type “winbindd” at the shell prompt (as root). To validate that Winbind is correctly seeing the domain, type “wbinfo –g” at the shell prompt; this should enumerate and print to screen all the groups in the AD domain (for further “wbinfo” options, type “wbinfo” at the shell). To validate authentication is functioning correctly, test logons through several different services including “ssh” and local login. To validate that IDMAP entries are being entered correctly in the LDAP directory, connect with an LDAP administration tool (e.g. LDP) to the OpenLDAP server. Expand the IDMAP container (ou=IDMAP); there should be numerous entries similar to the example below:

Once testing is complete, and the configuration has been validated as working, add the Winbind daemon (winbindd) to the appropriate Unix/Linux run-level configuration (consult the OS specific documentation for assistance with this step). To configure Winbind to use LDAP SSL for connections, add the following line to the “smb.conf” configuration file: ldap ssl = on Also change the idmap backend value to include an “s” in the URL address as shown below: idmap backend = ldap:ldaps://FQDNofLDAPSERVER

Winbind using an Active Directory Application Partition for IDMAP Back-End Active Directory, as with any LDAP V3 compliant directory service, can function as the backend for Winbind IDMAP back-end storage. This configuration uses a Windows Server 2003 Active Directory application partition to store the IDMAP entries. Using an application partition has some significant advantages over storing the IDMAP data in an AD domain partition or in the configuration partition: security principals can not be created in an application partition, preventing possible rogue accounts from being added using the “ldap admin dn” account info stored in the Samba “secrets.tdb” database. Additionally, the application partition replication scope is completely controllable (application partitions do not participate in global catalog indexing) allowing strict selection of one or more Domain Controllers to host the IDMAP data, which negates the risk of an LDAP flooding attack impacting domain or forest-wide function. Due to the potential issues with not using an AD application partition, it is not recommended that Winbind IDMAP be configured for use with a Domain Partition or the Configuration Partition. As such, Windows 2000 Active Directory is not recommended for use with Winbind for IDMAP storage.

Configuring Windows Server 2003 Active Directory to support Winbind IDMAP Note: The tasks outlined in this section assume that the actions affecting Active Directory are being executed by an account with Enterprise Admins and Schema Admins privileges. Prior to configuring Winbind IDMAP to store data in the AD, it is necessary to extend the AD schema with the necessary Samba schema extensions. To perform this action, login with Schema Admins privileges on the Active Directory Forest Schema Master domain controller, unzip the “ADSambaSchema.zip” archive (included with this document package) to “c:\sambaschema”. Open each “.ldf” file and perform a search and replace on the string “dc=testnet,dc=com“, replacing the string with the top level Domain Component (DC=) values for the AD forest. Once the files have been modified correctly, install the extensions by executing the “schemaupdate.bat” batch file from the command prompt. Be sure to change directory to “c:\sambaschema” prior to executing the batch file. Once the schema extensions have been loaded successfully, open the schema management MMC snap-in. Validate that the “uidNumber” and “gidNumber” attributes have no minimum or maximum value setting by viewing the properties of the attribute objects as shown below.

Having completed the schema updates and verified the “uidNumber” and “gidNumber” attributes, it is necessary to create a new user account, or group, in the Active Directory. This group will be used to set access control on the application partition created in the next step. If a single account is created, this account must be located in the same domain that will house the DC holding the application partition, as Winbind uses a simple LDAP bind for authentication. Additionally, if a group is used, the group can be housed anywhere in the forest, but an account must be present in the local domain partition of any DC holding a replica of the partition and being used for Winbind IDMAP. Note: For the purposes of this documentation, a single user account named “IDMAPManager” will be used to demonstrate the ACL settings for the application partition. To create an application partition: 1. Open a Command Prompt on the DC that should hold the first replica of the application partition. 2. Type: ntdsutil 3. At the ntdsutil command prompt, type: domain management 4. At the domain management command prompt, type: connection 5. At the connection command prompt, type:connect to server name of domain controller 6. At the connection command prompt, type: quit 7. At the domain management command prompt, do type: create nc dc=sambaidmap,dc=domainname,dc=com null Once the application partition has been created, open ADSIedit.msc and connect to the application partition using settings similar to those shown below.

Once connected, select the top level application partition (e.g. dc=sambaidmap,dc=domainname,dc=com) node in the left-hand pane and right-click selecting “new object” from the object list, select “sambaUnixIdPool”. When asked to enter the “ou=” attribute, type “idmap”. When queried for the mandatory “gidNumber” and “uidNumber” values, type in “10000” for each.

Once the “ou=idmap,dc=sambaidmap,dc=domainname,dc=com” container has been created, right-click on the object and select properties. On the security tab, click “Add” and proceed to add the “IDMAPManager” user account. Grant this account “Read,Write, Create All Child Objects, Delete All Child Objects” as shown below.

Having completed the steps above, the AD should now be ready to host IDMAP data. As with the OpenLDAP configuration, once the final configuration has been tested, SSL should be used to protect the “IDMAPManager” credentials. Any DC participating in an AD Forest with a Microsoft Enterprise CA implementation will already be capable of accepting SSL connections. To implement LDAP SSL without a Microsoft Enterprise CA, or for additional information configuring DC’s to use SSL, see: http://www.microsoft.com/technet/security/guidance/secmod154.mspx

Winbind IDMAP LDAP configuration for AD Application Partitions Configuring the smb.conf to instruct Winbind to use an LDAP backend for IDMAP data storage in an AD application partition is nearly identical to the configuration used for OpenLDAP. Add the following lines to a working “smb.conf” configuration file.

The “ldap admin dn” value should match the LDAP Distinguished Name (DN) of the “IDMAPManager” created in AD (or other user with rights to the idmap container). The “ldap idmap suffix” should be set to “ou=idmap”. The ldap suffix should match the DN of the application partition. The “idmap backend” value should be the IP address or fully qualified DNS name of the AD domain controller. Once the above settings are present, type the following command at the shell prompt: “smbpassword -w [password_of_IDMAPManager]” Where “password_of_IDMAPManager” would be the password for the IDMAPManager account in AD. The password will be stored in the Samba “secrets.ldb” database, which hashes the password and is only readable by the “root” account. Once Winbind and the supporting components are configured, issue the following command at a shell (logged in as root) to finalize the Winbind setup: “net ads join -U administrator” This command will join the host to the AD domain (supplement “administrator” with any account granted the necessary rights to join computers to the AD). To start and test Winbind, type “winbindd” at the shell prompt (as root). To validate that Winbind is correctly seeing the domain, type “wbinfo –g” at the shell prompt; this should enumerate and print to screen all the groups in the AD domain (for further “wbinfo” options, type “wbinfo” at the shell). To validate authentication is functioning correctly, test logons through several different services including “ssh” and local login. To validate that IDMAP entries are being entered correctly in the Active Directory application partition, connect with an LDAP administration tool (e.g. LDP) or ADSIEdit to the AD Application Partition. Expand the IDMAP container (ou=IDMAP); there should be numerous entries similar to the example below.

Once testing is complete, and the configuration has been validated as working, add the Winbind daemon (winbindd) to the appropriate Unix/Linux run-level configuration (consult the OS specific documentation for assistance with this step). To configure Winbind to use LDAP SSL for connections, add the following line to the “smb.conf” configuration file: ldap ssl = on Also change the idmap backend value to include an “s” in the URL address as shown below: idmap backend = ldap:ldaps://FQDNofADDomainController

For more information see:

rectory Authentication Integration Using Samba Winbind (284KB PDF)

Samba WinBind Active Directory Schema Extensions