Applies to openSUSE Leap 15.4

7 Active Directory support #

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

7.1 Integrating Linux and Active Directory 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 Leap Linux client:

Browsing shared files and directories with SMB: GNOME Files (previously called Nautilus) supports browsing shared resources through SMB.
Sharing files and directories with SMB: GNOME Files supports sharing directories and files as in Windows.
Accessing and manipulating user data on the Windows server: Through GNOME Files, users can access their Windows user data and can edit, create, and delete files and directories on the Windows server. Users can access their data without having to enter their password multiple times.
Offline authentication: Users can log in and access their local data on the Linux machine even if they are offline or the Active Directory server is unavailable for other reasons.
Windows password change: This port of Active Directory 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 desktop applications 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.

Note: Managing Unix attributes from Windows Server* 2016 and later

In Windows Server 2016 and later, Microsoft has removed the role IDMU/NIS Server and along with it the Unix Attributes plug-in for the Active Directory Users and Computers MMC snap-in.

However, Unix attributes can still be managed manually when Advanced Options are enabled in the Active Directory Users and Computers MMC snap-in. For more information, see https://blogs.technet.microsoft.com/activedirectoryua/2016/02/09/identity-management-for-unix-idmu-is-deprecated-in-windows-server/.

Alternatively, use the method described in Procedure 7.1, “Joining an Active Directory domain using User logon management” to complete attributes on the client side (in particular, see Step 6.c).

The following section contains technical background for most of the previously named features. For more information about file and printer sharing using Active Directory, see Book “GNOME User Guide”.

7.2 Background information for Linux Active Directory support #

Many system components need to interact flawlessly to integrate a Linux client into an existing Windows Active Directory domain. The following sections focus on the underlying processes of the key events in Active Directory server and client interaction.

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 Active Directory can use the LDAP protocol to exchange directory information with the clients. To learn more about LDAP in general, refer to Chapter 5, LDAP with 389 Directory Server.
Kerberos: Kerberos is a third-party trusted authentication service. All its clients trust Kerberos 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. To learn more about Kerberos in Linux, refer to Chapter 6, Network authentication with Kerberos.

Depending on which YaST module you use to set up Kerberos authentication, different client components process account and authentication data:

Solutions based on SSSD

The sssd daemon is the central part of this solution. It handles all communication with the Active Directory server.
To gather name service information, sssd_nss is used.
To authenticate users, the pam_sss module for PAM is used. The creation of user homes for the Active Directory users on the Linux client is handled by pam_mkhomedir.
For more information about PAM, see Chapter 2, Authentication with PAM.

Solution based on Winbind (Samba)

The winbindd daemon is the central part of this solution. It handles all communication with the Active Directory server.
To gather name service information, nss_winbind is used.
To authenticate users, the pam_winbind module for PAM is used. The creation of user homes for the Active Directory users on the Linux client is handled by pam_mkhomedir.
For more information about PAM, see Chapter 2, Authentication with PAM.

Figure 7.1, “Schema of Winbind-based Active Directory authentication” highlights the most prominent components of Winbind-based Active Directory authentication.

Figure 7.1: Schema of Winbind-based Active Directory authentication #

Applications that are PAM-aware, like the login routines and the GNOME display manager, 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.

7.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 Windows 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 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 service.
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 controller.

7.2.2 Domain login and user homes #

