UNIX/LINUX Kerberos Authentication from the point of view of Windows Administrators
This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at https://www.microsoft.com/info/cpyright.htm
First small disclaimer: This blog is not intended to provide a reader with detailed knowledge of UNIX/LINUX authentication and authorization mechanisms, but rather aimed to highlight some points that may not be apparent to IT professionals whose background mainly involves working in Microsoft based environments.
Why should Windows Administrators care?
With the wide spread of Active Directory and increasing desire of IT managers to simplify their computing environments many companies are looking at ways to centralize authentication of Windows and UNIX users/hosts against a single directory. Since Active Directory natively supports such critical standards as Kerberos and LDAP and is widely used for authentication by Windows clients it is viewed as a natural choice for bringing other platforms (ex. UNIX/LINUX) under its umbrella.
By providing centralized source of authentication IT managers achieve single-sign-on environments between disparate platforms, reduce administrative overhead of managing multiple identities and position themselves better to meet audit requirements.
Having said that, more and more Active Directory administrators are now involved in tasks of integrating UNIX/LINUX into Active Directory environments, therefore some knowledge of UNIX/LINUX authentication and authorization mechanism may become a mandatory skill for a lot of Windows Administrators, hence this small article.
Differences in Kerberos implementations between Active Directory/Windows and MIT Kerberos/UNIX
Despite the fact that Kerberos is an industry standard protocol, its specifications allow for vendor extensions in order to improve its functionality. Microsoft has done a lot of work in making Kerberos an underpinning of Windows security infrastructure, and in doing so several protocol extensions were implemented, which were submitted as standards.
One of such extensions that is important for this discussion is PAC (Privilege Access Certificate). In the Microsoft implementation of Kerberos, a token issued by KDC contains information about user’s group membership, which allows for using Kerberos not only for authentication but also for authorization. The authorization is possible, since the service accepting a Kerberos token can determine from the group list in the PAC portion of the token whether access should be allowed to a resource based on ACL applied to the resource in question.
On the other hand, MIT implementation of Kerberos which is widely used in UNIX environments does not have such a facility, which limits the use of Kerberos only to authentication purposes. This is a very critical difference between Microsoft and MIT implementation which has some consequences on how UNIX/LINUX servers are configured in Kerberos environments. What does this really mean in terms of configuration? This may sound very strange for Windows Administrators: In a typical UNIX/LINUX environment a user is typically authenticated against one database (ex. Kerberos KDC database) and his or her account information (ex. UID, GID, group membership) is pulled from a different directory (ex. LDAP, NIS, local password files). In other words, when setting up a UNIX/LINUX box two separate configuration tasks need to be performed: authentication and authorization. We will explore these UNIX/LINUX facilities in the next two sections. Of course, in Active Directory environment authentication and authorization information is stored in one place, which greatly simplifies administration and also improves performance since Kerberos has access to authorization data and packs it into the issued tokens, whereas in UNIX/LINUX environments additional network queries need to be performed outside Kerberos exchange to determine authorization attributes of a user.
What is PAM?
PAM stands for Pluggable Authentication Module, and is an API that allows the system administrator to configure authentication mechanisms rather than having authentication mechanisms hardcoded into the application. PAM is supported on Linux, HP-UX, AIX 5.1 and above, and Solaris. Administrators can customize an application's authentication system by making changes to /etc/pam.conf or an application specific file in the /etc/pam.d/ directory.
PAM modules are shared libraries that add support for a specific authentication mechanism. UNIX platforms that support PAM normally have a PAM module called pam_unix for standard UNIX local file authentication.
So from a perspective of a Windows Administrator how is PAM different let’s say from Windows GINA?
- By using PAM different applications can be configured to use different authentication sources. For example gdm (Gnome graphical login) could be configured to use MIT Kerberos pam_krb5 module, and let’s say telnet could be configured to use local UNIX password files pam_unix. Again, this quite different from a typical Windows environment where a user is typically authenticated once during login and against a single source. Obviously, this is a very important point to keep in mind when configuring a UNIX/LINUX box to authenticate against Active Directory. You need to ensure that all applications in question (ex. Graphical login, telnet, ssh, rlogin) are configured to authenticate against Active Directory.
- An application could be configured to authenticate against multiple sources. In other words, authentication could be chained. For example, graphical login could be configured to first try local UNIX password file, then MIT Kerberos, then NIS, and only then Active Directory. Obviously, we need to pay special attention to the sequence in which those authentication sources are configured, since you may get unexpected results if, for example, a user account with which you are logging-in is first found in local UNIX file, but really you meant to authenticate against Active Directory. So pay attention to the order of authentication sequence. If AD is the primary source of authentication, then move it to the beginning of the pam configuration file for the application in question.
- Within PAM paradigm it is possible to require for multiple authentication sources to succeed in order to allow user to gain access to an application. This is something that Windows Administrators are not really accustomed to, therefore carefully examine the pam configuration files, especially for the authentication sources marked as required, and ensure that nothing blocks a user from accessing an application if he or she is successfully authenticated against AD, of course unless your intentions are to require additional authentication on top of AD. We will examine a sample PAM configuration file later on in this document in order to provide you with a practical example.
What is NSS?
UNIX/LINUX operating systems use various “databases” to obtain information about users, groups and so forth. Traditionally, these databases were stored as flat text files in the /etc directory. For example, user information is stored in /etc/passwd and group information is stored in /etc/group. The Name Service Switch (NSS) is a subsystem built directly into the C runtime library (libc) and allows user and group identity information to be obtained from a variety of backend sources—not just the text files in the /etc directory. System administrators can change the NSS configuration by modifying the /etc/nsswitch.conf file. NSS modules are shared libraries that add support for user and group identity information to be retrieved from a specific backend data source. Common NSS modules are for nis, files, and db backends.
NSS is probably a completely new concept for a Windows Administrator. Since authorization data is packaged into Kerberos tokens, Windows Administrators usually do not need to perform tasks around retrieval of authorization data. I myself was initially caught by surprise when configuring a LINUX workstation for authentication against AD. After I completed configuration of pam modules for AD, I tried to login to the workstation by providing my AD credentials, but was not able to pass through login screen. I examined the logs and saw messages about successful authentication, so why I could not login? Well, after examining the logs further I saw a message about unsuccessful attempt to retrieve my account information (at that point I did not properly configure nssswitch.conf yet). That was a very good lesson which made me realize that login process on UNIX/LINUX consists of two completely separate processes: authentication and user information retrieval. Both processes need to succeed in order to login. Another probably strange thing, from a Windows Administrator point of view, is the fact that authentication information and user account information are typically stored in separate databases, in contrast to AD where everything is stored in a single database.
Configuration Example: Vintela Authentication Services
So let’s walk through a configuration example that should outline some of the concepts that we discussed in the article. In this example we will examine a configuration of LINUX workstation configured to authenticate against Active Directory. For the purposes of this example I will use Vintela Authentication (VAS) Services package, provided by Quest, which allows seamless integration of UNIX/LINUX operating systems with AD. This example assumes that VAS is already installed and configured.
For details on VAS see this link: https://www.quest.com/Vintela_Authentication_Services/
As an example we will take a look at configuring Gnome Graphical Login (GDM) to use AD as authentication source. So by switching to the /etc/pam.d directory and editing gdm file as shown below we will configure this application to among other things authenticate against AD.
auth [ignore=ignore success=done default=die] pam_vas3.so create_homedir get_tgt
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass
auth required /lib/security/$ISA/pam_deny.so
account [ignore=ignore success=done default=die] pam_vas3.so
account required /lib/security/$ISA/pam_unix.so broken_shadow
account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_krb5.so
account required /lib/security/$ISA/pam_permit.so
password [ignore=ignore success=done default=die] pam_vas3.so
password requisite /lib/security/$ISA/pam_cracklib.so retry=3
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password sufficient /lib/security/$ISA/pam_krb5.so use_authtok
password required /lib/security/$ISA/pam_deny.so
So let’s attempt to decipher this configuration file.
First of all, you will notice that the file is divided into three sections: auth, account and password.
auth – In this section we configure pam module’s sequence and parameters for performing validation of submitted user names and passwords
account – In this section we configure pam module’s sequence and parameters for performing account validation (account againg, expiration, etc)
password - In this section we configure pam module’s sequence and parameters with respect to dealing with password policies
Now let’s walk through the auth section. There are four pam modules specified there, and as explained earlier their sequence is important. So in our case VAS module will have precedence over all other modules, therefore user credentials will be first checked against AD. If credentials are validated successfully then no other pam modules in the auth section will be invoked (success=done assures us of that). You need to consult the VAS documentation to fully understand all options available to you when configuring this module (by the way, the same is true for any other pam module).
Should AD authentication fail, then pam_unix (local UNIX password file) will be tried, should this pam fail as well then pam_krb5 (MIT Kerberos implementation) will be tried. If none of the first 3 pam modules succeed then pam_deny will force login failure.
The remaining account and password sections are almost identical to auth section, therefore will not be discussed here.
Now let’s take a look at nsswitch.conf configuration file. To conserve space I only provide the relevant portion of the file here.
passwd: files vas3
shadow: files
group: files vas3
As you can see, this file is quite simple. It simply lists the order in which the system will attempt to gather user account information. For example, for a given user the system will first try to determine his or her group membership by looking at /etc/passwd identified by files keyword and then if that fails will switch to VAS, which it turn uses AD as a source of group membership.