11.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 11-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 11-1 Active Directory Authentication Schema
To communicate with the directory service, the client needs to
share at least two protocols with the server:
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 34.0,
LDAP—A Directory Service.
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. To learn more about Kerberos in Linux, refer to Section 40.0,
The following client components process account and authentication data:
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
- 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
- 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 23.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
11.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
The Windows domain controller providing both LDAP and KDC (Key
Distribution Center) services is located.
A machine account for the joining client is created in the directory
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.
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
11.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 11.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
- 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
policies, for example, the password is too short, too simple, or already
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
- Invalid workstation
When a user is just allowed to log in from specific workstations
and the current SUSE Linux Enterprise 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
SUSE Linux Enterprise Desktop supports local home directories for AD users. If configured through
YaST as described in Section 11.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.
11.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
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, SUSE Linux Enterprise acquires a new
Kerberos ticket as soon as the user has locked and unlocked the desktop
(for example, using a desktop screen saver).