2.2. 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.2.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).
Do not use the same user name in Windows and Active Directory.
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.
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.2.2. Configuring an AD Domain with ID Mapping as a Provider for SSSD
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
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
Red Hat recommends using the
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
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
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.
By default, SSSD retrieves information about user shells from the
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.2.3. Configuring SSSD to Use POSIX Attributes Defined in AD
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:
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
Follow the steps in Section 2.2.2, “Configuring an AD Domain with ID Mapping as a Provider for SSSD”.
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/*
SSSD will now use POSIX attributes from AD, instead of creating them locally.
For further details about ID mapping and the
ldap_id_mappingparameter, see the sssd-ldap(8) man page.