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