Join Ubuntu to Active Directory via SSH

Join Ubuntu 24.04 to a Windows AD domain and authenticate SSH with domain credentials.

Introduction

30 Second Summary

In any organization, managing separate usernames and passwords on every single server is a nightmare. One person leaves the company and you're hunting across dozens of machines to revoke their access.

In this project, you will join an Ubuntu server to a Windows Active Directory domain so that domain users can SSH in with their existing AD credentials. You'll then lock down access so only members of a specific security group can log in.

What You'll Build

Picture yourself SSHing into your Ubuntu server with a Windows AD username and password, landing in a home directory that was created automatically on first login, and knowing that only your approved team members can get in.

By the end of this project, you'll have:

  • An AD domain user authenticating over SSH into Ubuntu using their domain password, with a home directory automatically created on first login.
  • Group-based access control where only members of a designated AD security group can SSH in. All other domain users are denied.
  • Verification commands that confirm domain membership, Kerberos tickets, and SSSD authentication logs from the Ubuntu side.
  • Secret Mission: Test offline authentication by simulating a domain controller outage and proving cached credentials still work.

Are there any prerequisites?

Yes. You need a Windows Server 2022 Domain Controller with Active Directory Domain Services promoted and DNS configured. You also need an Ubuntu 24.04 VM with SSH running. Both VMs must be able to communicate over the network.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

Managing separate local accounts on every Linux server is painful and insecure. In this project, you'll join your Ubuntu VM to your Windows Active Directory domain so that AD users can SSH in with their domain credentials. Then you'll lock it down with group-based access control.

Install AD Integration Packages and Configure DNS

Ubuntu has no built-in way to communicate with Active Directory. It needs a set of packages that bridge Linux identity services with the Windows AD world.

The other critical piece is DNS. Active Directory relies on DNS SRV records to advertise its services. If Ubuntu cannot resolve your domain's DNS records, domain discovery and joining will fail silently. In this step, you will install the integration packages and point Ubuntu's DNS at your Domain Controller.

In this step, get ready to:
  • Install the AD integration packages (sssd-ad, sssd-tools, realmd, adcli).
  • Configure Ubuntu's DNS resolver to point at your Windows Server DC.
  • Verify that Ubuntu can discover your AD domain.
Update apt and install the AD integration packages

Your Ubuntu VM needs four packages that together enable Linux-to-AD communication. These are not installed by default.

  • Open a terminal on your Ubuntu VM (either SSH in or use the console directly).
  • Update your package lists and install the integration packages by running these commands:
sudo apt update
sudo apt install sssd-ad sssd-tools realmd adcli

When prompted to confirm the installation, type Y and press Enter.

What do these packages do?

  • sssd-ad is the SSSD backend that speaks the AD protocol. It handles authentication, user lookups, and credential caching.
  • sssd-tools provides diagnostic utilities for inspecting the SSSD cache and status.
  • realmd automates domain discovery, joining, and SSSD configuration. It saves you from hand-editing config files.
  • adcli performs low-level AD operations like creating and managing the computer account in AD.
  • Confirm the packages installed successfully by running:
dpkg -l | grep -E 'sssd-ad|sssd-tools|realmd|adcli'

You should see four lines, one for each package, with ii at the start of each line indicating they are installed.

Packages failed to install?

  • If you see a "Unable to locate package" error, run sudo apt update again to refresh your package lists. Your VM may not have fetched the latest repository metadata.
  • If you see a network timeout, check that your Ubuntu VM has internet access. Try ping 8.8.8.8 to confirm basic connectivity.
  • Still stuck? Help me troubleshoot my apt install failing for SSSD packages on Ubuntu 24.04.
Point Ubuntu's DNS at your Domain Controller

Active Directory uses DNS SRV records to advertise services like LDAP and Kerberos. Ubuntu must query your DC's DNS server to find these records. Without this, domain discovery will fail.

  • Find your Windows Server DC's IP address. On your Windows Server, open a Command Prompt and run ipconfig to note the IPv4 address.
  • Back on your Ubuntu VM, overwrite the DNS configuration by running this command:
