How to Configure LDAP Security on Windows Server 2022

Introduction to Domain Joining Windows and Linux Machines

Active Directory Domain Services (AD DS) on Windows Server 2022 serves as the central identity and access management platform for enterprise environments. Joining both Windows and Linux machines to an AD domain enables single sign-on, centralized authentication, Group Policy enforcement, and unified user management across heterogeneous infrastructure. While Windows domain joining is straightforward, Linux integration has become significantly simpler over recent years thanks to tools like realmd and SSSD. This guide covers Windows machine joining via PowerShell and the GUI, offline domain join with djoin.exe, Linux domain joining with realmd, SSSD configuration, Kerberos authentication, and troubleshooting common failures.

Joining Windows Machines to the Domain

The traditional method for joining a Windows machine to a domain uses System Properties. Right-click This PC, select Properties, then Change settings next to the computer name. In the System Properties dialog, click Change, select Domain, enter the domain name (e.g., corp.example.com), and click OK. You will be prompted for credentials with permission to join machines to the domain (Domain Admin or a delegated account).

The PowerShell approach using Add-Computer is faster and scriptable:

$DomainCred = Get-Credential -UserName "corpadministrator" -Message "Enter domain join credentials"

Add-Computer `
    -DomainName "corp.example.com" `
    -Credential $DomainCred `
    -OUPath "OU=Workstations,OU=HQ,DC=corp,DC=example,DC=com" `
    -NewName "WS-MKTG-005" `
    -Restart `
    -Force `
    -PassThru

-OUPath places the computer account in a specific Organizational Unit rather than the default Computers container. Placing workstations in the correct OU ensures the right Group Policy Objects apply immediately.

-NewName renames the computer at the same time as the domain join, reducing the number of reboots required.

Join a remote computer to the domain (useful for scripting bulk joins):

Add-Computer `
    -ComputerName "DESKTOP-REMOTE01" `
    -DomainName "corp.example.com" `
    -Credential $DomainCred `
    -LocalCredential (Get-Credential -UserName "DESKTOP-REMOTE01Administrator") `
    -OUPath "OU=Workstations,DC=corp,DC=example,DC=com" `
    -Restart `
    -Force

Verify the domain join after reboot:

(Get-WmiObject Win32_ComputerSystem).Domain
Get-ADComputer -Identity "WS-MKTG-005" | Select-Object Name, DistinguishedName, Enabled

Offline Domain Join with djoin.exe

Offline domain join allows you to join a computer to the domain without a direct connection to a domain controller. This is useful for provisioning machines in isolated networks, branch offices with intermittent connectivity, or during OS deployment before network configuration is complete.

Step 1 — On a domain-connected machine (run as Domain Admin), generate a blob file for the target computer:

djoin.exe /provision /domain corp.example.com /machine REMOTE-PC-01 /machineou "OU=Remote,DC=corp,DC=example,DC=com" /savefile C:DJoinREMOTE-PC-01.djoin

This creates a computer account in AD and saves the provisioning data to the specified file. The blob file contains the machine password and domain configuration data.

Step 2 — Transfer the blob file to the target machine (via USB, file share, or any available method). On the target machine (no domain connectivity required), apply the blob:

djoin.exe /requestodj /loadfile C:REMOTE-PC-01.djoin /windowspath C:Windows /localos

Step 3 — Restart the target machine. Upon reboot, it is domain-joined and will synchronize Group Policy when it next connects to the domain.

The blob file contains sensitive credentials. Transfer it securely and delete it after use:

Remove-Item -Path "C:DJoinREMOTE-PC-01.djoin" -Force

Joining Linux to Active Directory with realmd

realmd is a D-Bus system service that provides a simplified interface for joining enterprise identity domains. It detects the domain type, installs required packages, and configures SSSD or Winbind automatically. Most modern Linux distributions include realmd in their package repositories.

Install realmd and required dependencies on RHEL/CentOS/Rocky Linux:

dnf install -y realmd sssd sssd-tools sssd-ldap oddjob oddjob-mkhomedir adcli samba-common-tools krb5-workstation

On Ubuntu/Debian:

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

Discover the domain before joining to verify DNS resolution and realm detectability:

realm discover corp.example.com

This should return the realm type (active-directory), required packages, and the configured method (sssd). If discovery fails, check that the Linux machine’s DNS is pointing to the AD DNS server:

cat /etc/resolv.conf
nslookup corp.example.com

Join the domain:

realm join --user=administrator corp.example.com

You will be prompted for the administrator password. To join with a specific computer name or to a specific OU:

realm join --user=administrator --computer-name=LINUX-WEB01 --computer-ou="OU=Linux,OU=Servers,DC=corp,DC=example,DC=com" corp.example.com

Verify the domain join was successful:

realm list

This should show the realm name, type, configured status, and the domain suffix.

Configuring SSSD for Linux AD Authentication

System Security Services Daemon (SSSD) handles authentication, authorization, and caching of identity information from Active Directory. realmd configures a basic SSSD setup automatically, but you should review and tune the configuration for your environment.

The main SSSD configuration file is at /etc/sssd/sssd.conf. A typical configuration after realm join:

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

[domain/corp.example.com]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = CORP.EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
id_provider = ad
fallback_homedir = /home/%u@%d
ad_domain = corp.example.com
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = ad

Key settings to understand:

use_fully_qualified_names = True: Users must log in as [email protected] rather than just user. Set to False if you want short usernames, but this can cause conflicts if the same username exists in multiple domains.

cache_credentials = True: Allows users to log in even if the domain controller is temporarily unreachable, using cached Kerberos credentials.

ldap_id_mapping = True: SSSD generates UIDs and GIDs from the AD SID rather than requiring them to be set in AD. This is usually desired in mixed environments.

fallback_homedir: The template for home directory paths. %u expands to the username, %d to the domain.

After modifying sssd.conf, restart the service:

chmod 600 /etc/sssd/sssd.conf
systemctl restart sssd
systemctl enable sssd

Configure PAM to create home directories automatically on first login using oddjob:

systemctl enable --now oddjobd
authselect select sssd with-mkhomedir --force

On Debian/Ubuntu, use pam-auth-update:

pam-auth-update --enable mkhomedir

Verifying Linux Domain Join

After joining and configuring SSSD, verify that domain users and groups are resolvable from the Linux machine.

Check a specific domain user:

id [email protected]

This should return the user’s UID, GID, and group memberships pulled from AD. If it returns “no such user”, SSSD is not communicating with AD properly.

List all users via Name Service Switch (NSS):

getent passwd [email protected]

Look up a domain group:

getent group "domain [email protected]"

Test actual authentication (this prompts for the AD user’s password):

su - [email protected]

Check the SSSD cache and connectivity status:

sssctl domain-status corp.example.com
sssctl user-checks [email protected]

Kerberos Authentication from Linux

With the domain joined, Linux users can obtain Kerberos tickets for Single Sign-On to AD-integrated services such as file shares, web applications using Kerberos, and SSH servers with GSSAPI.

Obtain a Kerberos ticket interactively:

kinit [email protected]

Note: The realm name (CORP.EXAMPLE.COM) must be in uppercase for Kerberos. List current tickets:

klist

This shows the ticket-granting ticket (TGT) and any service tickets, along with their expiry times. Renew an expiring ticket:

kinit -R [email protected]

Destroy all tickets when done:

kdestroy

Access a Windows SMB file share using the Kerberos ticket:

smbclient //fileserver.corp.example.com/SharedDocs -k

The Kerberos configuration file is at /etc/krb5.conf. SSSD and realmd configure this automatically, but verify the realm and KDC settings:

cat /etc/krb5.conf

Group Policy for Linux with oddjob

While traditional Windows Group Policy does not apply to Linux clients, you can use a combination of SSSD access control and AD group membership to replicate GPO-like access restrictions on Linux machines.

Restrict which AD groups can log into the Linux machine:

realm permit -g "[email protected]"
realm permit -g "[email protected]"

This adds entries to /etc/sssd/sssd.conf under ad_access_filter. Only members of the specified AD groups can authenticate to this machine.

To allow all domain users (remove restrictions):

realm permit --all

Configure sudo access for an AD group by editing the sudoers file:

echo "%[email protected] ALL=(ALL) ALL" >> /etc/sudoers.d/domain-admins
chmod 440 /etc/sudoers.d/domain-admins

For more advanced sudo control integrated with AD, configure SSSD with sudo LDAP support by adding to /etc/sssd/sssd.conf:

[sssd]
services = nss, pam, sudo

[domain/corp.example.com]
sudo_provider = ad

Troubleshooting Domain Join Failures

Common domain join failures and their solutions:

DNS resolution failure: The Linux or Windows machine cannot resolve the domain name. Ensure the machine’s primary DNS server points to an AD DNS server. For Linux:

nslookup -type=SRV _ldap._tcp.corp.example.com
nslookup -type=SRV _kerberos._tcp.corp.example.com

Both SRV record lookups must succeed for domain join to work.

Clock skew error: Kerberos requires that the time difference between the joining machine and the domain controller be less than 5 minutes. Sync NTP:

# Linux
timedatectl set-ntp true
timedatectl status

# Check against a DC
ntpdate -q dc01.corp.example.com

Insufficient permissions: The account used for joining does not have permission to create computer accounts in AD, or the computer account already exists in a different OU. Either use a Domain Admin account or ensure the joining account has been granted the “Create Computer Objects” right on the target OU.

SSSD not starting after Linux join: Check for configuration errors:

journalctl -xe -u sssd
sssd --logger=stderr -d 4

User lookup failing after join: Clear the SSSD cache and restart:

sssctl cache-remove -o
systemctl restart sssd

Windows domain join error 0x54B (The specified domain does not exist): Usually a DNS issue. Verify the Windows machine can resolve the domain’s SRV records:

nslookup -type=SRV _ldap._tcp.corp.example.com

Managing AD-Joined Linux Machines with RSAT

Once Linux machines are joined to AD, you can manage their computer accounts from Windows using Remote Server Administration Tools (RSAT), just like Windows machines.

Install RSAT on Windows 10/11 or Windows Server 2022:

Get-WindowsCapability -Name RSAT* -Online | Where-Object State -eq NotPresent | Add-WindowsCapability -Online

View the Linux machine’s AD computer account:

Get-ADComputer -Identity "LINUX-WEB01" | Select-Object Name, DistinguishedName, OperatingSystem, LastLogonDate

Note that OperatingSystem may be blank for Linux machines joined via realm; you can update it manually:

Set-ADComputer -Identity "LINUX-WEB01" -OperatingSystem "Red Hat Enterprise Linux 9.2" -OperatingSystemVersion "9.2"

Check when the Linux machine last authenticated to the domain (useful for identifying stale accounts):

Get-ADComputer -Identity "LINUX-WEB01" -Properties LastLogonDate | Select-Object Name, LastLogonDate

Reset a Linux machine’s AD password if the secure channel is broken (this is equivalent to netdom resetpwd on Windows):

# On the Linux machine:
adcli update-computer --domain corp.example.com --login-user administrator

To remove a Linux machine from the domain:

realm leave corp.example.com

Then remove the lingering computer account from AD:

Remove-ADComputer -Identity "LINUX-WEB01" -Confirm:$false

Conclusion

Joining both Windows and Linux machines to an Active Directory domain on Windows Server 2022 creates a unified identity fabric across the entire enterprise. Windows machines benefit from seamless Group Policy, WSUS, and centralized management through RSAT and PowerShell. Linux machines joined via realmd and SSSD gain Kerberos-based authentication, centralized user management, and access control through AD group membership. By mastering djoin.exe for offline Windows provisioning, realm join for Linux integration, and the verification tools available on both platforms, administrators can confidently extend their AD domain to every machine in their infrastructure regardless of operating system.