Active Directory Authentication using LDAP

This guide will give instructions on how to add a Linux client into an existing Windows forest with open source utilities on the Linux clients. The topology in this guide is assumed to be very simple, so in real life things may be a bit more complicated. However, the ingredients are discussed here.

The target of this guide is receive uid/gid information from the Active Directory and mount the Windows shares, so the Linux machine no longer is an 'island'.

Introduction
There are 2 ways to get authentication (uid/gid) data from Active Directory:

Windows Server Configuration
First of all, adsiedit.msc is your friend. If you dont have it installed already, it can be installed from your Windows CD-ROM\Support\Tools\SUPTOOLS.msi. You can use it to set attributes. Contact your Server sysadmin for more information.

Note that not all of these changes are required. For testing, you should at least have an active user with the correct set of attributes and an allocated share on the AD. The Windows server should also have Services for Unix or a similar extension to the schema installed.

For secure TLS communication also a Certificate Server should be configured and in use.

Schema Changes
When installing Windows 2003 Server R2 onto your domain controllers you should have already done a schema upgrade in that process. If you are not using R2 then you will need to download MicrosoftServices for Unix 3.5 (SFU). This document specifically focuses on the use of R2 not SFU. Most of the concepts are similar, but the NSS mapping of attributes will be different. These schema changes are used later on in this section to map Active Directory user attributes to UNIX attributes.

Object management
As is the case with any other authentication mechanism, we need to configure the user objects for the users that are to use the system. However, if you are implementing this solution, more than likely your users already have Windows accounts. In that case, all we need to do is to modify the objects to be POSIX compliant.


 * 1) Open the Active Directory Users and Groups management tool.
 * 2) *Modify a group object to function as a POSIX group.
 * 3) *Right-click on the user group for assignment of a GID.
 * 4) *Click on the Unix Attributes tab.
 * 5) *Populate the NIS Domain dropdown and the GID number as appropriate.
 * 6) Modify a user object to function as a POSIX user.
 * 7) *Locate and activate the tab that says Unix Settings.
 * 8) *Under Unix Settings, set the UID and GID for the user, as well as the home directory location (on the Linux filesystem /home/).
 * 9) *Reset the user's password. This causes the AD password and the Unix password attributes to synchronize.
 * 10) Add the user as a Unix member of the group.
 * 11) *After you have added the user as a Unix user, you will also need to come back to the group properties and add the user as a member on the Unix Attributes tab. Otherwise, the user will not be populated in the msSFU30PosixMember attribute.
 * 12) This user should now be able to authenticate onto the Linux machine via any desired mechanism, including an SSH session.

One thing that can sometimes cause problems authenticating is to have the POSIX home directory be unavailable or not exist. Either you can create the directory manually, or you can run a script to collect the home directories and ensure that the directory exists.

Modifying existing user accounts
This batch lists all objects within the UNIT..

This VBScript gets / sets the unix attributes for all users within one OU. It tries to set the uidNumber by the numbers it extracts from the user's cn attribute field. If it is not found, it uses the number set in freeUidNumber and increases the variable. The script has to be run separately for each OU. The script can easily be modified to suit your needs. This was written for actual deployment, and seemed to produce good results. For future accounts it is advisable to generate the attributes automatically when new accounts are created; that is beyond the scope of this document.

This script can be run from the Windows command line by calling it with cscript.exe.

> cscript mod_unix_attributes.vbs --set --unit staff --fake

Defining a share
Go to start-settings->control panel->administrative tools->domain controller security policies

Then local policies->security options->Microsoft Network Server: Digitally sign communications (always). Check Define this policy and select the Disabled radio button, then click apply then ok.

Create a folder c:/share and share it, call it "share" Create a normal user and assign his home folder under share.

Disable AD's World Readable Password Hashes
On my brand new default install of Active Directory with SFU (I imagine this is for R2 as well) I noticed that the unix password hashes, the msSFU30Password or unixUserPassword attributes, are readable for all users by any authenticated user! Unacceptable. After much searching I discovered, via the adsiedit.msc tool, that these rights were being granted at the top level of the domain to the Pre-Windows 2000 Compatible Access group and inherited to the users. The quick and easy fix for me was to simply remove the only member of that group, the Authenticated Users group. After this the Default Security settings (view/change-able from the Active Directory Schema mmc snapin) for User objects only allowed Administrators, Account Operators, SYSTEM, and SELF to view them (as well as most other attributes). I figure this is good enough, since if you're admin account(s) are compromised you've got more to worry about than a rogue user being able to download all password hashes.

Another solution would be to modify the msSFU30Password/unixUserPassword attribute from adsiedit.msc and set the searchFlags attribute to 128. More info on this available here: How the Active Directory Schema Works I haven't tested this one yet, but it seems to accomplish the same thing.

I don't think these problems exist for the unicodePwd attribute at all.

Changing the strong password policy

 * 1) Click on Security Settings > Account Policies > Password Policy.
 * 2) Right-click on Minimum password length in the right pane.
 * 3) Click Properties from the context menu.
 * 4) Do not remove the check from the Define this policy setting checkbox!
 * 5) Enter a new minimum password length. Entering a Zero (0) will remove the password requirement.
 * 6) Click the OK button.
 * 7) Double-click on Passwords must meet complexity requirements in the right pane.
 * 8) Do not remove the check from the Define this policy setting checkbox!
 * 9) Select the Disabled option. (This will allow simpler passwords.)
 * 10) Click the OK button.
 * 11) Close the Default Domain Security Settings window.