echo "nameserver [[DC_IP="your Domain Controller's IP address (e.g. 192.168.1.10)"]]" | sudo tee /etc/resolv.conf

Why overwrite the whole file?

In a lab environment, you want Ubuntu to use your DC as its only DNS server. The DC hosts the AD-specific SRV records that realmd needs to discover the domain. Any other DNS server would not have these records.

On Ubuntu 24.04, /etc/resolv.conf may be managed by systemd-resolved. The tee command replaces whatever is there with your DC's address. For a lab this is the simplest approach.

  • Confirm the change took effect by running:
cat /etc/resolv.conf

You should see a single line: nameserver followed by your DC's IP address.

Still seeing the old DNS entries?

If /etc/resolv.conf reverted to its previous content, systemd-resolved may be overwriting it. Disable it temporarily for your lab by running:

sudo systemctl disable --now systemd-resolved
echo "nameserver [[DC_IP="your Domain Controller's IP address (e.g. 192.168.1.10)"]]" | sudo tee /etc/resolv.conf

Then run cat /etc/resolv.conf again to confirm the change sticks. Help me configure DNS on Ubuntu 24.04 to point at my AD Domain Controller.

Verify domain discovery

With the packages installed and DNS pointing at your DC, Ubuntu should now be able to find your AD domain. This is the moment that proves everything is wired up correctly.

  • Before you run the next command, predict what you think will happen. Will Ubuntu successfully find your Active Directory domain, or will it fail?
  • Discover your domain by running:
sudo realm -v discover [[DOMAIN_NAME="your domain name (e.g. nextwork.com)"]]

You should see output that includes these key lines:

  • type: kerberos confirming the domain uses Kerberos authentication.
  • server-software: active-directory confirming the server is a Windows AD domain controller.
  • client-software: sssd confirming SSSD is the local client that will handle authentication.

What does this output prove?

A successful realm discover means three things are working together: your DNS is resolving the AD SRV records, realmd found the domain controller, and SSSD is recognized as the client software that will handle the domain join.

This is the foundation for everything that follows. If realm discover fails, domain joining in the next step would also fail.

Seeing "No such realm found"?

  • Double-check that /etc/resolv.conf contains your DC's IP address. Run cat /etc/resolv.conf to verify.
  • Confirm your DC is reachable from Ubuntu. Run ping followed by your DC's IP address. If it times out, check your VMware network settings. Both VMs need to be on the same network segment.
  • Verify the AD DNS service is running on your Windows Server. On the DC, open Server Manager and confirm the DNS service shows a green status.
  • Make sure you typed the domain name exactly as it was configured on your DC (e.g. nextwork.com not NEXTWORK).
  • Still stuck? Help me troubleshoot why realm discover cannot find my Active Directory domain.

Your Ubuntu VM can now see the Active Directory domain. Next up, you will join Ubuntu to the domain and establish the trust relationship that lets AD users authenticate on Linux.

Join Ubuntu to the AD Domain

Your Ubuntu machine can see the Active Directory domain, but discovery alone doesn't grant trust. Until the machine formally joins, AD won't authenticate any users trying to log in from it.

Domain joining creates a computer account in AD and establishes a Kerberos trust relationship between your Ubuntu machine and the domain controller. In this step, you'll join the domain and verify the trust from both sides.

In this step, get ready to:
  • Join Ubuntu to the AD domain with realm join.
  • Verify domain membership from Ubuntu with realm list.
  • Confirm the computer account appears in Active Directory Users and Computers on Windows Server.
Join the domain with realm join

The realm join command registers your Ubuntu machine with Active Directory, creating a computer account and downloading the Kerberos keytab needed for secure authentication.

  • Join your Ubuntu machine to the AD domain by running this command:
sudo realm join [[DOMAIN="yourdomain.com"]]

What will this command ask you?

The command prompts you for the domain Administrator password. Type it in and press Enter. You won't see any characters appear as you type. This is normal for password prompts in Linux.

