SSSD Linux System Integrate With Active Directory

I would like to integrate Linux System Authentication against the centralized Active Directory using System Security Service Daemon (SSSD). SSSD supports two kinds mechanisms to integrate Linux System Authentication against AD for authentication. They are:

1. ID Mapping using ObjectSID in AD
2. Posix Attribute Mapping using posixAccount and posixGroup Object classes.


To implement the above mechanisms you need to configure the SSSD in the Linux System as a root user as follows:

1. Installing Packages

yum install sssd sssd-client krb5-workstation samba openldap-clients oddjob-mkhomedir sssd-libwbclient sssd-libwbclient-devel

2. Configuring the DNS Resolver

Edit the /etc/resolv.conf and verify the DNS Server entries are point to the naming servers and also search domain.  For example sample resolve.conf file is given below:

domain ad.example.edu

search ad.example.edu

nameserver ns1.example.edu

nameserver ns2.example.edu

Based on the above configuration it will obtain the ip address of the linux machine host from the domain naming service (DNS).

3. Configuring the Kerberos

This configuration is required for Active Directory Authentication using Kerberos protocol.

Edit the /etc/krb5.conf file and configure the Active Directory logging, libdefaults, realms, and domain realm sections as follows:

[logging]

 default = FILE:/var/log/krb5libs.log

 kdc = FILE:/var/log/krb5kdc.log

 admin_server = FILE:/var/log/kadmind.log

[libdefaults]

 default_realm = AD.EXAMPLE.EDU

 dns_lookup_realm = true

 dns_lookup_kdc = true

 ticket_lifetime = 24h

 renew_lifetime = 7d

 forwardable = true

 rdns = false

[realms]

 AD.EXAMPLE.EDU = {

  kdc = dcs01.ad.example.edu

  admin_server = dcs01.ad.example.edu

  default_domain = ad.example.edu

 }

[domain_realm]

 .ad.example.edu =AD.EXAMPLE.EDU

 ad.example.edu = AD.EXAMPLE.EDU

The realms and domain_realm section is required only if the domain discover service not available.

In the libdefaults section change the default_realm parameter according your environment.

In the realms section change  AD.EXAMPLE.EDU realms with your actual realm, The realm parameters kdc, admin_server, and default_domain values needs to be changed according to your environment.

In domain_realm section change realm names according to your environment.

4. Configuring the Samba

