Tuesday, 3 January 2012

Authenticating Linux against Active Directory

linux_64_2In my first blog article I mentioned authentication of Linux against Active Directory.  I thought I would expand on that here. Many IT organisations are heterogeneous. By this, I mean that they run and support different hardware and various operating systems. The main advantage of this diversity is that the applications demanded by the business can be run on their natural platform.  Although some .NET applications can be run on a Linux/Apache stack via the mono project, it goes against the grain.  It is far easy to provision a Windows server with IIS.  Conversely, a PHP/MySQL setup is going to be easier to support running under Linux with httpd, than on Windows. The disadvantage of heterogeneity is duplication of effort.  Too many IT departments reinvent the wheel when they roll out a new platform resulting in multiple storage infrastructures, hypervisors, DNS servers etc.
Active Directory is Microsoft’s X.500-style directory services product.  I believe it is better than many alternatives and one of the best products that Redmond has produced.  AD provides various authentication and access methods including good implementations of standards such as LDAP and Kerberos.  This means that AD can be used as an authentication and directory provider for other platforms besides Windows.
If you need to install Linux servers or workstations in your enterprise, you can use AD for authentication and user/group lookup.  This will allow your users to access your Linux devices with the same username and password as they use for Windows.  It also removes the need to maintain a parallel directory service such as OpenLDAP.
Here is my recipe for authenticating Linux against Active Directory.  I used CentOS 6, but you should be able to adapt the instructions to other Linux distributions or even to other Unix or Unix-like operating systems such as Oracle Solaris or BSD.  Some familiarity with Linux, its command line and a text editor such as vi is required.
  1. Set your host up on your network.
  2. Set the host’s hostname and DNS domain (the FQDN should be set correctly).
  3. Ensure forward and reverse DNS resolution of your Active Directory domain controllers from the Linux host works (forward and reverse), eg:
    [root@linuxserver /]# host dc01.yourdomain.com
    dc01.yourdomain.com has address

    [root@linuxserver /]# host domain name pointer dc01.yourdomain.com.
  4. Ensure forward and reverse DNS resolution of the Linux host from other network hosts works, eg:
    C:\> nslookup linuxserver
    Server:   dc01.yourdomain.com

    C:\> nslookup
    Server:   dc01.yourdomain.com
  5. Configure NTP and ensure the system clock is correct.  It is vital that your Linux host’s time is synchronised with the time on your AD domain controllers otherwise Kerberos will not work:
    [root@linuxserver ~]# vi /etc/ntp.conf
    Add some valid NTP servers, eg:
    server 0.pool.ntp.org
    server 1.pool.ntp.org
    server 2.pool.ntp.org
    server 3.pool.ntp.org

    [root@linuxserver ~]# chkconfig ntpd on
    [root@linuxserver ~]# server 0.pool.ntp.org
    [root@linuxserver ~]# /etc/init.d/ntpd start
  6. Install packages:
    [root@linuxserver /]#  yum install samba-common samba-winbind pam_krb5
  7. Enable winbind:
    [root@linuxserver /]#  chkconfig winbind on
  8. Join the Linux host to AD and configure authentication and the name service. We are using winbind for user and group naming and Kerberos for authentication.  Enter or copy and paste the command below. Replace the parameters, such as YOURDOMAIN.COM, with details that are correct for your organisation. Replace $username with the login name of an AD user with permissions to join computers to your domain. You will be prompted for a password after you have entered the command. You may see errors related to DNS. As long as you have followed the previous steps correctly, these can be safely ignored:
    [root@linuxserver /]#  authconfig --updateall --enablewinbind --disablewinbindauth --smbsecurity=ads --smbworkgroup=YOURDOMAIN --smbrealm=YOURDOMAIN.COM --smbservers="dc01.yourdomain.com,dc02.yourdomain.com" --winbindtemplatehomedir=/home/%U --winbindtemplateshell=/bin/bash --enablewinbindusedefaultdomain --winbindjoin=$username --enablemkhomedir --enablelocauthorize --enablekrb5 --krb5kdc="dc01.yourdomain.com,dc02.yourdomain.com" --krb5realm=YOURDOMAIN.COM --enablekrb5kdcdns --enablekrb5realmdns
  9. Tweak your winbind settings to achieve the following:
    • allow for consistent UIDs across Linux boxes by generating them algorithmically using AD SIDs
    • expand nested AD group up to 10 levels
    • normalize AD group names for Linux (eg replace spaces with underscores):
    [root@linuxsever /]#  vi /etc/samba/smb.conf
    The relevant section of the file should look like this after editing:
    workgroup = YOURDOMAIN
    password server = dc01.yourdomain.com dc02.yourdomain.com
    realm = YOURDOMAIN.COM
    security = ads
    idmap config YOURDOMAIN:backend = rid
    idmap config YOURDOMAIN:base_rid = 500
    idmap config YOURDOMAIN:range = 500-1000000
    #idmap uid = 16777216-33554431
    #idmap gid = 16777216-33554431
    template homedir = /home/%U
    template shell = /bin/bash
    winbind use default domain = true
    winbind offline logon = false
    winbind expand groups = 10
    winbind normalize names = yes
  10. Restart winbind and verify:
    [root@linuxserver /]# service winbind restart
    [root@linuxserver /]# wbinfo -i $username
    [root@linuxserver /]# getent passwd $username
    [root@linuxserver /]# getent group Domain_Admins
  11. Create and verify a Kerberos keytab using an AD account with required privileges:
    [root@linuxserver /]# net ads keytab create -U $username
    [root@linuxserver /]# klist –k
  12. Change default permissions for auto-created home directories:
    [root@linuxserver /]# vi /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf
    Edit any lines in the file that look like this:
    <helper exec="/usr/libexec/oddjob/mkhomedir -u 0022"
    They should look like this instead:
    <helper exec="/usr/libexec/oddjob/mkhomedir -u 0077"
  13. Allow only domain admins to login to server (or any other AD group of your choice as appropriate):
    [root@linuxserver /]# echo "+ : root Domain_Admins : ALL" >> /etc/security/access.conf
    [root@linuxserver /]# echo "- : ALL : ALL" >> /etc/security/access.conf
    Allow only domain admins to use sudo (or any other AD group of your choice as appropriate):
    [root@linuxserver /]# echo "%Domain_Admins ALL=(ALL) ALL" >> /etc/sudoers
If you’ve managed to get though all this, you should now have an AD-authenticated Linux server.  You should be able to login at the console or via SSH using the username and password of an AD user in the group you specified above.
As an added bonus, try SSO using Kerberos:
  1. Download and start Quest PuTTY from a domain-joined Windows workstation.
  2. Specify the hostname of your Linux box and connect .
  3. If you have configured everything correctly, your Kerberos ticket should be passed from your domain-joined Windows workstation via Quest PuTTY to the Linux server, allowing you access to the Linux server without having to type your password again.  True cross-platform Single Sign On!

No comments:

Post a Comment