Chapter 5. Active Directory Support

Contents

5.1. Integrating Linux and AD Environments
5.2. Background Information for Linux AD Support
5.3. Configuring a Linux Client for Active Directory
5.4. Logging In to an AD Domain
5.5. Changing Passwords

Active Directory* (AD) is a directory-service based on LDAP, Kerberos, and other services that is used by Microsoft Windows to manage resources, services, and people. In an MS Windows network, AD provides information about these objects, restricts access to them, and enforces policies. openSUSE® lets you join existing AD domains and integrate your Linux machine into a Windows environment.

5.1. Integrating Linux and AD Environments

With a Linux client (configured as an Active Directory client) that is joined to an existing Active Directory domain, benefit from various features not available on a pure openSUSE Linux client:

Browsing Shared Files and Folders with SMB

Both Nautilus (the GNOME file manager) and Konqueror (its KDE counterpart) support browsing shared resources through SMB.

Sharing Files and Folders with SMB

Both Nautilus (the GNOME file manager) and Konqueror (its KDE counterpart) support sharing folders and files as in Windows.

Accessing and Manipulating User Data on the Windows Server

Through Nautilus and Konqueror, users are able to access their Windows user data and can edit, create, and delete files and folders on the Windows server. Users can access their data without having to enter their password multiple times.

Offline Authentication

Users are able to log in and access their local data on the Linux machine even if they are offline or the AD server is unavailable for other reasons.

Windows Password Change

This port of AD support in Linux enforces corporate password policies stored in Active Directory. The display managers and console support password change messages and accept your input. You can even use the Linux passwd command to set Windows passwords.

Single-Sign-On through Kerberized Applications

Many applications of both desktops are Kerberos-enabled (kerberized), which means they can transparently handle authentication for the user without the need for password reentry at Web servers, proxies, groupware applications, or other locations.

A brief technical background for most of these features is given in the following section.

5.2. Background Information for Linux AD Support

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

Figure 5.1. Active Directory Authentication Schema

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 Chapter 4, LDAP—A Directory Service.

Kerberos

Kerberos is a third-party trusted authentication service. All its clients trust Kerberos's authorization 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 Chapter 2, 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.

5.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, which can be run during installation or in the installed system. The steps involved are:

  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.

5.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 into 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 5.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

A message stating that the password has expired and needs to be changed is displayed. The system prompts 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 the account has been disabled and to contact the system administrator.

Account locked out

The user sees an error message stating that the account has been locked and to 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 log in.

Invalid workstation

When a user is restricted to specific workstations and the current openSUSE machine is not among them, 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 informs the user that logging in is not possible at that time.

Account expired

An administrator can set an expiration time for a specific user account. If that user tries to log in after expiration, 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 renews the TGT in the background, requiring no user interaction.

openSUSE supports local home directories for AD users. If configured through YaST as described in Section 5.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) as long as the Linux client has been configured to perform offline authentication.

It is also possible to mount server home directories automatically; for more information, see Section “Configuring Clients” (Chapter 29, Samba, ↑Reference).

5.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.

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 (as in Windows). 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 connects 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).

5.3. Configuring a Linux Client for Active Directory

Before your client can join an AD domain, some adjustments must be made to your network setup to ensure the flawless interaction of client and server.

DNS

Configure your client machine to use a DNS server that can forward DNS requests to the AD DNS server. Alternatively, configure your machine to use the AD DNS server as the name service data source.

NTP

To succeed with Kerberos authentication, the client must have its time set accurately. It is highly recommended to use a central NTP time server for this purpose (this can also be the NTP server running on your Active Directory domain controller). If the clock skew between your Linux host and the domain controller exceeds a certain limit, Kerberos authentication fails and the client is logged in using the weaker NTLM (NT LAN Manager) authentication. For more details about using active directory for time synchronization, see Procedure 5.1, “Joining an AD Domain”.

DHCP

If your client uses dynamic network configuration with DHCP, configure DHCP to provide the same IP and hostname to the client. If possible, use static IP addresses.

Firewall

To browse your network neighborhood, either disable the firewall entirely or mark the interface used for browsing as part of the internal zone.

To change the firewall settings on your client, log in as root and start the YaST firewall module. Select Interfaces. Select your network interface from the list of interfaces and click Change. Select Internal Zone and apply your settings with OK. Leave the firewall settings with Next+Accept. To disable the firewall, just set Service Start to Manually and leave the firewall module with Next+Accept.

AD Account

You cannot log in to an AD domain unless the AD administrator has provided you with a valid user account for that domain. Use the AD username and password to log in to the AD domain from your Linux client.

Join an existing AD domain during installation (or by later activating SMB user authentication with YaST in the installed system).

[Note]

Currently only a domain administrator account, such as Administrator, can join openSUSE into Active Directory.

To join an AD domain in a running system, proceed as follows:

