Connect Linux to Active Directory using SSSD

• Author
• Recent Posts

Evi Vanoost

Evi Vanoost is the Director of IT Infrastructure for the Office of Research at the University of Rochester. He has over 20 years of experience in IT. With his team, Evi supports thousands of systems.

Latest posts by Evi Vanoost (see all)

• Connect Linux to Active Directory using SSSD - Tue, Sep 19 2023

Linux has long supported LDAP in Active Directory as an authentication method; however, many tutorials are incomplete or outdated. Various guides assume small SMB-sized domains, and the configurations may not scale well. In very large Active Directory forests, the standard configurations can make authentication extremely slow. The configuration discussed in this post was researched and tested in an AD environment containing millions of objects.

I have tested this configuration on Debian 10 and 11, Ubuntu 20 through 22, and Red Hat 7 through 9. Other distributions may require slight modifications.

For Debian-based distributions, run this command:

apt install realmd sssd oddjob oddjob-mkhomedir adcli sssd-ad cifs-utils msktutil
libnss-sss libpam-sss sssd-tools samba-common-bin krb5-user

The apt-get command installs packages and their dependencies on Debian-based distributions, on stripped-down Linux distros (e.g., server or cloud versions of Ubuntu). The base packages for realmd (used for configuring and managing network authentication services related to Active Directory) and System Security Services Daemon (SSSD—a software component commonly used on Linux systems to provide centralized authentication) may not be installed; hence, our inclusion.

For binding to Active Directory, we additionally require sssd-ad, the AD plugin for SSSD, and adcli, which is a tool to modify AD records. libnss-sss and libpam-sss contain the glue between SSSD and the PAM/NSS architecture underpinning all authentication on Linux.

Oddjob-mkhomedir contains hooks to automatically create home directories upon login. Additionally, cifs-utils and samba-common-bin contain the SMB protocol implementation, while msktutil and krb5-user are used to obtain and renew Kerberos tickets for computer and user objects.

On Red Hat-based distributions, run a similar command:

dnf install realmd sssd oddjob oddjob-mkhomedir adcli sssd-ad cifs-utils msktutil krb5-workstation krb5-libs samba-common-tools

On Red Hat-based distros, dnf is currently used to manage software; however, the packages can differ in both name and content, and some overlap. If your distro does not have dnf (Red Hat 7), you can replace dnf in the above command with its predecessor, yum.

The realm list command is used to list the Active Directory domains or other identity providers to which a Linux system has been joined using the realmd tool. This command provides information about the currently configured domain or domains and displays details such as the domain name, type of domain (e.g., Active Directory), and the status of the connection. The command requires the kerberos and ldap SRV records in DNS. If you have trouble finding the domain with realm list, make sure your DNS is returning records, as described in this troubleshooting article by Microsoft.

Output of the realm list command

As you can see, realmd will suggest several required packages for the domain compared with the apt-get install or dnf install commands above.

To join the computer to the domain with a privileged account, use the following command:

realm join -U ad_user domain.tld --computer-ou="ou=computers,ou=department"

The --computer-ou option does not need to be specified if an object for this computer already exists in AD, for example, if it is created in Active Directory Users and Computers (ADUC).

This command will request your credentials. Subsequently, it will configure the SSSD daemon. At this point, enable the automatic creation of the user's home directory using the authselect tool (Red Hat) or pam-auth-update (Debian).

Select the Create home directory option from pam auth update

Select the Create home directory option from pam-auth-update

Now, you should be able to query your user using the fully qualified username (FQUN). Make sure to escape the @ sign as some shells interpret certain symbols (shell expansion).

id ad_user\@domain.tld

Output of the id command

Back up and edit the configuration file. If you do not have a working sssd.conf, do not reboot because your system will not boot or log in when SSSD is broken, and you may have to use recovery mode.

cp /etc/sssd/sssd.conf /etc/sssd/sssd.back.20230101
nano /etc/sssd/sssd.conf

Now, you can configure SSSD to fit your environment.

[sssd]
config_file_version = 2
services = nss, pam
domains = domain.tld
default_domain_suffix = domain.tld


[domain/domain.tld]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = DOMAIN.TLD
realmd_tags = manages-system joined-with-adcli 
id_provider = ad
ldap_sasl_authid = HOSTNAME$
fallback_homedir = /home/%d/%u
ad_domain = domain.tld
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
ad_gpo_access_control = disabled
enumerate = False
ignore_group_members = True

[nss]
memcache_size_passwd = 200
memcache_size_group = 200
memcache_size_initgroups = 50

You can use the above configuration, replacing domain.tld with your own domain. Let me walk you through some of the modifications.

default_domain_suffix = domain.tld

This specifies the "default" domain people will use when logging in. Usually, people must log in using their FQUN (e.g., myaduser@mydomain.test). For example, when you use the login command:

login myaduser\@mydomain.test

When we set defaultdomainsuffix to mydomain.test, this automatically appends the domain as a suffix to all logins, making it easier for end users.

login myaduser

If you have a multidomain forest, users in other domains can still use an FQUN (for example: hraduser@hr.mydomain.test)

If your domain has Unix extensions, LDAP attributes regulate the settings for the default shell and home directory location. These lines set the default if a user does not have these attributes, or your domain does not have Unix extensions.

default_shell = /bin/bash
fallback_homedir = /home/%d/%u

The %d/%u home directory location makes sure that user accounts with overlapping sAMAccountNames in different domains do not collide (jdoe@finance.mydomain.test is unlikely to be the same jdoe@hr.mydomain.test). The %d will be replaced by the domain of the user when logging in. %u is the username, likely the sAMAccountName attribute. Using the above example, one user will log in to /home/finance.mydomain.test/jdoe while the other will use /home/hr.mydomain.test/jdoe.

With the default %u@%d, we've noticed some programs or users do not handle the @ symbol well. You do have to manually create the parent directory for each domain, since oddjob-mkhomedir does not handle creating parent directories.

mkdir /home/finance.mydomain.test /home/hr.mydomain.test

In this section, we disable GPO access control:

ad_gpo_access_control = disabled

Although not all applications (e.g., RDP) are aware of GPO, local logins are usually translated to "Allow log on locally," while SSH (remote) logins use the "Allow log on through Remote Desktop Services" GPO. A future article will dive into that translation layer in depth.

However, by disabling GPO, by default, nobody will be able to log in. To allow anyone with an active AD credential to log in (insecure):

realm permit --all

A more secure alternative is to specify a user or group.

realm deny --all
realm permit user@domain.tld
realm permit -g group@domain.tld

The following set of configurations is primarily intended for larger domains:

enumerate = False
ignore_group_members = True

By default, SSSD will enumerate (retrieve and cache) all user and group information, which in large domains is not feasible. Caching will run out of time and memory. Subsequently, retrievals of domain information (e.g., id and getent calls) become very slow. We set it to ignore nested group memberships. If you rely on properly structured nested groups, you may have to enable it.

[nss]
memcache_size_passwd = 200
memcache_size_group = 200
memcache_size_initgroups = 50

Users who complete a login will still have their information cached locally. The NSS section enlarges the default RAM cache to 200 MB, so queries are fast and do not need to hit the disk every time a getent call is made. Make sure to scale according to available resources, the number of users expected to log in, and group membership sizes.

Once all the changes are made, restart sssd. This command should not return anything, if all is well.

systemctl restart sssd

You can review the status of SSSD and the log files with the following:

systemctl status sssd
journalctl -u sssd

If you have problems in your environment, SSSD has an extensive debugging mechanism, which can help you gain insight into what is going on in your directory.