7:59 AM
Brian Seltzer
With older versions of Linux, we used OpenLDAP and Kerberos v5 client configurations to get Linux talking to Active Directory. You can still do that, but newer versions of Linux now include a better way, the System Security Services Daemon (SSSD).
SSSD provides centralized control of authentication against remote directories. A single configuration file, /etc/sssd/sssd.conf contains all of the configuration information for whatever remote directories your Linux machine needs to connect to, including Active Directory. When an authentication attempt is made, SSSD launches services on the fly to perform the authentication, and caches that user so that authentication can succeed later, even if the machine is off the network.
Identity and Authentication
When you logon to a computer, and you enter your username and password, two things happen. The computer has to find your identity to get important user information for use in your logon session, and it has to verify that you are who you say you are (that you are authentic).
In Linux, by default, user information is stored in the /etc/passwd file. This information include the username, user ID number (uidNumber), group ID number (gidNumber), loginShell, homeDirectory path, etc. The user's password (or rather an encrypted hash thereof) is typically stored in /etc/shadow. When you logon to Linux, your uidNumber and gidNumber are used to secure any files and folders that you own, so the uidNumber and gidNumber are a fundamental component of the user's identity.
To logon to Linux using your Active Directory account, an identity provider must be able to find an account in Active Directory that matches the user name that you enter, and return the uidNumber, gidNumber, etc, to Linux, just like when you logon using a local account in the passwd file.
By defaut, uidNumber, gidNumber, etc are not defined for Active Directory users that typically logon to Windows computers, because Windows doesn't use these values (Windows uses a SID which is somewhat equivalent to the uidNumber). Active Directory does support these values, they're just not typically populated with any information. So, some effort will need to be made to populate these values for users that need to logon to Linux. See the section towards the end of the article for how to do this.
LDAP is the identity provider to use with Active Directory. LDAP can query Active Directory to find your user account and return the uidNumber, etc, and that's where LDAP's job is finished. Wait a minute we haven't checked our password yet. That's where Kerberos comes in, Kerberos is our authentication provider. Once LDAP has found the identity information, Kerberos comes in to validate the user's password. Kerberos also stores proof that you successfully authenticated, in the form of a ticket granting ticket (TGT), which you can use later to access servers on the network without having the enter your username and password again.
Sound complicated? Don't blame Active Directory, Kerberos is an authentication provider only. It needs help from LDAP to be the identity provider. Anyway, LDAP is our identity provider and Kerberos is our authentication provider. But wait there's more...
Linux uses a few more pieces to make this all work. When we enable Active Directory authentication in Linux, we don't lose the ability to logon using local accounts in the passwd file, we can logon using local accounts or Active Directory accounts. Linux handles both, by using NSS (Network Security Services) and PAM (Pluggable Authentication Module). NSS specifies which methods to use to find user accounts (in local files, through SSSD, etc), and PAM handles the mechanics of executing the various types of logons.
To make all this work, there are various configuration files for NSS (/etc/nsswitch.conf), PAM (/etc/pam.d/system-auth-ac and others), and SSSD (/etc/sssd/sssd.conf). Luckily, a lot of the configuration work can be done for you simply by running one of the authentication configuration tools included in Fedora 16.
Configuring Authentication
To configure NSS, PAM, and SSSD to use Active Directory, launch the Authentication Configuration tool. From a Gnome classic session, select Application - Other - Authentication, or from a shall prompt, type system-config-authentication. The Authentication Configuration dialog is displayed (see figure 1).
 |