The login manager of GNOME (GDM) has been extended to allow the handling of Active Directory 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 several PAM modules as described in Section 7.2, “Background information for Linux Active Directory support”. If there are errors, the error codes are translated into user-readable error messages that PAM gives at login through any of the supported methods (GDM, 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 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 Leap 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, the client 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 Leap supports local home directories for Active Directory users. If configured through YaST as described in Section 7.3, “Configuring a Linux client for Active Directory”, user home directories are created when a Windows/Active Directory user first logs in to the Linux client. These home directories look and feel identical to standard Linux user home directories and work independently of the Active Directory Domain Controller.

Using a local user home, it is possible to access a user's data on this machine (even when the Active Directory server is disconnected) as long as the Linux client has been configured to perform offline authentication.

7.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 Active Directory 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 Active Directory 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 Leap acquires a new Kerberos ticket when the user has locked and unlocked the desktop (for example, using a desktop screen saver).

7.3 Configuring a Linux client for Active Directory #

Before your client can join an Active Directory 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 Active Directory DNS server. Alternatively, configure your machine to use the Active Directory 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 be also 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 7.2, “Joining an Active Directory domain using Windows domain membership”.

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 › Finish. To disable the firewall, check the Disable Firewall Automatic Starting option, and leave the firewall module with Next › Finish.

Active Directory account

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

7.3.1 Choosing which YaST module to use for connecting to Active Directory #

YaST contains multiple modules that allow connecting to an Active Directory:

User logon management. Use both an identity service (usually LDAP) and a user authentication service (usually Kerberos). This option is based on SSSD and in the majority of cases is best suited for joining Active Directory domains.
This module is described in Section 7.3.2, “Joining Active Directory using User logon management”.
Windows domain membership. Join an Active Directory (which entails use of Kerberos and LDAP). This option is based on winbind and is best suited for joining an Active Directory domain if support for NTLM or cross-forest trusts is necessary.
This module is described in Section 7.3.3, “Joining Active Directory using Windows domain membership”.

7.3.2 Joining Active Directory using User logon management #

The YaST module User Logon Management supports authentication at an Active Directory. Additionally, it also supports the following related authentication and identification providers:

Identification providers

Delegate to third-party software library. Support for legacy NSS providers via a proxy.
FreeIPA. FreeIPA and Red Hat Enterprise Identity Management provider.
Generic directory service (LDAP). An LDAP provider. For more information about configuring LDAP, see man 5 sssd-ldap.
Local SSSD file database. An SSSD-internal provider for local users.

Authentication providers

Delegate to third-party software library. Relay authentication to another PAM target via a proxy.
FreeIPA. FreeIPA and Red Hat Enterprise Identity Management provider.
Generic Kerberos service. An LDAP provider.
Generic directory service (LDAP). Kerberos authentication.
Local SSSD file database. An SSSD-internal provider for local users.
This domain does not provide authentication service. Disables authentication explicitly.

To join an Active Directory domain using SSSD and the User Logon Management module of YaST, proceed as follows:

Procedure 7.1: Joining an Active Directory domain using User logon management #

Open YaST.
To be able to use DNS auto-discovery later, set up the Active Directory Domain Controller (the Active Directory server) as the name server for your client.
1. In YaST, click Network Settings.
2. Select Hostname/DNS, then enter the IP address of the Active Directory Domain Controller into the text box Name Server 1.
  Save the setting with OK.
From the YaST main window, start the module User Logon Management.
The module opens with an overview showing different network properties of your computer and the authentication method currently in use.
Figure 7.2: Main window of User logon management #
To start editing, click Change Settings.
Now join the domain.
1. Click Add Domain.
2. In the appearing dialog, specify the correct Domain name. Then specify the services to use for identity data and authentication: Select Microsoft Active Directory for both.
  Ensure that Enable the domain is activated.
  Click OK.
3. (Optional) Usually, you can keep the default settings in the following dialog. However, there are reasons to make changes:
  - If the local host name does not match the host name set on the domain controller. Find out if the host name of your computer matches what the name your computer is known as to the Active Directory Domain Controller. In a terminal, run the command hostname, then compare its output to the configuration of the Active Directory Domain Controller.
    If the values differ, specify the host name from the Active Directory configuration under AD hostname. Otherwise, leave the appropriate text box empty.
  - If you do not want to use DNS auto-discovery. Specify the Host names of Active Directory servers that you want to use. If there are multiple Domain Controllers, separate their host names with commas.
4. To continue, click OK.
  If not all software is installed already, the computer will now install missing software. It will then check whether the configured Active Directory Domain Controller is available.
5. If everything is correct, the following dialog should now show that it has discovered an Active Directory Server but that you are Not yet enrolled.
  In the dialog, specify the Username and Password of the Active Directory administrator account (usually Administrator).
  To make sure that the current domain is enabled for Samba, activate Overwrite Samba configuration to work with this AD.
  To enroll, click OK.
  Figure 7.3: Enrolling into a domain #
6. You should now see a message confirming that you have enrolled successfully. Finish with OK.
After enrolling, configure the client using the window Manage Domain User Logon.
Figure 7.4: Configuration window of User logon management #
1. To allow logging in to the computer using login data provided by Active Directory, activate Allow Domain User Logon.
2. (Optional) Optionally, under Enable domain data source, activate additional data sources such as information on which users are allowed to use sudo or which network drives are available.
3. To allow Active Directory users to have home directories, activate Create Home Directories. The path for home directories can be set in multiple ways—on the client, on the server, or both ways:
  - To configure the home directory paths on the Domain Controller, set an appropriate value for the attribute UnixHomeDirectory for each user. Additionally, make sure that this attribute replicated to the global catalog. For information on achieving that under Windows, see https://support.microsoft.com/en-us/kb/248717.
  - To configure home directory paths on the client in such a way that precedence will be given to the path set on the domain controller, use the option fallback_homedir.
  - To configure home directory paths on the client in such a way that the client setting will override the server setting, use override_homedir.
  As settings on the Domain Controller are outside of the scope of this documentation, only the configuration of the client-side options will be described in the following.
  From the side bar, select Service Options › Name switch, then click Extended Options. From that window, select either fallback_homedir or override_homedir, then click Add.
  Specify a value. To have home directories follow the format /home/USER_NAME, use /home/%u. For more information about possible variables, see the man page sssd.conf (man 5 sssd.conf), section override_homedir.
  Click OK.
Save the changes by clicking OK. Then make sure that the values displayed now are correct. To leave the dialog, click Cancel.

7.3.3 Joining Active Directory using Windows domain membership #

To join an Active Directory domain using winbind and the Windows Domain Membership module of YaST, proceed as follows:

Procedure 7.2: Joining an Active Directory domain using Windows domain membership #

Log in as root and start YaST.
Start Network Services › Windows Domain Membership.
Enter the domain to join at Domain or Workgroup in the Windows Domain Membership screen (see Figure 7.5, “Determining Windows domain membership”). If the DNS settings on your host are properly integrated with the Windows DNS server, enter the Active Directory 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.
Figure 7.5: Determining Windows domain membership #
To use the SMB source for Linux authentication, activate Also Use SMB Information for Linux Authentication.
To automatically create a local home directory for Active Directory users on the Linux machine, activate Create Home Directory on Login.
Check Offline Authentication to allow your domain users to log in even if the Active Directory server is temporarily unavailable, or if you do not have a network connection.
To change the UID and GID ranges for the Samba users and groups, select Expert Settings. Let DHCP retrieve the WINS server only if you need it. This is the case when some machines are resolved only by the WINS system.
Configure NTP time synchronization for your Active Directory 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 stand-alone YaST NTP configuration module.
Click OK and confirm the domain join when prompted for it.
Provide the password for the Windows administrator on the Active Directory server and click OK (see Figure 7.6, “Providing administrator credentials”).
Figure 7.6: Providing administrator credentials #

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

Important: Domain name

Joining a domain may not succeed if the domain name ends with .local. Names ending in .local cause conflicts with Multicast DNS (MDNS) where .local is reserved for link-local host names.

Note: Only administrators can enroll a computer

Only a domain administrator account, such as Administrator, can join openSUSE Leap into Active Directory.

7.3.4 Checking Active Directory connection status #

To check whether you are successfully enrolled in an Active Directory domain, use the following commands:

klist shows whether the current user has a valid Kerberos ticket.
getent passwd shows published LDAP data for all users.

7.4 Logging in to an Active Directory 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 Active Directory credentials. Login is supported for GNOME, the console, SSH, and any other PAM-aware application.

Important: Offline authentication

openSUSE Leap supports offline authentication, allowing you to log in to your client machine even when it is offline. See Section 7.2.3, “Offline service and policy support” for details.

7.4.1 GDM #

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

Click Not listed.
In the text box Username, enter the domain name and the Windows user name in this form: DOMAIN_NAME\USER_NAME.
Enter your Windows password.

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

7.4.2 Console login #

Besides logging in to the Active Directory client machine using a graphical front-end, you can log in using the text-based console or even remotely using SSH.

To log in to your Active Directory client from a console, enter DOMAIN_NAME\USER_NAME at the login: prompt and provide the password.

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

At the login prompt, enter:
```
> ssh DOMAIN_NAME\\USER_NAME@HOST_NAME
```
The \ domain and login delimiter is escaped with another \ sign.
Provide the user's password.

7.5 Changing passwords #

openSUSE Leap helps the 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 Leap 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 provides feedback about password expiration and the prompt for new passwords in an interactive mode. To change passwords in the display managers, 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:

Log in at the console.
Enter passwd.
Enter your current password when prompted.
Enter the new password.
Reenter the new password for confirmation. If your new password does not comply with the policies on the Windows server, this feedback is given to you and you are prompted for another password.

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

Click the Computer icon on the left edge of the panel.
Select Control Center.
From the Personal section, select About Me › Change Password.
Enter your old password.
Enter and confirm the new password.
Leave the dialog with Close to apply your settings.

7.6 Active Directory certificate auto-enrollment #

Certificate auto-enrollment enables network devices to automatically enroll certificates from Active Directory Certificate Services, including SUSE Linux Enterprise Server devices, with no user intervention. This is managed by Active Directory's Group Policy, using Samba's samba-gpupdate command.

7.6.1 Configuring certificate auto-enrollment on the server #

The Windows server roles Certification Authority, Certificate Enrollment Policy Web Service, Certificate Enrollment Web Service, and Network Device Enrollment Service all must be installed and configured on the Active Directory server.

Configure Group Policy auto-enrollment as described in this Microsoft documentation: https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/configure-server-certificate-autoenrollment#configure-server-certificate-auto-enrollment.

7.6.2 Enable certificate auto-enrollment on the client #

Follow the steps in the following procedure to enable certificate on your clients.

Install the samba-gpupdate package. This will automatically install the certmonger, cepces, and sscep dependencies. Samba uses sscep to download the Certificate Authority root chain, then uses the certmonger paired with cepces to monitor the host certificate templates.
Join to an Active Directory domain (one where the CA has been previously configured as explained in Section 7.6.1, “Configuring certificate auto-enrollment on the server”).
On Winbind-joined machines, set the smb.conf global parameter by adding the line apply group policies = yes.
For SSSD-joined machines, install oddjob-gpupdate from https://github.com/openSUSE/oddjob-gpupdate.

Then verify that certificate auto-enrollment is correctly configured by running the following command on the client:

> /usr/sbin/samba-gpupdate --rsop

If you see output like the following example, it is correctly configured:

Resultant Set of Policy
Computer Policy
GPO: Default Domain Policy
==========================================================
CSE: gp_cert_auto_enroll_ext
-----------------------------------------------------------
Policy Type: Auto Enrollment Policy
-----------------------------------------------------------
[ <CA NAME> ] =
[ CA Certificate ] =
----BEGIN CERTIFICATE----
<CERTIFICATE>
----END CERTIFICATE----
[ Auto Enrollment Server ] = <DNS NAME>

Use the following command to display installed certificates:

> getcert list
 Number of certificates and requests being tracked: 1.
 Request ID 'Machine':
 status: MONITORING
 stuck: no
 key pair storage: type=FILE,location='/var/lib/samba/private/certs/Machine.key'
 certificate: type=FILE,location='/var/lib/samba/certs/Machine.crt'
 CA: <CA NAME>
 issuer: CN=<CA NAME>
 subject: CN=<HOSTNAME>
 expires: 2017-08-15 17:37:02 UTC
 dns: <hostname>
 key usage: digitalSignature,keyEncipherment
 eku: id-kp-clientAuth,id-kp-serverAuth
 certificate template/profile: Machine

Certificates are installed in /var/lib/samba/certs and private keys are installed in /var/lib/samba/private/certs.

For more information, see man samba-gpupdate.