Configuring an Active Directory Domain with POSIX Attributes

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 ¹ and AD-specific configuration ². 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.

1. 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.

2. In the AD domain, set the POSIX attributes to be replicated to the global catalog.

   1. 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.

   2. Install the AD Schema Snap-in to add attributes to be replicated to the global catalog.

   3. For the relevant POSIX attributes (uidNumber, gidNumber, unixHomeDirectory, and loginShell), open the Properties menu, select the Replicate this attribute to the Global Catalog check box, and then click OK.

3. 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
   

4. 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.

   1. Install the following packages:

      [root@server ~]# yum install krb5-workstation samba-common-tools sssd-ad
      

   2. Set up Kerberos to use the AD Kerberos realm.

      1. Open the Kerberos client configuration file.

         [root@server ~]# vim /etc/krb5.conf
         

      2. Configure the [logging] and [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 [realms] and [domain_realm] sections to explicitly define the AD server.

   3. Configure the Samba server to connect to the Active directory server.

      1. Open the Samba configuration file.

         [root@server ~]# vim /etc/samba/smb.conf
         

      2. Set the AD domain information in the [global] section.

         [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
         

   4. Add the Linux machine to the AD domain.

      1. Obtain Kerberos credentials for a Windows administrative user.

         [root@server ~]# kinit Administrator
         

      2. Add the machine to the domain using the net command.

         [root@server ~]# net ads join -k
         Joined 'server' to dns domain 'example.com'
         

         This creates a new keytab file, /etc/krb5.keytab.

      3. List the keys for the system and check that the host principal is there.

         [root@server ~]# klist -ke
         

      4. Test that users can search the global catalog, using an ldapsearch.

         [root@server ~]# ldapsearch -H ldap://server.ad.example.com:3268 -Y GSSAPI -N -b "dc=ad,dc=example,dc=com" "(&(objectClass=user)(sAMAccountName=aduser))"
         

5. Start the SSSD service.

   [root@server ~]# systemctl start sssd.service
   

6. Open the SSSD configuration file.

   [root@server ~]# vim /etc/sssd/sssd.conf
   

7. Configure the AD domain.

   1. In the [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.

   2. 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
      

   3. 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
      

   4. 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
      

   5. 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
      

   6. 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
      

8. 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
   

9. If necessary, install the oddjob-mkhomedir package to allow SSSD to create home directories for AD users.

   [root@server ~]# yum install oddjob-mkhomedir
   

10. Use authconfig to enable SSSD for system authentication. Use the --enablemkhomedir to enable SSSD to create home directories.

    [root@server ~]# authconfig --update --enablesssd --enablesssdauth --enablemkhomedir
    

11. Restart the SSH service to load the new PAM configuration.

    [root@server ~]# systemctl restart sshd.service
    

12. Restart SSSD after changing the configuration file.

    [root@rhel-server ~]# systemctl restart sssd.service
    

Using 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

The different pam.d files add a line for the pam_sss.so module beneath every pam_unix.so line in the /etc/pam.d/system-auth and /etc/pam.d/password-auth files.

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