27.2 Background Information for Linux AD Support

Many system components need to interact flawlessly to integrate a Linux client into an existing Windows Active Directory domain. Figure 27-1 highlights the most prominent ones. The following sections focus on the underlying processes of the key events in AD server and client interaction.

Figure 27-1 Active Directory Authentication Schema

To communicate with the directory service, the client needs to share at least two protocols with the server:

LDAP

LDAP is a protocol optimized for managing directory information. A Windows domain controller with AD can use the LDAP protocol to exchange directory information with the clients. To learn more about LDAP in general and about the open source port of it, OpenLDAP, refer to Section 26.0, LDAP—A Directory Service.

Kerberos

Kerberos is a third-party trusted authentication service. All its clients trust Kerberos's judgment of another client's identity, enabling kerberized single-sign-on (SSO) solutions. Windows supports a Kerberos implementation, making Kerberos SSO possible even with Linux clients.

The following client components process account and authentication data:

Winbind

The most central part of this solution is the winbind daemon that is a part of the Samba project and handles all communication with the AD server.

NSS (Name Service Switch)

NSS routines provide name service information. Naming service for both users and groups is provided by nss_winbind. This module directly interacts with the winbind daemon.

PAM (Pluggable Authentication Modules)

User authentication for AD users is done by the pam_winbind module. The creation of user homes for the AD users on the Linux client is handled by pam_mkhomedir. The pam_winbind module directly interacts with winbindd. To learn more about PAM in general, refer to Section 18.0, Authentication with PAM.

Applications that are PAM-aware, like the login routines and the GNOME and KDE display managers, interact with the PAM and NSS layer to authenticate against the Windows server. Applications supporting Kerberos authentication, such as file managers, Web browsers, or e-mail clients, use the Kerberos credential cache to access user's Kerberos tickets, making them part of the SSO framework.

27.2.1 Domain Join

During domain join, the server and the client establish a secure relation. On the client, the following tasks need to be performed to join the existing LDAP and Kerberos SSO environment provided by the Window domain controller. The entire join process is handled by the YaST Domain Membership module that can be run during installation or in the installed system:

  1. The Windows domain controller providing both LDAP and KDC (Key Distribution Center) services is located.

  2. A machine account for the joining client is created in the directory service.

  3. An initial ticket granting ticket (TGT) is obtained for the client and stored in its local Kerberos credential cache. The client needs this TGT to get further tickets allowing it to contact other services, like contacting the directory server for LDAP queries.

  4. NSS and PAM configurations are adjusted to enable the client to authenticate against the domain controller.

During client boot, the winbind daemon is started and retrieves the initial Kerberos ticket for the machine account. winbindd automatically refreshes the machine's ticket to keep it valid. To keep track of the current account policies, winbindd periodically queries the domain controller.

27.2.2 Domain Login and User Homes

The login managers of GNOME and KDE (GDM and KDM) have been extended to allow the handling of AD domain login. Users can choose to log in to the primary domain the machine has joined or to one of the trusted domains with which the domain controller of the primary domain has established a trust relationship.

User authentication is mediated by a number of PAM modules as described in Section 27.2, Background Information for Linux AD Support. The pam_winbind module used to authenticate clients against Active Directory or NT4 domains is fully aware of Windows error conditions that might prohibit a user's login. The Windows error codes are translated into appropriate user-readable error messages that PAM gives at login through any of the supported methods (GDM, KDM, console, and SSH):

Password has expired

The user sees a message stating that the password has expired and needs to be changed. The system prompts directly for a new password and informs the user if the new password does not comply with corporate password policies, for example, the password is too short, too simple, or already in the history. If a user's password change fails, the reason is shown and a new password prompt is given.

Account disabled

The user sees an error message stating that his account has been disabled and that he should contact the system administrator.

Account locked out

The user sees an error message stating that his account has been locked and that he should contact the system administrator.

Password has to be changed

The user can log in but receives a warning that the password needs to be changed soon. This warning is sent three days before that password expires. After expiration, the user cannot login again.

Invalid workstation

When a user is just allowed to log in from specific workstations and the current openSUSE machine is not in that list, a message appears that this user cannot log in from this workstation.

Invalid logon hours

When a user is only allowed to log in during working hours and tries to log in outside working hours, a message shows that login is not possible at this point in time.

Account expired

An administrator can set an expiration time for a specific user account. If that user tries to log in after that time has passed, the user gets a message that the account has expired and cannot be used to log in.

During a successful authentication, pam_winbind acquires a ticket granting ticket (TGT) from the Kerberos server of Active Directory and stores it in the user's credential cache. It also takes care of renewing the TGT in the background, not requiring any user interaction.

openSUSE supports local home directories for AD users. If configured through YaST as described in Section 27.3, Configuring a Linux Client for Active Directory, user homes are created at the first login of a Windows (AD) user into the Linux client. These home directories look and feel entirely the same as standard Linux user home directories and work independently of the AD domain controller. Using a local user home, it is possible to access a user's data on this machine, even when the AD server is disconnected, if the Linux client has been configured to perform offline authentication.

27.2.3 Offline Service and Policy Support

Users in a corporate environment must have the ability to become roaming users, for example, to switch networks or even work disconnected for some time. To enable users to log in to a disconnected machine, extensive caching was integrated into the winbind daemon. The winbind daemon enforces password policies even in the offline state. It tracks the number of failed login attempts and reacts according to the policies configured in Active Directory. Offline support is disabled by default and must be explicitly enabled in the YaST Domain Membership module.

As in Windows, when the domain controller has become unavailable, the user can still access network resources (other than the AD server itself) with valid Kerberos tickets that have been acquired before losing the connection. Password changes cannot be processed unless the domain controller is online. While disconnected from the AD server, a user cannot access any data stored on this server. When a workstation has become disconnected from the network entirely and attaches to the corporate network again later, openSUSE acquires a new Kerberos ticket as soon as the user has locked and unlocked the desktop (for example, using a desktop screen saver).