Linux authentication with Active Directory using Kerberos 5

Separation

The character separating the domain and user name in Windows is the backslash \, however, this character has a special meaning for the shell. To avoid conflict, admins should set winbind separator to avoid the use of a shell metacharacter and choose a plus sign (+), as shown in line 16 of Listing 3.

If you only have one domain, you don't need to separate the domain and user names. Winbind provides the setting winbind use default domain = yes in the global section of the configuration file. This parameter tells Linux to use Active Directory user names without the domain element. If you do not set this, you will need to add a domain name prefix to the domain users served up by Winbind to use them on Linux (see Figure 3).

Left to its own devices, the Linux system is unable to convert domain user and group names to their numeric counterparts: User Identification (UID) and Group Identification (GID). However, this is necessary because Linux does not use names internally, relying on the UID and GID instead. For example, the ls command parses a file's inode to discover its owner's UID and translates this value to a name before displaying the information on screen.

Linux uses a universal API, NSS, for mapping names. NSS can search the /etc/passwd file, or assuming you have the module loaded, query an Active Directory server. This capability lets you list the users and groups in an ADS realm as if they were local accounts. To allow this to happen, you need to add the winbind name service to the passwd and group databases in the central /etc/nsswitch.conf configuration file:

passwd: files winbind
group:  files winbind

These lines tell the name service to start by searching local files such as /etc/passwd before contacting winbindd. If you additionally run NIS, you can type compat instead of files.

One thing still standing in the way of successful cooperation between Linux and the Windows-based Active Directory Service is that the Linux computer needs to become a domain member to receive user and group information for the domain.

The security = ads parameter in line 5 adds Samba as an Active Directory domain member. The net ads command, which is part of the Samba distribution (see Figure 4), completes the transaction. The domain user, Administrator in this case, must be authorized to add the Linux computer to the domain. net prompts you to enter the password for the authorized user and, if the password is correct, creates the computer account on the domain controller. If this all works out, the Linux client is now a full member of the Active Directory environment.

To test whether the connection to the domain controller is working properly, run the wbinfo diagnostics tool. This tool is part of the Winbind package. The -u parameter tells the command to list all the domain users available in the domain:

KDC+wneu
KDC+mkreis [...]

The domain you are using here is called KDC. The domain name is followed by the separator configured as your winbind separator, + in this case, and the user name. The names retrieved from Active Directory are now known to Linux and can be used to log in. The groups defined in Active Directory can be listed by calling wbinfo -g:

KDC+accounts
KDC+asp [...]

To output an overview of all known users and groups in the domain or local databases, use getent passwd or getent group. The output is similar to /etc/passwd and /etc/group.

Now test whether Linux can identify the user and group names in your Active Directory: If the Linux system administrator can assign the ownership and group ownership of a file stored on a Linux machine to a domain user and group in Active Directory, you're winning! Depending on the winbind use default domain parameter in your Samba configuration, root can specify the owner as Domain+User and the group as Domain+Group (Listing 4).

Listing 4

Changing Ownership

01 # ls -l foo.txt
02 -rw-r--r-- 1 root root May 02 15:53 foo.txt
03 # chown KDC+wnew foo.txt
04 # chgrp KDC+asp foo.txt
05 # ls -l foo.txt
06 -rw-r--r-- 1 KDC+wneu KDC+asp May 02 15:53 foo.txt

Wedding Kerberos to PAM

The next trick is to integrate Kerberos, the Active Directory domain users, and the Linux login mechanism. Formerly, each of these services expected users to authenticate, then each applied its own authentication and authorization mechanisms to grant users access to the services it provided. The Pluggable Authentication Modules (PAM) provide a unified interface for this integrated authentication [4].

Changing the authentication method in PAM means changing and serving up matching modules that all programs can then access. In other words, PAM adds an abstraction layer between authentication and the actual services but without needing to change applications. Applications such as FTP and Telnet servers connect to an authentication service by calling PAM library functions that are available as shared libraries.

A special module library is available to change the user login authentication method to Kerberos via the Pluggable Authentication Modules. Packages for the library are available for most popular distributions. The module itself is called pam_krb5.so, and it typically resides in /lib/security [5].

Individual Configuration

The module not only handles the Kerberos-based login, but transparently requests a TGT from the Authentication Server on behalf of the user. Getting this to work involves changing a number of configuration settings in the /etc/pam.d/ directory.

Each application that requires authentication and uses PAM requires an individual file in /etc/pam.d/. Distributions tend to organize the configuration in slightly different ways, and some of them import shared files. Each line in these files includes the type, a control flag, a path to the module in question, and optional arguments, all of which are separated by blanks (see Listing 5). Fedora uses the authconfig tool, OpenSUSE relies on YaST for manipulating the PAM configuration, and Debian users need to fire up their favorite editor to manually modify the files.

Listing 5

PAM Configurations

01 # /etc/pam.d/common-auth
02 auth     sufficient pam_krb5.so forwardable
03 auth     required   pam_unix.so nullok_secure use_first_pass
04 auth     required   pam_deny.so
05
06 # /etc/pam.d/common-account
07 account  sufficient pam_krb5.so forwardable
08 account  required   pam_unix.so
09
10 # /etc/pam.d/common-session
11 session  sufficient pam_krb5.so
12 session  required   pam_unix.so
13
14 # /etc/pam.d/common-password
15 password sufficient pam_krb5.so nullok obscure md5
16 password required   pam_unix.so nullok obscure md5

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Likewise

    Likewise Open provides smooth integration with Active Directory environments. We show you how to install and configure the admin-friendly authentication system.

  • Samba 4

    Since the release of the final version, Samba 4 has become increasingly significant in IT practice; now it has found its way into Jessie, the next Debian release. We take a look at the new features.

  • FreeIPA

    FreeIPA offers integrated identity management and big ideas for the future.

  • Filter Proxy for AD

    You might want to reap the benefits of active directory’s single sign-on for your virus scanning and content filtering. If you also use Squid to handle user access to the internet, you have a front-row seat for “when worlds collide.”

  • Samba 4

    A technical preview version of Samba 4 became available at the end of January. We took a look at what’s coming in the next version of the Samba file and print service suite.

comments powered by Disqus

Direct Download

Read full article as PDF:

028-034_ad-pam.pdf  (948.46 kB)

News