Now, you need to put the new Password Policy into effect.


 * 1) Click Start > Run... ; Type cmd into the "Open:" input box ; Click the "OK" button.
 * 2) Type: gpupdate /force

Configure the certificate server
You will need to install at least one Microsoft Enterprise Certificate Server and allow automatic computer enrollment for the domain, or at least the domain controller. Under Start > Control Panel > Add or Remove Programs > Add/Remove Windows Components:


 * 1) Install the IIS Service
 * 2) Install the CA Service
 * 3) On the CA Type page, click Enterprise root CA, and then click Next.
 * 4) On the CA Identifying Information page, in the Common name for this CA box, type the name of the server, and then click Next.
 * 5) On the Certificate Database Settings page, accept the defaults in the Certificate database box and the Certificate database log box, and then click Next.
 * 6) You will get a prompt to stop Internet Information Services, click Yes.
 * 7) Enable Active Server Pages (ASPs), by clicking Yes.

Turning off SMB signing
There are three steps:


 * 1) Disable SMB policies in the 'Default Domain Controller Policy".
 * 2) Disable SMB policies in the 'Default Domain Policy'.
 * 3) Apply the policies to the server and the workstations.

The four settings in each policy are:


 * Microsoft Network server: Digitally sign communications (always) - Disable
 * Microsoft Network server: Digitally sign communications (if client agrees) - Disable
 * Microsoft Network client: Digitally sign communications (always) - Disable
 * Microsoft Network client: Digitally sign communications (if server agrees) - Disable

Open Default Domain Controllers Policy from the Administrative tools. Right click on Local policies and expand security options. Change the policy by double-clicking on it. Once you have changed the settings in the 'Default Domain Controllers Policy' you must do this also for the 'Default Domain Policy'.

Once done, you either need to reboot the server twice, or push the policy application using 'gpudate /force /boot' and then reboot. Can check with "gpedit.msc" On Windows 2000 run "secedit /refreshpolicy machine_policy /enforce" and reboot.

Creating a LDAP browser user
To create a user for browsing the Active Directory, you need first to create a standard user using the Active Directory Users and Computers MMC. Define User cannot change password and Password never expires.

After the user has been created, you need to set the UNIX attributes for the user. Give it the UID and GID 499, with home directory /dev/null and shell /bin/false.

Allowing Anonymous Searches in Active Directory
To enable anonymous searches on your Active Directory, follow these steps:

Select "Create a custom task to delegate" and click "Next".
 * 1) On your Windows 2000 Active Directory server, run the Active Directory Users and Groups administration tool.
 * 2) Select the top level of the directory from the tree view in the left hand panel, and right click. A menu will appear. Select the first item, which should be "Delegate Control..."
 * 3) Click "Next"
 * 4) In the next window, titled "Users or Groups", click "Add ..."
 * 5) In the next list, select "ANONYMOUS LOGON" and click "Add". You may also need to select "Everyone" and the "Guests" group, depending on how you have Active Directory configured. Click OK when this is done.
 * 6) Click "Next"
 * 1) Click "Next"
 * 2) In the next list, select "Read". "Read All Properties" will be selected at the same time. Click "Next" when this is done.
 * 3) Click "Finish".

Kerberos clients
Kerberos is an authentication method developed in the 80's at Massachusetts Institute of Technology (MIT), US. The preferred implementation is MIT version 5. In Windows Server 2003, Kerberos policy is defined in the Default Domain Group Policy object and implemented by the domain’s KDC. Basically Kerberos allows users and services to demonstrate their identity to each other.

The key innovation underlying Kerberos is the notion that the password can be viewed as a special case of a shared secret--something that the user and the service hold in common, and which (again ideally) only they know. Establishing identity shouldn't require the user to actually reveal that secret; there ought to be a way to prove that you know the secret without sending it over the network. In the simplest case, the user takes something like a timestamp, and encrypts it with the shared secret key. If the user used the wrong key, the timestamp won't decrypt properly, and the service can reject the user's authentication attempt.

After the user sends an authentication request to the server, the server sends the user a two-part message. One part contains the user's credentials, the latter message the ticket granting ticket (TGT). TGT is good only for a fairly short period, typically eight or ten hours.

See for more basic information of Kerberos.

You may use this configuration file /etc/krb5.conf as the basis:

File: Minimum configuration of /etc/krb5.conf

[libdefaults] default_realm = OPENAD.LOCAL ticket_lifetime = 36000 renew_lifetime = 604800 clockskew = 300 [realms] OPENAD.LOCAL = { kdc = 192.168.0.30:88 admin_server = 192.168.0.30:749 default_domain = 192.168.0.30 } [domain_realm] .openad.local = OPENAD.LOCAL openad.local = OPENAD.LOCAL [logging] kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmin.log default = FILE:/var/log/krb5lib.log

Note: Do NOT use DNS names, use IP addresses and do NOT comment the config file because the kerberos client will not read the config file correctly. Do not change the case of OPENAD.LOCAL because the convention is to define realms in uppercase. The clockskew line indicates how sensitive kerberos should be for differences in times between the server and the client. You can increase this value but its best to ensure that server and client have the same time by using an NTP server.

Verify that reverse DNS lookups work, otherwise krb won't work with realms that have several domain controllers.

