This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.
I’m not sure if it’s the gradual improvement in my Linux knowledge, better information on the ‘net, or just that integrating Windows and Unix systems is getting easier but I finally got one of my non-Windows systems to authenticate against Active Directory (AD) today. It may not sound like much of an achievement but I’m pretty pleased with myself.
Active Directory is Microsoft’s LDAP-compliant directory service, included with Windows server products since Windows 2000. The AD domain controller that I used for this experiment was running Windows Server 2003 with service pack 2 (although the domain is still in Windows 2000 mixed mode and the forest is at Windows 2000 functional level) and the client PC was running Red Hat Enterprise Linux (RHEL) 5.
The first step is to configure the Linux box to use Active Directory. I ran this as part of the RHEL installation but it can also be configured manually, or using system-config-authentication. The best way to do this is using LDAP and Kerberos (as described by Scott Lowe) but Scott’s advice indicates that would require some AD schema changes to incorporate Unix user information; the method I used is based on Winbind and doesn’t seem to require any changes on the server as Winbind allows a Unix/Linux box to become a full member of a Windows NT/AD domain.
The settings I used can be seen in the screen grab, specifying the Winbind domain (NetBIOS domain name), security model (ADS), Winbind ADS realm (DNS domain name), Winbind domain controller(s) and the template shell (for users with shell access), following which 
I selected the Join Domain button and supplied appropriate credentials and the machine was successfully joined the domain (an error was displayed in the terminal window indicating that Kerberos authentication failed – not surprising as it hadn’t been configured – but the message continued by reporting that it had fallen back to RPC communications and resulted in a successful join).
For reference, the equivalent manual process would have been something like:
- Edit the name service switch file (/etc/nsswitch.conf) to include the following:
passwd: files winbind
shadow: files winbind
group: files winbind
netgroup: files
automount: files
- Edit the Samba configuration file (/etc/samba/smb.conf) to include the following configuration lines in the
[global] section:
workgroup = DOMAINNAME
security = ads
password server = domaincontroller.domainname.tld
realm = DOMAINNAME.TLD
idmap uid = 16777216-33554431
idmap uid = 16777216-33554431
template shell = /bin/bash
winbind use default domain = false
- Edit the PAM authentication configuration (/etc/pam.d/system-auth) to append
broken_shadow to account required pam_unix.so and to insert:
auth sufficient pam_winbind.so use_first_pass
account [default=bad success=ok user_unknown=ignore] pam_winbind.so
password sufficient pam_winbind.so use_authtok
- Join the domain:
/usr/bin/net join -w DOMAINNAME -S domaincontroller.domainname.tld -U username
- Restart the winbind and nscd services:
service winbind restart
service nscd restart
It’s also possible to achieve the same results using authconfig (as described by Bill Boswell).
Once these configuration changes have been made, AD users should be able to authenticate, but they will not have home directories on the Linux box, resulting in a warning:
Your home directory is listed as:
‘/home/DOMAINNAME/username‘
but it does not appear to exist. Do you want to log in with the / (root) directory as your home directory? It is unlikely anything will work unless you use a failsafe session.
or just a simple:
No directory /home/DOMAINNAME/username!
Logging in with home = “/”.
This is easy to fix, as described in Red Hat knowledgebase article 5367, adding session required pam_mkhomedir.so skel=/etc/skel umask=0077 to /etc/pam.d/system-auth. After restarting the winbind service, the first subsequent login should be met with:
Creating directory ‘/home/DOMAINNAME/username‘
The parent directory must already exist; however some control can be exercised over the naming of the directory – I added template homedir = /home/%D/%U to the [global] section in /etc/samba/smb.conf (more details can be found in Red Hat knowledgebase article 4760).
At this point, AD users can log on (using DOMAINNAME\username at the login prompt) and have home directories dynamically created but (despite selecting the cache user information and local authorization is sufficient for local users options in system-config-authentication) if the computer is offline (e.g. a notebook computer away from the network), then login attempts will fail and the user is presented with the following warning:
Incorrect username or password. Letters must be typed in the correct case.
or:
Login incorrect
In order to allow offline working, I followed some advice relating to another Linux distribution (Mandriva disconnected authentication and authorisation) but it still worked for me on RHEL. All that was required was the addition of winbind offline logon = yes to the [global] section of /etc/samba/smb.conf along with some edits to the /etc/pam.d/system-auth file:
- Append
cached_login to auth sufficient pam_winbind.so use_first_pass.
- Add
account sufficient pam_winbind.so use_first_pass cached_login.
These changes (along with another winbind service restart) allowed users to log in using cached credentials (once a successful online login had taken place), displaying the following message:
Logging on using cached account. Network ressources [sic] can be unavailable
Unfortunately, the change also prevented local users from authenticating (except root), with the following strange errors in /var/log/messages:
May 30 11:30:42 computername pam_winbind[3620]: request failed, but PAM error 0!
May 30 11:30:42 computername pam_winbind[3620]: internal module error (retval = 3, user = `username')
May 30 11:30:42 computername login[3620]: Error in service module
After a lot of googling, I found a forum thread at LinuxQuestions.org that pointed to account [default=bad success=ok user_unknown=ignore] pam_winbind.so as the culprit. After I removed this line from /etc/pam.d/system-auth (it had already been replaced with account sufficient pam_winbind.so use_first_pass cached_login), both AD and local users could successfully authenticate:
May 30 11:37:25 computername -- username[3651]: LOGIN ON tty1 BY username
I should add that this configuration is not perfect – Winbind seems to take a minute or so to work out that cached credentials should be used (sometimes resulting in failed login attempts before allowing a user to log in) and it also seems to take a long time to login when working offline, but nevertheless I can use my AD accounts on the Linux workstation and I can log in when I’m not connected to the network.
If anyone can offer any advice to improve this configuration (or knows how moving to a higher domain/forest functional level may affect it), please leave a comment below. If you wish to follow the full LDAP/Kerberos authentication route described in Scott Lowe’s article (linked earlier), it may be worth checking out Microsoft Services for Unix (now replaced by the Identity Management for Unix component in Windows Server 2003 R2) or the open source alternative, AD4Unix.