On a successful join there is no output. Silence means success. If you see an error, check the troubleshooting callout below.

What does realm join do under the hood?

  • Creates a computer account object for your Ubuntu machine in Active Directory.
  • Generates /etc/sssd/sssd.conf automatically with your domain configuration, including cache_credentials = True for offline authentication support.
  • Starts the SSSD service, which handles all future identity lookups and authentication against AD.
  • Generates a Kerberos keytab at /etc/krb5.keytab so the machine can authenticate to AD without a password.

Seeing an error during realm join?

  • If you see a preauthentication failure, double-check the Administrator password. Make sure Caps Lock is off.
  • If realm cannot find the domain, confirm your DNS is still pointing at the DC. Run cat /etc/resolv.conf and verify the nameserver IP matches your Windows Server.
  • Kerberos requires system clocks to be within a few minutes of each other. If you suspect clock drift, run date on both machines and compare. Install ntpdate or use timedatectl to sync time if needed.

Still stuck? Help me troubleshoot my realm join error.

Verify domain membership from Ubuntu

Before you run the verification command, take a guess. What information do you think Ubuntu now knows about your domain?

  • Check that your domain is configured by running:
realm list

You should see output that includes your domain name, configured: kerberos-member, server-software: active-directory, and client-software: sssd. You'll also see login-formats and login-policy fields.

What do these fields mean?

  • configured: kerberos-member confirms your machine is a trusted member of the domain, not just a discoverer.
  • client-software: sssd tells you SSSD is handling identity and authentication on the Linux side.
  • login-formats shows the username pattern (e.g. user@yourdomain.com) that domain users will use to log in.

Realm list shows nothing?

If realm list returns empty output, the join likely failed silently. Run sudo systemctl status sssd to check if SSSD is running. If SSSD is not active, try the join again with verbose output by running:

sudo realm join -v [[DOMAIN="yourdomain.com"]]

The verbose flag shows each step so you can identify where it fails. Help me figure out why realm list is empty after joining.

Confirm the computer account in Active Directory

You've confirmed the join from Ubuntu's perspective. Now verify it from the Windows Server side by checking that a computer object was created for your Ubuntu machine.

  • Switch to your Windows Server VM.
  • Open Server Manager if it is not already open.
  • Click Tools in the top menu bar.
  • Select Active Directory Users and Computers.
  • In the left panel, expand your domain and click the Computers container.
  • You should see a computer object with your Ubuntu machine's hostname listed here.

This computer object is the Windows side of the trust relationship. It proves AD recognizes your Ubuntu machine as a domain member.

Don't see the computer object?

If the object is not in the Computers container, try pressing F5 to refresh the view in ADUC. If it still doesn't appear, go back to Ubuntu and run realm list again to confirm the join actually succeeded. Help me find my Ubuntu computer object in Active Directory.

Your Ubuntu machine is now a trusted member of your AD domain. Next up, you'll put that trust to use by SSHing into Ubuntu with an Active Directory user account.

SSH into Ubuntu with AD Credentials

Your Ubuntu machine is a trusted member of the Active Directory domain. The real test is whether a domain user can actually log in over SSH using their AD credentials.

You need a domain user account to test with. Your first SSH attempt will reveal a gap that is common in real AD-Linux deployments. Let's find it and fix it.

In this step, get ready to:
  • Create a test domain user in Active Directory.
  • SSH into Ubuntu using AD domain credentials.
  • Configure automatic home directory creation for domain users.
Create a test domain user on Windows Server

Before you can test SSH authentication, you need a regular domain user account. The Administrator account works technically, but a dedicated test user proves that any AD user can authenticate.

  • Switch to your Windows Server 2022 VM.
  • Open Active Directory Users and Computers from Server Manager by clicking Tools in the top menu bar.
  • Expand your domain in the left pane and click the Users container.
  • Right-click in the right pane, select New, then User.
  • Enter testuser in the User logon name field.
  • Fill in the first name as Test and last name as User.
  • Click Next.
  • Set a password for the user. Uncheck User must change password at next logon so you can use the password immediately over SSH.
  • Click Next, then Finish.

