SLES 15 Active Directory Integration with SSSD: A Step-by-Step Guide

For a typical SUSE Linux Enterprise Server 15 host that needs domain users to log in, SUSE documents YaST User Logon Management with SSSD as the best fit in most Active Directory environments. SSSD provides the Linux identity and PAM authentication path, while Active Directory remains the source for accounts and Kerberos authentication. Winbind is a better fit when your design depends on NTLM or cross-forest trust support. If you prefer automation, SUSE also documents joining with realmd; it is a domain-discovery and membership tool, so confirm which client software and access policy your system will configure before using it at scale.

This walkthrough follows the SLES 15 SP7 Security and Hardening Guide, checked on October 6, 2026. SUSE service packs can differ, and the instructions below are a documentation-based procedure, not a claim that the commands were run against your domain. Replace the example domain and host names with values from your environment. Test first on a noncritical SLES machine and keep a local administrator account available in case domain authentication is misconfigured.

Choose the integration method that fits the job

SUSE describes the SSSD-backed YaST option as suitable for most AD joins and identifies Winbind for cases needing NTLM or cross-forest trusts. Those are practical starting points, not a substitute for testing application-specific needs such as Samba file serving, sudo rules, SSH key lookup, or multi-domain name collisions. For a plain Linux login fleet, begin with SSSD unless a documented requirement points elsewhere.

What to prepare before joining SLES to Active Directory

• A stable host name: Choose the intended fully qualified host name and make sure it resolves consistently in your network and in AD. Coordinate any computer-account naming convention with the directory team.
• Working AD-aware DNS: The SLES client must query a DNS server that can resolve the AD zone and its service (SRV) records. Using a public resolver alone commonly breaks domain discovery.
• Synchronized time: Kerberos depends on the client and domain controllers having closely aligned clocks. Confirm NTP synchronization before troubleshooting passwords or SSSD.
• Network access to domain controllers: Confirm the firewall and routing allow the protocols and ports required by your organization’s AD design, including DNS, Kerberos, LDAP and any required global catalog or password-change traffic. Do not open every port broadly; have the AD/network administrator provide the approved rules.
• An authorized enrollment identity: Use an account permitted to add or reuse computer objects in the correct organizational unit. Avoid routine use of a highly privileged account when delegated join rights are available.
• Recovery access: Keep a tested local administrator login and a way to access the console. Do not make the domain the only route back into a server before validating the new login path.

SUSE specifically calls out AD-reachable DNS and accurate time for Kerberos. Its guide notes that a domain ending in .local can conflict with multicast DNS in some join scenarios. If your AD uses that suffix, check the implications for your SLES release and network configuration with the directory administrator before changing naming or resolver settings.

hostnamectl --static
hostname -f
timedatectl status
getent hosts ad01.corp.example.com
host -t SRV _ldap._tcp.dc._msdcs.corp.example.com

The host command may require the DNS utilities package on a minimal installation. These checks do not prove that every required firewall path is open; they help catch common name-resolution and clock problems before enrollment.

Join the domain using YaST and SSSD

1. Set the resolver. Open YaST and choose Network Settings, then Hostname/DNS. Configure the AD DNS server, or an internal resolver that forwards the AD zone correctly. Save and confirm the host can resolve the domain controller and the AD service records.
2. Open User Logon Management. From the YaST main window, launch User Logon Management and select Change Settings. This is the SSSD-based authentication module in the SLES 15 SP7 guide; it is different from the Windows Domain Membership module, which uses Winbind.
3. Add the AD domain. Choose Add Domain, enter the DNS domain name such as corp.example.com, and select Microsoft Active Directory for both identity data and authentication. Make sure the domain is enabled. If DNS auto-discovery is not appropriate in your network, specify the approved domain controller host names as the guide describes.
4. Check the machine name and discovery result. Compare the local host name with the intended computer name in AD. Correct any mismatch before enrollment. YaST should discover an AD server and report that the client is not yet enrolled. If discovery fails, return to DNS, time, routing, and firewall checks rather than trying random authentication providers.
5. Enroll with an authorized account. Enter the AD credentials permitted to join the machine. YaST can install missing software during this process. The dialog may offer an option to overwrite Samba configuration; enable it only when that change is intended for your Samba/AD setup, and preserve the existing configuration first if Samba services are already in use.
6. Enable the intended login behavior. In Manage Domain User Logon, turn on domain user logon only after deciding which accounts should have access. Configure creation of local home directories if users need them. SUSE documents the fallback_homedir and override_homedir options and shows /home/%u as a possible format. In a multi-domain environment, design a unique path and check the SSSD manual before relying on a short user name alone.
7. Save, review, and test with a nonprivileged user. Apply the settings, confirm the domain and chosen options are correct, then test a normal domain account at the console or through the actual login service you plan to use. Do not test only with the account that joined the machine.

