Stealthbits

How to Join Linux Hosts to Active Directory Using realmd & SSSD

Blog >How to Join Linux Hosts to Active Directory Using realmd & SSSD

This blog uses apt commands in its examples (for Debian-based distros like Ubuntu, Kali, Mint, etc.), however, examples have also been tested with yum/dnf commands (for RPM-based distros like CentOS, Red Hat, Fedora, openSUSE, etc.).

A Very Brief Summary of Linux With Active Directory

When joining a Linux host to Active Directory (AD), two components are required. The first component handles the central identity and authentication source. In this case, that’s Active Directory. The second component handles available domain discovery and acts as a middleman between the first component and the discovered identity source.

Over the years there have been a few different ways to achieve this, however, most were cumbersome to configure. With realmd that’s no longer the case, which is how we’ll be discovering and joining Active Directory. It’s not too much of a lift either, as realmd handles configuration of complex Linux services (for example, SSSD or Winbind).

Joining Active Directory Using realmd

First, make sure your Linux host can communicate with the domain controller(s) over the network. Proper DNS and hostname resolution are important to this process.

Now, let’s install realmd and check to see if we’re already a member of a domain. If realmd wasn’t previously installed, then we shouldn’t have any domain membership.

sudo apt install realmd
realm list

The output should be empty, indicating the host isn’t joined to AD or another domain service. If the output lists a domain you’d like to leave, run the following as the domain admin user originally used to join the domain:

sudo realm leave example.com -U user@example.com

Next, we’ll want to discover our domain:

realm discover <domain_controller_hostname_or_ip>

The output should look like the following and provides a list of packages that must be installed in order to join the domain:

example.com
  type: kerberos
  realm-name: EXAMPLE.COM
  domain-name: example.com
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin

Realm discovery output may differ per your specific host and domain controller setup.

We can then go ahead with installing the listed required packages (highlighted above) and join the domain with domain admin credentials:

sudo apt install sssd sssd-tools libnss-sss libpam-sss adcli samba-common-bin
sudo realm join --client-software=sssd <domain_controller_hostname_or_ip> -U <domain_admin>

When specifying a domain admin, we can just use the username instead of example.com\user format, since we’re already specifying a domain controller in the command.

In one of my labs, I ran into an invalid hostname error while joining a domain, which can occur if a hostname isn’t set with a proper format (on a VM for example, with a hostname of “localhost.localdomain”). To resolve this, simply set the hostname with hostnamectl:

sudo hostnamectl set-hostname '<new_hostname>'

After joining the domain, we can once again run realm list to view our work, confirm success, and review domain info:

example.com
  type: kerberos
  realm-name: EXAMPLE.COM
  domain-name: example.com
  configured: kerberos-member
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin
  login-formats: %U@example.com
  login-policy: allow-realm-logins

In my case, the login-formats property (highlighted above) indicates domain users will be specified in user@example.com format on this host, rather than domain\user format.

Finally, restart the SSSD service and use id to verify Active Directory user information. The id output should show a domain user’s UID, groups, and more:

sudo service sssd restart
id user@example.com

That’s all there is to it! This is by no means a comprehensive guide for all the options you can manually configure along the way, however, this is the quickest route to get Linux hosts joined to Active Directory using a modern approach.

Mapping Linux UIDs/GIDs to SIDs in Active Directory

One more thing we should touch on is how POSIX UIDs and GIDs are mapped to SIDs in Active Directory since Linux doesn’t have a concept of SIDs like Windows does.

realmd uses SSSD by default, rather than Winbind. One big benefit of this approach is that SSSD automatically handles POSIX UID/GID generation using the SID of each Active Directory user/group. If you keep the default SSSD settings on each Linux host you join to the domain, then these UID/GID values should be mapped consistently across Linux hosts.

For example, in my lab this result is consistent no matter which Linux host I run it on that’s joined to the same domain:

user@my-linux-host:~$ id user@example.com

uid=778006423(user@example.com) gid=778001234(domain users@example.com) groups=778001234 (domain users@example.com)

It’s possible to take a deeper dive into UID/GID generation and mapping, however, that’s out of the scope of this blog. However, with our setup, we’ll have consistent AD user and group UIDs/GIDs throughout the domain.

