SSSD and Active Directory

This section describes the use of sssd to authenticate user logins against an Active Directory via using sssd’s “ad” provider. In previous versions of sssd, it was possible to authenticate using the “ldap” provider. However, when authenticating against a Microsoft Windows AD Domain Controller, it was generally necessary to install the POSIX AD extensions on the Domain Controller. The “ad” provider simplifies the configuration and requires no modifications to the AD structure.

Prerequisites, Assumptions, and Requirements

  • This guide does not explain Active Directory, how it works, how to set one up, or how to maintain it. It may not provide “best practices” for your environment.

  • This guide assumes that a working Active Directory domain is already configured.

  • The domain controller is acting as an authoritative DNS server for the domain.

  • The domain controller is the primary DNS resolver as specified in /etc/resolv.conf.

  • The appropriate _kerberos, _ldap, _kpasswd, etc. entries are configured in the DNS zone (see Resources section for external links).

  • System time is synchronized on the domain controller (necessary for Kerberos).

  • The domain used in this example is myubuntu.example.com .

Software Installation

The following packages are needed: krb5-user, samba, sssd, and ntp. Samba needs to be installed, even if the system is not exporting shares. The Kerberos realm and FQDN or IP of the domain controllers are needed for this step.

Install these packages now.

sudo apt install krb5-user samba sssd chrony

See the next section for the answers to the questions asked by the krb5-user postinstall script.

Kerberos Configuration

The installation of krb5-user will prompt for the realm name (in ALL UPPERCASE), the kdc server (i.e. domain controller) and admin server (also the domain controller in this example.) This will write the [realm] and [domain_realm] sections in /etc/krb5.conf. These sections may not be necessary if domain autodiscovery is working. If not, then both are needed.

If the domain is myubuntu.example.com, enter the realm as MYUBUNTU.EXAMPLE.COM

Optionally, edit /etc/krb5.conf with a few additional settings to specify Kerberos ticket lifetime (these values are safe to use as defaults):

[libdefaults]

default_realm = MYUBUNTU.EXAMPLE.COM
ticket_lifetime = 24h #
renew_lifetime = 7d

If default_realm is not specified, it may be necessary to log in with “username@domain” instead of “username”.

The system time on the Active Directory member needs to be consistent with that of the domain controller, or Kerberos authentication may fail. Ideally, the domain controller server itself will provide the NTP service. Edit /etc/chrony/chrony.conf:

server dc.myubuntu.example.com

Samba Configuration

Samba will be used to perform netbios/nmbd services related to Active Directory authentication, even if no file shares are exported. Edit the file /etc/samba/smb.conf and add the following to the [global] section:

[global]

workgroup = MYUBUNTU
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
realm = MYUBUNTU.EXAMPLE.COM
security = ads

Note

Some guides specify that “password server” should be specified and pointed to the domain controller. This is only necessary if DNS is not properly set up to find the DC. By default, Samba will display a warning if “password server” is specified with “security = ads”.

SSSD Configuration

There is no default/example config file for /etc/sssd/sssd.conf included in the sssd package. It is necessary to create one. This is a minimal working config file:

[sssd]
services = nss, pam
config_file_version = 2
domains = MYUBUNTU.EXAMPLE.COM

[domain/MYUBUNTU.EXAMPLE.COM]
id_provider = ad
access_provider = ad

# Use this if users are being logged in at /.
# This example specifies /home/DOMAIN-FQDN/user as $HOME.  Use with pam_mkhomedir.so
override_homedir = /home/%d/%u

# Uncomment if the client machine hostname doesn't match the computer object on the DC.
# ad_hostname = mymachine.myubuntu.example.com

# Uncomment if DNS SRV resolution is not working
# ad_server = dc.mydomain.example.com

# Uncomment if the AD domain is named differently than the Samba domain
# ad_domain = MYUBUNTU.EXAMPLE.COM

# Enumeration is discouraged for performance reasons.
# enumerate = true

After saving this file, set the ownership to root and the file permissions to 600:

sudo chown root:root /etc/sssd/sssd.conf

sudo chmod 600 /etc/sssd/sssd.conf

If the ownership or permissions are not correct, sssd will refuse to start.

Verify nsswitch.conf Configuration

The post-install script for the sssd package makes some modifications to /etc/nsswitch.conf automatically. It should look something like this:

passwd:         compat sss
group:          compat sss
...
netgroup:       nis sss
sudoers:        files sss

Modify /etc/hosts

Add an alias to the localhost entry in /etc/hosts specifying the FQDN. For example:

192.168.1.10 myserver myserver.myubuntu.example.com

This is useful in conjunction with dynamic DNS updates.

Join the Active Directory

Now, restart chrony and samba and start sssd.

sudo systemctl restart chrony.service
sudo systemctl restart smbd.service nmbd.service 
sudo systemctl start sssd.service

Test the configuration by obtaining a Kerberos ticket:

sudo kinit Administrator

Verify the ticket with:

sudo klist

If there is a ticket with an expiration date listed, then it is time to join the domain:

sudo net ads join -k

A warning about “No DNS domain configured. Unable to perform DNS Update.” probably means that there is no (correct) alias in /etc/hosts, and the system could not provide its own FQDN as part of the Active Directory update. This is needed for dynamic DNS updates. Verify the alias in /etc/hosts described in “Modify /etc/hosts” above.

(The message “NT_STATUS_UNSUCCESSFUL” indicates the domain join failed and something is incorrect. Review the prior steps before proceeding).

Here are a couple of (optional) checks to verify that the domain join was successful. Note that if the domain was successfully joined but one or both of these steps fail, it may be necessary to wait 1-2 minutes and try again. Some of the changes appear to be asynchronous.

Verification option #1:

Check the default Organizational Unit for computer accounts in the Active Directory to verify that the computer account was created. (Organizational Units in Active Directory is a topic outside the scope of this guide).

Verification option #2

Execute this command for a specific AD user (e.g. administrator)

getent passwd username

Note

If enumerate = true is set in sssd.conf, getent passwd with no username argument will list all domain users. This may be useful for testing, but is slow and not recommended for production.

Test Authentication

It should now be possible to authenticate using an Active Directory User’s credentials:

su - username

If this works, then other login methods (getty, ssh) should also work.

If the computer account was created, indicating that the system was “joined” to the domain, but authentication is unsuccessful, it may be helpful to review /etc/pam.d and nssswitch.conf as well as the file changes described earlier in this guide.

Home directories with pam_mkhomedir (optional)

When logging in using an Active Directory user account, it is likely that user has no home directory. This can be fixed with pam_mkdhomedir.so, which will create the user’s home directory on login. Edit /etc/pam.d/common-session, and add this line directly after session required pam_unix.so:

session    required    pam_mkhomedir.so skel=/etc/skel/ umask=0022

Note

This may also need override_homedir in sssd.conf to function correctly, so make sure that’s set.

Desktop Ubuntu Authentication

It is possible to also authenticate logins to Ubuntu Desktop using Active Directory accounts. The AD accounts will not show up in the pick list with local users, so lightdm will need to be modified. Edit the file /etc/lightdm/lightdm.conf.d/50-unity-greeter.conf and append the following two lines:

greeter-show-manual-login=true
greeter-hide-users=true

Reboot to restart lightdm. It should now be possible to log in using a domain account using either username or username/username@domain format.

Resources

Last updated 6 months ago. Help improve this document in the forum.