$ dig openad.local +short $ dig -x 192.168.0.30 +short <- repeat for each IP listed by the above command

Request a ticket to ensure you can contact the OPENAD realm:

$ kinit Administrator@OPENAD.LOCAL    <- YES, the case is IMPORTANT Password for Administrator@OPENAD.LOCAL:

It will ask for the password as shown above; if you type in correctly; then you will be returned to the prompt which means it worked. See troubleshooting if you receive any errors.

You can check the active tickets with the klist command and destroy them with kdestroy.

$ klist $ kdestroy

The tickets have a lifetime, usually less than a day. Within this time it is possible to use OpenLDAP or Winbind to get the records from the userbase. Each user issues a personal krb ticket before logging in.

Keytab: automatic ticket updating
Because the Kerberos ticket has a very short lifetime, and no one can login at the box from ldap without a valid system-wide ticket for LDAP (/tmp/krb5cc_0), we will create a cron job to update it. For this the password/encryption key has to be stored into the keytab where the cron job can read it.

Create a new user (for example krbcron_ ) for each Linux client in Active Directory. These Kerberos agents do not need any special attributes. Admit them the permissions to request Kerberos tickets and read the user attributes you need to map. You also need write access to the servicePrincipalName and userPrincipalName attributes, as well as change the password for the Kerberos agent. By default these attributes may not permitted to read/write. This user principal is then mapped to the particular client. It is not tolerable to create Kerberos Service Principal with the same name in more user accounts. In such case, Kerberos would not be able to authenticate it correctly.

Install the Support Tools package that has the ktpass utility. Save this small batch script (mapkeytab.bat) to your PATH on the Windows server.

@echo off


 * %1 is the username
 * %2 is the hostname
 * %3 is the realm

REM change the '*' character to the real password in case you want to loop this. REM else you will be prompted for the password.

ktpass -princ nssldap/%2@%3 -mapuser %1@%3 -pass * -out %2.keytab -ptype KRB5_NT_PRINCIPAL DesOnly -crypto DES-CBC-MD5

Test with one client, execute the script:

mapkeytab.bat krbcron_client21 client21 OPENAD.LOCAL

It should output something like this:

Targeting domain controller: openad.local Successfully mapped nssldap/krbcron_client21 to krbcron. Type the password for nssldap/krbcron_client21: Type the password again to confirm: Key created. Output keytab to krbcron_keytab: Keytab version: 0x502 keysize 55 nssldap/krbcron_client21@OPENAD.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 5 etype 0x3 (DES-CBC-MD5) keylength 8 (0xba1308b93ed97a54) Account krbcron has been set for DES-only encryption.

For several clients at once:

for %a in (21,22,23,24) do mapktpass krbcron_client%a OPENAD.LOCAL

Copy the files through some secure medium to the Linux box. If your keytab is empty, just rename the file:

mv krbcron_client21.keytab /etc/krb5.keytab chmod 644 /etc/krb5.keytab ; chown root /etc/krb5.keytab

Or use the command ktutil as follows:

ktutil: rkt krbcron_client21.keytab ktutil: list slot KVNO Principal ---  1    3 nssldap/krbcron_client21@OPENAD.LOCAL ktutil: wkt /etc/krb5.keytab ktutil: q
 * 1) ktutil

Create an init script to refresh the Kerberos TGT for the LDAP. After the execution, /tmp/krb5cc_0 will be updated.

TODO! Meanwhile, use this command:


 * 1) /usr/bin/kinit -k nssldap/krbcron_$HOSTNAME -c /tmp/krb5cc_0


 * 1) rc-update add krb5cron default

Set up your crontab to refresh your local service ticket cache every 10 hours using the keytab. Use the master ticket cache /tmp/krb5cc_0 so that the pam modules use the correct ticket. Later we will use another location for user tickets.

0 */10 * * * /etc/init.d/krb5cron

Note that this applies to any sort of unattended programs that you wish to run, not just cron. Of course, you have to evaluate whether or not this is acceptable to you; if the machine where you store this principal is compromised, then this principal is compromised.

Security and Certificate
Simple Authentication and Security Layer (SASL) is a standard that allows other protocols to use a wide range of extensible security mechanisms. SASL is security mechanism-independent. SASL-aware applications can use any security mechanism that is available on a specific platform and that has been complied into the SASL libraries. Cyrus-SASL is the layer between OpenLDAP and Kerberos.

During the bind phase, the client requests a specific security mechanism from SASL. OpenLDAP supports TLS and SSL. The client and server then use the SASL protocol to carry out any additional steps required by the agreed upon security mechanism.

The Start TLS operation establishes Transport Layer Security (the descendant of SSL) on the connection. It can provide data confidentiality protection (hide the data) and/or data integrity protection (protect from tampering). The START_TLS mechanism uses the standard ldap port (tcp/389) to negotiate using TLS after the connection has been initiated.

During TLS negotiation the server sends its X.509 certificate to prove its identity. The client may also send a certificate to prove its identity. After doing so, the client may then use SASL/EXTERNAL to have this identity used in determining the identity used in making LDAP authorization decisions.

Servers also often support the non-standard "LDAPS" ("Secure LDAP", commonly known as "LDAP over SSL") protocol on a separate port, by default 636. The LDAPS differs from LDAP in that it connects to a special port, ldaps (tcp/636). LDAP is a standard, and not less secure given that a secure TLS tunnel is used. The client and server establish TLS before any LDAP messages are transferred (without a Start TLS operation). The LDAPS connection must be closed upon TLS closure.

