Configure SSSD for Windows AD Authentication on Ubuntu 24.04

This guide will take you through how to install and configure SSSD for Windows AD authentication on Ubuntu 24.04. SSSD (System Security Services Daemon) is a system service to access remote directories and authentication mechanisms such as an LDAP directory, an Identity Management (IdM) or Active Directory (AD) domain, or a Kerberos realm.

In this setup, Windows Server 2025 is used as the AD Domain Controller.

Configure SSSD for Windows AD authentication on Ubuntu

If you already have a Windows Active Directory (AD) server up and running, you can integrate your Ubuntu system with it to enable centralized authentication using SSSD (System Security Services Daemon). This allows Ubuntu users to log in with their AD credentials, improving security and simplifying user management across mixed environments.

To integrate Ubuntu with Windows Active Directory (AD) for authentication, proceed as follows.

Prerequisites

Before proceeding with the SSSD configuration for Windows Active Directory (AD) authentication, ensure the following prerequisites are met:

Administrative Access

You need sudo/root access on the Linux machine to install necessary packages and perform system configuration.

Additionally, you need proper Active Directory permissions (typically domain join rights) on the AD side to be able to join the Linux machine to the domain.

Run System Update

Ensure that your system package cache is up-to-date. If you are dealing with a production server that might be affected by the updates, you can skip this step.

sudo apt update

System Hostname Configuration

The system should have a properly set Fully Qualified Domain Name (FQDN).

Check with;

hostname -f

Sample output;

noble.kifarunix.com

You can set the FQDN using the command:

sudo hostnamectl set-hostname host.example.com

You can also update the /etc/hosts to include your FQDN:

sudo vim /etc/hosts

127.0.1.1 host.example.com host

Or use the host static IP address instead of 127.0.0.1.

You can restart the following service:

sudo systemctl restart systemd-hostnamed

DNS Resolution for AD Domain

The system must be able to resolve the AD domain via DNS, including SRV records. So, if you are not using AD server as the default DNS server already or via the networking interface configuration, you can update it temporarily in the /etc/resolv.conf.

sudo vim /etc/resolv.conf

Set the AD Domain Controller IP as the DNS server (Replace the ip.of.the.ad.server with correct IP address of the AD server):

nameserver ip.of.the.ad.server

Verify the AD DNS records. Active Directory relies heavily on DNS SRV records to locate services like:

• _ldap._tcp.<domain>: For LDAP-based queries.
• _ldap._tcp.dc._msdcs.<domain>: For locating domain controllers.
• _kerberos._tcp.<domain>: For Kerberos authentication.

To verify them, run:

dig -t SRV _kerberos._tcp.kifarunix.com +short

Sample output;

0 100 88 dc01.kifarunix.com.

dig -t SRV _ldap._tcp.kifarunix.com +short

Sample output;

0 100 389 dc01.kifarunix.com.

dig -t SRV _ldap._tcp.dc._msdcs.kifarunix.com +short

Sample output;

0 100 389 dc01.kifarunix.com.

Verify Connectivity to AD Ports

It’s essential to ensure that the following ports are open and reachable between the client and the domain controllers:

• LDAP Port 389 (TCP & UDP). This is required for:
  • Domain discovery (via DNS SRV records).
  • Initial LDAP communication (used by adcli, realmd, etc.).
  • Authentication and domain join.
  • Netlogon communication (UDP 389).
• LDAPS Port 636 (TCP). Required for:
  • Secure LDAP (LDAPS) communication after joining the AD.

Verify;

nc -vz dc01.kifarunix.com 389

Connection to dc01.kifarunix.com (10.184.10.40) 389 port [tcp/ldap] succeeded!

nc -vz dc01.kifarunix.com 636

Connection to dc01.kifarunix.com (10.184.10.40) 636 port [tcp/ldaps] succeeded!

Time Synchronization

• Ensure the system time is in sync with the AD domain (Kerberos is sensitive to time).
• You can use chrony or systemd-timesyncd.
• It is recommended to use AD as the time server because it ensures accurate time synchronization essential for Kerberos authentication and domain security, which generic NTP servers alone can’t guarantee.

You can configure time sync with AD using chrony or ntp. We use Chrony here.

sudo apt install chrony -y

Set the local time server;

sudo sed -i '/^pool/ s/^/#/;/^#pool 2.ubuntu/ a\server dc01.kifarunix.com iburst' /etc/chrony/chrony.conf

sudo systemctl restart chronyd

Verify;

chronyc sources

Sample output;

MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^* dc01.kifarunix.com            3   6    77    30  -3631ns[ +497us] +/- 7778ms

Enable the service;

sudo systemctl enable chronyd

Install SSSD and Required Packages on Ubuntu

To install SSSD and other necessary packages to join the domain on Ubuntu 24.04, run the command below;

