Ubuntu 11.10 - Logging into Active Directory

HOWTO: Configure Ubuntu 11.10 to log into Active Directory using SSSD.  My previous articles on this subject dealt with older versions of Linux that did not use SSSD (See "references" at the bottom of this article for links to the older articles).  SSSD provides the ability to integrate the LDAP and Kerberos configurations into one config file (/etc/sssd/sssd.conf), provides for multiple AD domain/forest configurations, and caches logon information for offline access.

Configuration of SSSD and related configuration of NSS and PAM is fairly easy on Ubuntu 11.10.  This will probably be the shortest article of the series.

Installing SSSD
To begin the configuration, we need to install SSSD. To do this, open up a shell prompt, and type the following command:

sudo apt-get update && sudo apt-get install sssd

Apt will install sssd and its dependencies, and perform much of the configuration for you, including adding sss to the NSS and PAM config files.

Configuring SSSD
Next, we need to edit the /etc/sssd/sssd.conf file and add the specifics of our Active Directory.  Edit your sssd.conf file to look like the following:

services = nss, pam
config_file_version = 2
domains = default
access_provider = simple
simple_allow_users = myuser
enumerate = false
cache_credentials = True
id_provider = ldap
auth_provider = krb5
chpass_provider = krb5
krb5_realm = MYDOMAIN.COM
krb5_server = server1.myDomain.com
krb5_kpasswd = server1.myDomain.com
ldap_uri = ldap://server1.myDomain.com/
ldap_search_base = dc=myDomain,dc=com
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_id_use_start_tls = False
ldap_default_bind_dn = cn=myLDAPuser,cn=Users,dc=myDomain,dc=com
ldap_default_authtok = myLDAPuserPassword
ldap_default_authtok_type = password
ldap_user_object_class = person
ldap_user_name = samAccountName
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_user_home_directory = unixHomeDirectory
ldap_group_object_class = group
ldap_user_search_filter =(&(objectCategory=User)(uidNumber=*))

Replace myUser and myDomain references to match your Active Directory information.  Below is a description of some of the lines of the file:

As you can see, the configuration specifies the identity_provider (LDAP), auth_provider (Kerberos), and the LDAP and Kerberos settings that we entered previously, but we've also added a few things.  Our configuration for Active Directory is under the [domain/default] section.  You can name this section something else, like [domain/mydomain] if you like, and you can add more sections if for example you have multiple Active Directories or multiple domains in your AD forest.  Let's look at the various lines that we added and what they mean.

access_provider and simple_allow_users: (optional) this is a simple way to specify which users in AD are allowed to logon to this Linux machine.  If you remove these lines, any AD user will be able to logon.  You can add multiple users by adding more usernames to the simple_allow_users line, separated by commas.  There are a number of different ways to control access, via other access providers, group filters, etc, but I won't get into that here, let's keep things simple for now.

enumerate: If set to true, SSSD will cache all of the users in your AD, which could take a really long time if you have a lot of users.  Setting this to false is highly recommended.

cache_credentials: If set to true, after a user has successfully logged on, SSSD will store their credentials, allowing them to logon again even if the machine is off the network and AD is unavailable.  This is especially nice for laptops that are often off the network.  Without cached credentials, you would have to have a local account to logon to your laptop when you were offline.

ldap_tls_cacertdir and ldap_id_use_start_tls: you can configure LDAP to use SSL to encrypt traffic between Linux and AD.  Yes it is recommended to do so, but I'm not getting into it here, this article is getting long enough as it is.  The good news is that your user's password is not going over the wire in the clear, Kerberos still does the password check in an encrypted fashion, but the bind user ID that we will use to connect to the LDAP server will have it's password sent in clear text.  So yes, I recommend implementing SSL, but I'll save that for another article.

ldap_default_bind_dn: this is the distinguished name of an Active Directory user account that we will use to connect to AD to lookup our logon user.  This bind account needs no special rights (certainly not administrative rights!), just a plain old user.  Any old user can lookup users in AD.

ldap_default_authtok: this is the password for the bind user mentioned above.

ldap_default_authtok_type: set this to the word password.  There are other authtok types, but I'll save that for later.

The last few lines in the sssd.conf map SSSD ldap attributes and classes to Active Directory attibute and class names.  I've also added an ldap_user_search_filter that will help search performance.

Tweaking PAM
One other thing you must do for an AD user to logon to Ubuntu, is tell PAM to automatically create the home directory when a new user logs on for the first time.  To do this, edit the file /etc/pam.d/common-session and add the line for pam_mkhomedir.so as shown below:

session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session optional pam_umask.so
session optional pam_sss.so
session optional pam_mkhomedir.so skel = /etc/skel/ mask=0077
session required pam_unix.so 
session optional pam_ck_connector.so nox11

Now reboot and you should be able to logon using the account you specified in simple_allow_users.  If you can not, then check below for common problems.

Check the Time and Date
Kerberos cannot work if your clock is more than five minutes off from the clock of the Kerberos server (AD domain controller).  Make sure the clock is correct and use NTP to keep the clock in sync.

AD Users Must Have Unix Attributes Populated
In order for AD users to logon, they should have the following attributes set in their AD account:

uidNumber (example: 1001)
gidNumber (example: 1003)
loginShell (example: /bin/bash)
unixHomeDirectory (example /home/myuser)

You can use ADSIEDIT.MSC to access these attributes, since the Microsoft GUI admin tools don't present these attributes to be edited.  uidNumber and gidNumber should be set to a number above 1000.  The uidNumber should be unique per user. 

Legacy Users with uid/gid Below 1000
If you already have users in your AD with uidNumber or gidNumber below 1000 (previous versions of Linux often set the minimum to 500), you can tweak the minimums on Ubuntu.  Edit the file /etc/login.defs and find the references to MIN_UID and MIN_GID, and change them from 1000 to 500.

I hope that helps.  I could go on about this subject, but I already have in previous articles.  If you aren't quite comfortable with this yet, please read my previous articles that went into some of this in a bit more depth.

Fedora 16 - Logging into Active Directory
Active Directory Authentication on Fedora/Redhat Linux
Active Directory Authentication on Ubuntu Linux

Good Luck!

Related Posts:


Anonymous said...

I just had a few comments/clarifications to make on your post (excellent write-up, by the way).

The simple access provider also supports 'simple_allow_groups' so you can easily restrict access to one or more POSIX-compliant groups.

You typoed 'ldap_tls_cacertdir' in the detailed section below the config file. (The sssd.conf example has it correct).

As for the recommendation about TLS, you should make your users aware that the 'ldap_id_use_start_tls' option applies ONLY to nsswitch lookups. ALL authentications (where passwords must be protected) occur over encrypted channels. In the case of AD and your setup, it uses Kerberos. If it was just a simple LDAP auth, it would mandate the use of either TLS or LDAPS before allowing you to bind.

I strongly recommend reading https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20with%20a%20Windows%202008%20Domain%20Server (or http://goo.gl/hQNLr if that doesn't come through) for extensive details on setting up Active Directory as a managed client machine with a host keytab instead of using a bind user.

You also may want to look into pam_oddjob_mkhomedir if any of your install base has SELinux enabled.

I hope this helps!

-- Stephen Gallagher, Lead Developer of the System Security Services Daemon

Brian said...

Thanks, I fixed the text. I could have gone on about the various ways to control access, but I didn't want the article to turn into an ebook :) thanks for the input!

Post a Comment

Related Posts Plugin for WordPress, Blogger...