Authenticating Linux users against AD using Kerberos

Authenticating Linux users against AD

using Kerberos

This is a neat trick for those of you who have Microsoft's Active Directory (AD) in your environment and don't want to have to manage two different username/passwords in the environment. In very over simplified terms Microsoft AD is basically an LDAP directory bolted on top of a Kerberos authentication system. Knowing this, you can configure your Linux systems to authenticate directly against an AD domain without requiring your Linux servers(#) to be added to the AD domain and without using AD as your directory service for Unix. I will use RHEL5 as my example distribution for this: (Note: Strictly speaking, this technique should work on any Unix platform that has kerberos support. I've personally witnessed it working on HPUX. However, configuring kerberos and your authenication methods to support this will vary significantly between platforms. Redhat just make it really easy on their Linux distribution. Your mileage will vary.) Only two or three changes are effectively required. Even in stripped down systemsthe kerberos client libraries are usually part of the distribution so its rare package installations are required. Edit /etc/krb5.conf Run authconfig to enable Kerberos for authentication on the system. (Optional) If you use ssh to connect you need to modify sshd_config to add Kerberos support 1. Edit /etc/krb5.conf (If this file is missing, the package required on RedHat systems is krb5-libs) Let's assume your AD domain is MYAD.COM Edit the [libdefaults] section. Replace EXAMPLE.COM with MYAD.COM. (Kerberos uses capitalisation to indicate a REALM vs a DNS domain) Set dns_lookup_realm & dns_lookup_kdc to true Delete the entire [realms] section as you won't be specifiying the servers unless you know you really need to. I'll explain why below. (##) Edit the [domain_realm] section and replace all references to example.com to your AD Domain, in this example MYAD.COM eg [domain_realm] .myad.com = MYAD.COM myad.com - MYAD.COM Save the file and exit your editor. 2. Run the following command (RH Linux specific ) authconfig --update --enablekrb5 3. Configure SSH Edit the sshd_config file to enable kerberos support vi /etc/ssh/sshd_config Uncomment or add these if necessary and set the following: KerberosAuthentication yes KerberosOrLocalPasswd yes Restart sshd On RH: service sshd restart -- Now you can add users to your system with usernames matching an AD account and they will be able to authenticate via AD. (Note: AD is case insensitive, Unix is not. Create you usernames with all lowercase even if the convention without your organisation is mixed case or something different.) A quick way to add a user without a local password that will be forced to authenticate via AD is as follows: adduser -m -r testuser This will create a user as a system account (Cannot be logged in via a local password) Now, login via ssh using the userid you have created (assuming you know the password!) and you should be able to login to the system. I also use this technique for services that use local authentication but where I don't want to provide a unix shell. eg Chrooted SFTP. I can change my adduser command to: adduser -m -r -s /sbin/nologin testuser or edit /etc/passwd and change the user shell. I have found this technique useful on many clients sites especially for providing access for non techie type users to services running on Unix hosts. (#) Not all Unix platforms will allow this. One of the behind the scenes steps of adding a host to an AD domain is the creation of a host principal in Kerberos. Some PAM implementations on Unix systems will insist on a host principal existing in the Kerberos Realm (In this case AD) before it will allow users to be authenticated. Redhat Linux does not insist on the existence of the host principal. Your mileage will vary with other distributions. (##) Kerberos supports special DNS records called SRV records. These are automatically created within an AD domain and tell clients where to find the servers providing Kerberos authentication services. This is why we set "dns_lookup_realm & dns_lookup_kdc" to true in our /etc/krb5.conf. If you want to see what servers are providing authentication services in an AD command run this on your Unix host. "#" indicates a Unix command prompt and ">" indicates an nslookup prompt. # nslookup > set type=srv > _kerberos._tcp.myad.com <----- replace myad.com with your AD domain name. You will be presented with a list of all Active Directory domain controllers serving the AD domain. Much better than manually trying to maintain server entries on your Unix hosts. (###) If a user has a valid shell and can login to the host via this technique, they will also be able to update their password in AD using the passwd command. However, no one else, including root (####), will be able to update someone elses passwd unless they know the users original passwd and can obtain a valid kerberos ticket using kinit. (####) This is not strictly true. If you create a root principal in kerberos and grant it admin privilege, root can change any passwd in kerberos. However, they would need to do so via the kadmin tool.