Chapter 2. Using Active Directory as an Identity Provider for SSSD

The System Security Services Daemon (SSSD) is a system service to access remote directories and authentication mechanisms. It connects a local system (an SSSD client) to an external back-end system (a domain). This provides the SSSD client with access to identity and authentication remote services using an SSSD provider. For example, these remote services include: an LDAP directory, an Identity Management (IdM) or Active Directory (AD) domain, or a Kerberos realm.
When used as an identity management service for AD integration, SSSD is an alternative to services such as NIS or Winbind. This chapter describes how SSSD works with AD. For more details on SSSD, see the System-Level Authentication Guide.

2.1. Configuring an AD Provider for SSSD

The AD provider enables SSSD to use the LDAP identity provider and the Kerberos authentication provider with optimizations for AD environments.

2.1.1. Overview of the Integration Options

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 the System Administrator's Guide. Linux UIDs and GIDs are compliant with the POSIX standard.
  • Windows use security IDs (SID).
Users authenticating to a Red Hat Enterprise Linux system, including AD users, must have a UID and GID assigned. For this purpose, SSSD provides the following integration options:
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. Therefore, each AD domain has the same ID range on every SSSD client machine.
  • 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.

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:
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 in Automatically generate new UIDs and GIDs for AD users, 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.

2.1.2. Configuring an AD Domain with ID Mapping as a Provider for SSSD

Prerequisites

Make sure that both the AD system and the Linux system are properly configured:
  • Verify the configuration for name resolution. In particular, verify the DNS SRV records. For example, for a domain named ad.example.com:
    • To verify the DNS SRV LDAP records:
      # dig -t SRV _ldap._tcp.ad.example.com
    • To verify AD records:
      # dig -t SRV _ldap._tcp.dc._msdcs.ad.example.com
    If you later connect SSSD to a particular AD domain controller, it is not necessary to verify the DNS SRV records.
  • Verify that system time on both systems is synchronized. This ensures that Kerberos is able to work properly.
  • Open the required ports on both the Linux system and all AD domain controllers in both directions: from the Linux system to the AD domain controller and back.

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

    Service Port Protocol Notes
    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

Configure the Local System

Red Hat recommends using the realm join command to configure the system. See Chapter 3, Using realmd to Connect to an Active Directory Domain. The realmd suite edits all required configuration files automatically. For example:
# 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.

Optional: Configure User Home Directories and Shells

The pam_oddjob_mkhomedir.so library automatically creates home directories when users first log in to the Linux system. By default, SSSD retrieves the format of the home directory from the AD identity provider. To customize the directory format on Linux clients:
  1. Open the /etc/sssd/sssd.conf file.
  2. In the [domain] section, use one of these options:
    • fallback_homedir sets a fallback home directory format, which is used only if a home directory is not defined in AD
    • override_homedir sets a home directory template, which always overrides the home directory defined in AD
    For example, to always use the format /home/domain_name/user_name:
    [domain/EXAMPLE]
    [... file truncated ...]
    override_homedir = /home/%d/%u
    For details, see the sssd.conf(5) man page.
By default, SSSD retrieves information about user shells from the loginShell parameter configured in AD. To customize the user shell settings on Linux clients:
  1. Open the /etc/sssd/sssd.conf file.
  2. Define the required user shell settings using these options:
    • shell_fallback sets a fallback value, which is used only if no shells are defined in AD
    • override_shell sets a value that always overrides the shell defined in AD
    • default_shell sets a default shell value
    • allowed_shells and vetoed_shells set lists of allowed or blacklisted shells
    For details, see the sssd.conf(5) man page.

Load the New Configuration

  • Restart SSSD after changing the configuration file.
    # systemctl restart sssd.service

Additional Resources

  • See the sssd-ldap(5) and sssd-krb5(5) man pages for other configuration options for LDAP and Kerberos providers.
  • See the sssd-ad(5) man page for other configuration options for AD providers.

2.1.3. Configuring SSSD to Use POSIX Attributes Defined in AD

Note

Previously, the Identity Management for UNIX extension was available to provide POSIX attributes to user accounts. The extension is now deprecated. See the Microsoft Developer Network for details.
If you have been using Identity Management for UNIX, see this Knowledgebase article for answers to frequently asked questions.
For old procedures that reference Identity Management for Unix and the Services for Unix package, see these Red Hat Knowledgebase articles:

Recommendations

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.

Join the Linux System to the AD Domain

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.

    Note

    If you used the realm utility to join the domain and added the --automatic-id-mapping=no switch, the realm utility already set up SSSD with ldap_id_mapping = false.
  3. If you previously requested any users with the default ID mapping configuration, remove the SSSD caches:
    rm -f /var/lib/sss/db/*
SSSD will now use POSIX attributes from AD, instead of creating them locally.