Using Active Directory to authenticate users on a Linux computer

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.

Winbind settingsThe 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 Winbind join 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:

  1. Edit the name service switch file (/etc/nsswitch.conf) to include the following:
  2. passwd: files winbind
    shadow: files winbind
    group: files winbind
    netgroup: files
    automount: files

  3. Edit the Samba configuration file (/etc/samba/smb.conf) to include the following configuration lines in the [global] section:
  4. 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

  5. Edit the PAM authentication configuration (/etc/pam.d/system-auth) to append broken_shadow to account required pam_unix.so and to insert:
  6. 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

  7. Join the domain:
  8. /usr/bin/net join -w DOMAINNAME -S domaincontroller.domainname.tld -U username

  9. Restart the winbind and nscd services:
  10. 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.

14 thoughts on “Using Active Directory to authenticate users on a Linux computer

  1. 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.

  2. 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

  3. 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:

    • This advice was based on Red Hat Enterprise Linux (RHEL) 5 – you may find that you need to do something differently for another distro.
    • My domain was still in Windows 2000 mixed mode and the forest was at Windows 2000 functional level – again, this may affect your results, e.g. if your domain/forest was working at 2003 or 2008 level.
    • You may need to allow unsigned communications (although this shouldn’t be an issue with modern SAMBA implementations) – check out my follow-up post on using Active Directory for Linux/Mac OS X authentication.
    • You might find some more hints in the post I wrote about using AD to authenticate users on a Mac. Although the Mac configuration was performed using a GUI, it is BSD Unix underneath and the Windows side should be the same.

    I hope something here provides the answer you are looking for – otherwise try one of the big Linux forums – somewhere like LinuxQuestions.org.

  4. 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

  5. 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.

  6. 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.

  7. @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.

  8. 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

  9. 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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.