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.
