SLES 15 SP1 integração SSSD and Active Directory,

SLES 15 systems will likely deploy with v1.16.x of the SSSD supporting smartcard-based authentication.

The environment

Microsoft Windows Active Directory Domain Services
SUSE Linux Enterprise Server

Installation methods

• SLES 12 SP1: Using the YaST Windows Domain Membership (samba-client) and Authentication Client (auth-client) modules.
• SLES 12 SP2-SP3: Using the YaST User Logon Management (auth-client) module.
• SLES 15: Using the YaST User Logon Management (auth-client) module.
• SLES 12-15: Using the SLES command line

 

This example will focus on deploying a basic configuration of the SSSD against a basic Active Directory back-end using the SLES command line. The SSSD could be deployed using YaST equally as well and arguably with less effort, but the components required for manual deployments provide additional functionality. Specifically, tools for troubleshooting Active Directory connectivity out-of-band of the SSSD, and other utilities for interacting with Active Directory. Additionally, it is likely that the manual methodology can be transferred to any number of configuration management platforms for automated deployments.

Configuration details

Domain FQDN: corp.domain.com
Domain Controller/Admin Server/KDC: win2016srv.corp.domain.com
Domain DNS Service Host: win2016srv.corp.domain.com
SLES Host: sles.corp.domain.com

Functioning DNS and time synchronisation configurations are a strict requirement of the SSSD Active Directory providers (think how important both are for normal domain member servers). Ensure the SLES host uses the same time and DNS sources as the target domain.

This configuration assumes the SLES host

• Is currently configured for local authentication only.
• Is not currently joined to a Windows domain.
• Will create local home directories when an Active Directory user logs in.
• Is using the same NTP source as the target domain.
• Can resolve itself using the DNS service used in the target domain.
• Is participating in the DNS space of the target domain (has a FQDN in the domain).

 

* If the SLES host has a FQDN in another name space this nuance can still be accommodated with te SSSD configuration, more on that further in the document.

Implementation

1. Install the following software packages and any dependencies.

krb5-client
samba-client
openldap2-client
sssd-ad

2. Verify the SLES host can resolve itself using the DNS service used in the target domain.

~# nslookup sles.corp.domain.com win2016srv.corp.domain.com

3. Verify the SLES host is synchronizing time with the NTP source in the target domain.

~# ntpq -p

4. Make backup copies of the following files:

/etc/krb5.conf
/etc/samba/smb.conf
/etc/nsswitch.conf
/etc/openldap/ldap.conf
/etc/sssd/sssd.conf

5. Shutdown and disable the Name Service Caching Daemon (nscd).

~# systemctl stop nscd.service
~# systemctl disable nscd.service

* The nscd should not run and cache users and groups concurrently with the SSSD.

6. Configure the Kerberos client (/etc/krb5.conf) to permit the kinit utility to communicate with the target domain.

[libdefaults]
dns_canonicalize_hostname = false
rdns = false
default_realm = CORP.DOMAIN.COM
default_ccache_name = /tmp/krb5cc_%{uid}

[realms]
CORP.DOMAIN.COM = {
kdc = win2016srv.corp.domain.com
default_domain = corp.domain.com
admin_server = win2016srv.corp.domain.com
}

[logging]
kdc = FILE:/var/log/krb5/krb5kdc.log
admin_server = FILE:/var/log/krb5/kadmind.log
default = SYSLOG:NOTICE:DAEMON

[domain_realm]
. corp.domain.com = CORP.DOMAIN.COM
corp.domain.com = CORP.DOMAIN.COM

7. Configure the Samba client (/etc/samba/smb.conf) to permit the net utility to communicate with the target domain.

Add the following directives to the global section:

[global]
workgroup = CORP
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
realm = CORP.DOMAIN.COM
security = ADS
create krb5 conf = no

* The short domain name is used for the WORKGROUP directive value.

8. Modify the passwd and group sources in the Name Service Switch configuration file (/etc/nsswitch.conf) to reference the SSSD when resolving users and groups.

passwd: compat sss
group:  compat sss

9. Configure the OpenLDAP client (/etc/openldap/ldap.conf) to establish runtime defaults for client utilities such as ldapsearch.

URI ldap:// win2016srv.corp.domain.com
BASE dc=corp,dc=domain,dc=com

REFERRALS OFF

* LDAP referrals from a Windows Domain Controller are only meaningful to other Windows Domain Controllers.

10. Use the configured Kerberos client to authenticate to the target domain as Administrator.

~# kinit Administrator

* A successful authentication returns you to a normal prompt.

11. Use the net utility to join the system to the domain and generate a system keytab file.

~# net ads join osname=”SLES” osVersion=15 osServicePack=”Latest” –no-dns-updates -k

* Note that WordPress removes the double dash preceding the “no-dns-updates” argument.

12. Use the net and ldapsearch utilities to access Active Directory using the joined system.

Verify a SASL/GSSAPI connection can be instantiated using the active Kerberos session:

~# ldapsearch sAMAccountName=Administrator

Tear down the active Kerberos session:

~# kdestroy

Use the net utility and the system keytab file to perform the same search:

~# net ads search sAMAccountName=Administrator -P

* Now that SASL/GSSAPI connectivity has been validated using the Kerberos, OpenLDAP, and Samba clients, and the system keytab file, the SSSD client and its Active Directory providers can be configured.

13. Configure the Pluggable Authentication Module (PAM) configuration on the SLES host to authenticate users using the SSSD, and create home directories for them on login if they do not already exist.

~# pam-config –add –sss
~# pam-config –add –mkhomedir 

ID mapping modes

Before the SSSD itself is configured a bit about how the daemon will reference UID and GID values for users and groups.

Non-mapped (static)

ldap_id_mapping = false

UID and GID values are stored in Active Directory attributes (uidNumber and gidNumber in LDAP parlance) and read by the daemon when the user or group is referenced. If other standard POSIX attribute values are populated (loginShell, homeDirectory, gecos) they will be read as well.

Mapped (calculated)

ldap_id_mapping = true

UID and GID values are calculated using an algorithm run against Active Directory user and group Security Identifiers (SID) to generate unique UID and GID values. Because the object SIDS do not change these values persist across servers running the SSSD.

The default for the SSSD Active Directory providers is to map UID and GID values.

* When mapping UID and GID values the daemon can be configured to provide other POSIX attribute defaults (loginShell, homeDirectory, gecos) with additional configuration file directives.

* Note that when using ID mapping the GID for all users is the “Domain Users” group by default.

* Switching between non-mapped and mapped UID and GID resolution when file shares reference them is not a trivial task.

14. Configure the SSSD client configuration file (/etc/sssd/sssd.conf) for the target domain.

[sssd]
config_file_version = 2
services = nss,pam
domains = corp.domain.com

[nss]
filter_users = root
filter_groups = root

[pam]

[domain/corp.domain.com]
id_provider = ad
auth_provider = ad

cache_credentials = true
enumerate = false

override_homedir = /home/%d/%u

# dns_discovery_domain = corp.domain.com
# ad_server = _srv_, win2016srv.corp.domain.com

# Enable to increase logging verbosity for troubleshooting domain connectivity
# debug_level = 7

Directive notes:

* [domain/corp.domain.com]
When the Active Directory provider is used, the SSSD Authentication Domain labels must match the FQDN of the target Active Directory domain.

* services = nss,pam
Configure which SSSD responders to invoke. In this case the NSS responder to resolve users and groups, and the PAM responder to provide a facility to authenticate them.

* cache_credentials = true
User credentials are cached in the SSSD domain cache using a SHA512 hash. This reduces authentication load on the back end and facilitates offline authentication.

* enumerate = false
Active UID and GID enumeration should be disabled in large environments, as daemons and systems can be computationally overwhelmed and present unnecessary load on back ends.

Although the default is “false” for this directive, it is specified explicitly in this configuration as a best practice.

Married with the “cache_credentials = true” directive = value, enumeration is passive and effectively puts the server in a cache-on-query mode.

* override_homedir = /home/%d/%u
Authenticated users will have home directories created in /home/corp.domain.com/ path.

* dns_discovery_domain = corp.domain.com
If the AD DNS domain space differs from the SLES host, specify the AD domain name space to be used for service location.

* ad_server = _srv_, win2016srv.corp.domain.com
If Active Directory service location is working properly this directive is not required. This configuration attempts to locate Domain Controllers using Active Directory SRV records, then using a statically configured host if that fails. The default behavior is to attempt to use service location via SRV records only.

15. Enable and start the SSSD at system boot

~# systemctl enable sssd.service
~# systemctl start sssd.service

16. Ensure the SSSD can resolve and authenticate Active Directory users and groups.

~# id administrator
~# ssh administrator@sles.corp.domain.com

Summary

This completes a basic functional configuration of the SSSD Active Directory providers. Once the system is joined to the domain and the SSSD is configured, the daemon is only dependent on the Kerberos system keytab file and the SSSD software stack to maintain Active Directory integration. Subsequently, the Kerberos, Samba, and OpenLDAP client configurations can be modified without impacting the SSSD. However, maintaining alignment with all configurations with respect to the target Active Directory environment provides system administrators with valuable tools for out-of-band troubleshooting of the SSSD and system interactions with Active Directory.

Additionally, the default policy in modern Active Directory environments promotes machine passwords for computer objects are reset every thirty days (a process normally parented by the Windows netlogin process). The machine password is a component in establishing the secure channel between the computer object, representing the host, and the target Domain Controller. The SSSD honours this policy by resetting and writing updated machine passwords to the system keytab file every thirty days emulating that security.

The SSSD can be configured against simple and complex Active Directory environments alike. The software stack is mature, provides extensive features, exceptionally tight integration between SUSE Linux Enterprise Server and Desktop systems with Active Directory environments, and is still under aggressive development.

Many of the advanced configurations and optimisations of benefit in more complex environments are covered in the official Administering SSSD on SUSE Linux Enterprise Server 12 –  Course SLE342 available from SUSE training.