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:
- Edit the Samba configuration file (/etc/samba/smb.conf) to include the following configuration lines in the
[global]
section: - Edit the PAM authentication configuration (/etc/pam.d/system-auth) to append
broken_shadow
toaccount required pam_unix.so
and to insert: - Join the domain:
- Restart the winbind and nscd services:
passwd: files winbind
shadow: files winbind
group: files winbind
netgroup: files
automount: files
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
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
/usr/bin/net join -w DOMAINNAME -S domaincontroller.domainname.tld -U username
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
toauth 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.
One thing that I didn’t make clear in the original post is that
system-config-authentication
has tabs for user information and for authentication. The authentication tab is the one that is required in order to allow Active Directory users to log on to the Linux box via Winbind. Kerberos support can also be configured here, if required.hi Mark.. i have gone through ur blog regarding joining of linux box as ADS 2003 domain member…but not gettin the result as you explained…..
Could you help me out if I send my configuration file.
Thanks and regards
Manabjyoti saikia
Hi Manabjyoti – unfortunately I’m not in a position to offer support (I’m already pretty maxed out with my day job) but hopefully these pointers will help:
I hope something here provides the answer you are looking for – otherwise try one of the big Linux forums – somewhere like LinuxQuestions.org.
Thanks for your reply Mark………..I will follow your suggestion…….
But let me tell you about my prob…..
Everything going fine as you mentioned….except when I tried to log in as domain user in my linux sys. I got “login incorrect” instead of home directory missing message….
Anyway thanks for your support….
Thanks and regards
Manabjyoti
Thanks for the guide. It was very useful. One thing I have discovered is that the minute delay in logging in using cached credentials does not occur if you do a “smbcontrol winbindd offline”, at the CLI.
Maybe you could add a cron job to your laptop to test the reachability of the AD server, and switch between offline and online modes based on that? I haven’t tried this out myself yet, but I would think it would work pretty well.
Nice idea Dan – I’ll give that a shot (and glad it worked for you!)
Much thanks for the guide. This guide is by far the most useful and most accurante (for RHEL 5 users anyway).
I do have to point out an issue though, on your Samba configuration in Step 3 you have the following:
“winbind use default domain = false”
This makes it so that the user has to log in as DOMAIN\user instead of just using the user without specifying the domain.
The pros of setting this value to false is are:
1. The user doesn’t have belong to the realm specified in the smb.conf to authenticate. The user may exist in a child domain and still authenticate by specify thier Domain\ when logging in.
The cons are:
1. More keys to type.
2. If ever, the user needs to run scripts, services, etc. as thier user, they will deal with bash errors because the shell cannot deal with “\” character.
In any case, this is all based on the Domain Structure the user has as well as preference. On another, note I do have this issue that I cannot get across. Whenever logging via ssh using putty I get the following error:
“id: cannot fine the name for group ID 10000”
It doesn’t seem to cause an issue as far as I can tell but I would like to know how to get around that.
Thanks!
Victor.
@Victor – I’m glad you found this useful – and thanks for the extra information! I haven’t seen that
ssh
error though – sorry I can’t help.Great Post. Worked Perfectly for me. Also I am authenticating to a windows server 2008 machine which confirms that this works with domain controllers above windows 2000
Thanks a lot man :-)
urs tutorial+session required /lib/security/$ISA/pam_mkhomedir.so skel=/etc/skel umask=0077
tested successfully on Centos 5.3 without errors
Cheers