Fetching the Certificate
If you are running Microsoft Certificate Server on your Active Directory server, you can download the CA cert from http://You-IP-Address-or-NAME/certsrv/. If Firefox does not work with the ASP Scripts, you may try to use Konqueror to download the certificate on the Linux client. You should save it on your hard drive and move it to the appropriate location:

$ chmod 644 adcert.pem
 * 1) mv adcert.pem /etc/ssl/certs/

If your Active Directory server doesn't have certificate from Verisign, Thawte, etc., then you will need to convert the CA Certificate to PEM format:

$ openssl x509 -in certnew.cer -inform DER -out /etc/ssl/certs/adcert.pem -outform PEM

OpenLDAP configuration files
Once we are able to authenticate, the next step is to get the user information from the AD server. OpenLDAP has two configuration files:
 * /etc/openldap/ldap.conf for the LDAP client libraries and tools ;
 * /etc/ldap.conf (or /etc/libnss-ldap.conf) is used by the NSS and PAM.

LDAP client (/etc/openldap/ldap.conf)
First configure just the client side, so that user can use ldapsearch to test and debug basic connectivity.

The TLS_CACERT variable should point to the certificate you have obtained. TLS_REQCERT tells the client not to request the certificate since we have already installed it on the local client.

Testing the LDAP connection

Let's the check if the connection is working properly. Remember to always check out a valid Kerberos ticket if you don't run the cron job.

$ kinit Administrator@OPENAD.LOCAL

Your friends here are ldapsearch and s_client. You may test different things if the communication works, whether you can establish a secure tunnel and your certificate is ok.

If the admin account is unavailable, you may try to search rootDSE, for which the anonymous operation should be permitted. By default, the Windows Server 2003 Active Directory does not allow anonymous operations on the LDAP directory.

$ ldapsearch -x -s base -b ""

With a user account you should first try that the queries are working without SASL or TSL. Use the -W switch, or put your password into /etc/ldap.secret for a while (remember to remove it).

$ ldapsearch -Hldap://192.168.0.30 -b "" -s base -x -D "cn=Administrator,cn=Users,dc=openad,dc=local" -y /etc/ldap.secret

or try:

$ ldapsearch -Hldap://192.168.0.30 -b "" -s base -x -D "Administrator@openad.local" -W

If successful, you should receive an output describing the Active Directory LDAP description. If you cannot perform simple top level searches on your Active Directory, then you should locate and fix any problems.

If you receive GSSAPI errors, you may need to examine the reverse DNS settings or add some lines to your /etc/hosts. Invalid name errors are caused by a problem with the reverse DNS of the AD server. Generic errors can be caused by an invalid DNS of the client computer. Below is a sample /etc/hosts file - the order of records is important:

127.0.0.1      localhost.localdomain    localhost 192.168.0.31   ad_client.openad.local   ad_client 192.168.0.30   ad_server.openad.local

Once that works try with SASL but without TSL:

$ ldapsearch -Hldap://192.168.0.30 -b "" -s base -Omaxssf=0

Notice the '-Omaxssf=0' which should disable SASL security layers. This is also a feature with Active Directory: large queries with SASL will fail because Active Directory is not using the negotiated buffer size correctly. You can try this by omitting the switch and performing a large query. Ldapsearch should respond with, depending on the version and whether you are using TLS/SSL, "ldap_result: Can't contact LDAP server" or "ldap_sasl_interactive_bind_s: Inappropriate authentication".

You may also receive these errors (among others):

No credentials cache found: check (klist) that you have a valid TGT. GSSAPI Error: An invalid name was supplied: add the server to /etc/hosts. Cannot determine realm for numeric host address: check that reverse DNS works

If you use SSL, you can use the openssl s_client:

$ openssl s_client -connect openad.local:636 -CAfile /etc/ssl/certs/adcert.pem

Note: The host variable is the fully qualified domain name FQDN or IP address of the Active Directory you wish to authenticate against. We could list a number of domain controllers separated by a space, or we could just enter the domain name of which a domain controller would be returned from DNS. If you enable SSL, you will have to use the FQDN.

Finally, try with both SASL and TSL:

$ ldapsearch -Hldap://192.168.0.30 -b "" -s base -Omaxssf=0 -ZZ

If you get:

certificate verify failed. check your certificate status requirements.

Name Service Switch Module (/etc/ldap.conf)
Now as the LDAP client is working, you should move on to configuring the Name Service Switch module (nss_ldap). The are two configuration steps here: first one is rather easy- just add the keyword ldap to passwd, shadow, group in /etc/nsswitch.conf. Depending on your requirements, you may need to search other information from ldap as well, but this is sufficient for user accounts.

This can be mitigated by adding nss_reconnect_tries 2 to /etc/ldap.conf. This will cause a small delay (8-16 seconds by default).

The nss_ldap module contains the real magic, and can be configured in many different ways depending on your requirements. This configuration example is written to use SASL+TLS security layers and obtain users from the AD that have attributes set by the Server for NIS extension.

Let's first examine the connection section of this file. Stay away from spaces, LDAP doesn't like them.

Base is used to define where in Active Directory to start looking for objects. This is good if you want to limit the ability of only certain users contained within a certain set of OUs to have the ability to login to a Linux workstation, or if you have a huge LDAP, less information is carried over the network.