You should see testuser listed in the Users container alongside the built-in accounts.

Why use_fully_qualified_names matters

Because SSSD sets use_fully_qualified_names = True by default after a realm join, you log in as testuser@yourdomain.com rather than just testuser.

This prevents collisions between local Linux accounts and domain accounts that share a name.

SSH into Ubuntu with the domain user

Now for the moment of truth. You have a domain-joined Ubuntu machine and a domain user. Time to connect.

Before you run this, do you think the login will work perfectly on the first try? What might be missing?

  • From your Windows machine, open a terminal (PowerShell or Command Prompt).
  • SSH into the Ubuntu VM using your domain user by running this command:
ssh [[TESTUSER_FQDN="testuser@yourdomain.com"]]@[[UBUNTU_IP="your Ubuntu VM's IP address"]]
  • When prompted, enter the password you set for testuser in Active Directory.

The authentication succeeds. You get a shell prompt. But look closely at the output. You see a warning message about the home directory:

Could not chdir to home directory /home/testuser@yourdomain.com: No such file or directory

The user lands in / (the root of the filesystem) instead of a proper home directory. This is the intended gap.

SSSD authenticates the user successfully, but it does not create home directories for domain users. That responsibility belongs to PAM (Pluggable Authentication Modules), which needs to be told explicitly to create them.

  • Type exit to disconnect from the SSH session.

Why does this happen?

The realm join command configures SSSD with fallback_homedir = /home/%u@%d. This tells the system what path domain users' home directories should be. But it does not enable the PAM module that actually creates the directory on first login.

This is a common gotcha in real AD-Linux deployments. Authentication and home directory creation are separate concerns handled by different system components.

Enable automatic home directory creation

The fix is a single command on your Ubuntu machine. The pam-auth-update tool manages PAM configuration modules on Ubuntu. The mkhomedir module creates home directories automatically when a user logs in for the first time.

  • Switch back to your Ubuntu VM terminal.
  • Enable the mkhomedir PAM module by running this command:
sudo pam-auth-update --enable mkhomedir

What does this command do?

This adds the pam_mkhomedir.so module to your PAM session configuration. Every time a user logs in and their home directory does not exist, PAM will create it automatically using /etc/skel as a template.

Now SSH in again from your Windows machine to confirm the fix works.

What do you expect to see this time? Will the home directory warning be gone?

  • From your Windows terminal, SSH into Ubuntu again by running:
ssh [[TESTUSER_FQDN="testuser@yourdomain.com"]]@[[UBUNTU_IP="your Ubuntu VM's IP address"]]
  • Enter the same password as before.

This time you land in a proper bash shell with no home directory warning. Your prompt shows you are in the home directory.

  • Confirm your identity and group memberships by running:
id

You should see output showing the AD user's UID, GID, and domain group memberships. It looks something like:

uid=1725801103(testuser@yourdomain.com) gid=1725800513(domain users@yourdomain.com) groups=1725800513(domain users@yourdomain.com)
  • Verify your current working directory by running:
pwd

The output shows /home/testuser@yourdomain.com. Your domain user has a proper home directory that was automatically created on login.

SSH login denied or permission error?

If SSH rejects the connection entirely (not just the home directory issue), your domain's Group Policy Objects (GPOs) may be blocking the login. SSSD enforces GPO-based access control by default.

To fix this, edit /etc/sssd/sssd.conf and add ad_gpo_access_control = permissive under the domain section. Then restart SSSD with sudo systemctl restart sssd and try again.

Help me troubleshoot my AD SSH login

Still seeing the home directory warning?

Make sure you ran sudo pam-auth-update --enable mkhomedir on the Ubuntu machine, not on Windows.

If the first SSH session cached a failed state, try clearing the SSSD cache with sudo sssctl cache-remove on Ubuntu and reconnecting.

