Chapter 1. Connecting RHEL systems directly to AD using SSSD

This section describes using the System Security Services Daemon (SSSD) to connect a RHEL system to Active Directory (AD). You need two components to connect a RHEL system to Active Directory (AD). One component, SSSD, interacts with the central identity and authentication source, and the other component, realmd, detects available domains and configures the underlying RHEL system services, in this case SSSD, to connect to the domain.

1.1. Overview of direct integration using SSSD

You use SSSD to access a user directory for authentication and authorization through a common framework with user caching to permit offline logins. SSSD is highly configurable; it provides Pluggable Authentication Modules (PAM) and Name Switch Service (NSS) integration and a database to store local users as well as extended user data retrieved from a central server. SSSD is the recommended component to connect a RHEL system with one of the following types of identity server:

  • Active Directory
  • Identity Management (IdM) in RHEL
  • Any generic LDAP or Kerberos server
Note

Direct integration with SSSD works only within a single AD forest by default.

The most convenient way to configure SSSD to directly integrate a Linux system with AD is to use the realmd service. It allows callers to configure network authentication and domain membership in a standard way. The realmd service automatically discovers information about accessible domains and realms and does not require advanced configuration to join a domain or realm.

You can use SSSD for both direct and indirect integration with AD and it allows you to switch from one integration approach to another. Direct integration is a simple way to introduce RHEL systems to an AD environment. However, as the share of RHEL systems grows, your deployments usually need a better centralized management of the identity-related policies such as host-based access control, sudo, or SELinux user mappings. Initially, you can maintain the configuration of these aspects of the RHEL systems in local configuration files. However, with a growing number of systems, distribution and management of the configuration files is easier with a provisioning system such as Red Hat Satellite. When direct integration does not scale anymore, you should consider indirect integration. For more information on moving from direct integration (RHEL clients are in the AD domain) to indirect integration (IdM with trust to AD), see Moving RHEL clients from AD domain to IdM Server.

For more information on which type of integration fits your use case, see Deciding between indirect and direct integration.

Additional resources

  • The realm(8) man page.
  • The sssd-ad(5) man page.
  • The sssd(8) man page.

1.2. Supported Windows platforms for direct integration

You can directly integrate your RHEL system with Active Directory forests that use the following forest and domain functional levels:

  • Forest functional level range: Windows Server 2008 - Windows Server 2016
  • Domain functional level range: Windows Server 2008 - Windows Server 2016

Direct integration has been tested on the following supported operating systems:

  • Windows Server 2019
  • Windows Server 2016
  • Windows Server 2012 R2
Note

Windows Server 2019 does not introduce a new functional level. The highest functional level Windows Server 2019 uses is Windows Server 2016.

1.3. Connecting directly to AD

This section describes how to integrate directly with AD using either ID mapping or POSIX attributes.

1.3.1. Connecting a RHEL system to an AD Domain

This procedure describes how to connect a RHEL system to an AD domain using SSSD.

Prerequisites

  • Ensure that none of the following ports are blocked to the AD domain controllers.

    Table 1.1. Ports Required for Direct Integration of Linux Systems into AD Using SSSD

    ServicePortProtocolNotes

    DNS

    53

    UDP and TCP

     

    LDAP

    389

    UDP and TCP

     

    Kerberos

    88

    UDP and TCP

     

    Kerberos

    464

    UDP and TCP

    Used by kadmin for setting and changing a password

    LDAP Global Catalog

    3268

    TCP

    If the id_provider = ad option is being used

    NTP

    123

    UDP

    Optional

  • Ensure that you are using the AD domain controller server for DNS.
  • Verify that the system time on both systems is synchronized. This ensures that Kerberos is able to work correctly.

Procedure

  1. Install the following packages:

    # yum install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
  2. Configure the local RHEL system with the realm join command. The realmd suite edits all required configuration files automatically. For example, for a domain named ad.example.com:

    # realm join ad.example.com

    If you do not want to use realmd, you can configure the system manually. See Manually Connecting an SSSD Client to an Active Directory Domain in the Red Hat Knowledgebase.