The scope attribute confines the search to the base, one level below, or to search through all lower levels. This is done by entering the word base, one, or sub.

Binddn is not needed with SASL, but left here for posterity. Without a secure communication, a bind user is required in order to query the LDAP contents. This account is just a domain user with read access. The password for this user should be written to /etc/ldap.secret and should not be world-readable.

Attribute Mapping
Next you will need to map some nss attributes, as the local unix LDAP attributes differ from what the attributes are called at the Windows server. The unix attribute names vary slightly on different version of the SFU packages, so these may not work out-of-the-box. You need to either have a print of your test users' attributes, or have access to one of the domain controllers, preferably with permissions to modify the attribute values.

The config file is continued with attribute bindings:

The nss_base_passwd, nss_base_shadow, and nss_base_group will all need to be changed to suit your enviroment. In general, you can just use the value of the base variable. If your Active Directory authenticates for a sub-domain, you will need to adjust accordingly.

The userPassword line is not necessary when pam_password is set to ad. In this case, the pam_ldap module controls the management of password functions using the Active Directory password stored in the unicodePwd attribute. This will be covered later.

More information of the AD attributes that can be mapped, for various purposes, are found at and.

Now getent should enumerate all user accounts and groups within the files, and then append all Active Directory accounts that have the correct UNIX attributes.

$ getent passwd aduser aduser:*:10002:10000:test user:/home/OPENAD/aduser:/bin/bash

You can get the full attribute list for a user with ldapsearch:

$ ldapsearch -b "ou=users,dc=openad,dc=local" -s one "(cn=aduser)"

LDAP Attributes ( /etc/ldap.conf )
In order to make PAM_LDAP talk to Active Directory, you must map a few more Unix attributes to their equivalent Active Directory names. The configuration file is the same as for the NSS module, so it may be called on other distros than Gentoo.

Pam_login_attribute defines what username the user will use to logon with. To ensure consistency with Active Directory and Services for UNIX, you use the sAMAccountName attribute. Pam_filter allows us to filter out just user accounts so that we are not trying to authenticate users against other Active Directory objects. Lastly, pam_password which allows us to define the password to be for Active Directory. This must be set to ad, otherwise issues may arise when you attempt to change your password from the Linux workstation.

Groups
Logins validated by the Windows server won't correctly pickup membership in local groups, making sound, USB devices, etc. inaccessible. To fix that configure the pam_group module.

Login files
There are several login files, their names are corresponding to the names of the programs, which are performing the user authentication. These files are located in the directory. The common configuration file is ignored when these files exist.

You may configure everything by plain file, but that may mess up how other modules do their work. More common way to accomplish this is to make login to use the common-* files. Do not copy these files as-is, although it may work. Merge the necessary lines into your working setup, and adjust as needed. Pam_mount is already introduced here, and it requires it has been setup properly. See section 4: network shares.

Note that when you make changes to, you have to wait for a while (15 seconds or so) for the login manager to notice the changes. Knowing this will help you a lot if you make changes. :) Note: Make sure you keep at least one root login open while making changes to these files, and have a livecd at hand. You may accidentaly lock yourself out of the system.

The 'sufficient' control token, when successful, permits access, even if the authentication from a previous 'required' module in the stack failed. The try_first_pass parameter is instructing the pam module that the password supplied to the previous pam module should be tried first. This way the user will not be invoked another prompt asking for the password. To debug the pam modules, you can also add the debug parameter, which will cause logging of the debug messages into /var/log/auth.log.

The PAM docs say that "use_first_pass is used to lock the choice of old and new passwords to that dictated by the previously stacked password module," and that "use_authtok is used to force the module to set the new password to the one provided by the previously stacked password module." So use_authtok is designed to have the module use the new password but request the old one directly from the user. The reason for this option is that it is convenient when you use a password strength checking module like pam_cracklib.


 * required is equivalent to [success=ok new_authtok_reqd=ok ignore=ignore default=bad]
 * requisite is equivalent to [success=ok new_authtok_reqd=ok ignore=ignore default=die]
 * sufficient is equivalent to [success=done new_authtok_reqd=done default=ignore]
 * optional is equivalent to [success=ok new_authtok_reqd=ok default=ignore]

Now go to the console and login with an AD username. If it doesn't work immediately, wait for a minute or two. Pam_login should mount your AD directory automagically.

client21 login: aduser password: You must be a msSFU30PosixMember of cn=Users,dc=openad,dc=local to login. login(pam_unix)[14441]: session opened for user aduser by (uid=0) pam_mount: realpath of volume "/home/OPENAD/aduser" is "/home/OPENAD/aduser" login[14441]: pam_mount: realpath of volume "/home/OPENAD/aduser" is "/home/OPENAD/aduser" pmvarrun: parsed count value 0 aduser@client21 ~ $ df Filesystem          1K-blocks      Used Available Use% Mounted on /dev/hda3              8372704   4653376   3294008  59% / udev                   256772       160    256612   1% /dev shm                    256772         0    256772   0% /dev/shm //win2003/aduser     15358136   5383352   9974784  36% /home/OPENAD/aduser

Sudo and nscd
To enable ldap users easy access to sudo, the sudoers table needs to contain the user group (LinuxUsers) in the AD. Sudo reads the entries from Name Service Cache Daemon (NSCD) that sits between the applications using name services and the mechanisms providing those name services. It caches name service data and improves response times.