sudo apt install realmd sssd sssd-ad sssd-tools adcli libpam-sss \
         libnss-sss sssd-tools \
         oddjob-mkhomedir

Import and Install Windows AD CS Root CA Certificate

Next, we need to ensure that the remote hosts can trust the AD Certificate Authority (CA). If you have setup your AD server with LDAPS, then the Active Directory Certificate Services (AD CS) issues the SSL/TLS certificates that protect the LDAPS connection. In order for the remote hosts to establish a secure LDAPS connection, it must trust the AD CS Root CA certificate.

Therefore, you have to import the AD CS root CA certificate and install on the host.

To import the AD CS root CA certificate:

• Open the Certification Authority console on the AD CS server (run certsrv.msc).
• Right-click the CA name in the left pane, select Properties.
• In the General tab, select the root CA certificate and click View Certificate.
• In the certificate window, go to the Details tab and click Copy to File.
• Follow the Certificate Export Wizard:
  • Choose DER encoded binary X.509 (.CER) for .cer, or select Base-64 encoded X.509 (.CER) for .pem compatibility.
  • Click Browse to specify a file name and location where to save the certificate.
  • Click Finish to import.
• If .pem or .crt format is needed and you chose Base-64, the .cer file is already in PEM format (you can rename it to .pem to .crt if required).

Transfer the exported CA certificate file to the Linux system (e.g., via SCP ).

I have already transferred this file and installed under /usr/local/share/ca-certificates:

cat /usr/local/share/ca-certificates/ad-cd-root-ca.crt

Here is my sample certificate! It is different for you, so do not use this one!

-----BEGIN CERTIFICATE-----
MIIDaTCCAlGgAwIBAgIQH1caEucYr4pMEt2XbV00IjANBgkqhkiG9w0BAQ0FADBH
MRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJa2lmYXJ1bml4
MRUwEwYDVQQDEwxraWZhcnVuaXgtQ0EwHhcNMjUwODA5MTcwOTM4WhcNMzAwODA5
MTcxOTM3WjBHMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJ
a2lmYXJ1bml4MRUwEwYDVQQDEwxraWZhcnVuaXgtQ0EwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQC1dPRaG78k7ggr8oBFTqetXDN4vo9kyB0elE3kuGgC
bZOZSpK61uRTorPZkohW0pNTi2VZAsW2oYMbY4dM4B8UEJUgyN6oDlgz38D9P1BC
6Ny4VCfm0xMU9FYp/f/L+F2AyiH0WH9/+hVJE1cDjPn6bEpsaBZdcVi0+cL9w6cb
+4OFpqhoR+dgL44PnkMde+eIfRxZ2hCLT32LT23yo5MekNhb2mlhATcx9kK448L3
CfC002RzuEt2i8K0enZGvahcNv2eFbx8QD+PCxs2TJgQRSrXvBKo71YG0OCNZS8n
+rnaRHWPKLW9XC17hXC56xABs0UZ9hQQxkoErAtCU8ERAgMBAAGjUTBPMAsGA1Ud
DwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQGDoGWUmlYMc9fFuhV
L9v0AM4kSzAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQ0FAAOCAQEAeM9+
YI/4dvEqrmo6dpIr+XNGfRN78zShBFZJoEx7McyQtHI0mM+G03VINiDevHzcF5bj
dEPok6kJdU8ntmwuNZrbeQoHRAWQYCemOvaSe/WYZ/CZz5D4vCtcKGnYXnZKloZ+
b6sL5opF8PCzYVy7sJDWQGEQrtA2HUANexCjOJ7bKnjdjI2R3bGa2zOGWLrOGi5f
lRv0+bdenzudhmUNhjmdrlc910bCe4u9ihpUA/zgctWWmkasmQVdh6U2EqV58v3b
wcHHmht9EyHdek7iBbMCvGo4kbDfflt5d5nmnoFtkb0QBZpSZMwYtTdCgOnAVA6J
je1IhclnDq/d23boXQ==
-----END CERTIFICATE-----

Once the certificate is in place, install it:

sudo update-ca-certificates

Next, test the connection to the AD via LDAPs port to confirm CA certificate trust.

openssl s_client -connect dc01.kifarunix.com:636 -showcerts

Ensure the return code is Ok.

openssl s_client -connect dc01.kifarunix.com:636 -showcerts 2>/dev/null | grep 'Verify return code'

Sample output;

Verify return code: 0 (ok)

    Verify return code: 0 (ok)

Your Linux host should now be able to communicate legitimately with AD.

You can also use ldapsearch command to verify LDAPS communication:

ldapsearch -H ldaps://dc01.kifarunix.com:636 -x \
	-D "[email protected]" -W \
	-b "dc=kifarunix,dc=com" "(sAMAccountName=user)"

When prompted for the password, use the user (e.g [email protected]) password.

