WARNING: The Identity Management for UNIX extension used in the following section is now deprecated. As explained on the Microsoft Developer Network, an attempt to upgrade a system running Identity Management for UNIX might fail with a warning suggesting you to remove the extension. No replacement for the extension is currently available. It is recommended to avoid using Identity Management for UNIX and instead set POSIX information on the IdM server using the ID Views mechanism, described in Using ID Views in Active Directory Environment.
To use AD-defined POSIX attributes in SSSD, it is recommended to replicate them to the global catalog for better performance. Once they are in the global catalog, they are available to SSSD and any application which uses SSSD for its identity information. Additionally, if the POSIX attributes are used, ID mapping has to be disabled in SSSD, so the POSIX attributes are used from AD rather than creating new settings locally.
Other configuration is available in the general LDAP provider configuration 1 and AD-specific configuration 2. This includes setting of LDAP filters for a specific user or group subtree, filters for authentication, and values for some account settings.
NOTE: The following procedure covers the manual configuration of an Active Directory domain. By using realmd, steps 4 to 11 below can be done automatically by using the
realm join command. See Using realmd to Connect to an Active Directory Domain for details.
Make sure that both the AD and Linux systems have a properly configured environment.
Name resolution must be properly configured, particularly if service discovery is used with SSSD.
The clocks on both systems must be in sync for Kerberos to work properly.
In the AD domain, set the POSIX attributes to be replicated to the global catalog.
Install Identity Management for UNIX Components on all primary and child domain controllers. This allows the POSIX attributes and related schema to be available to user accounts. These attributes are available in the UNIX Attributes tab in the entry's Properties menu.
Install the AD Schema Snap-in to add attributes to be replicated to the global catalog.
For the relevant POSIX attributes (
loginShell), open the Properties menu, select the Replicate this attribute to the Global Catalog check box, and then click OK.
On the Linux client, add the AD domain to the client's DNS configuration so that it can resolve the domain's SRV records.
search example.com nameserver 192.0.2.1
Set up the Linux system as an AD client and enroll it within the AD domain. This is done by configuring the Kerberos and Samba services on the Linux system.
Install the following packages:
[root@server ~]# yum install krb5-workstation samba-common-tools sssd-ad
Set up Kerberos to use the AD Kerberos realm.
Open the Kerberos client configuration file.
[root@server ~]# vim /etc/krb5.conf
[libdefaults]sections so that they connect to the AD realm.
[logging] default = FILE:/var/log/krb5libs.log [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d rdns = false forwardable = yes
If auto-discovery is not used with SSSD, then also configure the
[domain_realm]sections to explicitly define the AD server.
Configure the Samba server to connect to the Active directory server.
Open the Samba configuration file.
[root@server ~]# vim /etc/samba/smb.conf
Set the AD domain information in the
[global] workgroup = EXAMPLE client signing = yes client use spnego = yes kerberos method = secrets and keytab log file = /var/log/samba/%m.log password server = AD.EXAMPLE.COM realm = EXAMPLE.COM security = ads
Add the Linux machine to the AD domain.
Obtain Kerberos credentials for a Windows administrative user.
[root@server ~]# kinit Administrator
Add the machine to the domain using the
[root@server ~]# net ads join -k Joined 'server' to dns domain 'example.com'
This creates a new keytab file,
List the keys for the system and check that the host principal is there.
[root@server ~]# klist -ke
Test that users can search the global catalog, using an
[root@server ~]# ldapsearch -H ldap://server.ad.example.com:3268 -Y GSSAPI -N -b "dc=ad,dc=example,dc=com" "(&(objectClass=user)(sAMAccountName=aduser))"
Start the SSSD service.
[root@server ~]# systemctl start sssd.service
Open the SSSD configuration file.
[root@server ~]# vim /etc/sssd/sssd.conf
Configure the AD domain.
[sssd]section, add the AD domain to the list of active domains. This is the name of the domain entry that is set in [domain/NAME] in the SSSD configuration file.
Create a new domain section at the bottom of the file for the AD domain. This section has the format domain/NAME, such as
domain/ad.example.com. For each provider, set the value to
ad, and give the connection information for the specific AD instance to connect to.
[domain/ad.example.com] id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad
Disable ID mapping. This tells SSSD to search the global catalog for POSIX attributes, rather than creating UID:GID numbers based on the Windows SID.
# disabling ID mapping ldap_id_mapping = False
If home directory and a login shell are set in the user accounts, then comment out these lines to configure SSSD to use the POSIX attributes rather then creating the attributes based on the template.
# Comment out if the users have the shell and home dir set on the AD side #default_shell = /bin/bash #fallback_homedir = /home/%d/%u
Set whether to use short names or fully-qualified user names for AD users. In complex topologies, using fully-qualified names may be necessary for disambiguation.
# Comment out if you prefer to user shortnames. use_fully_qualified_names = True
Enable credentials caching; this allows users to log into the local system using cached information, even if the AD domain is unavailable.
cache_credentials = true
Set the file permissions and owner for the SSSD configuration file.
[root@server ~]# chown root:root /etc/sssd/sssd.conf [root@server ~]# chmod 0600 /etc/sssd/sssd.conf [root@server ~]# restorecon /etc/sssd/sssd.conf
If necessary, install the
oddjob-mkhomedirpackage to allow SSSD to create home directories for AD users.
[root@server ~]# yum install oddjob-mkhomedir
authconfigto enable SSSD for system authentication. Use the
--enablemkhomedirto enable SSSD to create home directories.
[root@server ~]# authconfig --update --enablesssd --enablesssdauth --enablemkhomedir
Restart the SSH service to load the new PAM configuration.
[root@server ~]# systemctl restart sshd.service
Restart SSSD after changing the configuration file.
[root@rhel-server ~]# systemctl restart sssd.service
authconfig automatically configured the NSS and PAM configuration files to use SSSD as their identity source.
For example, the
nsswitch.conf file has SSSD (
sss) added as a source for user, group, and service information.
passwd: files sss group: files sss ... services: files sss ... netgroup: files sss
pam.d files add a line for the
pam_sss.so module beneath every
pam_unix.so line in the
auth sufficient pam_sss.so use_first_pass ... account [default=bad success=ok user_unknown=ignore] pam_sss.so ... password sufficient pam_sss.so use_authtok ... session optional pam_mkhomedir.so session optional pam_sss.so