Without NSCD, an application makes a call to one of the standard libc function calls: getxxnam, getxxuid, getxxent, and getxbyy. NSS then dynamically loads the correct module for the name service mechanism specified in. With NSCD, the application still makes the same call, but now the corresponding libc function actually calls NSCD through an Inter-Process Communication (IPC) call. If NSCD has cached the data required by the application, it returns it; otherwise, it calls the NSS module in the usual way.

Turn nscd on and put it to your chosen runlevel, after you have obtained the Kerberos ticket. The default configuration is ok, although for a large LDAP you may want to raise the passwd database size to a few megabytes.

Then edit sudoers as you see fit:

Joining the Domain
This is quite simple, if you have configured Samba properly. You can use this example samba configuration /etc/samba/smb.conf as a base to work on: Note: This smb.conf will setup uses OPENAD.LOCAL as the name of the AD domain, with WIN2003 being the server.

Run testparm to see if your syntax is ok.
 * 1) testparm

Since Samba version 3.0.23, there is no need to enter the administrator password for joining the domain. The net command can do a whole lot of things, but this is sufficient to join the domain. Run this on the Linux box as root:
 * 1) net ads join

Mounting Network Shares with Samba
In order to access any files on the Windows server, you need to configure Samba. Use the configuration presented in previous chapter to work on.

On your Linux machine, you should be able to connect to Windows shares using Samba’s smbclient without a password (thanks to Kerberos). To test this, type

You should then be at an smbclient prompt: smb: >

If you re-defined the share. Default share is c$, which is the C:\ drive root. If you can browse the share at this point, good. Exit.

To virtually mount a windows share to a point on your samba server is not so simple. That's why this process is presented here in the form of a walkthrough, errors and all. By default, Windows servers (2003 at least) uses SMB signing, which is not resolved by the Samba folk in the 3.0 version. (4.0 is in the makes, preview was published a while ago - it could be in that version but it won't be out for the public before 2007 anyways).

cli_negprot: SMB signing is mandatory and we have disabled it. 32453: protocol negotiation failed SMB connection failed CIFS as an alternative that works:
 * 1) mkdir /mnt/win2003
 * 2) smbmount //win2003/c$ /mnt/win2003/
 * 1) user=Administrator;
 * 2) mount -t cifs //win2003/share /mnt/win2003/ -o username=$user,uid=$user,dir_mode=0700

Without SMB signing

In case CIFS doesn't work and you control the server we'll disable SMB signing. This is a Group Policy in Windows Server and the instructions are given up there where the other Windows configuration tasks are mentioned. So let's turn those options off at the server (in case you don't control your server, try out CIFS). Then mounting should be possible:


 * 1) user=Administrator;
 * 2) mount -t smbfs //win2003/share /mnt/win2003/ -o username=$user,uid=$user,gid=$user,dmask=0700
 * 3) ls /mnt/win2003

$HOME auto-mounting
The next step is to mount various users' home directories into /home/DOMAIN/$user. It seems that you cannot mount a sub-directory under a share with Samba, so depending on your AD server-side directory structure and naming conventions, use the --bind option of mount to re-mount a sub-directory of the mounted share to the individual user's home folder.

This really isn't very elegant so that's why we need to call each share on the Win2003 server by the users name. This way we can call the users share with pam_mount when user logs in.

Here are the necessary config files:

Note: pay attention to the cifsmount command; the default syntax in version 0.12.0 is incorrect.

Modify your login files.

Network File System (NFS) with Kerberos
This section describes, how to use kerberos for a strong authentication and integrity with NFSv3 and NFSv4. It is not a general explanation on how NFSv3 and NFSv4 are working.

Packages
The following packages are required for kerberized NFS:


 * : User space components of NFS
 * : Automatic ticket renewing system
 * : To use POSIX Acccess Control Lists (Optional)

Kernel Options
These kernel options are required to get the kerberos support for the NFS server

Either you have to Build-In the Kerberos V mechanism or as a module. If you you build it as a module, you have to load the rpcsec_gss_krb5 and auth_rpcgss at system boot.

User mapping
On the Domain Controller from the Active Directory you have to create a new user each for the client (nfsad_client) and the server (nfsad_server).

After creating this new user, you have to map the nfs service for each machine onto the user. For the client: ktpass.exe /princ nfs/ad_client.openad.local@OPENAD.LOCAL /mapuser nfsad_client /pass * /out keytab_nfsad_client /ptype KRB5_NT_PRINCIPAL DesOnly /crypto DES-CBC-CRC

And for the server: ktpass.exe /princ nfs/ad_server.openad.local@OPENAD.LOCAL /mapuser nfsad_client /pass * /out keytab_nfsad_client /ptype KRB5_NT_PRINCIPAL DesOnly /crypto DES-CBC-CRC

The created keytab entries has to be copied in a secure flavour onto each machine and added to the machines keytab list /etc/krb5.keytab with ktutil, as described earlier.

Make sure, that you are using "Fully Qualified Domain Names" (FQDN) and that the host entries in /etc/hosts are setup correctly, with these FQDN's. For more information see this documentation.

Automatic Ticket Renewing
In order to renew the tickets for the NFS service, you have add the following line to the file:

Not only the system kerberos tickets have to be renewed, even each user need valid tickets. In order to do that, you can use krenew. This can be done with a shell script, while user login:

Each user has to execute this script in his. The is executed at login into tty, ssh and KDE. So every user needs to add the following line:

And at logout the krenew process should be stopped. This can be done with the bash script:

The following line has to be added to the :

Take care, that the init_krenew.sh and stop_krenew.sh has executable rights (chmod +x).

In order to stop the krenew process at logout from KDE 4, the following line has to be added, to the file:

Starting up Services
Now the services can be started. On the server the rpc.svcgssd daemon has to be started:

/etc/init.d/rpc.svcgssd start && rc-update -a rpc.svcgssd default

And on the client you have to startup the rpc.gssd daemon:

/etc/init.d/rpc.gssd start && rc-update -a rpc.gssd default

Check carefully the /var/log/messages for errors.

NFSv3
This subsection describes, how to use NFSv3 with kerberos.

Exports
For NFSv3 with krb5 you will need two lines in /etc/exports for one export. The second line is used for mounting the export. Because, the NFSv3 client is not capable of mounting kerberized NFSv3 exports. With the first line, the authentication and integrity checks are performed. In order to have full authentication and integrity working, the exported directory should have set no rights for others, for example 750.

Mounting
To mount the kerberized NFSv3 export, you will need the extra option krb5i. The filesystem type is nfs.

mount -t nfs 192.168.0.30:/export /mnt/export -o sec=krb5i,acl

Auto-Mounting at Startup
To automount this export at startup, you have to add the following line to the /etc/fstab:

Known Problems
If the home directory is exported as a kerberized NFSv3 export and has 750 rights, some programs seem to have problems:

Firefox & Co.: If the directories with the personal settings has no rights for others, firefox, thunderbird and sunbird doesn't startup with the Firefox is still running error message. In order to avoid this behaviour, you should set at least the execute bit for others:

chmod -R 711 $HOME/.mozilla && chmod -R 711 $HOME/.thunderbird

OpenOffice: The following lines (43-44) in /usr/lib/openoffice/program/soffice have to be commented:

is known to not working with a kerberized NFSv3 exported home directory.

It seems, that all programs, that uses lock files have problems with with a kerberized NFSv3 exported home directory.

NFSv4
This subsection describes how to use NFSv4 with kerberos. [edit] Exports

The NFSv4 client is able to mount directly kerberos exports. So you will need only one line in the /etc/exports:

Mounting
To mount the kerberized NFSv4 export, you will need the extra option krb5i. The filesystem type has changed to nfs4.

mount -t nfs4 192.168.0.30:/ /mnt/export -o sec=krb5i,acl

Auto-Mounting at startup
To automount this export at startup, you have to add the following line to the /etc/fstab:

$HOME Skeleton
Users can have a preconfigured $HOME from the local skeleton, if you include the right session line:

/etc/pam.d/common-session:session    required      /lib/security/pam_mkhomedir.so skel=/etc/skel/ silent

The contents of /etc/skel/ will be copied as the base for the user's $HOME. Set custom files here. You can pre-configure window managers, desktop environments, .bashrc, applications and so on this way.

Running Scripts at Login
As users may login via the console or X, different files are evaluated during those processes. If you use GDM, you may consider putting the call for your scripts at /etc/gdm/Xsession. It is not convenient to put lengthy scripts, or scripts that should be only run once, in $HOME/.bashrc. It could be that the user doesn't even open up a bash session. For console and ssh logins you may want to use $HOME/.bash_profile, if you are using the bash or $HOME/.login, if you are using the tcsh, to execute startup scripts. Both scripts are also sourced from /usr/share/config/kdm/Xsession at logon if you are using KDM.

Running Scripts at Logout
To run scripts at console or ssh logout you can use $HOME/.bash_logout to execute these scripts. If you are using KDM, you have to modify /etc/kde/shutdown/agent-shutdown.sh to execute scripts at logout.

Evolution Email Client
As Evolution-2.6.0 doesn't have an LDAP backend, the user account have to be set with separate tools. Evolution uses the ~/.gconf/apps/evolution directory to store this data. I suggest using evolution-gconf-tools to do this job. The version 0.2.0 supports LDAP searches. The author of this article has made changes to this package, and the changes haven't been accepted upstream yet (the original author hasn't responded to my emails).

TODO: link for the package.

Simply edit /etc/gconf/evolution-gconf-tools/configure and run evolution-gconf-setup-user.

Troubleshooting
If you've gotten this far and everything works, your Linux client is now a fully-fledged member of your Active Directory domain, and can be managed like any other AD object. A nice bonus is you may have local Linux accounts on the Samba box that are not visible in Active Directory; which means your Linux admins can SSH directly into the client for admin chores, and not have to fuss with AD roadblocks.

This chapter tries to tackle with common problems that may appear during the configuration phase.

On a Red Hat system, PAM_LDAP is part of the NSS_LDAP RPM. PAM_LDAP by default uses the same configuration file (/etc/ldap.conf), so all of the nss_ldap changes work also for pam_ldap

Note that PAM_LDAP is only used for authentication, whereas NSS_LDAP is used for all user information. A user can still log on to a Linux system without NSS_LDAP working, although they will get frequent messages saying "I have no name!". If this is happening to you, then it is possible that you have PAM_LDAP working correctly but NSS_LDAP broken.

On some recent Debian systems, PAM_LDAP and NSS_LDAP have different configuration files. I am not entirely convinced of the wisdom of this, but it could be useful in certain situations, and for debugging purposes. If you are on such a system, it would be wise to locate all files containing the name "ldap.conf" on your system and work out which of these belong to PAM_LDAP and which belong to NSS_LDAP.

Note that to be able to change passwords on an Active Directory server from Linux, you need to have SSL and TLS enabled, both at the client end and at the server end. Enabling SSL and TLS on an LDAP client is covered in the SecurityFocus article, Linux Authentication Using OpenLDAP, Part One.

Read the info in here for more things you can do with other authentication with AD.

A good troubleshooting guide is chapter 9 of "Samba-3 by Example" (Adding UNIX/LINUX Servers and Clients). Also refer to chapter 12 (Identity Mapping) of "The Official Samba-3 HOWTO and Reference Guide" to learn about winbind in greater depth.

First of all, check that the Linux and Windows computers have the same clock time. They must be 5 minutes apart, at most. Run ntp-client and use the domain-server as the time server.

See for a list of Kerberos error messages. Some errors you might encounter:

kinit(v5): Preauthentication failed while getting initial credentials

Solution: Might just fix after you wait for a few minutes. :)