• Replace dc01.kifarunix.com, [email protected], and dc=kifarunix,dc=com with your AD details.
• If the command returns success results, LDAPS is working. If it fails, check firewall rules, certificate trust, or AD server configuration.

Decide: Join Ubuntu to AD or Use a Bind DN?

At this stage, you need to choose how Ubuntu will interact with Active Directory.

• Do you want to bind with a service account (Bind DN) for LDAP lookups/authentications only?
• Or do you want to fully join the Ubuntu machine to the domain for Kerberos-backed SSSD authentication?

This decision affects how authentication, user lookups and integration will work.

Use a Bind DN (Service Account, No Domain Join)

A Bind DN is a dedicated Active Directory account typically low-privileged and read-only that systems or applications use to bind to the AD server and perform LDAP searches for users, groups, and other directory objects.

The use BIND DN comes in handy when:

• When anonymous LDAP binds are disabled (default in most Windows AD setups).
• When you want read-only directory access for user lookup without fully joining the domain.
• When you are using LDAP only for LDAP-based authentication only, not full Kerberos-based SSSD domain integration.

The use of a Bind DN requires sssd to be configured manually with the bind credentials in order to authenticate to the AD server and perform LDAP searches for user and group information. Without these credentials, and with anonymous bind disabled (which is the default in AD), SSSD will not be able to query the directory.

Joining Ubuntu to the AD Domain

If anonymous LDAP binds are disabled, which is the default in modern Windows Server, and no Bind DN is configured for read-only directory access, systems and applications will not be able to perform user or group lookups unless the system is joined to the AD domain and can use Kerberos authentication to securely query the directory.

Hence, if no Bind DN is configured and anonymous access is disabled, you must join the system to the Windows Active Directory domain in order to perform user and group lookups for authentication. Linux machines will get a computer account in AD (like Windows machines).

In my AD, there is no Bind DN configured and anonymous access is disabled. Therefore, we will have to join the Ubuntu system to the AD domain to set up SSSD authentication.

Join Ubuntu to the Windows AD Domain

Once you have the required packages installed, the next step is to join the Ubuntu system to your Windows Active Directory (AD) domain. This allows the system to authenticate users using Kerberos and retrieve user and group information directly from AD through SSSD.

Before proceeding, ensure the prerequisites above are met.

...
* Trying to set computer password with Kerberos  
! Couldn't set password for computer account: HOSTNAME$: Message stream modified  
adcli: joining domain failed: Couldn't set password for computer account: HOSTNAME$: Message stream modified

Discover and Join the AD Domain using realm command

While LDAPS (TCP 636) is used for secure LDAP communication, domain discovery and joining processes rely on LDAP over TCP/UDP port 389, tools such as adcli and realmd use port 389 to locate domain controllers, authenticate, and initiate the join process.

Therefore, ensure that port 389 (both TCP and UDP) is reachable from the client to the domain controllers for successful domain integration.

To begin with, you need to verify that your Ubuntu system can connect and communicate with the Active Directory domain. This can be done using the realm command.

Typically, you would use the following commands to discover and join an Active Directory domain:

sudo realm discover -v DOMAIN-OR-REALM

For example;

sudo realm discover -v kifarunix.com

If you want to use LDAPS, just pass the option, --use-ldaps.

Sample output;

 * Resolving: _ldap._tcp.dc01.kifarunix.com
 * Resolving: dc01.kifarunix.com
 * Performing LDAP DSE lookup on: 10.184.10.40
 * Successfully discovered: kifarunix.com
kifarunix.com
  type: kerberos
  realm-name: KIFARUNIX.COM
  domain-name: kifarunix.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

You can then join the machine to AD:

sudo realm join -v dc01.kifarunix.com --membership-software=samba

Note that membership software samba does not support ldaps hence, you cannot use --use-ldaps.

The command will:

• Prompts for the AD admin password.
• Installs missing packages (if PackageKit is running).
• Joins the domain (creates computer account in AD).
• Configures SSSD, Kerberos (/etc/krb5.conf), NSS (/etc/nsswitch.conf), PAM (/etc/pam.d/ files), and keytab (/etc/krb5.keytab).
• Enables automatic home directory creation for AD users.

Sample command output;

 * Resolving: _ldap._tcp.dc01.kifarunix.com
 * Resolving: dc01.kifarunix.com
 * Performing LDAP DSE lookup on: 10.184.10.40
 * Successfully discovered: kifarunix.com
Password for Administrator: 
 * Unconditionally checking packages
 * Resolving required packages
 * Installing necessary packages: samba-common-bin
 * LANG=C LOGNAME=root /usr/bin/net --configfile /var/cache/realmd/realmd-smb-conf.OXI1A3 -S dc01.kifarunix.com -U Administrator --use-kerberos=required ads join kifarunix.com
