In this guide, you’ll learn how to join RHEL 8/9/10 to Windows AD with SSSD. This allows RHEL systems to authenticate against Active Directory, centralizing user management and improving security. We will also cover how to configure secure LDAPS for encrypted communication with your domain controllers.
Table of Contents
How to Join RHEL 8/9/10 to Windows AD with SSSD
If you already have a Windows Active Directory (AD) server up and running, you can integrate your RHEL systems with it to enable centralized authentication using SSSD (System Security Services Daemon). This allows users to log in with their AD credentials, improving security and simplifying user management across mixed environments.
To integrate RHEL 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.
Access to Red Hat Repositories
Before setting up SSSD on a RHEL system, ensure that the system has access to the required Red Hat repositories. This means the system must be registered either with the Red Hat Customer Portal (CDN) or with a Red Hat Satellite server if your organization uses Satellite for content management. Without this registration and repository access, the system will not be able to install or update the necessary packages such as sssd, realmd, or authconfig. For Satellite-connected systems, ensure the correct activation key and organization are used during registration.
System Hostname Configuration
The system should have a properly set Fully Qualified Domain Name (FQDN).
Check with;
hostname -fSample output;
rhel10.kifarunix.com
You can set the FQDN using the command:
sudo hostnamectl set-hostname host.example.comYou can also update the /etc/hosts to include your FQDN:
sudo vim /etc/hosts127.0.1.1 host.example.com hostOr use the host static IP address instead of 127.0.0.1.
You can restart the following service:
sudo systemctl restart systemd-hostnamedDNS 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 network interface configuration, you can update it temporarily in the /etc/resolv.conf.
sudo vim /etc/resolv.confSet 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 +shortSample output;
0 100 88 dc01.kifarunix.com.
dig -t SRV _ldap._tcp.kifarunix.com +shortSample output;
0 100 389 dc01.kifarunix.com.
dig -t SRV _ldap._tcp.dc._msdcs.kifarunix.com +shortSample 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 389Connection to dc01.kifarunix.com (10.184.10.40) 389 port [tcp/ldap] succeeded!
nc -vz dc01.kifarunix.com 636Connection 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
chronyorsystemd-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, because it is installed by default on RHEL nodes.
Set the local time server;
sudo sed -i '/^pool/ s/^/#/;/^#pool / a\server dc01.kifarunix.com iburst' /etc/chrony.confsudo systemctl restart chronydVerify;
chronyc sourcesSample output;
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* dc01.kifarunix.com 3 6 7 0 +47ns[ -139us] +/- 45ms
Enable the service;
sudo systemctl enable chronydInstall SSSD and Required Packages on RHEL
Verify that the system has repositories setup!
sudo subscription-manager repos --list-enabledSample output for our RHEL 10 node:
+----------------------------------------------------------+
Available Repositories in /etc/yum.repos.d/redhat.repo
+----------------------------------------------------------+
Repo ID: rhel-10-for-x86_64-baseos-rpms
Repo Name: Red Hat Enterprise Linux 10 for x86_64 - BaseOS (RPMs)
Repo URL: https://cdn.redhat.com/content/dist/rhel10/$releasever/x86_64/baseos/os
Enabled: 1
Repo ID: rhel-10-for-x86_64-appstream-rpms
Repo Name: Red Hat Enterprise Linux 10 for x86_64 - AppStream (RPMs)
Repo URL: https://cdn.redhat.com/content/dist/rhel10/$releasever/x86_64/appstream/os
Enabled: 1
Next install SSSD and other necessary packages to join the domain on RHEL 8/9/10;
sudo dnf install samba-common-tools realmd oddjob \
oddjob-mkhomedir sssd adcli krb5-workstation \
openldap-clients sssd-toolsImport 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 /etc/pki/ca-trust/source/anchors/:
cat /etc/pki/ca-trust/source/anchors/ad-cs-root-ca.crtHere 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-trustNext, test the connection to the AD via LDAPs port to confirm CA certificate trust.
openssl s_client -connect dc01.kifarunix.com:636 -showcertsEnsure 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 RHEL 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 RHEL to AD or Use a Bind DN?
At this stage, you need to choose how RHEL 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 RHEL 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 RHEL 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 RHEL system to the AD domain to set up SSSD authentication.
Join RHEL 8/9/10 to the Windows AD Domain
Once you have the required packages installed, the next step is to join the RHEL 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.
realm join command, we include the --membership-software=samba option, and in the adcli join command, we include the --ldap-passwd option. These are necessary because, without them, you may encounter the following error during the join process:...
* 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 modifiedRead more on this thread.
Discover and Join RHEL to 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 RHEL 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-REALMFor example;
sudo realm discover -v kifarunix.comIf you want to use LDAPS, just pass the option, --use-ldaps.
sudo realm discover -v kifarunix.com --use-ldapsSample output;
* Resolving: _ldap._tcp.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-common
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd-ad
required-package: adcli
required-package: samba-common-tools
You can then join the machine to AD:
sudo realm join -v dc01.kifarunix.com --membership-software=sambaNote that membership software samba does not support ldaps hence, you cannot use --use-ldaps.
sudo realm join -v dc01.kifarunix.com --membership-software=samba --use-ldapsThe command will:
- Prompts for the AD admin password.
- Installs missing packages.
- 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 [email protected]:
* Membership software samba does not support ldaps, trying without.
* Required files: /usr/sbin/sssd, /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/libexec/sssd/gpo_child, /usr/bin/net
* LANG=C LOGNAME=root KRB5CCNAME=/var/cache/realmd/realm-ad-kerberos-6EL9A3 /usr/bin/net --configfile /var/cache/realmd/realmd-smb-conf.IZK9A3 -S dc01.kifarunix.com --use-kerberos=required ads join kifarunix.com
Using short domain name -- KIFARUNIX
Joined 'RHEL10' to dns domain 'kifarunix.com'
* LANG=C LOGNAME=root KRB5CCNAME=/var/cache/realmd/realm-ad-kerberos-6EL9A3 /usr/bin/net --configfile /var/cache/realmd/realmd-smb-conf.IZK9A3 -S dc01.kifarunix.com --use-kerberos=required ads keytab create
* /usr/bin/systemctl enable sssd.service
* /usr/bin/systemctl restart sssd.service
* /usr/bin/sh -c /usr/bin/authselect select sssd with-mkhomedir --force && /usr/bin/systemctl enable oddjobd.service && /usr/bin/systemctl start oddjobd.service
Backup stored at /var/lib/authselect/backups/2025-08-15-07-04-17.ZLwm44
Profile "sssd" was selected.
Make sure that SSSD service is configured and enabled. See SSSD documentation for more information.
- with-mkhomedir is selected, make sure pam_oddjob_mkhomedir module
is present and oddjobd service is enabled and active
- systemctl enable --now oddjobd.service
Created symlink '/etc/systemd/system/multi-user.target.wants/oddjobd.service' → '/usr/lib/systemd/system/oddjobd.service'.
* Successfully enrolled machine in realm
You can verify that the machine has joined the AD;
realm listSample 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-common
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd-ad
required-package: adcli
required-package: samba-common-tools
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 = /etc/pki/ca-trust/source/anchors/ad-cs-root-ca.crtSuch 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 = /etc/pki/ca-trust/source/anchors/ad-cs-root-ca.crt
And of course, you can customize the SSSD configuration file to suit your requirements.
Check validity of the SSSD configuration:
sudo sssctl config-checkFix any issue if there is any. Otherwise, proceed.
Clear SSSD cache and restart the service:
sudo sss_cache -Esudo systemctl restart sssdConfirm the service is running fine:
systemctl status sssdTest 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 instead of including the domain name, simply edit SSSD config and change the line:
use_fully_qualified_names = TrueTo:
use_fully_qualified_names = FalseNext, restart SSSD service.
sudo systemctl restart sssdRestrict 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 permitcommand, for example:
Deny all;
sudo realm deny --allThis 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 AdminsAllow 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 sssdEnable AD Login and Auto-Home Directory Creation On First Login
To enable Active Directory (AD) logins on a Linux system with automatic home directory creation upon first login, you can use authselect with the sssd profile, combined with oddjobd. This setup ensures that when a domain user logs in, their home directory is automatically created if it doesn’t exist, making it easier to manage user environments in enterprise settings.
To proceed, ensure the oddjob service is running:
systemctl status oddjobdIf not, start and enable it:
sudo systemctl enablem--now oddjobdNext, select and enable the sssd profile with the mkhomedir feature.
sudo authselect select sssd --force with-mkhomedirKeep 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.60[email protected]@10.184.10.60's password:
Register this system with Red Hat Insights: rhc connect
Example:
# rhc connect --activation-key --organization
The rhc client and Red Hat Insights will enable analytics and additional
management capabilities on your system.
View your connected systems at https://console.redhat.com/insights
You can learn more about how to register your system
using rhc at https://red.ht/registration
[email protected]@rhel10:~$ pwd
/home/[email protected]
[email protected]@rhel10:~$
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...
Aug 15 03:51:11 rhel10 sshd-session[8208]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.184.10.1 [email protected]
Aug 15 03:51:11 rhel10 sshd-session[8208]: pam_sss(sshd:account): Access denied for user [email protected]: 6 (Permission denied)
Aug 15 03:51:11 rhel10 sshd-session[8208]: Failed password for [email protected] from 10.184.10.1 port 60202 ssh2
Aug 15 03:51:11 rhel10 sshd-session[8208]: fatal: Access denied for user [email protected] by PAM account configuration [preauth]
Join RHEL 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.
How to join RHEL system to Active Directory domain using adcli?
To manually join an RHEL system to a Windows AD domain over LDAPS using adcli, proceed as follows:
Configure Kerberos for Active Directory Integration
By default, here is how the krb5.conf configuration look like:
sudo cat /etc/krb5.conf# To opt out of the system crypto-policies configuration of krb5, remove the
# symlink at /etc/krb5.conf.d/crypto-policies which will not be recreated.
includedir /etc/krb5.conf.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
spake_preauth_groups = edwards25519
dns_canonicalize_hostname = fallback
qualify_shortname = ""
# default_realm = EXAMPLE.COM
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
# EXAMPLE.COM = {
# kdc = kerberos.example.com
# admin_server = kerberos.example.com
# }
[domain_realm]
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM
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.confincludedir /etc/krb5.conf.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = KIFARUNIX.COM
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
spake_preauth_groups = edwards25519
dns_canonicalize_hostname = fallback
qualify_shortname = ""
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
KIFARUNIX.COM = {
kdc = dc01.kifarunix.com
admin_server = dc01.kifarunix.com
default_domain = kifarunix.com
}
[domain_realm]
.kifarunix.com = KIFARUNIX.COM
kifarunix.com = KIFARUNIX.COMNext, 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: KCM:1000
Default principal: [email protected]
Valid starting Expires Service principal
08/16/2025 09:56:28 08/16/2025 19:56:28 krbtgt/[email protected]
renew until 08/23/2025 09:56:24
This indicates that the Kerberos authentication is working properly and that the RHEL 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-passwdIf all goes well, you should receive an output similar to:
* Using domain name: kifarunix.com
* Calculated computer account name from fqdn: RHEL10
* 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-69SmZp/krb5.d/adcli-krb5-conf-J1pS7O
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: rhel10.kifarunix.com
* Using domain name: kifarunix.com
* Using computer account name: RHEL10
* Using domain realm: kifarunix.com
* Calculated computer account name from fqdn: RHEL10
* Generated 120 character computer password
* Using keytab: FILE:/etc/krb5.keytab
* A computer account for RHEL10$ does not exist
* Found well known computer container at: CN=Computers,DC=kifarunix,DC=com
* Calculated computer account: CN=RHEL10,CN=Computers,DC=kifarunix,DC=com
* Trying to set computer password with LDAP
* Encryption type [16] not permitted.
* Encryption type [23] not permitted.
* Encryption type [3] not permitted.
* Encryption type [1] not permitted.
* Created computer account: CN=RHEL10,CN=Computers,DC=kifarunix,DC=com
* Trying to set computer password with LDAP
* Set password for: CN=RHEL10,CN=Computers,DC=kifarunix,DC=com
* Retrieved kvno '2' for computer account in directory: CN=RHEL10,CN=Computers,DC=kifarunix,DC=com
* Checking RestrictedKrbHost/rhel10.kifarunix.com
* Added RestrictedKrbHost/rhel10.kifarunix.com
* Checking RestrictedKrbHost/RHEL10
* Added RestrictedKrbHost/RHEL10
* Checking host/rhel10.kifarunix.com
* Added host/rhel10.kifarunix.com
* Checking host/RHEL10
* Added host/RHEL10
* 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 = /etc/pki/ca-trust/source/anchors/ad-cs-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/bashIn summary:
- Global Settings
- Services Enabled:
nss,pam(for name resolution and authentication) - Configured Domain:
kifarunix.com - Config Version:
2
- Services Enabled:
- [nss] Section
- Filters out local users:
rootis excluded from domain resolution.
- Filters out local users:
- [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.
- Uses Active Directory as the identity (
- 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-cs-root-ca.crt - Disables LDAP referrals (avoids redirection issues)
- Applies timeouts and connection expiry settings for robustness.
- Connects to LDAP over SSL (
- Behavior
- Short names enabled:
use_fully_qualified_names = False(e.g.,aliceinstead of[email protected]) - Caching enabled for offline use:
cache_credentials = True - No user/group enumeration to reduce performance overhead.
- Short names enabled:
- Home directory and shell defaults:
- Home:
/home/%u - Shell:
/bin/bash
- Home:
- Identity & Authentication
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.collyFor multiple specific users;
access_provider = ad
simple_allow_users = b.colly, j.smith, a.leeFor groups:
access_provider = simple
simple_allow_groups = IT AdminsFor a comprehensive description of options used above, refer to man sssd.conf and man sssd-ad.
Next, open the /etc/openldap/ldap.conf and replace the value of TLS_CACERT with the path to the CA certificate created above.
sudo vim /etc/openldap/ldap.conf...
# TLS certificates (needed for GnuTLS)
#TLS_CACERT /etc/pki/tls/cert.pem
TLS_CACERT /etc/pki/ca-trust/source/anchors/ad-cs-root-ca.crtSave 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/sssdsudo chown -R root: /etc/sssdPerform static analysis of SSSD configuration to check if any error;
sudo sssctl config-checkRestart SSSD service if there is no issue with sssd.conf file.
sudo systemctl restart sssdCheck the status of SSSD to ensure that it is running.
systemctl status sssd
Enable SSSD to run on system boot;
sudo systemctl enable sssdIf you ever make changes to SSSD, ensure you clear cache and restart it;
sudo sss_cache -Esudo systemctl restart sssdSimilarly, update the PAM modules to enable automatic creation of a user’s home directory on first login, as shown above.
sudo authselect select sssd with-mkhomedirEnsure the oddjob service is running:
systemctl status oddjobdIf not, start and enable it:
sudo systemctl enable --now oddjobdAlso, verify that you can now see AD user details on the host;
id j.doeSample output;
uid=71001104(j.doe) gid=71000513(domain users) groups=71000513(domain users),71001105(soc-l1)
getent passwd j.doeSample output;
j.doe:*:71001104:71000513:John Doe:/home/j.doe:/bin/bash
Upon SSH login, you should land on your home directory;
[email protected]'s password:
Register this system with Red Hat Insights: rhc connect
Example:
# rhc connect --activation-key --organization
The rhc client and Red Hat Insights will enable analytics and additional
management capabilities on your system.
View your connected systems at https://console.redhat.com/insights
You can learn more about how to register your system
using rhc at https://red.ht/registration
Last login: Sat Aug 16 10:34:25 2025 from 10.184.10.1
a.smith@rhel10:~$ pwd
/home/a.smith
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_mkhomedirmodule 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
- To leave without deleting the computer account, run:
- 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).
- To delete the computer account, run:
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 authselect select local --forceFinally, verify disconnection with:
realm listor
sudo adcli infoAnd there you go. You have successfully installed and configured SSSD for Windows AD authentication on RHEL 8/9/10.
Conclusion
You’ve configured RHEL 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.
