Join Ubuntu Linux to Active Directory Domain

Joining an Ubuntu Linux server to a Windows Active Directory (AD) domain enables centralized authentication and management. The steps in this guide use Realmd for domain discovery and joining, and SSSD for authentication and identity management.

Prerequisites

• PHX Development Environment (PXD).
• A functional Windows Active Directory Domain Services (AD DS) in your network.
• Administrative access to the AD domain.
• Ubuntu server with network access to the AD domain controller.

PXD Environment

Step 1: Install Required Packages

Install the necessary packages for Realmd and SSSD:

sudo apt update
sudo apt -y install realmd sssd sssd-tools libnss-sss libpam-sss adcli samba-common-bin oddjob oddjob-mkhomedir packagekit

Step 2: Configure DNS and Join the Domain

Update your network configuration to point to the AD domain controller for DNS.

Edit /etc/netplan/01-netcfg.yaml (adjust the filename if necessary):

nameservers:
  addresses: [10.0.0.100]  # Replace with your AD server's IP

Apply the changes:

sudo netplan apply

Discover the AD domain:

realm discover C2.ORG  # Replace with your realm

Output example:

c2.org
  type: kerberos
  realm-name: C2.ORG
  domain-name: c2.org
  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

Join the domain (you’ll be prompted for the AD Administrator password):

sudo realm join C2.ORG

Verify by checking an AD user’s info:

id tony@c2.org

Example output:

uid=1259201103(tony@c2.org) gid=1259200513(domain users@c2.org) groups=1259200513(domain users@c2.org),1259200512(domain admins@c2.org),1259200572(denied rodc password replication group@c2.org)

If you want home directories created automatically on first login, edit /etc/pam.d/common-session and add:

session optional        pam_mkhomedir.so skel=/etc/skel umask=077

Test login with an AD user:

exit  # Log out if needed
# Login as tony@c2.org

Step 3: Omit Domain Name for Users (Optional)

To use usernames without the domain suffix:

Edit /etc/sssd/sssd.conf:

use_fully_qualified_names = False

Restart SSSD:

sudo systemctl restart sssd

Verify:

id Administrator

Step 4: Assign Fixed UID/GID (Optional)

By default, UIDs/GIDs are mapped dynamically. For fixed mappings, add UNIX attributes (uidNumber, gidNumber) to AD user accounts first (use AD tools for this).

Then, edit /etc/sssd/sssd.conf:

ldap_id_mapping = False
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber

Clear cache and restart:

sudo rm -f /var/lib/sss/db/*
sudo systemctl restart sssd

Verify:

id tony

Step 5: Grant Sudo Access to Domain Admins (Optional)

To allow members of the AD “Domain Admins” group to perform sudo commands on the Ubuntu server, configure sudoers appropriately. This enables them to use commands like sudo su - for root access.

Create a new sudoers file for domain admins:

sudo visudo -f /etc/sudoers.d/domain-admins

Add the following line (replace C2.ORG with your actual domain name, and escape spaces in group names with double backslashes):

%Domain\\ Admins@C2.ORG ALL=(ALL:ALL) ALL

• The format uses % for groups, and @ for the realm if fully qualified names are enabled.
• If you disabled fully qualified names in Step 3, adjust to: %Domain\\ Admins ALL=(ALL:ALL) ALL
• Test with getent group "Domain Admins@C2.ORG" to ensure the group is recognized by SSSD.

Verify sudo access by logging in as a domain admin and running a sudo command:

sudo whoami  # Should output 'root'

Step 6: SSSD AD Group Policies Workaround

See known issues  in Ubuntu Server documentation  there is a known issue that will cause RDP connection to fail because there are no group policies configured.

In log file /var/log/sssd/sssd_c2.org.log this can be seen:

   *  (2024-07-18  4:03:15): [be[c2.org]] [sdap_access_send] (0x0400): [RID#25] Performing access check for user [tony@c2.org]
   *  (2024-07-18  4:03:15): [be[c2.org]] [sdap_account_expired_ad] (0x0400): [RID#25] Performing AD access check for user [tony@c2.org]
   *  (2024-07-18  4:03:15): [be[c2.org]] [sdap_account_expired_ad] (0x4000): [RID#25] User account control for user [tony@c2.org] is [10200].
   *  (2024-07-18  4:03:15): [be[c2.org]] [sdap_account_expired_ad] (0x4000): [RID#25] Expiration time for user [tony@c2.org] is [9223372036854775807].
   *  (2024-07-18  4:03:15): [be[c2.org]] [ad_gpo_access_send] (0x0400): [RID#25] Configuration hint: PAM service 'xrdp-sesman' is not mapped to any Group Policy rule. If you plan to use this PAM service it is recommended to use the ad_gpo_map_* family of options to map this PAM service to a Group Policy rule. PAM services not present in any map will fall back to value set in ad_gpo_default_right, which is currently set to Denied (see manual pages 'man sssd-ad' for more details).
   *  (2024-07-18  4:03:15): [be[c2.org]] [ad_gpo_access_send] (0x0400): [RID#25] service xrdp-sesman maps to Denied
   *  (2024-07-18  4:03:15): [be[c2.org]] [ad_gpo_access_done] (0x0040): [RID#25] GPO-based access control failed.
********************** BACKTRACE DUMP ENDS HERE *********************************

To fix this we can change /etc/sssd/sssd.conf and apply as a workaround the follows:

ad_gpo_access_control = permissive

systemctl restart sssd

This will make SSSD try to perform GPO operations, but not fail if it can’t.

Step 7: Connect using RDP

Now you can connect using for example Remmina (recommended) as user tony with password Supersecret!

Best Practices

• Use secure passwords and limit administrative access.
• Monitor SSSD logs for issues: /var/log/sssd/.
• Test thoroughly before production use.
• Consider using Kerberos for enhanced security.

Additional Information

• Ubuntu 22.04 LTS : Join in Active Directory Domain : Server World 
• Ubuntu Server documentation 
  • How to set up SSSD with Active Directory - Ubuntu Server documentation