Password for [KIFARUNIX\Administrator]:get_kdc_ip_string: get_kdc_list fail NT_STATUS_NO_LOGON_SERVERS
get_kdc_ip_string: get_kdc_list fail NT_STATUS_NO_LOGON_SERVERS
DNS update failed: NT_STATUS_INVALID_PARAMETER

Using short domain name -- KIFARUNIX
Joined 'NOBLE' to dns domain 'kifarunix.com'
No DNS domain configured for noble. Unable to perform DNS Update.
 * LANG=C LOGNAME=root /usr/bin/net --configfile /var/cache/realmd/realmd-smb-conf.OXI1A3 -S dc01.kifarunix.com -U Administrator ads keytab create
Password for [KIFARUNIX\Administrator]:
 * /usr/sbin/update-rc.d sssd enable
 * /usr/sbin/service sssd restart
 * Successfully enrolled machine in realm

You can verify that the machine has joined the AD;

realm list

Sample output;

kifarunix.com
  type: kerberos
  realm-name: KIFARUNIX.COM
  domain-name: kifarunix.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: %[email protected]
  login-policy: allow-realm-logins

Check how SSSD is configured;

sudo cat /etc/sssd/sssd.conf

[sssd]
domains = kifarunix.com
config_file_version = 2
services = nss, pam

[domain/kifarunix.com]
default_shell = /bin/bash
ad_server = dc01.kifarunix.com
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = KIFARUNIX.COM
realmd_tags = manages-system joined-with-samba 
id_provider = ad
fallback_homedir = /home/%u@%d
ad_domain = kifarunix.com
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad

Enforcing LDAPS in SSSD Configuration

To ensure all LDAP communication between your Linux client and Active Directory domain controllers is encrypted using LDAPS, you must explicitly configure SSSD to use secure connections only.

Therefore, update the SSSD configuration above and add these lines:

ldap_uri = ldaps://dc01.kifarunix.com:636
ldap_tls_reqcert = demand
ldap_tls_cacert = /usr/local/share/ca-certificates/ad-cd-root-ca.crt

Such that it may look like;

sudo cat /etc/sssd/sssd.conf

[sssd]
domains = kifarunix.com
config_file_version = 2
services = nss, pam

[domain/kifarunix.com]
default_shell = /bin/bash
ad_server = dc01.kifarunix.com
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = KIFARUNIX.COM
realmd_tags = manages-system joined-with-samba 
id_provider = ad
fallback_homedir = /home/%u@%d
ad_domain = kifarunix.com
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad
ldap_uri = ldaps://dc01.kifarunix.com:636
ldap_tls_reqcert = demand
ldap_tls_cacert = /usr/local/share/ca-certificates/ad-cd-root-ca.crt

Clear SSSD cache and restart the service:

sudo sss_cache -E

sudo systemctl restart sssd

Confirm the service is running fine:

systemctl status sssd

Test user lookup

As you can see from both the output of realm list and from sssd.conf, AD has enabled the use of full username (user@domain), hence, you must use full username including the domain:

id [email protected]

Example output;

uid=71001108([email protected]) gid=71000513(domain [email protected]) groups=71000513(domain [email protected]),71001109([email protected])

Otherwise, if you want to use short usernames, simply edit SSSD config and change the line:

use_fully_qualified_names = True

To:

use_fully_qualified_names = False

Next, restart SSSD service.

sudo systemctl restart sssd

Restrict Access to Specific AD Users

By default, as shown in the login policy from the realm list command output, any user in the Active Directory domain (kifarunix.com) can log in to the system. This default behavior poses a security risk, especially in environments with many domain users.

To improve security, it is recommended to:

• Deny login access to all domain users by default
• Explicitly allow only specific users or groups using the realm permit command, for example:

Deny all;

sudo realm deny --all

This will update the SSSD config and change the value of access_provider option from ad to deny.

Allow specific groups

sudo realm permit -g "IT Admins" 

This will then update the SSSD configuration file to add such lines:

access_provider = simple
simple_allow_groups = IT Admins

Allow specific users:

sudo realm permit [email protected]

This will update the SSSD configuration by adding the line; simple_allow_users = b.colly.

Restart SSSD service after the changes.

sudo systemctl restart sssd

Enable Auto-Home Directory Creation On First Login

Next, run the command below to ensure that users can have their home directories created on their first login.

sudo pam-auth-update --enable mkhomedir

Keep in mind:

• The format of the home directory depends on the type of username used during login.
• If you log in with the fully qualified username (e.g. [email protected]), the home directory will be created as:
  

  /home/[email protected]

• If you log in with the short username (e.g. user), the home directory will be:
  

  /home/user

Make sure this matches your expected directory structure or adjust settings accordingly (e.g. using use_fully_qualified_names in SSSD config).

Validate AD Based SSH Authentications