Another benefit of this approach is that UIDs and GIDs generated by SSSD can also be applied to the uidNumber and gidNumber attributes in Active Directory for users and groups. This allows applications that may query these attributes to perform UID/GID to SID mapping, ultimately resulting in the same AD users or groups being referenced regardless if a user/group is in use on a Linux or Windows host.

To view uidNumber and gidNumber attributes in Active Directory Users and Computers, make sure you have Advanced Features enabled under the View dropdown.

You’ll then be able to view and edit those fields in a user or group’s Properties menu, on the Attribute Editor tab.

Depending on the number of users and groups in your domain, it may take a long time to manually assign uidNumber and gidNumber values. Although methods to programmatically populate these fields will be environment-specific, we can at least list all AD users and groups, with UIDs and GIDs, using the getent command from a Linux host joined to the domain.

By default, getent will only list local users and groups. However, this can be modified by adding a line to your /etc/sssd/sssd.conf file and restarting SSSD.

It should be noted that enabling this enumeration is an expensive option and can cause undue stress on the Active Directory server. Typically, I like to step through this process outside of production hours, save the results, and then disable the full user/group enumeration. First, we can add enumerate = True to sssd.conf, and then restart the SSSD service:

echo "enumerate = True" | sudo tee -a /etc/sssd/sssd.conf &> /dev/null
sudo service sssd restart

Depending on the size of your Active Directory, it can take up to ten minutes to complete the initial enumeration into the local cache. During this period, you’ll notice domain users and groups populating in the respective outputs from getent passwd and getent group. Once enumeration to the local cache is complete, we can use the following commands to format getent output. The first outputs each domain user, their UID, and their GID in comma-separated format, while the second outputs each domain group with its GID in comma-separated format.

getent passwd | awk -F: '{print $1 "," $3 "," $4}' | grep <domain>
getent group | awk -F: '{print $1 "," $3}' | grep <domain>

Example User Output: user@example.com,778006423,778001234

Example Group Output: domain users@example.com,778001234

A couple notes on these commands and output. First, <domain> needs to be replaced with your domain name. Second, you can redirect outputs to text or CSV files, for parsing into Active Directory’s uidNumber and gidNumber attributes. Once you’ve saved the output from the getent commands, you can remove the enumerate value from sssd.conf and restart the SSSD service to prevent the expensive LDAP enumeration from continuously occurring:

sudo sed -i '/enumerate = True/d' /etc/sssd/sssd.conf
sudo service sssd restart

With this UID and GID information in CSV format, you could create a script that imports each CSV and automatically updates uidNumber and gidNumber for Active Directory users and groups. For example, the following Windows PowerShell command adds the specified UID and GID to those attributes in AD:

Set-ADUser <ad_user> -Replace @{uidNumber="<uid>"; gidNumber="<gid>"}

With this command (and Set-ADGroup, respectively), it wouldn’t be too difficult to generate a script that fits your environment and speeds up the process of mapping UIDs/GIDs to uidNumber and gidNumber in AD, which ultimately map to Windows SIDs.

Stealthbits, Active Directory, & Linux

Linux hosts are often used for some of the most critical functions in an organization’s infrastructure. As a byproduct, it’s important for admins to monitor these hosts, understand how they’re used, observe who accesses them, and verify how they’re secured. This is even more critical when Linux hosts are joined to Active Directory.

StealthAUDIT, a full-fledged data access governance solution, includes preconfigured and customizable jobs for auditing, analyzing, and reporting on both Unix/Linux and Active Directory.

From over-provisioning user access to weak passwords, to high-risk open SMB/NFS shares, it only takes one compromised host or user for attackers to move laterally into admin rights in your domain.

IDENTIFY THREATS. SECURE DATA. REDUCE RISK. Find out how Stealthbits can simplify monitoring, detection, and remediation in your organization here.

Leave a Reply

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

Subscribe

DON’T MISS A POST. SUBSCRIBE TO THE BLOG!

 

Loading

© 2020 Stealthbits Technologies, Inc.

Start a Free Stealthbits Trial!

No risk. No obligation.

FREE TRIAL