How do you verify the SSSD join?

Check that SSSD is active, that NSS can resolve a known domain identity, and that a real login succeeds. After the test user signs in, check for a Kerberos ticket. SUSE lists klist and getent passwd among its connection checks.

systemctl status sssd
getent passwd 'alex@corp.example.com'
id 'alex@corp.example.com'
klist

The exact identity string depends on the SSSD naming settings; some environments use DOMAIN\user rather than a UPN-style name. If getent returns no record, verify that you are querying the configured name format and domain, then inspect service logs:

sudo journalctl -u sssd --since "15 minutes ago"

A successful lookup alone does not prove that the user can log in, and an existing Kerberos ticket does not prove that every application uses the intended PAM stack. Test a new session, a password change if required, group-based authorization, and the relevant SSH or desktop login path. Confirm that access is restricted to the people you intended to allow.

SSSD or Winbind: which trade-off matters most?

For most SLES clients that need AD identities and interactive logins, SSSD is the straightforward choice supported by SUSE’s User Logon Management guidance. It integrates identity lookup and PAM authentication and can cache information for resilience when the directory is temporarily unreachable. Cached access has limits: a first-time login cannot rely on a cached credential, and directory-backed resources or password changes still need a reachable domain controller. Establish and test your offline-login policy rather than treating caching as a full AD outage solution.

Choose Winbind when a requirement specifically depends on Samba’s domain integration, NTLM, or cross-forest trusts. It is not simply an alternate checkbox for SSSD: each path uses different daemons and NSS/PAM components. Document which service owns domain lookups and logins, and avoid mixing old manual PAM/NSS edits with YaST-managed settings.

Use realmd when a repeatable shell workflow matters. SUSE’s SLES 15 SP7 Storage Administration Guide documents realm discover --verbose for DNS-based discovery, realm join --verbose for enrollment, and realm permit for login permissions. Inspect what client software is selected and what SSSD configuration is produced on your release. Avoid broad “allow everyone” access in production unless that is an explicit policy.

Common failures and the next check

• Domain discovery returns nothing: Check the client’s DNS server and the AD SRV record, then confirm the host can reach the listed domain controllers.
• Kerberos errors despite a correct password: Check system time synchronization, the DNS name used for the domain controller, and whether the computer account is enabled and correctly named.
• The user resolves but cannot log in: Confirm domain login is enabled in YaST, check access restrictions and account status in AD, and review SSSD/PAM logs.
• The login works but the home directory is missing: Confirm home-directory creation is enabled and that the configured path is valid and unique for the user.
• A join fails after prior experiments: Check for stale computer objects, duplicate host names, leftover Winbind or manual NSS/PAM configuration, and mismatched machine passwords. Coordinate cleanup with the AD administrator before deleting a computer object or clearing local SSSD data.

When should you stop and choose a different approach?

Pause before rollout if your environment relies on cross-forest trust behavior, NTLM, a Samba server role, several forests with overlapping short user names, or complex access rules that YaST’s basic settings do not express. Those conditions can change the preferred provider or require additional SSSD configuration. Test them with representative accounts and real services in a staging system, and keep the recovery login until the policy is proven.

Bottom line: For a standard SLES 15 SP7 workstation or server that needs Active Directory identities and logins, start with the YaST User Logon Management path backed by SSSD. Get DNS, time, host naming, and join permissions right first; then verify name lookup, Kerberos, PAM login, and access scope. Select Winbind for the specific Samba, NTLM, or cross-forest requirements SUSE identifies, and use realmd when its command-line workflow better fits your operational process.

Sources: SUSE SLES 15 SP7 Security and Hardening Guide: Active Directory support; SUSE SLES 15 SP7 Storage Administration Guide: realmd; SUSE SLES 15 SP7: authentication clients and SSSD; SUSE SLES 15 SP7 Release Notes.