You can then test the SSH authentication using an AD user account.

ssh [email protected]@10.184.10.33

Creating directory '/home/[email protected]'.
Welcome to Ubuntu 24.04 LTS (GNU/Linux 6.8.0-63-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

 System information as of Wed Aug 13 05:54:51 PM UTC 2025

  System load:  0.08               Processes:               164
  Usage of /:   42.3% of 13.67GB   Users logged in:         1
  Memory usage: 11%                IPv4 address for enp1s0: 10.184.10.33
  Swap usage:   0%

 * Strictly confined Kubernetes makes edge and IoT secure. Learn how MicroK8s
   just raised the bar for easy, resilient and secure K8s cluster deployment.

   https://ubuntu.com/engage/secure-kubernetes-at-the-edge

Expanded Security Maintenance for Applications is not enabled.

167 updates can be applied immediately.
1 of these updates is a standard security update.
To see these additional updates run: apt list --upgradable

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status

Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings


1 updates could not be installed automatically. For more details,
see /var/log/unattended-upgrades/unattended-upgrades.log

*** System restart required ***

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

Last login: Wed Aug 13 17:41:39 2025 from 10.184.10.1
[email protected]@noble:~$ pwd
/home/[email protected]
[email protected]@noble:~$ ls -alhd .
drwxr-x--- 3 [email protected] domain [email protected] 4.0K Aug 13 17:54 .
[email protected]@noble:~$ exit
logout
Connection to 10.184.10.33 closed.

If you try to login as a user that is not permitted, SSH will failed with connection closed error.

The SSH authentication logs will show;

sudo tail -f /var/log/auth.log

...
2025-08-13T19:54:14.855320+00:00 noble sshd[4336]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.184.10.1  [email protected]
2025-08-13T19:54:14.910986+00:00 noble sshd[4336]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.184.10.1 [email protected]
2025-08-13T19:54:14.973863+00:00 noble sshd[4336]: pam_sss(sshd:account): Access denied for user [email protected]: 6 (Permission denied)
2025-08-13T19:54:14.973961+00:00 noble sshd[4336]: Failed password for [email protected] from 10.184.10.1 port 53852 ssh2
2025-08-13T19:54:14.974196+00:00 noble sshd[4336]: fatal: Access denied for user [email protected] by PAM account configuration [preauth]

Join Ubuntu to Windows AD via LDAPS using ADCLI

adcli is a lower-level tool for AD actions (discover, join, manage accounts). It creates the computer account and keytab but requires manual SSSD/Kerberos configuration post-join.

Therefore, to manually join an Ubuntu system to a Windows AD domain over LDAPS using adcli, you need to ensure that these packages are installed: krb5-config and krb5-user in addition to the ones installed above. These packages enable Kerberos authentication and secure LDAP communication, allowing Ubuntu to authenticate against AD without using the realm tool.

Just in case they have not been installed yet, execute the command below to install.

sudo apt install krb5-config krb5-user

During krb5-user install, you may prompt for your:

• Kerberos realm (in uppercase, like KIFARUNIX.COM)
  
• Kerberos servers (KDC) hostname(s). You should provide the Fully Qualified Domain Name(s) (FQDN) of your domain controllers that act as KDCs e.g dc01.kifarunix.com.
  
• Hostname of the administrative server for your realm. Ideally same as KDC, dc01.kifarunix.com.
  

And the installation will proceed.

If for some reason these details are not prompted or incorrectly set during installation, you can edit later in Kerberos configuration, /etc/krb5.conf.

By default, with the prompts above, here is how the krb5.conf configuration look like:

sudo cat /etc/krb5.conf

[libdefaults]
	default_realm = KIFARUNIX.COM

# The following krb5.conf variables are only for MIT Kerberos.
	kdc_timesync = 1
	ccache_type = 4
	forwardable = true
	proxiable = true
        rdns = false


# The following libdefaults parameters are only for Heimdal Kerberos.
	fcc-mit-ticketflags = true

[realms]
	KIFARUNIX.COM = {
		kdc = dc01.kifarunix.com
		admin_server = dc01.kifarunix.com
	}
	ATHENA.MIT.EDU = {
		kdc = kerberos.mit.edu
		kdc = kerberos-1.mit.edu
		kdc = kerberos-2.mit.edu:88
		admin_server = kerberos.mit.edu
		default_domain = mit.edu
	}
	ZONE.MIT.EDU = {
		kdc = casio.mit.edu
		kdc = seiko.mit.edu
		admin_server = casio.mit.edu
	}
	CSAIL.MIT.EDU = {
		admin_server = kerberos.csail.mit.edu
		default_domain = csail.mit.edu
	}
	IHTFP.ORG = {
		kdc = kerberos.ihtfp.org
		admin_server = kerberos.ihtfp.org
	}
	1TS.ORG = {
		kdc = kerberos.1ts.org
		admin_server = kerberos.1ts.org
	}
	ANDREW.CMU.EDU = {
		admin_server = kerberos.andrew.cmu.edu
		default_domain = andrew.cmu.edu
	}
        CS.CMU.EDU = {
                kdc = kerberos-1.srv.cs.cmu.edu
                kdc = kerberos-2.srv.cs.cmu.edu
                kdc = kerberos-3.srv.cs.cmu.edu
                admin_server = kerberos.cs.cmu.edu
        }
	DEMENTIA.ORG = {
		kdc = kerberos.dementix.org
		kdc = kerberos2.dementix.org
		admin_server = kerberos.dementix.org
	}
	stanford.edu = {
		kdc = krb5auth1.stanford.edu
		kdc = krb5auth2.stanford.edu
		kdc = krb5auth3.stanford.edu
		master_kdc = krb5auth1.stanford.edu
		admin_server = krb5-admin.stanford.edu
		default_domain = stanford.edu
	}
        UTORONTO.CA = {
                kdc = kerberos1.utoronto.ca
                kdc = kerberos2.utoronto.ca
                kdc = kerberos3.utoronto.ca
                admin_server = kerberos1.utoronto.ca
                default_domain = utoronto.ca
	}

[domain_realm]
	.mit.edu = ATHENA.MIT.EDU
	mit.edu = ATHENA.MIT.EDU
	.media.mit.edu = MEDIA-LAB.MIT.EDU
	media.mit.edu = MEDIA-LAB.MIT.EDU
	.csail.mit.edu = CSAIL.MIT.EDU
	csail.mit.edu = CSAIL.MIT.EDU
	.whoi.edu = ATHENA.MIT.EDU
	whoi.edu = ATHENA.MIT.EDU
	.stanford.edu = stanford.edu
	.slac.stanford.edu = SLAC.STANFORD.EDU
        .toronto.edu = UTORONTO.CA
        .utoronto.ca = UTORONTO.CA

So, we will backup this file and create a simplified version with the content ONLY relevant to us!

sudo cp /etc/krb5.conf{,bak}

And here is how our simplified version now looks like;

cat /etc/krb5.conf

[libdefaults]
    default_realm = KIFARUNIX.COM
    dns_lookup_realm = true
    dns_lookup_kdc = true
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true
    rdns = false

[realms]
    KIFARUNIX.COM = {
        kdc = dc01.kifarunix.com:88
        admin_server = dc01.kifarunix.com:749
        default_domain = kifarunix.com
    }

[domain_realm]
    .kifarunix.com = KIFARUNIX.COM
    kifarunix.com = KIFARUNIX.COM

Next, test Kerberos authentication. You need to first ensure that your system time is in sync and DNS is resolving your DC.

Then try obtaining a Kerberos ticket:

kinit [email protected]

Note that you can use any other non-administrator user, but it must have sufficient privileges to perform the join operation.

You’ll be prompted for the AD password.

Check ticket:

klist

Sample output;

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: [email protected]

Valid starting       Expires              Service principal
08/13/2025 20:07:54  08/14/2025 06:07:54  krbtgt/[email protected]
	renew until 08/20/2025 20:07:50

This indicates that the Kerberos authentication is working properly and that the Ubuntu system can authenticate against the AD domain securely.

Now use adcli to join the domain using Kerberos.

sudo adcli join --use-ldaps kifarunix.com -U administrator --verbose --ldap-passwd

If all goes well, you should receive an output similar to:

[sudo] password for kifarunix: 
 * Using domain name: kifarunix.com
 * Calculated computer account name from fqdn: NOBLE
 * Calculated domain realm from name: KIFARUNIX.COM
 * Discovering domain controllers: _ldap._tcp.kifarunix.com
 * Sending NetLogon ping to domain controller: dc01.kifarunix.com
 * Received NetLogon info from: dc01.kifarunix.com
 * Using LDAPS to connect to dc01.kifarunix.com
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-IDdOfy/krb5.d/adcli-krb5-conf-u62dqy
Password for [email protected]: 
 * Authenticated as user: [email protected]
 * Using GSSAPI for SASL bind
 * Looked up short domain name: KIFARUNIX
 * Looked up domain SID: S-1-5-21-1399238093-1182849409-1522810622
 * Received NetLogon info from: dc01.kifarunix.com
 * Using fully qualified name: noble.kifarunix.com
 * Using domain name: kifarunix.com
 * Using computer account name: NOBLE
 * Using domain realm: kifarunix.com
 * Calculated computer account name from fqdn: NOBLE
 * Generated 120 character computer password
 * Using keytab: FILE:/etc/krb5.keytab
 * Found computer account for NOBLE$ at: CN=NOBLE,CN=Computers,DC=kifarunix,DC=com
 * Trying to set computer password with LDAP
 * Set password for: CN=NOBLE,CN=Computers,DC=kifarunix,DC=com
 * Retrieved kvno '3' for computer account in directory: CN=NOBLE,CN=Computers,DC=kifarunix,DC=com
 * Checking RestrictedKrbHost/NOBLE
 *    Added RestrictedKrbHost/NOBLE
 * Checking HOST/NOBLE
 *    Added HOST/NOBLE
 * Checking RestrictedKrbHost/NOBLE.kifarunix.com
 *    Added RestrictedKrbHost/NOBLE.kifarunix.com
 * Checking HOST/NOBLE.kifarunix.com
 *    Added HOST/NOBLE.kifarunix.com
 * Discovered which keytab salt to use
 * Added the entries to the keytab: [email protected]: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: host/[email protected]: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: host/[email protected]: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: RestrictedKrbHost/[email protected]: FILE:/etc/krb5.keytab
 * Added the entries to the keytab: RestrictedKrbHost/[email protected]: FILE:/etc/krb5.keytab

And that confirms the machine successfully joined the domain. The machine account in Active Directory should have been created, and a keytab file has been generated at /etc/krb5.keytab on the localhost. The keytab is used to securely store the machine’s Kerberos credentials, allowing the system to authenticate with the domain without needing to enter a password each time.

Configure SSSD to Enforce LDAPS for Windows AD authentication

As already mentioned, adcli command do not automatically configure SSSD. Hence, to be able to authenticate against AD when you join the node using adcli, you must manually configure SSSD.

Similarly, SSSD do not ship with any configuration file by default. As such, you need to create your configuration file that defines your LDAP authentication specifics.

Below is our sample configuration;

sudo cat /etc/sssd/sssd.conf

[sssd]
services = nss, pam
config_file_version = 2
domains = kifarunix.com

[nss]
filter_groups = root
filter_users = root

[pam]
offline_credentials_expiration = 60

[domain/kifarunix.com]
id_provider = ad
auth_provider = krb5
chpass_provider = krb5
access_provider = ad
krb5_validate = true

ldap_uri = ldaps://dc01.kifarunix.com:636
ldap_search_base = dc=kifarunix,dc=com
ldap_schema = ad
ldap_id_mapping = True
ldap_tls_reqcert = demand
ldap_tls_cacert = /usr/local/share/ca-certificates/ad-cd-root-ca.crt
ldap_search_timeout = 50
ldap_network_timeout = 60
ldap_opt_timeout = 15
ldap_connection_expire_timeout = 900
ldap_referrals = false
case_sensitive = false
krb5_store_password_if_offline = True
krb5_realm = KIFARUNIX.COM
ad_server = dc01.kifarunix.com
ad_domain = kifarunix.com
use_fully_qualified_names = False
cache_credentials = True
enumerate = False

# Home directory and shell settings
fallback_homedir = /home/%u
override_shell = /bin/bash

In summary:

• Global Settings
  • Services Enabled: nss, pam (for name resolution and authentication)
  • Configured Domain: kifarunix.com
  • Config Version: 2
• [nss] Section
  • Filters out local users: root is excluded from domain resolution.
• [pam] Section
  • Offline credentials are valid for 60 days.
• [domain/kifarunix.com] Section
  • Identity & Authentication
    • Uses Active Directory as the identity (id_provider = ad) and access provider.
    • Kerberos is used for authentication and password changes.
    • Kerberos realm: KIFARUNIX.COM
    • Passwords are stored locally if offline.
  • LDAP Configuration
    • Connects to LDAP over SSL (ldaps://dc01.kifarunix.com:636)
    • Trusts only if the certificate is valid (ldap_tls_reqcert = demand)
    • Uses a custom CA cert: /usr/local/share/ca-certificates/ad-cd-root-ca.crt
    • Disables LDAP referrals (avoids redirection issues)
    • Applies timeouts and connection expiry settings for robustness.
  • Behavior
    • Short names enabled: use_fully_qualified_names = False (e.g., alice instead of [email protected])
    • Caching enabled for offline use: cache_credentials = True
    • No user/group enumeration to reduce performance overhead.
  • Home directory and shell defaults:
    • Home: /home/%u
    • Shell: /bin/bash

You can also update your access filters to allow specific users to access the system.

For example, to allow a number of users ONLY, then edit the configuration and change access_provider from ad to simple and add a line defining the specific users.

access_provider = ad
simple_allow_users = b.colly

For multiple specific users;

access_provider = ad
simple_allow_users = b.colly, j.smith, a.lee

For groups:

access_provider = simple
simple_allow_groups = IT Admins

For a comprehensive description of options used above, refer to man sssd.conf and man sssd-ad.

Next, open the /etc/ldap/ldap.conf and replace the value of TLS_CACERT with the path to the CA certificate created above.

sudo vim /etc/ldap/ldap.conf

...
# TLS certificates (needed for GnuTLS)
#TLS_CACERT     /etc/ssl/certs/ca-certificates.crt
TLS_CACERT      /usr/local/share/ca-certificates/ad-cd-root-ca.crt

Save and close the configuration file.

Set Proper Permissions and Ownership on SSSD configurations

Assign the root user read/write access to /etc/sssd/.

sudo chmod 600 -R /etc/sssd

sudo chown -R root: /etc/sssd

Perform static analysis of SSSD configuration to check if any error;

sudo sssctl config-check

Restart SSSD service if there is no issue with sssd.conf file.

sudo systemctl restart sssd

Check the status of SSSD to ensure that it is running.

systemctl status sssd

● sssd.service - System Security Services Daemon
     Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: enabled)
     Active: active (running) since Wed 2025-08-13 13:05:53 UTC; 5s ago
   Main PID: 50718 (sssd)
      Tasks: 4 (limit: 4614)
     Memory: 53.9M (peak: 54.1M)
        CPU: 305ms
     CGroup: /system.slice/sssd.service
             ├─50718 /usr/sbin/sssd -i --logger=files
             ├─50719 /usr/libexec/sssd/sssd_be --domain kifarunix.com --uid 0 --gid 0 --logger=files
             ├─50720 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
             └─50721 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files

Aug 13 13:05:53 noble.kifarunix.com systemd[1]: Starting sssd.service - System Security Services Daemon...
Aug 13 13:05:53 noble.kifarunix.com sssd[50718]: Starting up
Aug 13 13:05:53 noble.kifarunix.com sssd_be[50719]: Starting up
Aug 13 13:05:53 noble.kifarunix.com sssd_pam[50721]: Starting up
Aug 13 13:05:53 noble.kifarunix.com sssd_nss[50720]: Starting up
Aug 13 13:05:53 noble.kifarunix.com systemd[1]: Started sssd.service - System Security Services Daemon.
Aug 13 13:05:54 noble.kifarunix.com sssd_be[50719]: Backend is online

Enable SSSD to run on system boot;

sudo systemctl enable sssd

if you ever make changes to SSSD, ensure you clear cache and restart it;

sudo sss_cache -E

sudo systemctl restart sssd

Similarly, update the PAM modules to enable automatic creation of a user’s home directory on first login, as shown above.

sudo pam-auth-update --enable mkhomedir

Also, verify that you can now see AD user details on the host;

id j.doe

Sample output;

uid=71001104(j.doe) gid=71000513(domain users) groups=71000513(domain users),71001105(soc-l1)

getent passwd j.doe

Sample output;

j.doe:*:71001104:71000513:John Doe:/home/j.doe:/bin/bash

Verify GUI authentication via Windows AD

If you’re using a desktop system, follow the same procedure to install and configure SSSD for Active Directory integration. Once configured:

• You should be able to log in from the graphical login screen using your AD credentials.
• Use either the short username (user) or fully qualified format ([email protected]), depending on your SSSD settings.
• Ensure the pam_mkhomedir module is enabled to automatically create home directories on first login.

This allows seamless GUI logins for AD users on Linux desktops.

Leave and Disconnect a Linux Server from Windows AD

After integrating your Linux server with Active Directory, you might need to disconnect it from the domain. You can either leave the computer account intact in AD for future use or remove it entirely.

• For realmd-based setups:
  • To leave without deleting the computer account, run:
    

    sudo realm leave kifarunix.com

  • To leave and remove the computer account (requires AD admin credentials), run:
    

    sudo realm leave --remove kifarunix.com

• For manual adcli setups:
  • To delete the computer account, run:
    

    sudo adcli delete-computer --domain=kifarunix.com

  • To leave without deleting the account, stop SSSD (sudo systemctl stop sssd) and remove the Kerberos keytab (sudo rm -rf /etc/krb5.keytab).

After leaving the domain, clean up your system by removing SSSD caches:

sudo rm -rf /var/lib/sss/db/*

Revert PAM and NSS settings as appropriate:

sudo pam-auth-update --remove sssd

Finally, verify disconnection with:

realm list

or

sudo adcli info

And there you go. You have successfully installed and configured SSSD for Windows AD authentication on Ubuntu 24.04.

Conclusion

You’ve configured Ubuntu to authenticate with Windows AD using SSSD, with LDAPS for secure communication. Whether joined via realm or adcli, your system now supports centralized login. Remember to enforce access controls and cleanly disconnect when needed.

Related Tutorials

Configure SSSD for OpenLDAP Authentication on Ubuntu 18.04

Install phpLDAPadmin on CentOS 8

Configure ownCloud OpenLDAP Authentication

Configure OpenLDAP Host Based Authentication

How to Create OpenLDAP Member Groups