| Figure 1 - Authentication Configuration |
Your Active Directory domain has a name, well two names, a NetBIOS name and a DNS name. The NetBIOS name is usually a short name such as myDomain, and the DNS name, is a fully-qualified DNS name such as myDomain.com or myDomain.net or whatever.
The Kerberos realm will be an uppercase version of the DNS name of your domain, MYDOMAIN.COM for example. For the KDC and Admin server fields, enter the fully-qualified DNS name of an Active Directory domain controller, for example, server1.myDomain.com.
The LDAP Server can be the same domain controller prefaced with ldap://, for example, ldap://server1.myDomain.com/.
The LDAP Seach Base DN points to a location within your Active Directory under which your users are stored. Typically, you'll enter the DN of the domain, so that LDAP will be able to find any user in the domain. In a large domain, to improve search performance, you may want to point to a subfolder (an Organizational-Unit or OU) in AD. To enter the base of your AD domain, we enter the LDAP representation of the domain, where each part of the DNS name is prefaced with DC= and the parts are separated by commas, for example, DC=myDomain,DC=com.
On the Advanced Options tab, select "Create Home Directories on First Logon".
Now click Apply. We're nearly done. When you click apply, the Authentication Configuration tool modifies /etc/nsswitch.conf and files in /etc/pam.d to include SSSD as a source for identities/authentication, and it adds our Kerberos and LDAP information into /etc/sssd/sssd.conf. But don't try to logon just yet, there's a bit more to do.
Editing the Configuration
The Authentication Configuration tool did most of the job for us, but it doesn't know some of the particulars of Active Directory, so we have to tweak /etc/sssd/sssd.conf to get things working. Edit your sssd.conf file and configure it as shown below.
[sssd] services = nss, pam config_file_version = 2 domains = default
[nss]
[pam]
[domain/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=*))
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_certdir 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.
Managing the SSSD Daemon
Now that we've got our sssd.conf file worked out, we can give things a try. First we've got to restart our SSSD daemon so that it reads our new configuration. Let's use the systemctl command to manage the SSSD daemon.
To make sure SSSD starts on boot up, type:
systemctl enable sssd.service
To start SSSD, type:
systemctl start sssd.service
And to restart SSSD, type:
systemctl restart sssd.service
Now we can try logging in. For this part, I think it's handy to try logging on via a secure shell session, while remaining logged on with our local account at the Linux console. So make sure you've got your ssh server setup. To do that, open a shell prompt, any type:
sudo yum install openssh-server
systemctl start sshd.service
Now from a remote computer, try to ssh into your linux machine. When prompted for a username and password, enter your Active Directory user name and password. Assuming you didn't fat finger anything, your login should be successful, assuming that your AD account has a uidNumber set, and a few other things hold true. At this point you are sure to run into a few snags, so lets talk about all the bad stuff that is sure to happen.
Checking Kerberos
Kerberos relies on the date and time on your Linux machine being nearly the same (within five minutes) as the date and time on your AD domain controller. If your clock is off, Kerberos won't work. Set your clock, and better yet, configure NTP to keep your clock in sync. To find out if Kerberos is working correctly, you can use kinit to perform an authentication manually. If it's not already installed you'll need to install krb5-workstation:
yum install krb5-workstation
Now, try authenticating against your user ID in AD:
kinit [email protected]
You should be prompted for your password. If things go well, you should receive your TGT, which you can view by typing:
klist
If this didn't work, you've probably fat fingered the Kerberos information in the sssd.conf file, or your clock is not set correctly.
Checking LDAP
Assuming that your AD account has a uidNumber, etc, you should be able to lookup your AD account using the getent command:
getent passwd myuser
If this command doesn't return anything, then you've probably fat fingered the LDAP information in the sssd.conf file, or the /etc/nsswitch.conf file is not configured to use SSSD. You should see references to SSS in the nsswitch.conf. This should have been taken care of automatically when we ran the auth config.
SELinux Alerts
Oh what a pain. You may get errors while trying to logon. Use the SELinux Troubleshooter, which is sure to be flashing away in your face when the errors occur, to address these errors. The SELinux Troubleshooter will show you what error occured and the commands you need to run to fix them.
Configuring Your Active Directory Account
As I mentioned before, your AD account needs some Linux attributes to be populated. Specifically, uidNumber and gidNumber need to be populated with unique numbers, preferably over 1000. UID's less than 1000 are generally reserved for local accounts. Older versions of Linux used to reserve numbers below 500. If you have existing UID's in AD that are below 1000, you'll need to edit some files in the /etc/pam.d directory and change the minimum UID number.
Besides uidNumber and gidNumber, two other useful attributes are loginShell and unixHomeDirectory. Set loginShell to your preferred shell, such as /bin/bash and set your unixHomeDirectory like /home/myuser.
How do you set these attributes? Microsoft, in their wisdom, didn't account for these in the Active Directory Users and Computers management tool. We can use the ADSIEDIT.MSC to set these, or we can write a script to set these.
OK, hopefully this has helped you, I could go on discussing various tweaks to this configuration, but this article is long enough. Stay tuned for related articles where I'll cover some of the finer details.
References
Active Directory Authentication on Fedora/Redhat (old method)
Active Directory Authentication on Ubuntu (old method)
Related Posts:
Image icons used on this site are courtesy of Oxygen-icons.org
0 comments:
Post a Comment