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
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
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.
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
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
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
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”.
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
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:
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
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.
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
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
This may also need override_homedir in
sssd.confto 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:
Reboot to restart lightdm. It should now be possible to log in using a domain account using either username or username/username@domain format.