Configure the Samba Server to connect the Active Directory server. Edit the /etc/samba/smb.conf and add the following content under [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 = dcs01.ad.example.edu

realm = AD.EXAMPLE.EDU

security = ads

In the global section you need to modify the workgroup, password server, and realm according to your environment. The workgroup details are available for the ad object in the Active Directory User and Computer Console as follows: 

Right Click your Suffix (ad.example.edu) --> Find --> Enter Name (Search User Name) -->  Search Result --> Click Search Result --> Click Account --> User Logon Name (pre-Windows 2000).

The User Logon Name (pre-Windows 2000) value is your workgroup value.

The password server value is your ad domain controller.

The realm is your ad realm.

   

5. Joining the Linux Machine with Domain Controller

  After configuring the Steps 3 and 4, you need to perform the following tasks to join the Linux Machine with AD Domain Controller:

  5.1 Obtain Kerberos Credentials:

 The following command being used to obtain the kerberos credentials from the AD domain controller:

   kinit administrator

   

   After executing the above command and it will append the default realm with administrator account. For example user name will be administrator@AD.EXAMPLE>EDU. It will also ask the administrator password to authenticate user against AD domain controller. After successful authentication, kerberos key tab file will be generated in the /etc/krb5.keytab.

   If you found any issue while obtaining the Kerberos credentials from the AD domain controllers, you can execute the following command to trace the kerberos authentication errors in the console.

KRB5_TRACE=/dev/stdout kinit administrator 

 5.2 Joining Linux Machine to Domain Controller:

   After executing the step 5.1 successfully, you can execute the following command to join the Linux Computer to the AD Domain controller.

net ads join -k

After executing the above command successfully, the Linux machine will be added into the AD Domain controller. You can find the Linux machine name in the DomainJoinStaging orgainizational unit under ad.example.edu. The sample computer path is CN=testlinuxmachine,OU=DomainJoinStaging,DC=ad,DC=example,DC=edu

The CN is your Linux Machine Name. In my example my machine name is testlinuxmachine.ad.example.edu

You can verify computer name according your environment.

6. Configuring the SSSD authentication

Execute the following command to enable the SSSD authentication against the Active Directory:

authconfig --update --enablesssd --enablesssdauth –-enablemkhomedir

It will enable the sssd authentication and the changes will be written into the /etc/pam.d/ directory and also it will generate the nsswitch.conf file in the /etc/ directory.

7. Implementing the SSSD Mechanisms

After executing the step 6 it will enable the sssd authentication for the Linux Machine against with AD domain controller. But it will not create the /etc/sssd/sssd.conf file. You need to create the sssd.conf file under /etc/sssd/ directory and add the following content in the sssd.conf file.

[sssd]

domains =  ad.example.edu

services = nss, pam

config_file_version = 2

[domain/ad.example.edu]

id_provider = ad

auth_provider = ad

access_provider = ad

chpass_provider = ad

ad_domain = ad.example.edu

ad_server = dcs01.ad.example.edu

ad_hostname = dcs01.ad.example.edu

ldap_schema = ad

cache_credentials = true

debug_level = 1

ldap_idmap_default_domain_sid = <Domain SID>

krb5_auth_timeout = 30

krb5_realm = ad.example.edu

In the sssd section you need to modify domains, and services according to your environment. In my example domains value is ad.exampel.edu and services values are nss, pam, and pac.

The naming service switch (nss) being used to retrieve the Active Directory Identity Objects. For example id and groups.

The Pluggable Authentication Module (PAM) is being used to authenticate the user against the active directory.

You can configure the additional services as per your requirement. For example sudo service is being used to grant the Admin Sudo Access for certain users in the Linux System.

The [domain/ad.example.edu] section you need to modify provider name parameters for authentication, authorization, and changing passwords. In my example I have selected my provider name is ad because I am going to integrate Linux System with Active Directory. This provider is a generic provider for ldap. The example providers given below 

id_provider = ad

auth_provider = ad

access_provider = ad

chpass_provider = ad

You need to modify the ad domain controller parameter as follows:

ad_domain = ad.example.edu

ad_server = dcs01.ad.example.edu

ad_hostname = dcs01.ad.example.edu

ldap_idmap_default_domain_sid = <Domain SID>
krb5_realm = ad.example.edu

You need to modify the cache credential parameter because user needs to login off line.

    7.1 ID Mapping Using ObjectSID in AD

     This configuration copied under   [domain/ad.example.edu] section and it is required because it will create the user home directory and also it will generate the uid and guid based on the active directory objectSid parameter.

     ldap_idmap_range_min = 1824600000

     ldap_idmap_range_size = 2000000
     ldap_id_mapping = true
     fallback_homedir = /home/%u
   
     In the above configuration ldap_idmap_range_min and ldap_idmap_range_size parameters are optional. If you getting any ObjectSid to UID or GID conversion error, you need to include ldap idmap range parameters, otherwise it not required.
 
    You can specify the default home directory parameter fallback_homedir value to create the home directory after user login successfully to the Linux System.

   The ldap_id_mapping parameter value is true by default.
 

    7.2 Posix Attribute Mapping using posixAccount and posixGroup Object classes

    The following parameters needs to be modified when implementing the Posix Attribute mechanism.

      ldap_id_mapping = false

      ldap_user_home_directory = unixHomeDirectory

      

        7.2.1 Active Directory User Configuration

        The following modification needs to be done to implement with Posix Attribute Mechanism for the Active Directory User.

          a) You need to include the PosixAccount Object class in the User Object

          b) You need to add the following attributes in the user object after including the PosixAccount Object class. They are

          

           uidNumber:  The uidNumber is mapped to the unix system user uid

           gidNumber:  The gidNumber is mapped to the unix system group gid. This is a primary group id for the unix system and it is a single valued attribute. This value should map with active directory group gidNumber

           unixHomeDirectory :  The unixHomeDirectory mapped to the unix System User Home Directory

               loginShell:  The loginshell mapped to default shell for the linux system user.

              The user modification ldif script is given below using posixAccount object class for the existing user:

ldapmodify -x -D <Admin DN> -W -h <Ldap Host> -p 389

dn: CN=12345678,OU=people,DC=ad,DC=example,DC=edu

changetype: modify

add: objectClass

