Chapter 2. Using Active Directory as an Identity Provider for SSSD
2.1. Configuring an AD Provider for SSSD
2.1.1. Overview of the Integration Options
- 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).
- 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.
NoteWhen 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, as described in Use POSIX attributes defined in AD.
- Use POSIX attributes defined in AD
- AD can create and store POSIX attributes, such as
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
- Verify the configuration for name resolution. In particular, verify the DNS SRV records. For example, for a domain named
If you later connect SSSD to a particular AD domain controller, it is not necessary to verify the DNS SRV records.
- 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
- 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 = adoption is being used
NTP 123 UDP Optional
Configure the Local System
realm joincommand to configure the system. See Chapter 3, Using
realmdto Connect to an Active Directory Domain. The
realmdsuite edits all required configuration files automatically. For example:
# realm join ad.example.com
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
pam_oddjob_mkhomedir.solibrary 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:
- Open the
- In the
[domain]section, use one of these options:
For example, to always use the format
fallback_homedirsets a fallback home directory format, which is used only if a home directory is not defined in AD
override_homedirsets a home directory template, which always overrides the home directory defined in AD
[domain/EXAMPLE] [... file truncated ...]
override_homedir = /home/%d/%uFor details, see the sssd.conf(5) man page.
loginShellparameter configured in AD. To customize the user shell settings on Linux clients:
- Open the
- Define the required user shell settings using these options:
For details, see the sssd.conf(5) man page.
shell_fallbacksets a fallback value, which is used only if no shells are defined in AD
override_shellsets a value that always overrides the shell defined in AD
default_shellsets a default shell value
vetoed_shellsset lists of allowed or blacklisted shells
Load the New Configuration
- Restart SSSD after changing the configuration file.
# systemctl restart sssd.service
- 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
Join the Linux System to the AD Domain
Disable ID Mapping in SSSD
- Open the
- In the AD domain section, add the
ldap_id_mapping = falsesetting.
NoteIf you used the
realmutility to join the domain and added the
realmutility already set up SSSD with
ldap_id_mapping = false.
- If you previously requested any users with the default ID mapping configuration, remove the SSSD caches:
rm -f /var/lib/sss/db/*
ldap_id_mappingparameter, see the sssd-ldap(8) man page.