Share with friends and colleagues on social media

From both feature and security perspectives, integrating Linux systems with Active Directory environments has been a challenge for their respective system administrators and organisations. However, modern Linux distributions include the System Security Services Daemon (SSSD) which addresses many of the legacy shortcomings handily. The daemon uses identity and authentication providers (and other service providers) to communicate with varying back-ends (LDAP, Kerberos, AD, IPA, and IdM), concurrently. Using the Active Directory identity and authentication providers, the SSSD can integrate Linux systems with Active Directory Domain Services instances tightly enough to function nearly as well as native domain member servers in those environments.

This example deployment configures a SLES 12 or SLES 15 host to resolve and authenticate Active Directory users and groups (even across trusts) and honour object security and GPO access policies natively, by default. All of this and offline authentication too!

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

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

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

~# ntpq -p

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

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

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

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

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

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

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

~# kinit Administrator

* A successful authentication returns you to a normal prompt.

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

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

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

An example of using mapped UIDs and GIDS

An example of using mapped UIDs and GIDS

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.

Share with friends and colleagues on social media

Comments

  • mweiss2 says:

    Thanks a lot for this article!! Here some feedback:

    1. Please do NOT disable nscd completely and just disable caching of users,groups and netgroups in the nscd.conf!

    2. please do not hard-code the kdc/kpasswd in krb5.conf! There is DNS name resolution available for that!

    3. please do NOT use –no-dns-updates for the domain join! It is expected that clients do their own DNS updates in AD! (and if you have to use that – also disable it in sssd.conf!)

    • Martin,
      Concerning the NSCD, see my previous (overdue) response 🙂 .

      Again, the post is far from a deep dive. This is a short tutorial for getting an AD integrated authentication host up and going. To your point though using DNS to resolve KDCs in the /etc/krb5.conf in my opinion as well is best practise:

      dns_lookup_realm = true
      dns_lookup_kdc = true

      Concerning the use of “–no-dns-updates for the domain join” I would have to say this is use case dependent. Not all SSSD AD provider based clients are going to participate in the expected AD DNS updates. These clients (as in this brief example) I agree should use the “dyndns_update = false” directive in the SSSD.conf. Honestly, without adcli on the system Dynamic DNS updates on SLE SSSD clients was not really possible, but more on this in the next bit.

      In this use case the net utility actually throws DNS errors (cosmetic really) and the –no-dns-updates switch is used to avoid them. The net utility in general becomes less of a good fit for the SSSD as the stack matures. Towards that end I have worked with the SLE team to include the adcli utility (starting with SLE 15) in the SLE repos as it understands the tight AD integration provided by the SSSD a bit better resulting in less nuances such as this. Among them allowing the daemon to participate in AD dynamic DNS update configurations.

      These comments and responses do help flesh out the content and intent, so thank you!

      — lawrence

  • Jose Gonzalez Goni says:

    Hey there,
    On this guide you disable nscd.
    However, SSSD does not provide hostname caching (or at least not that I’m aware of), therefore, NSCD is usually configured to cache hostnames only and kept enabled.
    Could you please review?
    Thank you,

    • Jose,
      Always, thank you for the feedback. Correct, the SSSD does not provide host or service caching and disabling the NSCD disables those facilities as well. However, far from a deep dive this is a short tutorial for getting an AD integrated authentication host up and going. And frankly for some use cases host and service caching are not a concern. If it is, disabling user and group caching for hosts that should run both the SSSD and the NSCD concurrently is well documented.

      Additionally in the official SUSE course “Administering SSSD on SUSE Linux Enterprise Server 12 — Course SLE342” (authored by me), this configuration use case is covered in more detail.

      — lawrence

  • Leave a Reply

    Your email address will not be published. Required fields are marked *