Help me fix my PAM mkhomedir configuration

Your AD user can now SSH into Ubuntu and land in a proper home directory. Next up, you'll lock down access so only authorized groups can log in.

Restrict SSH Access to an AD Security Group

Right now, every domain user can SSH into your Ubuntu server. In a real enterprise environment, that is a serious security risk.

The principle of least-privilege access control says users should only have access to the systems they need. You'll create an Active Directory security group, add permitted users to it, and configure realmd to enforce the restriction so only group members can log in.

In this step, get ready to:
  • Create a security group in Active Directory and add your test user to it.
  • Configure realm to deny all domain users except the authorized group.
  • Verify that group members can SSH in while non-members are denied.
Create an AD security group on Windows Server

A security group in AD is the standard way to bundle users who share the same access level. Instead of granting SSH access user-by-user, you assign it to a group and manage membership from one place.

  • Switch back to your Windows Server VM.
  • Open Active Directory Users and Computers from Server Manager (Tools menu at the top right).
  • Right-click the Users container in your domain tree.
  • Select New, then Group.
  • Enter Linux-SSH-Users as the group name.
  • Set Group scope to Global and Group type to Security.
  • Click OK to create the group.

You should see Linux-SSH-Users appear in the Users container.

  • Right-click the Linux-SSH-Users group and select Properties.
  • Go to the Members tab.
  • Click Add.
  • Type testuser in the object names field, click Check Names to resolve it, then click OK.
  • Click OK to close the Properties dialog.

Your test user is now a member of the Linux-SSH-Users group. This group membership is what Ubuntu will check when deciding who gets SSH access.

Why a group instead of individual users?

In production, servers multiply fast. Managing access by individual username means updating every server when someone joins or leaves. With a security group, you add or remove a user in one place and every server respects the change instantly.

Lock down SSH access on Ubuntu

The realm command can control which domain users are allowed to log in. The strategy is deny-all-first, then whitelist only the group you trust.

  • Switch back to your Ubuntu terminal.
  • Block all domain users from logging in by running this command:
sudo realm deny --all
  • Now permit only the Linux-SSH-Users group by running:
sudo realm permit -g [[DOMAIN_GROUP="linux-ssh-users@yourdomain.com"]]
  • Confirm the policy is active by running:
realm list

In the output, look for a permitted-groups field showing your group name. This confirms the access policy is set.

What do these commands do?

The realm deny --all command blocks every domain account from logging in. It acts as a clean slate.

The realm permit -g command then punches a hole for one specific group. Under the hood, realm switches SSSD from GPO-based access control to a simple allow/deny list. Only users in the named group pass the check.

Not seeing permitted-groups in realm list?

Make sure you ran both commands in order. The deny must come before the permit. If the output still shows permitted-logins as empty or the field is missing, try restarting SSSD:

sudo systemctl restart sssd

Then run realm list again.

Help me troubleshoot realm permit on my Ubuntu server.

Test group-based access control

The policy is set. Now you need to prove it works in both directions: a permitted user gets in, and an unauthorized user is blocked.

  • Before you test, think about this: your testuser is in the Linux-SSH-Users group. Do you expect their SSH login to succeed or fail?
  • From your Windows Server, SSH into Ubuntu as your test user by running:
ssh [[AD_USER="testuser@yourdomain.com"]]@[[UBUNTU_IP="your Ubuntu VM's IP address"]]

Enter the domain password when prompted. The login succeeds because testuser is a member of the permitted group.

  • Run id to confirm your domain identity and group memberships are visible.
  • Type exit to return to your Windows Server session.

That confirms the happy path. Now you need to prove the deny side works too.

  • On your Windows Server, open Active Directory Users and Computers.
  • Right-click the Users container, select New, then User.
  • Create a user with the logon name testuser2.
  • Set a password and uncheck the password-expiry options as needed.
  • Click Finish. Do NOT add testuser2 to the Linux-SSH-Users group.
  • Now predict: testuser2 is a valid domain account but is not in the permitted group. What do you expect SSH to do?
  • Attempt SSH from Windows Server as testuser2:
ssh [[AD_USER2="testuser2@yourdomain.com"]]@[[UBUNTU_IP="your Ubuntu VM's IP address"]]

Enter testuser2's password when prompted. The connection is denied. You should see a message indicating the login was not permitted.

What should I see?

The SSH client shows "Permission denied" after you enter the password. The domain credentials are valid, but the access policy on Ubuntu blocks the login because testuser2 is not in the Linux-SSH-Users group.

  • For the final check, switch back to your Ubuntu terminal and run:
realm list

Confirm the permitted-groups field shows your security group. This proves your access policy is correctly enforced at the realm level.

Permitted user getting denied too?

SSSD may have cached the user's old group membership from before you created the group. Clear the cache and restart SSSD:

sudo sss_cache -E
sudo systemctl restart sssd

Then try the SSH login again. Also confirm on the Windows side that testuser actually appears in the Linux-SSH-Users group Members tab.

Help me troubleshoot why my AD group member is being denied SSH access.

Your Ubuntu server now enforces group-based access control. Only users you explicitly authorize through Active Directory can SSH in. Next up, you'll tackle a Secret Mission to prove this setup can survive a domain controller outage.

Secret mission

Test Offline Authentication (Simulated DC Outage)

What happens when your domain controller goes offline? In production, network outages are inevitable. Prove your setup is resilient by simulating a DC outage and confirming that SSSD credential caching keeps your domain users connected over SSH.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely in your local VMware lab, so there are no ongoing cloud costs. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

  • Computer account for Ubuntu in Active Directory (Computers container).
  • Two test domain users (testuser and testuser2) in AD.
  • Security group Linux-SSH-Users in AD.
  • SSSD domain configuration and membership on Ubuntu.
  • Home directory at /home/testuser@yourdomain.com on Ubuntu.

Keep everything running

No action needed. Choose this if you are still actively building or plan to continue with a follow-up project that builds on this AD integration.

  • Both VMs remain powered on and domain-joined.
  • Your test users, security group, and SSSD configuration stay in place.
  • The installed packages (sssd-ad, sssd-tools, realmd, adcli) remain on Ubuntu.

Pause - I'll come back to this later

Shut down both VMs to free up system memory and CPU. Domain membership persists across reboots, so everything will work again when you power the VMs back on.

  • In VMware, right-click the Ubuntu VM and select Shut Down Guest.
  • Right-click the Windows Server VM and select Shut Down Guest.
  • When you return, power on the Windows Server first. The DC must be running before Ubuntu can authenticate against it.

Delete - I don't want to use this again

Remove all project resources and return both machines to their pre-project state.

  • On Ubuntu, unjoin the domain by running:
sudo realm leave [[DOMAIN="yourdomain.com"]]

What does this command do?

This removes the machine's Kerberos membership, deconfigures SSSD, and deletes the computer account from Active Directory.

  • Remove the test user home directory on Ubuntu by running:
sudo rm -rf /home/testuser@*
  • Remove the installed packages by running:
sudo apt remove --purge sssd-ad sssd-tools realmd adcli -y
  • On the Windows Server, open Active Directory Users and Computers.
  • Navigate to the Computers container and delete the Ubuntu computer object if realm leave did not already remove it.
  • Navigate to the container where you created your users and delete testuser and testuser2.
  • Delete the Linux-SSH-Users security group.

Nice Work!

Nice Work!

Nice work! You just built a centralized identity setup where your Ubuntu server authenticates SSH users against a Windows Active Directory domain controller.

You've learned how to:

  • Join an Ubuntu 24.04 server to a Windows Server 2022 Active Directory domain using SSSD and realmd.
  • Authenticate SSH sessions with AD credentials and configure automatic home directory creation via PAM.
  • Enforce least-privilege access by restricting SSH to a specific AD security group.
  • Secret Mission: Validate offline authentication with SSSD credential caching during a simulated domain controller outage.

Ready to quiz yourself?