Procedure 5.1. Joining an AD Domain

  1. Log in as root and start YaST.

  2. Start Network Services+Windows Domain Membership.

  3. Enter the domain to join at Domain or Workgroup in the Windows Domain Membership screen (see Figure 5.2, “Determining Windows Domain Membership”). If the DNS settings on your host are properly integrated with the Windows DNS server, enter the AD domain name in its DNS format (mydomain.mycompany.com). If you enter the short name of your domain (also known as the pre–Windows 2000 domain name), YaST must rely on NetBIOS name resolution instead of DNS to find the correct domain controller. To select from a list of available domains instead, use Browse to list the NetBIOS domains, then select the desired domain.

    Figure 5.2. Determining Windows Domain Membership

    Determining Windows Domain Membership

  4. Check Also Use SMB Information for Linux Authentication to use the SMB source for Linux authentication.

  5. Check Create Home Directory on Login to automatically create a local home directory for your AD user on the Linux machine.

  6. Check Offline Authentication to allow your domain users to log in even if the AD server is temporarily unavailable, or if you do not have a network connection.

  7. Select Expert Settings, if you want to change the UID and GID ranges for the Samba users and groups. Let DHCP retrieve the WINS server only if you need it. This applies when some of your machines are resolved by the WINS system only.

  8. Configure NTP time synchronization for your AD environment by selecting NTP Configuration and entering an appropriate server name or IP address. This step is obsolete if you have already entered the appropriate settings in the standalone YaST NTP configuration module.

  9. Click Finish and confirm the domain join when prompted for it.

  10. Provide the password for the Windows administrator on the AD server and click OK (see Figure 5.3, “Providing Administrator Credentials”).

    Figure 5.3. Providing Administrator Credentials

    Providing Administrator Credentials

After you have joined the AD domain, you can log in to it from your workstation using the display manager of your desktop or the console.

5.4. Logging In to an AD Domain

Provided your machine has been configured to authenticate against Active Directory and you have a valid Windows user identity, you can log in to your machine using the AD credentials. Login is supported for both desktop environments (GNOME and KDE), the console, SSH, and any other PAM-aware application.

[Important]Offline Authentication

openSUSE supports offline authentication, allowing you to remain logged in to your client machine even if the client machine is disconnected from the network.

5.4.1. GDM and KDM

To authenticate a GNOME client machine against an AD server, proceed as follows:

  1. Select the domain.

  2. Enter your Windows username and press Enter.

  3. Enter your Windows password and press Enter.

To authenticate a KDE client machine against an AD server, proceed as follows:

  1. Select the domain.

  2. Enter your Windows username.

  3. Enter your Windows password and press Enter.

If configured to do so, openSUSE creates a user home directory on the local machine on the first login of each AD authenticated user. This allows you to benefit from the AD support of openSUSE while still having a fully functional Linux machine at your disposal.

5.4.2. Console Login

You can not only log in to the AD client machine using a graphical front-end, but also by using the text-based console login or by using SSH.

To log in to your AD client from a console, enter DOMAIN\user at the login: prompt and provide the password.

To remotely log in to your AD client machine using SSH, proceed as follows:

  1. At the login prompt, enter:

    ssh DOMAIN\\user@hostname
    

    The \ domain and login delimiter is escaped with another \ sign.

  2. Provide the user's password.

5.5. Changing Passwords

openSUSE has the ability to help a user choose a suitable new password that meets the corporate security policy. The underlying PAM module retrieves the current password policy settings from the domain controller, informing the user about the specific password quality requirements a user account typically has, by means of a message on login. Like its Windows counterpart, openSUSE presents a message describing:

  • Password history settings

  • Minimum password length requirements

  • Minimum password age

  • Password complexity

The password change process cannot succeed unless all requirements have been successfully met. Feedback about the password status is given both through the display managers and the console.

GDM and KDM provide feedback about password expiration and prompt for new passwords in an interactive mode. To change passwords in the display managers, just provide the password information when prompted.

To change your Windows password, you can use the standard Linux utility, passwd, instead of having to manipulate this data on the server. To change your Windows password, proceed as follows:

  1. Log in at the console.

  2. Enter passwd.

  3. Enter your current password when prompted.

  4. Enter the new password.

  5. Reenter the new password for confirmation. If your new password does not comply with the policies on the Windows server, you are prompted for another password.

To change your Windows password from the GNOME desktop, proceed as follows:

  1. Click the Computer icon on the left edge of the panel.

  2. Select Control Center.

  3. From the Personal section, select Change Password.

  4. Enter your old password.

  5. Enter and confirm the new password.

  6. Leave the dialog with Close to apply your settings.

To change your Windows password from the KDE desktop, proceed as follows:

  1. Select Personal Settings from the main menu.

  2. Select Security & Privacy.

  3. Click Password & User Account.

  4. Click Change Password.

  5. Enter your current password.

  6. Enter and confirm the new password and apply your settings with OK.

  7. Leave the Personal Settings with File+Quit.