Verification steps

  • Display an AD user details, such as the administrator user:

    # getent passwd administrator@ad.example.com
    administrator@ad.example.com:*:1450400500:1450400513:Administrator:/home/administrator@ad.example.com:/bin/bash

Additional resources

  • See the realm(8) man page.
  • See the nmcli(1) man page.

1.3.2. Options for integrating with AD: using ID mapping or POSIX attributes

Linux and Windows systems use different identifiers for users and groups:

  • Linux uses user IDs (UID) and group IDs (GID). See Managing Users and Groups in Configuring Basic System Settings. Linux UIDs and GIDs are compliant with the POSIX standard.
  • Windows use security IDs (SID).
Important

Do not use the same user name in Windows and Linux.

To authenticate to a RHEL system as an AD user, you must have a UID and GID assigned. SSSD provides the option to integrate with AD either using ID mapping or POSIX attributes. The default is to use ID mapping.

1.3.2.1. Automatically generate new UIDs and GIDs for AD users

SSSD can use the SID of an AD user to algorithmically generate POSIX IDs in a process called ID mapping. ID mapping creates a map between SIDs in AD and IDs on Linux.

  • When SSSD detects a new AD domain, it assigns a range of available IDs to the new domain.
  • When an AD user logs in to an SSSD client machine for the first time, SSSD creates an entry for the user in the SSSD cache, including a UID based on the user’s SID and the ID range for that domain.
  • Because the IDs for an AD user are generated in a consistent way from the same SID, the user has the same UID and GID when logging in to any Red Hat Enterprise Linux system.

See Connecting a RHEL system to an AD Domain using SSSD.

Note

When all client systems use SSSD to map SIDs to Linux IDs, the mapping is consistent. If some clients use different software, choose one of the following:

  • Ensure that the same mapping algorithm is used on all clients.
  • Use explicit POSIX attributes defined in AD.

1.3.2.2. Use POSIX attributes defined in AD

AD can create and store POSIX attributes, such as uidNumber, gidNumber, unixHomeDirectory, or loginShell.

When using ID mapping described above, SSSD creates new UIDs and GIDs, which overrides the values defined in AD. To keep the AD-defined values, you must disable ID mapping in SSSD.

See Connecting to AD using POSIX attributes defined in Active Directory.

1.3.3. Connecting to AD using POSIX attributes defined in Active Directory

For best performance, publish the POSIX attributes to the AD global catalog. If POSIX attributes are not present in the global catalog, SSSD connects to the individual domain controllers directly on the LDAP port.

Prerequisites

  • Ensure that none of the following ports are blocked to the AD domain controllers.

    Table 1.2. Ports Required for Direct Integration of Linux Systems into AD Using SSSD

    ServicePortProtocolNotes

    DNS

    53

    UDP and TCP

     

    LDAP

    389

    UDP and TCP

     

    Kerberos

    88

    UDP and TCP

     

    Kerberos

    464

    UDP and TCP

    Used by kadmin for setting and changing a password

    LDAP Global Catalog

    3268

    TCP

    If the id_provider = ad option is being used

    NTP

    123

    UDP

    Optional

  • Ensure that you are using the AD domain controller server for DNS.
  • Verify that the system time on both systems is synchronized. This ensures that Kerberos is able to work correctly.

