Linux authentication with Active Directory using Kerberos 5
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).
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 .
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 .
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.
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
Should you trust an online service to store your online passwords?
New B+ board lets you build cool things without the complication of a powered USB hub.
Redmond rushes in to root out alleged malware haven.
New initiative will bring futuristic virtual reality effects to the web surfing experience.
Dyreza malware launches a man-in-the-middle attack that compromises SSL.
New cloud combines worldwide access with local attention to data security.
A first cousin of the recent Heartbleed attack affects EAP-based wireless and peer-to-peer authentication.
FOSS community acts to protect freedom of choice for laptop devices.
Quintessential open source browser shores up its market share with a step toward the proprietary dark side.
Authorities in 16 countries take action against users of the imfamous BlackShades malware tool.