Solution: Make sure that the Kerberos Ticket on the Windows Server was created with the correct mapping and service.

kinit(v5): Cannot resolve network address for KDC in requested realm while getting initial credentials

Solution: Check /etc/krb5.conf.

KDC has no support for encryption type

Solution: Try resetting the Administrator password in Active Directory as it's possible AD has not generated DES keys for the Administrator principal (reference: http://lists.samba.org/archive/samba-technical/2003-July/030726.html)

SMB signing

cli_negprot: SMB signing is mandatory and we have disabled it. 17352: protocol negotiation failed SMB connection failed
 * 1) mount -t smbfs -o username=Administrator //win2003/c\$ /mnt/samba/

Solution: Like mentioned above, smbfs *is not* compatible with SMB signing, and therefore cannot be used with win2k3 DCs in their default mode. Use mount -t cifs.

samba/secrets

$ net ads join Failed to open /var/lib/samba/secrets.tdb

Solution: sudo chmod 777 /var/lib/samba/secrets.tdb

READERS NOTE: The above solution seems like an unnecessary compromise in security. Try running "net ads join" as root. (A root prompt would end in a '#' and not a '$' as above!)

authtok errors from pam_mount

Solution: This is because you have a sufficient line in one of the PAM files within /etc/pam.d and pam_mount.so can not be used after a sufficient line. This error isn't fatal and is skipped. You'll probably notice it if you su and then su again (it's because of the pam_rootok.so line within /etc/pam.d/su)

id: cannot find name for user ID 1001

This is because your Active Directory cannot be searched anonymously. There are two solutions for this problem:

1. . Enable anonymous searches on your Active Directory 2. . Insert an administrator DN and password into /etc/ldap.conf

GSSAPI Error: No credentials cache found

This might occur after successful login, after ldappasswd. Solution: This means you are doing a SASL bind to the server, and you have no K5 ticket to authenticate you with for GSSAPI. Request a ticket.

GSSAPI Error: Cannot start kerberos signing/sealing when using TLS/SSL

SASL/GSSAPI already encrypts the LDAP traffic, this error is trying to say TLS/SSL is redundant.

TODO
Please finish this section if you find the HOWTO helpful.

Windows printers
See

Mounting a Linux share
The /etc/smb.conf file in our case, sets up the home directory as a share. To mount my home directory from a Windows machine on the DC03 domain, I do this:
 * Log onto the Windows machine as user "fredrick".
 * Select Run from the start menu and enter "\\acdsmb-doctor\fredrick".

Everything worked. I was not prompted for a password when connecting to the Samba share. This is because the initial authentication to the domain granted the Windows machine a ticket which is then used for subsequent share connections on the domain including those with Samba environments that have been joined to the domain.

Official Samba Documentation

 * http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/domain-member.html#domain-member-server
 * http://us1.samba.org/samba/docs/man/Samba-HOWTO-Collection/winbind.html
 * - The samba/ADS HOWTO
 * - Helpful info for winbind

Windows Server

 * Windows Server 2003 Setup Guide
 * Change the strong password policy
 * Group policy management extension

Information on the WWW

 * Active Directory authentication for Linux - an excellent tutorial to LDAP-based authentication
 * Active Directory and nss_ldap for Linux - quite helpful
 * elkabong's blog - Linspire Client Configuration Files
 * Active Directory and Linux - AD4Unix + LDAP
 * How to integrate Samba into Active Directory - forums.gentoo.org
 * Configuring Unix to use Active Directory - from an MKS AD4Unix Schema extension point-of-view
 * Setup Linux to authenticate against a Samba server - pam configuration
 * Authorization with LDAP - a short article
 * linux client/Active Directory server home directories A thread with people solving other people's problems
 * Unite your Linux and Active Directory autfag.com/columns/article.asp?EditorialsID=858 Linux-Windows Single Sign-On - at Redmond, US
 * http://www.intraperson.com/autodir.html
 * Join Samba 3 to Your Active Directory Domain

Helpful Software

 * sadms
 * Samba4 release notes

Original Article
The original author for the winbind section is James Young: How to integrate Samba into Active Directory

Need an alternative solution that is easier to configure? pam_krb5+ldap to authenticate linux clients against active directory and/or openldap

Аутентификация в Active Directory используя LDAP