Procedure

  1. Install the following packages:

    # yum install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
  2. Configure the local RHEL system with ID mapping disabled using the realm join command with the --automatic-id-mapping=no option. The realmd suite edits all required configuration files automatically. For example, for a domain named ad.example.com:

    # realm join --automatic-id-mapping=no ad.example.com
  3. If you already joined a domain, you can manually disable ID Mapping in SSSD:

    1. Open the /etc/sssd/sssd.conf file.
    2. In the AD domain section, add the ldap_id_mapping = false setting.
    3. Remove the SSSD caches:

      rm -f /var/lib/sss/db/*
    4. Restart SSSD:

      systemctl restart sssd

SSSD now uses POSIX attributes from AD, instead of creating them locally.

Note

You must have the relevant POSIX attributes (uidNumber, gidNumber, unixHomeDirectory, and loginShell) configured for the users in AD.

Verification steps

  • Display an AD user details, such as the administrator user:

    # getent passwd administrator@ad.example.com
    administrator@ad.example.com:*:10000:10000:Administrator:/home/Administrator:/bin/bash

Additional resources

  • For further details about ID mapping and the ldap_id_mapping parameter, see the sssd-ldap(8) man page.

1.3.4. Connecting to multiple domains in different AD forests with SSSD

This procedure describes joining and authenticating to multiple Active Directory (AD) domains in different forests where there is no trust between them.

This example describes joining two domains, addomain1.com and addomain2.com. Use realmd to join the first domain and automatically configure SSSD, Kerberos, and other utilities for that domain. Use adcli to join additional domains, and manually edit configuration files to include those domains.

Prerequisites

  • Ensure that none of the following ports are blocked to the AD domain controllers.

    Table 1.3. Ports Required for Direct Integration of Linux Systems into AD Using SSSD

    ServicePortProtocolNotes

    DNS

    53

    UDP and TCP

     

    LDAP

    389

    UDP and TCP

     

    Kerberos

    88

    UDP and TCP

     

    Kerberos

    464

    UDP and TCP

    Used by kadmin for setting and changing a password

    LDAP Global Catalog

    3268

    TCP

    If the id_provider = ad option is being used

    NTP

    123

    UDP

    Optional

  • Ensure that you are using the AD domain controller server for DNS.
  • Verify that the system time on both systems is synchronized. This ensures that Kerberos is able to work correctly.
  • Ensure you have credentials for an AD administrator account in each AD domain which has rights to join machines to that domain

Procedure

  1. Install required packages.

    # yum install sssd realmd adcli samba-common-tools oddjob oddjob-mkhomedir
  2. Use realmd to join the first AD domain, addomain1.com.

    # realm join ADDOMAIN1.COM
  3. Rename the system keytab to a unique name.

    # mv /etc/krb5.keytab /etc/addomain1.com.krb5.keytab
  4. Use adcli to join the second AD domain, and any additional domains. Use the -K option to specify a unique path for the Kerberos keytab where host credentials will be written.

    # adcli join -D dc2.addomain2.com -K /etc/addomain2.com.krb5.keytab
  5. Modify /etc/krb5.conf.

    • Add the includedir option to include SSSD configuration files.
    • Enable DNS lookups for AD Domain Controllers with the dns_lookup_kdc option.

      includedir /var/lib/sss/pubconf/krb5.include.d/
      
      [logging]
       default = FILE:/var/log/krb5libs.log
       kdc = FILE:/var/log/krb5kdc.log
       admin_server = FILE:/var/log/kadmind.log
      
      [libdefaults]
       default_realm = ADDOMAIN1.COM
       dns_lookup_realm = false
       dns_lookup_kdc = true
       ticket_lifetime = 24h
       renew_lifetime = 7d
       forwardable = true
      
      ...
  6. Modify /etc/sssd/sssd.conf to include information about all AD domains in use.

    [sssd]
    services = nss, pam
    config_file_version = 2
    domains = addomain1.com, addomain2.com
    
    [domain/addomain1.com]
    id_provider = ad
    access_provider = ad
    krb5_keytab = /etc/addomain1.com.krb5.keytab
    ldap_krb5_keytab = /etc/addomain1.com.krb5.keytab
    ad_server = dc1.addomain1.com
    ad_maximum_machine_account_password_age = 0
    use_fully_qualified_names = true
    default_shell=/bin/bash
    override_homedir=/home/%d/%u
    
    [domain/addomain2.com]
    id_provider = ad
    access_provider = ad
    krb5_keytab = /etc/addomain2.com.krb5.keytab
    ldap_krb5_keytab = /etc/addomain2.com.krb5.keytab
    ad_server = dc2.addomain2.com
    ad_maximum_machine_account_password_age = 0
    use_fully_qualified_names = true
    default_shell=/bin/bash
    override_homedir=/home/%d/%u
    
    [nss]
    
    [pam]
    • For each domain section, specify the path to the Kerberos keytab that corresponds to each domain with the krb5_keytab and ldap_krb5_keytab options.
    • Set ad_maximum_machine_account_password_age = 0 to disable renewing host Kerberos keys.
    • Set use_fully_qualified_names = true to differentiate users from different domains.
    • Set override_homedir = /home/%d/%u so users (%u) from different domains (%d) each receive unique home directories. For example, the home directory for user linuxuser@addomain1.com is /home/addomain1.com/linuxuser.
  7. SSH retrieves host keys from the system keytab and provides single sign-on functionality through GSSAPI/Kerberos. If you would like to use single sign-on, copy all current Kerberos host keys to the /etc/kbr5.keytab system keytab.

    # ktutil
    ktutil:  rkt /etc/addomain1.com.krb5.keytab
    ktutil:  rkt /etc/addomain2.com.krb5.keytab
    ktutil:  wkt /etc/krb5.keytab
  8. Restart and enable the SSSD service.

    # systemctl restart sssd
    # systemctl enable sssd

Verification steps

  1. Display user details for users from each AD domain:

    # id administrator@addomain1.com
    uid=1240800500(administrator@addomain1.com) gid=1240800513(domain users@addomain1.com) groups=1240800513(domain users@addomain1.com),1240800512(domain admins@addomain1.com),1240800518(schema admins@addomain1.com),1240800520(group policy creator owners@addomain1.com),1240800572(denied rodc password replication group@addomain1.com),1240800519(enterprise admins@addomain1.com)
    
    # id administrator@addomain2.com
    uid=1013800500(administrator@addomain2.com) gid=1013800500(administrator@addomain2.com) groups=1013800500(administrator@addomain2.com),1013800513(domain users@addomain2.com)
  2. Log in as a user from each domain and verify the correct home directory is created for the user.

    # ssh administrator@addomain1.com@localhost
    administrator@addomain1.com@localhost's password:
    Creating directory '/home/addomain1.com/administrator'.
    
    $ pwd
    /home/addomain1.com/administrator
    # ssh administrator@addomain2.com@localhost
    administrator@addomain2.com@localhost's password:
    Creating directory '/home/addomain2.com/administrator'.
    
    $ pwd
    /home/addomain2.com/administrator

1.4. How the AD provider handles trusted domains

This section describes how SSSD handles trusted domains if you set id_provider = ad in the /etc/sssd/sssd.conf file.

  • SSSD only supports domains in a single AD forest. If SSSD requires access to multiple domains from multiple forests, consider using IPA with trusts (preferred) or the winbindd service instead of SSSD.
  • By default, SSSD discovers all domains in the forest and, if a request for an object in a trusted domain arrives, SSSD tries to resolve it.

    If the trusted domains are not reachable or geographically distant, which makes them slow, you can set the ad_enabled_domains parameter in /etc/sssd/sssd.conf to limit from which trusted domains SSSD resolves objects.

  • By default, you must use fully-qualified user names to resolve users from trusted domains.

Additional resources

  • The sssd.conf(5)` man page.

1.5. realm commands

The realmd system has two major task areas:

  • Managing system enrollment in a domain.
  • Controlling which domain users are allowed to access local system resources.

In realmd use the command line tool realm to run commands. Most realm commands require the user to specify the action that the utility should perform, and the entity, such as a domain or user account, for which to perform the action.

Table 1.4. realmd Commands

CommandDescription

Realm Commands

discover

Run a discovery scan for domains on the network.

join

Add the system to the specified domain.

leave

Remove the system from the specified domain.

list

List all configured domains for the system or all discovered and configured domains.

Login Commands

permit

Enable access for specific users or for all users within a configured domain to access the local system.

deny

Restrict access for specific users or for all users within a configured domain to access the local system.

For more information about the realm commands, see the realm(8) man page.