objectClass: posixAccount

-

replace: gidNumber

gidNumber: 50001

-

replace: uidNumber

uidNumber: 12345678

-

replace: unixHomeDirectory

unixHomeDirectory: /home/12345678

-

add: loginShell

loginShell: /bin/bash 

        7.2.2 Active Directory Group Configuration

        The following modification needs to be done to implement with Posix Attribute Mechanism for the Active Directory Group.

          a) You need to include the PosixGroup Object class in the Group Object

          b) You need to add the following attributes in the group object after including the PosixGroup Object class. They are

          

           gidNumber:  The gidNumber is mapped to the unix system group gid

           member :  The member field will mapped to the Linux User Groups.

           The group modification ldif script is given below using posixGroup object class for the existing group:

           dn: CN=developer,OU=Groups,DC=ad,DC=example,DC=edu

           changetype: modify

            replace: ObjectClass

            ObjectClass: top

            ObjectClass: Group

            ObjectClass: posixGroup

             -

            replace: gidNumber

            gidNumber: 50001

            -

            add: member

            Member: CN=12345678,OU=people,DC=ad,DC=example,DC=edu

           Note: The user object gidNumber must match with group object gidNumber. This values should be same while mapping the user to group to create the Linux System User.

  

8. Changing the Ownership

Execute the following command to change the Owner ship and also permission to read the sssd.conf file as a root user in the /etc/sssd directory.

chown root:root sssd.conf

chmod 600 sssd.conf

9. Restart the SSSD Service

Execute the following command to restart the sssd service.

service sssd restart

10. Testing the SSSD Authentication

Use any ssh client or putty. I am showing the example using the ssh in the command line to test the sssd authentication against active directory.

    ssh -l testuser@ad.example.edu sssdlab.ad.example.edu
 
   After entering the above command it will ask the user password and enter the user password and it will login to the Linux System and automatically create the home directory and default shell as you supplied in the sssd.conf file or from the ad if your using the posix attribute mechanism.
 

11. SSSD Log Location

If you found any error while authenticating the user against active directory. The following configuration needs to be done to logging the data as a debug mode.

   a) Edit the /etc/sssd/sssd.conf file
   b) Add the debug_level=9 parameter value under [domain/ad.example.edu] section
   c) The following log files will be created in the /var/log/sssd directory:

     krb5_child.log
     ldap_child.log
     sssd_ad.example.edu.log
     sssd.log
     sssd_nss.log
     sssd_pam.log
   
     If you found any error while starting the sssd service, check sssd.log file.
     If you found any authentication errors and getting the data from the AD, you can check sssd_ad.example.edu.log for authentication and extracting the data from AD.
     If you can verify request and response details from AD in the ldap_child.log
      If you can verify Kerberos request and response details from AD in the krb5_child.log
     You can check nss service error in sssd_nss.log and pam service errors in sssd_pam.log

12. Clearing SSSD Cache from memory.

      If you found any errors with related to ID Mapping after switching the ID Mapping to PosixAttribute Mapping vice versa. You need to clean the sssd data base and also sssd mem cache.

  

a) stop the sssd service as follows:

    service sssd stop

b) remove the database as follows:

    rm /var/lib/sssd/db/*

c) remove the mem cache as follows:

     rm /var/lib/sssd/mc/*

  

 d) Start the SSSD service as follows:

     service sssd start

   

13. Common Errors

13.1 pam_access(sshd:account): access denied for user `user1@example.edu' from `machine.example.edu'

   Cause: 

    The Linux System Enforce with Access Control Policies in the access.conf file.

   Solution:

    Add the User or Group info into the /etc/security/access.conf file and the issue will be resolved. The access.conf sample configuration is given below:

  + : (user1) : ALL

13.2 pam_sss(sshd:chauthtok): User info message: Password change failed. Server message: Old password not accepted

   The above error thrown while changing the password first logon in the SSSD Linux machine and also creating the home directory first time.

 Cause: 

 The Client Linux SSSD machine establish the connectivity from Work Station to Kerberos Authentication Server taking more than kerberos auth timeout value when changing the password on first logon. 

   Solution:

    Edit the /etc/sssd/sssd/conf file and increase the krb5_auth_timeout value. The default value is 6 seconds. You need to increase the timeout value according to your environment. For example  krb5_auth_timeout value is 60 seconds.