Skip to content

Instantly share code, notes, and snippets.

@firemanxbr

firemanxbr/rhel9-sssd-samba-ad.md

Forked from swamikevala/rhel9-sssd-samba-ad.md
Created April 29, 2025 07:10
Show Gist options
  • Save firemanxbr/f109bba2bd8e447eccb6577a1992bd21 to your computer and use it in GitHub Desktop.
Save firemanxbr/f109bba2bd8e447eccb6577a1992bd21 to your computer and use it in GitHub Desktop.
Download ZIP
Configure RHEL9.5 with sssd, samba and AD (by OpenAI Deep Research)
Raw
rhel9-sssd-samba-ad.md

RHEL 9.5 AD Integration with SSSD and Samba (Step-by-Step Guide)

Important Note: (18-Feb-2025) This gist has some issues. Please see the addendum. Thanks @hortimech for pointing this out

A step-by-step configuration guide for setting up RHEL 9.5 with SSSD and Samba for Active Directory integration. Covers all required configuration files, settings, and explanations for each option. Also sources for further documentation and troubleshooting recommendations:

  • Domain Joining with SSSD (configuring sssd.conf, realmd, Kerberos, and automatic authentication for SSH and Samba)
  • Samba Configuration with SSSD (using sss as the backend for identity mapping, Kerberos authentication, and ensuring smooth Windows/Mac access)
  • Kerberos-based Single Sign-On (SSO) (ensuring users can access SMB shares without re-entering credentials)
  • Offline Authentication (caching credentials for when AD is unreachable)
  • AD Group Membership Update Optimization (configuring SSSD caching policies to reflect changes within 1-2 minutes)
  • Permissions Management (ensuring group-based access with standard octal permissions, avoiding ACLs unless strictly needed)
  • SSH Key Management with AD (fetching SSH public keys stored in Active Directory for login authentication)

1. Joining RHEL 9.5 to the AD Domain

Install Required Packages: Ensure your RHEL system has the tools for domain joining and SSSD. Install packages like realmd, SSSD, ADCLI, Kerberos client, and Samba tools. For example:

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

This will install realmd (for easy domain join), sssd (for authentication), adcli (for AD enrollment), Kerberos client libraries, and Samba. The oddjob-mkhomedir package is included to create home directories on first login (Chapter 1. Connecting RHEL systems directly to AD using SSSD | Red Hat Product Documentation) (Chapter 1. Connecting RHEL systems directly to AD using SSSD | Red Hat Product Documentation)

Enable and Start SSSD: After installation, start SSSD and enable it at boot:

systemctl enable --now sssd

Also start the oddjobd service (for home directory creation) if it's not already running:

systemctl enable --now oddjobd

DNS and Time Sync: Before joining the domain, ensure the system’s DNS is pointed at the AD domain’s DNS servers and that time is synchronized between RHEL and the domain controllers (Kerberos authentication is time-sensitive) (Chapter 1. Connecting RHEL systems directly to AD using SSSD | Red Hat Product Documentation) For time sync, install or configure chronyd or ntpd as needed.

Discover the Domain: Use the realm command to discover your AD domain. For example, if your domain is example.com:

realm discover example.com

This should output domain configuration details if DNS is set correctly (e.g. domain controllers, realm name, etc.).

Join the Domain: Use realmd to join the machine to AD. You’ll need an AD account with permissions to join computers to the domain (e.g. Domain Admin or a delegated user). For example:

realm join --user=Administrator --client-software=sssd --membership-software=samba --automatic-id-mapping=yes example.com

You will be prompted for the AD administrator password. After a successful join, realmd will automatically update configuration files: it creates or updates /etc/sssd/sssd.conf, /etc/krb5.conf, and adds the machine Kerberos key to /etc/krb5.keytab. It also adjusts PAM and NSS via authselect to use SSSD (and enables home directory creation if oddjob-mkhomedir is installed).

Note: Ensure the realm name (EXAMPLE.COM) and workgroup (NetBIOS domain, e.g. EXAMPLE) are noted; we’ll need them for Samba config.

Verify Domain Join: You can confirm the join with:

# getent passwd [email protected]
[email protected]:*:1234567890:1234567890:Administrator:/home/EXAMPLE/administrator:/bin/bash

If you see a valid passwd entry for the AD user (UID/GID are large numbers derived from AD), the join is working and SSSD is resolving identities.

Home Directory Creation: Realmd typically enables automatic homedir creation. To double-check, ensure that authselect is using the with-mkhomedir profile. You can run:

authselect list

The active profile should be “sssd with-mkhomedir”. If not, apply it:

authselect select sssd with-mkhomedir --force

This ensures that when an AD user logs in, a home directory (e.g. /home/<username> or /home/<DOMAIN>/<username>) is created via pam_oddjob_mkhomedir.so. (The exact path depends on fallback_homedir setting in SSSD – we’ll adjust that next.)

2. Configuring SSSD for Authentication and Identity Management

After the realm join, SSSD should already be configured for your domain in /etc/sssd/sssd.conf. We will refine this configuration to meet our requirements (offline auth, fast group updates, SSH keys, etc.). Open /etc/sssd/sssd.conf as root (ensure its permissions are 600). Key settings:

[sssd] Section:

  • Ensure the services include nss, pam, and add ssh (to enable SSH public key retrieval via SSSD). For example:

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

    Adding “ssh” to services instructs SSSD to start its SSH responder for public key lookups (Linux SSH Key + Password Auth for Users Stored in Active Directory)

[domain/example.com] Section: (Replace with your domain name) Set or verify the following options:

  • id_provider = ad and auth_provider = ad (these should be set by realmd). This tells SSSD to use the AD domain for identity and auth.

  • use_fully_qualified_names = False – This allows users to log in with just username instead of user@domain or DOMAIN\user ( Article - Join RHEL or compatible (Or... ) ( Article - Join RHEL or compatible (Or... ) With this set to false, SSSD will map the short name to the AD domain by default. (Ensure fallback_homedir is adjusted accordingly, as shown next.)

  • fallback_homedir = /home/%u – Sets home directory template to /home/username (omit domain component) ( Article - Join RHEL or compatible (Or... ) ( Article - Join RHEL or compatible (Or... ) By default realmd might set this to /home/%d/%u (domain/user). If you prefer home directories without the domain prefix, use /home/%u. (Make sure this matches what you want; if you have multiple domains, you might keep the domain directory.)

  • cache_credentials = True – Enables offline authentication caching (13.2.16. Domain Options: Enabling Offline Authentication | Red Hat Product Documentation) (13.2.16. Domain Options: Enabling Offline Authentication | Red Hat Product Documentation) This is essential for allowing logins when the AD servers are unreachable. With this on, once a user successfully logs in, their credentials are cached locally so that future logins (or sudo, etc.) can succeed offline.

  • entry_cache_timeout = 120 (seconds) – Reduce SSSD’s cache update interval for identities. By default, SSSD would cache user and group info for 90 minutes (5400s) (13.2.16. Domain Options: Enabling Offline Authentication | Red Hat Product Documentation) which is too long for our requirement. Setting entry_cache_timeout = 120 forces SSSD to refresh user and group info from AD every 2 minutes. This helps pick up group membership changes quickly. (You can adjust this value; 120s will reflect changes within ~2 minutes. Setting 300s would reflect within ~5 minutes. Note: Lower values cause more frequent queries to AD, so consider your AD load. 1–5 minutes is reasonable for fast updates in a small/medium environment.)

  • entry_cache_user_timeout = 120 and entry_cache_group_timeout = 120 – You can also set user and group cache timeouts separately (if not set, they default to the general entry_cache_timeout) (SSSD Manual pages) (SSSD Manual pages) Setting both to 120 ensures both user info and group memberships refresh quickly.

  • enumerate = False – (Should be default) Ensure this remains false. We do not want SSSD to periodically enumerate all users/groups in AD, as that can be expensive. We only fetch what we need (login or lookup requests).

  • ldap_use_tokengroups = True – This leverages an AD-specific feature to retrieve group memberships in a single query using the user’s TokenGroups attribute (Linux SSH Key + Password Auth for Users Stored in Active Directory) This can improve performance, especially if users are members of many groups or nested groups, by avoiding multiple LDAP queries. (SSSD will retrieve the full list of group SIDs from the tokenGroups in the user’s Kerberos ticket or via LDAP, rather than resolving each group membership individually.)

  • ldap_id_mapping = True/False – This setting controls how UID/GIDs are assigned. By default, SSSD’s AD provider maps AD SIDs to UIDs/GIDs automatically (algorithmically). If your AD users and groups have POSIX attributes (uidNumber/gidNumber) defined, you should disable SSSD’s mapping to use those exact values: ldap_id_mapping = false (Chapter 1. Connecting RHEL systems directly to AD using SSSD | Red Hat Product Documentation) In that case, also ensure ldap_schema = ad and possibly enumerate = false (and that the AD attributes are published in Global Catalog or accessible). If AD does not have POSIX attrs, leave ldap_id_mapping = true (the default) so SSSD will generate consistent IDs from the AD SIDs. Either approach ensures all Linux servers have consistent UID/GID for the same AD user (see Section 6 for more details on ID mapping).

  • ad_gpo_access_control = permissive (optional): By default, SSSD will honor Active Directory GPOs for login access (e.g., the “Allow log on locally” or “Allow log on through Remote Desktop” rights) ( Article - Join RHEL or compatible (Or... ) If your AD environment does not use these policies for Linux servers, you can set ad_gpo_access_control = permissive or = disabled to ignore GPO-based access control. This will ensure all AD users (or those permitted via SSSD’s own access rules) can log in. (If you find that only domain admins can log in by default, it’s likely due to AD’s default policy. Adjusting this setting or updating the policy to include your users/groups will fix that.)

  • ad_update_samba_machine_account_password = True – Important for Samba: This setting tells SSSD to automatically update the machine account password in AD (and Samba) when it changes (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim) AD machine passwords typically rotate every 30 days. Enabling this ensures SSSD will keep the /etc/krb5.keytab and Samba’s machine credentials (secrets.tdb) in sync when the password updates. We will also adjust Samba to avoid conflicts (disabling its own password roll mechanism).

  • Other defaults (for the AD provider) like access_provider = ad, chpass_provider = ad, krb5_realm = EXAMPLE.COM, realmd_tags = manages-system, etc., are usually set by realmd. You can leave those as is.

After editing, your /etc/sssd/sssd.conf domain section might look like:

[domain/example.com]
id_provider = ad
auth_provider = ad
access_provider = ad
use_fully_qualified_names = False
fallback_homedir = /home/%u
cache_credentials = True
entry_cache_timeout = 120
entry_cache_user_timeout = 120
entry_cache_group_timeout = 120
ldap_use_tokengroups = True
# If AD has POSIX IDs:
# ldap_id_mapping = False
# If relying on automatic mapping (default):
# ldap_id_mapping = True   (comment or omit if default)
enumerate = False
ad_update_samba_machine_account_password = True
# (Other defaults like default_shell, etc., can be set if needed)

Storing SSH Public Keys in AD: We want SSH to use public keys stored in AD for user logins (so users don’t need to manage ~/.ssh/authorized_keys on each server). We’ll use the attribute altSecurityIdentities in AD to store the SSH keys (this is one approach; alternatively, you could extend the AD schema with an sshPublicKey attribute, but using an existing attribute avoids schema changes).

In Active Directory (Windows Server 2012 R2): For each user who needs key-based SSH access, open Active Directory Users and Computers (ADUC) with “Advanced Features” enabled. In the user’s properties Attribute Editor, find altSecurityIdentities. Paste the user’s public SSH key into this attribute’s value. The key should be in standard OpenSSH format (e.g., ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ... comment) (Linux SSH Key + Password Auth for Users Stored in Active Directory) (Linux SSH Key + Password Auth for Users Stored in Active Directory) You can store multiple keys by adding multiple values to altSecurityIdentities if needed.

Now configure SSSD to retrieve that attribute:

  • Add to the domain section in sssd.conf:

    ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities
ldap_user_ssh_public_key = altSecurityIdentities

    The first line tells SSSD to pull the altSecurityIdentities attribute for users and store it in the cache. The second line tells SSSD that this attribute contains the SSH public key(s) for the user (Linux SSH Key + Password Auth for Users Stored in Active Directory)

    If you had extended your AD schema to have an attribute named e.g. sshPublicKey for users, you would use that name instead on both lines.

Apply Changes: After editing sssd.conf, save it and ensure its permissions are root:root and 600. Then restart SSSD to apply:

systemctl restart sssd

Check SSSD’s status for any errors (systemctl status sssd). If SSSD fails to start, most likely it’s a syntax issue or file permission issue (SSSD is very strict about sssd.conf ownership and perms). The command sssctl config-check is also useful to validate the config.

Configure SSH Daemon to Use SSSD for Keys: Edit /etc/ssh/sshd_config to retrieve keys via SSSD:

  • Ensure GSSAPI authentication is enabled (this allows Kerberos SSO via SSH if desired). Typically, GSSAPIAuthentication yes is default on RHEL 9.

  • Add an AuthorizedKeysCommand that points to SSSD’s utility, and run it as root. For example:

    AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys %u
AuthorizedKeysCommandUser root

    This tells sshd to execute sss_ssh_authorizedkeys <username> as root to fetch the authorized keys for the user (22.6. Configuring SSSD to Provide a Cache for the OpenSSH Services | Red Hat Product Documentation) (Linux SSH Key + Password Auth for Users Stored in Active Directory) The sss_ssh_authorizedkeys tool will query SSSD’s cache for the ldap_user_ssh_public_key attribute we configured.

    (In the example above, we apply this globally. You could also wrap these lines in a Match Group or Match User block if you only want to enable AD key retrieval for certain users/groups (Linux SSH Key + Password Auth for Users Stored in Active Directory) but usually global is fine if your local users still have their normal authorized_keys files.)

  • Ensure PasswordAuthentication is set to “yes” (or “no” depending on your policy) and PubkeyAuthentication yes (they are “yes” by default on RHEL, meaning SSH will allow either method). If you want to enforce 2FA (key and password), you can use AuthenticationMethods "publickey,password" as shown in the example snippet (Linux SSH Key + Password Auth for Users Stored in Active Directory) but that’s optional and beyond the scope here.

Reload the SSH daemon:

systemctl reload sshd

At this point, SSSD is fully configured: it will handle AD authentication and identity, support offline logins, fetch group memberships quickly, and provide SSH public keys from AD. We can now integrate Samba.

3. Setting Up Samba with SSSD for File Sharing

In this step, we configure the Samba file server to use the AD integration via SSSD, so that Windows and macOS clients can seamlessly access SMB shares with AD credentials (and SSO via Kerberos). We will use Samba’s “security = ADS” mode (Active Directory domain member) and the idmap_sss backend to fetch UID/GID mappings from SSSD.

Install Samba Packages: If you haven’t already, ensure the Samba server packages are installed. We installed some in step 1, but specifically we need the Samba daemon and the SSSD Winbind integration module:

dnf install samba samba-common samba-winbind samba-winbind-clients sssd-winbind-idmap

Note: The realm join ... --membership-software=samba we ran earlier already created the machine account in AD and stored the machine credentials. If you joined the domain without that option, you should join Samba manually now. To do so, ensure you have a Kerberos ticket or admin credentials, then run: net ads join -U Administrator (for a fresh join) or net ads join -k (using your existing keytab credentials). This will register the machine in AD for Samba and create a /etc/samba/secrets.tdb (and add SPNs like cifs/servername to the AD computer account). If the realm join was done with --membership-software=samba, this step is not needed as the machine account is ready for Samba.

Configure smb.conf: Edit /etc/samba/smb.conf. We’ll set global options and define a share. Key global settings:

[global]
   workgroup = EXAMPLE        # NetBIOS domain name (uppercase, usually the part before .COM)
   realm = EXAMPLE.COM        # Kerberos realm (uppercase domain FQDN)
   security = ads
   kerberos method = secrets and keytab
   # Use SSSD for id mapping:
   idmap config * : backend = tdb
   idmap config * : range = 10000-19999
   idmap config EXAMPLE : backend = sss
   idmap config EXAMPLE : range = 20000-2147483647
   template shell = /bin/bash
   template homedir = /home/%U
   machine password timeout = 0
   # (Optional) Disable printing service if not needed:
   load printers = no
   printing = bsd
   printcap name = /dev/null
   disable spoolss = yes

Explanation of these settings:

Add Share Definitions: Next, define your file shares. For example, suppose we need a share for a group of video editors:

[Projects]
   comment = Video Projects Share
   path = /shares/projects    # directory on the filesystem
   read only = no
   valid users = @editors     # Only allow members of AD group "editors"
   create mask = 0660
   directory mask = 0770
  • valid users = @editors restricts access to members of the AD group “editors”. Note: Because SSSD is providing NSS, Samba can recognize Unix group names. We’ve set use_fully_qualified_names = False, so the AD group EXAMPLE\editors is known on the system simply as “editors”. Samba will check membership via Unix group lookup. (If you left FQDN on, you could specify EXAMPLE\editors or [email protected] as the group.) You can also list multiple groups/users or use valid users = EXAMPLE\someuser for individual accounts as needed (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim)
  • create mask and directory mask ensure that new files are group-readable/writable (660) and new directories are group-accessible (770) (active directory - Samba file server + AD + SSSD without Winbind - Unix & Linux Stack Exchange) This is important for collaborative environments: it ensures files created by one user can be modified by other group members (since the group will have rw permission). The example above gives no permissions to “other”. Adjust masks as needed (e.g., 0770 for create mask if you want to prevent group members from deleting each other’s files might not be effective without sticky bit; for simplicity 660/770 is fine).
  • You might also set force create mode = 0660 and force directory mode = 0770 to ensure those permission bits are always set regardless of the client’s requested bits.
  • If you want newly created files to always have a specific group (to maintain group ownership even if user’s primary group is different), consider setting the parent directory’s setgid bit (chmod g+s /shares/projects). On XFS/ext4, this will cause files to inherit the directory’s group. You could also use Samba’s force group = editors option on the share to force all files to be owned by the “editors” group.

Repeat the share definition for each share you need, adjusting path, permissions, and allowed users/groups accordingly.

Filesystem Permissions: On the Linux filesystem itself, you must ensure the directories have correct ownership and permissions to match the Samba settings:

  • Create the directory (if not already existing): mkdir -p /shares/projects.
  • Set ownership to an appropriate user and the AD group. For example, you might set the owner to a lead user or to root, and the group to “editors”: chown root:editors /shares/projects (assuming “editors” is resolved via SSSD to the AD group’s GID).
  • Set mode 770: chmod 770 /shares/projects (group rwx, others none) (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim)
  • If using setgid for group inheritance: chmod g+s /shares/projects.
  • SELinux context: On RHEL, make sure the directory is labeled for Samba. If SELinux is enforcing, run: chcon -t samba_share_t /shares/projects (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim) For a permanent solution, use semanage fcontext -a -t samba_share_t "/shares/projects(/.*)?" and then restorecon -R /shares/projects. This gives Samba the rights to read/write those directories. (If you skip this, you might get “Permission denied” due to SELinux even if file perms are open.)

Start Samba Services: Enable and start the Samba daemons:

systemctl enable --now smb
systemctl enable --now winbind

We start winbind as well because even though we’re using SSSD for identity, Samba may still require the winbind daemon for certain domain queries and for the idmap plugin to function (the idmap_sss module works through winbind’s interface to SSSD) Starting winbind ensures Samba can fetch info from SSSD properly.

(You do not need to configure winbind’s own /etc/nsswitch.conf or PAM integration – we are not using winbind for system logons, just as a service for Samba. SSSD remains the source of truth for identities.)

Open Firewall: If a firewall is running, allow SMB service:

firewall-cmd --add-service=samba --permanent
firewall-cmd --reload

This opens the standard SMB ports (TCP 445, and 139 if needed).

At this point, your Samba server is joined to AD and configured to use SSSD for identity mapping. It will accept Kerberos tickets from clients and rely on SSSD to map those to Unix users. Next, we ensure that single sign-on works properly.

4. Ensuring Kerberos-based Single Sign-On (SSO)

One major benefit of this integration is that AD users should be able to access Samba shares without re-entering credentials if they’ve already authenticated to AD (SSO), and also not be prompted for passwords repeatedly. Here’s how to ensure that:

  • Kerberos Keytab and SPNs: Verify that the machine has the proper service principal names (SPNs) in AD and keys in the keytab. The realm join or net ads join should have created these. Run: klist -k /etc/krb5.keytab | grep -i cifs. You should see entries for cifs/<hostname> (and possibly cifs/<hostname>.<domain>). Samba will use these to accept Kerberos tickets for the CIFS service. If they are missing, you can add them via: net ads keytab add cifs -U Administrator (which fetches the CIFS SPN key into the keytab). Also ensure host/<hostname> entries exist (they typically do).

  • DNS Configuration: Clients will request tickets for cifs/<SERVERNAME>.<DOMAIN>. Make sure the hostname clients use to connect matches the AD computer name. For example, if your server’s AD name is FS01.EXAMPLE.COM, clients should connect to \\fs01.example.com\share. If you use an alias or CNAME, you’ll need to add an SPN for that alias in AD (setspn command) and have the key in the keytab (or map the alias to the computer account in AD). Otherwise, Kerberos authentication may fail and clients will fall back to NTLM. To keep it simple, use the server’s actual AD name.

  • Client Setup (Windows): If the Windows client is joined to the same AD domain (or a trusted domain) and the user is logged in with their AD credentials, accessing the Samba share should use the existing Kerberos ticket. For example, if a user is logged into AD and goes to \\fs01.example.com\Projects, Windows will automatically try Kerberos. As long as the server is properly joined (which we did) and SPNs are correct, the user should get in without a password prompt. (They might see a brief “Accessing…” but no creds dialog.)

  • Client Setup (macOS): For Mac clients, if they are bound to AD (using Apple’s AD integration) or if the user has obtained a Kerberos TGT (for instance, using the Ticket Viewer or kinit), the Mac SMB client will also attempt Kerberos SSO. On macOS, you can integrate with AD so that the user’s login is an AD login (then they automatically have a Kerberos ticket). If that’s not the case, users can use the Kerberos SSO app or kinit in Terminal to get a ticket for their AD account before connecting. If a Mac is not AD-bound and no Kerberos ticket is present, it will prompt for username/password when connecting to the share. They should use their AD credentials (which will work over NTLMSSP if not Kerberos).

  • SMB Signing/Encryption: By default, in a domain environment, SMB signing is typically required. Samba with security=ads enables signing by default (server signing = default which means required if client requires it, otherwise optional). Kerberos also provides channel integrity. You usually do not need to change these defaults. (Just ensure you haven’t set server signing = disabled, as that could cause Windows 2012R2+ clients (which expect signing) to refuse to connect.)

  • Testing Kerberos SSO: A simple test from the Linux server itself is to use the Samba client with Kerberos:

    kinit [email protected]    # obtain Kerberos ticket for a domain user
smbclient -L fs01.example.com -k   # list shares using Kerberos auth
smbclient //fs01.example.com/Projects -k -c 'displaycar'  # any command to test, e.g., list files

    The -k flag tells smbclient to use the Kerberos ticket. If configured correctly, you should see the share listing without being prompted for a password (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim) You can also do this from any Linux that’s joined to the domain or has Kerberos config.

    On a Windows client, simply navigate to the UNC path or map the drive. If it immediately shows the share contents, SSO is working. If you get a prompt, it indicates Kerberos didn’t work and it’s falling back to NTLM (or the connection failed). Common causes for a prompt:

    • SPN issues (client can’t find a Kerberos service ticket for the server because SPN is missing or mismatched). Use the Windows klist command or Event Viewer on the client to diagnose Kerberos errors.
    • Time skew (if the server and client times differ by more than 5 minutes, Kerberos will fail). Ensure NTP is working on all systems.
    • DNS/resolution issues (client might be using a hostname that doesn’t match the principal in the ticket).
    • macOS note: In Finder, if not using Kerberos, when prompted for credentials to fs01.example.com, the user should enter “EXAMPLE\username” and their password to authenticate via NTLM. But again, with a proper AD Mobile account or a kinit, it should not prompt.

  • Troubleshooting Authentication:

    • Check Samba logs (e.g., /var/log/samba/log.smbd). When a Kerberos auth occurs, Samba logs will show entries about GSSAPI authentication. If it falls back to NTLM, you’ll see NTLMSSP mentions.
    • You can increase Samba’s log level temporarily for debugging (log level = 3 in smb.conf) to see more details.
    • On the client side, Windows klist tickets will show if it has a ticket for cifs/yourserver. If not, that’s why it prompted.
    • If Kerberos fails, Windows might automatically try NTLM. If your AD user is not allowed (say, not in valid users group), it will then deny access even if the password was correct.
    • Use testparm on the Samba server to check smb.conf for typos or issues.

In summary, with the above configuration, Kerberos SSO should “just work” for domain-authenticated clients. Users who log into their machine with AD credentials will get access to the Samba shares without being asked for a password again, satisfying the Single Sign-On requirement.

5. Fine-Tuning Group Membership Refresh Timing

We have already adjusted SSSD’s cache timeouts to 2 minutes (120s) in the config. This is the primary mechanism to ensure group membership changes propagate quickly. Let’s elaborate and ensure this meets the requirement:

  • How SSSD Caching Works: When a user or group is looked up (via login or getent), SSSD caches that info. We set entry_cache_timeout = 120, meaning any cached object older than 120 seconds will be considered expired and SSSD will fetch an updated copy from AD on next request (13.2.16. Domain Options: Enabling Offline Authentication | Red Hat Product Documentation) By lowering this from the default 5400s (90 min) (13.2.16. Domain Options: Enabling Offline Authentication | Red Hat Product Documentation) we drastically shorten the window in which a group change in AD could go unnoticed on the server. In practice, if you add a user to an AD group, within 2 minutes SSSD will expire the old cache and pick up the new membership. (If you need an even faster reflection, you could reduce it further to 60s, but that will increase load on AD slightly. 2 minutes is usually a good compromise.)

  • SSSD Background Refresh: SSSD has a feature to refresh expired entries in the background. We did not explicitly set it, but by default when an entry is expired, the next request triggers an update. Optionally, you can configure refresh_expired_interval and entry_cache_nowait_percentage to optimize this. For example, you could set entry_cache_nowait_percentage = 50 which means after 50% of the cache timeout has passed (i.e., 60s out of 120s), SSSD will return cached data to the caller but initiate an asynchronous refresh in the background (SSSD Manual pages) This can reduce latency for the first lookup after expiration at the cost of extra background queries. In most cases, simply having a short timeout is sufficient.

  • Testing Group Changes: It’s a good idea to test the propagation:

    1. Pick a user and a group they currently are not a member of. On the RHEL server, run id username to see their groups.
    2. In AD, add that user to the group (or remove, to test removal).
    3. Wait ~2 minutes, then run id username again on the server. You should see the new group in the output (or gone, if removed). If it doesn’t show up, check SSSD logs because by 2 minutes it should have expired the old info and queried AD again.
    4. Also test access to a share that is permitted via that group: e.g., if that group was given access in valid users, try to access the share after the change. You might need the user to reconnect or re-login for a new SMB session, because Samba will evaluate group membership at session start. If the user already had a session open before the change, Samba won’t know mid-session – they may need to disconnect/reconnect to see new permissions.

  • Avoiding Excessive Load: With a 2-minute cache, every 2 minutes per user (or group) something will requery AD when accessed. In a domain with, say, hundreds of active users on the server (or many processes calling getent frequently), this could mean a steady stream of LDAP lookups. Given we have two domain controllers and presumably moderate user count, this should be fine. But if needed, you can tune upward to 3–5 minutes to reduce load. The question’s requirement was 1–2 minutes desired, 5 min max, so 120s–300s is the range. 5 minutes (300s) might be a safer default if your AD is busy, but it means worst-case a user waits 5 minutes to gain access after a group change. 2 minutes is more responsive.

    You can also stagger different cache types: for example, user entries at 300s and group entries at 120s. But since a user’s group membership can be part of the user entry, keeping them the same simplifies it.

  • SSSD Monitor and Logs: If you suspect caching is not updating, look at /var/log/sssd/sssd_[domain].log. It will show cache hits and misses and queries. You can also use sss_cache utility if you ever need to manually invalidate caches. For instance, sss_cache -E will wipe the entire cache (forcing fresh lookups for all entries), and sss_cache -u username invalidates one user. This is useful for on-demand flush (for example, an admin can run it right after making a critical group change in AD to force immediate pickup, rather than waiting 2 minutes).

  • GP update vs cache: Remember that even though SSSD picks up group membership quickly, if a user is already logged into a Linux session, their kernel group memberships are fixed at login (the groups listed in id at login time). For new operations like file access via Samba, it will query groups fresh per session. For SSH, if using key or re-auth, it might re-evaluate groups on each login. So, the update will be effective for new logins or new SMB sessions. It won’t magically propagate into an already running process’s credential set. Typically, that’s fine (the user might just re-login to gain new permissions).

In summary, with our SSSD tuning, group membership changes propagate in near real-time (within a couple of minutes) to the Linux system. This meets the requirement of 1–2 minutes update time. It does so without manual intervention, while avoiding the long default cache that could delay updates for hours.

6. Permissions Management and Considerations

In this environment, we use standard Linux permissions (rwx) with group control to manage access, instead of complex ACLs. Here are important considerations:

  • Group-Based Access Control: Organize your AD users into groups that correspond to access roles for the file shares. We saw an example with an “editors” group for the Projects share. Make sure the membership is correct in AD. Samba/SSSD will rely on these group memberships to allow or deny access (via valid users = @group or simply via file system permissions).

  • File System Permissions (POSIX): On the server’s file system (ext4, XFS, ZFS), the directories and files will have Unix owner and group, and mode bits (e.g., 770). SSSD ensures that when an AD user accesses the system, they have a corresponding Linux UID and their groups have GIDs. When that user creates a file, it will be owned by their UID and their primary GID (which by default is one of their AD groups, often the “Domain Users” or something unless overridden). To make collaboration smoother, it’s common to set the group ownership of the directory to the intended group and use the setgid bit, so that new files inherit that group. Alternatively, use Samba’s force group parameter on the share. For example, if /shares/projects is group-owned by “editors” and has the setgid bit, any file created there will have group “editors”. With create mask 660, all editors can then read/write each other’s files.

  • UID/GID Mapping Consistency: Since we are not using local Linux users, the UID and GID for each AD user/group are generated by SSSD or taken from AD. Consistency is important because if you have multiple Linux servers accessing the same storage (say via NFS or a clustered filesystem), you want the IDs to match. SSSD with the same configuration on all servers will produce the same IDs for a given AD user, as it’s either using the same algorithm or the same AD-provided attribute. For example, if user Alice has SID ending in -1111, SSSD might map that to UID 100201111 (depending on domain SID and algorithm). All servers in the domain will compute the same UID for Alice (active directory - Samba file server + AD + SSSD without Winbind - Unix & Linux Stack Exchange) If using AD’s uidNumber, then it’s obviously the same everywhere. This means file ownership will be recognized correctly across servers – a file created by Alice on Server1 will show as owned by Alice on Server2 (assuming both use SSSD with the domain). We disabled automatic ID mapping only if POSIX IDs are present to use the AD values directly; otherwise, SSSD’s generated IDs act like a “virtual UID/GID” that is consistent across machines (Chapter 1. Connecting RHEL systems directly to AD using SSSD | Red Hat Product Documentation) (Chapter 1. Connecting RHEL systems directly to AD using SSSD | Red Hat Product Documentation) Windows and Mac clients don’t directly see these UIDs, but the Samba server does and uses them for permission checks.

  • Cross-Platform UID/GID: Windows uses SIDs for identity. Samba will translate the Windows user’s SID to a UID via SSSD, and then enforce file permissions. Mac (as an SMB client) behaves like Windows in that it doesn’t see the Unix UID – it also relies on the server to enforce rights. So as long as the server’s mapping is consistent, everything works. The actual numeric UID/GID doesn’t matter to Windows/Mac, just that the server knows what it is. For troubleshooting, you can use wbinfo -n user (to get SID) and wbinfo -S <SID> to see the ID mapping, or simply id user to check the UID/GIDs resolved.

  • Default Permissions Model: We are not using Windows-style ACLs on the shares. By default, Samba will map the Windows security model to the underlying POSIX permissions. We set nt acl support = no in the example (implicitly by relying solely on POSIX masks), which tells Samba not to present or allow Windows ACL changes on these shares, and to rely purely on the UNIX mode bits (Chapter 1. No-Frills Samba Servers) This simplifies things: Windows “Security” tab will either not show or show a basic view, and administrators should manage permissions via Unix chmod/chgrp (or via command line, or an automation tool). This meets our current requirement and avoids the complexity of syncing NTFS-style ACLs.

  • Future-proofing for ACLs: If in the future you need finer access control (e.g., allow certain users read-only, others full control, or multiple group access on the same directory), you might consider using POSIX ACLs (setfacl/getfacl on ext4/XFS) or enabling Windows ACLs in Samba. All the file systems mentioned (ext4, XFS, ZFS) support ACLs:

    • ext4/XFS support POSIX ACLs if mounted with the acl option (which is usually default).
    • ZFS on Linux can emulate NFSv4/Windows ACLs. Samba can store Windows ACLs in extended attributes (vfs objects = acl_xattr) and present full Windows security control to clients. Enabling that would let you manage permissions from Windows’ GUI as well, storing results in filesystem ACL entries. This is more complex to manage but is possible. For now, to keep it simple, we stick with group-based chmod 770 style permissions. Should you need to transition, you would remove or set nt acl support = yes (the default) and possibly use inherit acls = yes and map acl inherit = yes in smb.conf along with enabling ACLs on the filesystem. That’s beyond our current scope, but it’s achievable without rejoining the domain (just config and possibly adding RFC2307 attributes or using the existing SIDs as needed).

  • Name Mapping Consistency: Ensure that the group names you use in configurations (like “editors”) match exactly the SamAccountName or CN of the group in AD. SSSD will typically expose AD groups by their SamAccountName. If your group names have spaces or special chars, you might need to quote them in smb.conf (e.g., valid users = @"Domain Users"). It’s often easier to use alias groups for Linux purposes if needed (e.g., an “editors” group separate from perhaps a longer name used in AD).

  • SUID/SGID and Special Bits: Standard chmod permissions will cover most needs (770 means group can read/write, others none). If you have directories where multiple groups need access, you might implement a structure like subfolders owned by different groups. Without ACLs, a file or directory can only have one owning group. This is where careful planning of group strategy is needed (or move to ACL if many overlaps).

  • Integrity of Permissions: With this setup, permission enforcement happens at two levels:

    1. Samba will check valid users/read list/write list settings – we used valid users = @group as a gate.
    2. Then the Linux kernel enforces the filesystem permissions based on the user’s UID/GID (which Samba switched to when handling the connection via smbd process). Both need to allow access. If a user is in the right group but the file’s mode doesn’t grant group permission, they can’t access. Conversely, even if the file’s mode is open, if Samba’s valid users denies them, they can’t access. We set them consistently (only group members can connect, and group perms allow it).

  • SELinux: As mentioned, keep SELinux in mind. The default Samba policy expects share paths labeled with samba_share_t. Use chcon/semanage as shown. If you ever get stuck with permission issues, run ausearch -m avc -c smbd to see if SELinux blocked something. You can also set setsebool -P samba_enable_home_dirs 1 if you are sharing home directories, or other booleans depending on use-case.

  • Ownership and Identity Mapping Check: Use commands like ls -l on the share directories to see owner/group names. Thanks to SSSD’s NSS, you should actually see the AD usernames and group names in ls -l output, not numeric IDs. For example, a file might show owner alice and group editors if those correspond to AD user Alice and AD group editors. If you see numeric IDs in ls -l, it means NSS (SSSD) isn’t mapping those to names (which would indicate a misconfig). In our setup, it should resolve because SSSD is in nsswitch.conf for passwd and group.

In short, use groups to manage access, keep the file modes consistent (770 for dirs, 660 for files, etc.), and avoid granting broad “other” permissions. This will ensure that only the intended users (via their group membership) can access the resources. By not using ACLs now, we keep management straightforward (just add/remove users to groups in AD to grant/revoke access). If later needed, we can extend to ACLs without re-architecting the whole system – the pieces (SSSD, Samba, AD) already allow for it.

7. Testing and Troubleshooting

Finally, it’s crucial to test the entire setup end-to-end and be prepared to troubleshoot common issues:

Test SSH Login (Password): Pick an AD user account and attempt to SSH into the RHEL server:

ssh [email protected]

(use the actual domain if not example.com). The login should accept the user’s AD password. If it fails, check:

  • Did you get a password prompt? If not, perhaps your PAM or sssd config is wrong. If you did but it rejects the password, check /var/log/secure (or journal) for pam_sss errors. Ensure the user is allowed to login (if GPOs are in effect, or if realm permit was used to restrict logins, that could block it).
  • Try id username on the server to see if the system recognizes the user. If id shows the user’s UID and groups, SSSD is working for identity. If not, SSSD might not be hooked into NSS properly (check nsswitch.conf has passwd: files sss).
  • If id works but ssh doesn’t, possibly an issue with PAM or with authorized services. Ensure /etc/pam.d/sshd includes the auth and account lines for pam_sss (authselect should have set this up).
  • Also check time sync and DNS – if those are off, Kerberos (used by SSSD for auth) might fail. SSSD can fall back to LDAP simple bind if Kerberos fails, but better to fix Kerberos (see /var/log/sssd/sssd_example.com.log for clues).

Test SSH Login (Public Key): Now test that SSH key retrieval from AD works:

  • Make sure you’ve stored your test user’s public key in the altSecurityIdentities attribute as described in section 2.
  • From a client (or even from the server itself, simulating another host), attempt to SSH using key auth. For example, if you have the private key on your local machine, use: ssh -i /path/to/privatekey [email protected]. It should log you in without prompting for a password, using the key.
  • If it falls back to asking for password, then the key-based auth failed. Check a few things:
    • On the RHEL server, run /usr/bin/sss_ssh_authorizedkeys username as root. It should output the public key(s) for that user in authorized_keys format. If it outputs nothing or an error, SSSD either didn’t retrieve the key or the user isn’t found. Ensure ldap_user_ssh_public_key is set correctly and restart sssd, and that the user has that attribute in AD.
    • Check /var/log/secure on the server for sshd messages. You might see errors like “AuthorizedKeysCommand returned no keys” or SSSD errors. SSSD’s SSH responder logs to /var/log/sssd/ssh.log (and domain log).
    • Remember that altSecurityIdentities is a multi-valued attribute; SSSD will treat each value as a key. Make sure the key format is correct (no extra spaces or line breaks).
    • Once working, sshd will accept the key and then PAM will still prompt for a password by default (because by default it requires any auth, and if key succeeded, it won't ask password). If you set AuthenticationMethods "publickey,password" as in the earlier example, it would require both (which is more secure but requires user do key auth and password). If you only need key OR password, don’t set that line (or use the default which is any method is fine).

Test Samba Access (Windows): On a Windows client in the domain:

  • Open Run dialog (Win+R) and enter \\fs01.example.com\Projects (use your server’s name and share).
  • It should open the share. If prompted for credentials, something is off with SSO (see the Kerberos troubleshooting above). Try entering your AD username/password – it should accept and show files if everything else is right, but ideally we want no prompt.
  • Create a new folder or file on the share. Then on the RHEL server, check ls -l in /shares/projects to see the ownership. It should show the username and the group (likely “editors”) on the file. This confirms that ID mapping via SSSD is working and that file creation obeys the group settings. Also verify the permissions are -rw-rw---- (660) for the new file due to Samba’s mask.
  • Delete or edit a file to ensure you have proper access.
  • If you cannot see the share at all (e.g., “network path not found”), check DNS (can the Windows client resolve the hostname?), and ensure the Samba service is running and firewall open. Try ping fs01 or ping fs01.example.com from Windows. If name resolution fails, add an entry in DNS or use the FQDN.
  • If you get “Access Denied” on the share, check that the user is indeed in the “editors” group in AD and that group was allowed. Also check Samba logs; it might show which user it thought you are and why it denied.
  • If file operations work but are slow, consider enabling SMB multi-channel if you have multiple NICs and clients that support it (beyond scope, but Samba server multi channel support = yes is available in newer versions). Also ensure using SMB3 on clients (Windows 2012R2+ will use SMB3 by default).

Test Samba Access (macOS): On a Mac, in Finder, use Go > Connect to Server (⌘+K) and enter smb://fs01.example.com/Projects.

  • If the Mac is not domain-joined, it will prompt for credentials. Enter the AD user and password. If it mounts the share, good – that means basic auth works. If you want true SSO, consider binding the Mac to AD or obtaining a Kerberos ticket. If the Mac is bound to AD (e.g., the user logs into the Mac with an AD account), it should attempt Kerberos and might not prompt.
  • Once mounted, test creating files, etc., similarly.
  • macOS uses some special SMB client behaviors: it might create temporary files (like ._DS_Store). Our config with masks should handle those. If you notice odd issues with macOS (resource forks, etc.), Samba has a module “vfs_fruit” designed for macOS compatibility (especially for Time Machine or preserving Finder metadata). For pure file sharing, it’s optional. If needed, one can enable: 
    vfs objects = fruit streams_xattr
fruit:metadata = netatalk
fruit:resource = xattr
    on the share definition. This is more for preserving HFS+ metadata, not strictly needed for functionality.

Offline Authentication Test: To test offline login, you can simulate AD being unreachable. Caution: Do this in a controlled way (perhaps temporarily stop SSSD’s connection or network). An easy test:

  • Disconnect the server from the network (if possible) or turn off the DNS/AD temporarily (not always feasible in production).
  • Try to SSH into the server as an AD user who has logged in before. It should allow you (using cached credentials) even though it cannot contact AD at that moment (13.2.16. Domain Options: Enabling Offline Authentication | Red Hat Product Documentation) If it logs you in, offline caching works. If it fails, ensure cache_credentials = true is set and that the user had a successful login in the past (SSSD only caches after a successful online login).
  • Note that for offline logins, the cache has an expiry. By default, SSSD does not expire cached creds (unless you set offline_credentials_expiration). We left it as default (which is effectively infinite or “until account_cache_expiration”). You can set offline_credentials_expiration = X (days) in the [pam] section to force cache to purge after X days without contact (13.2.16. Domain Options: Enabling Offline Authentication | Red Hat Product Documentation) If you do that (say 30 days), then beyond 30 days offline, the login would fail until AD is reachable again to revalidate. In our config, not setting it means users can authenticate offline indefinitely using the last known password. You might want to configure a limit for security, depending on your policies.

Performance and Load Testing: Since this server is for video editing workloads, test with realistic file operations:

  • Copy large files to/from the share from a client. Monitor throughput. With SMB3 on a gigabit network, you should see close to 100 MB/s on large sequential transfers if everything is optimal (or much more on 10GbE). If performance is lower than expected:
    • Check CPU usage on the server (top or perf stat). SMB is single-threaded per connection, so one CPU core will handle one file transfer. A slow CPU can bottleneck a single stream. If clients do parallel transfers, Samba will use multiple cores (one per client or per file transfer).
    • If CPU is a bottleneck, ensure you’re not using SMB encryption (which can tax CPU) unless needed. SMB signing also has some overhead but usually not huge.
    • You can experiment with Samba parameters: e.g., enabling asynchronous I/O explicitly (aio read size = 1, aio write size = 1 to force async for all reads/writes) if not already on. This can help on Linux if the underlying FS and storage benefit from async behavior.
    • Another tuning: socket buffers. The default might be fine, but as noted in some experiences, increasing SO_RCVBUF/SO_SNDBUF (via socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536) can help saturate high bandwidth links ( [Samba] Strategy for tuning so_sndbuf and so_rcvbuf ) However, modern Samba defaults already disable Nagle (TCP_NODELAY is effectively on by default) and handle buffer auto-tuning well. So manual socket options are usually not needed (Turning off Nagles Algorithm - Google Groups) Use caution if setting them; improper values can hurt performance.
    • If multiple 4K video streams are being edited from the share concurrently, consider network bandwidth and disk I/O. XFS or ZFS on good storage should handle sequential reads well. ZFS may need tuning (recordsize, cache) for large files, but that’s outside our scope.
    • Monitor network (with iftop or similar) and disk throughput (iostat) during the tests to identify bottlenecks.

Logging and Monitoring:

  • SSSD logs: /var/log/sssd/ will have a log for each domain (sssd_example.com.log) and others for ssh/pam. Increase debug level in sssd.conf (debug_level = 9 in the domain section) if you need verbose logging for troubleshooting authentication or cache issues. Remember to turn it down after, as it can be very verbose.
  • Samba logs: /var/log/samba/ (or the journal). By default, Samba’s log level is low. You can increase log level in smb.conf for more detail on connection issues or performance.
  • Check system logs (/var/log/messages or journalctl -xe) for any PAM errors, SSSD errors, or Samba startup issues.

Common Issues Recap and Resolutions:

  • Cannot enumerate or see users/groups on Linux: Ensure getent passwd <user> works. If not, check SSSD config and that sssd is running. Use realm list to see if the domain is listed. If sssd is running but not responding, sss_cache -E and systemctl restart sssd.
  • Login failures: Look at sssd_example.com.log for hints (e.g., “Authentication failed for user …”). Could be wrong password (try kinit user to verify credentials against AD). Could be clock skew (check chronyc tracking). Could be user not allowed by policy (try setting ad_gpo_access_control = permissive to test if that fixes it, meaning GPO was blocking).
  • File permission issues: If an AD user can log in via SSH but can’t create files in a share they should, check the Unix perms of the directory (ls -ld /shares/projects). If the GID isn’t the expected group or the mode is wrong, fix that (chown/chmod as needed). If the group is correct but user is not in that group (per Linux), check id user to see if the group appears. If not, perhaps the group membership hasn’t refreshed – try sss_cache -E or restart sssd to force update (and check why it wasn’t up to date; maybe they never relogged and cache was still holding an old entry).
  • Case sensitivity: AD logins are usually case-insensitive. SSSD treats names case-insensitively by default. But Linux file systems are case-sensitive. Keep in mind if you have mixed-case usernames or group names; typically stick to lower-case for convenience.
  • Group not appearing on Linux: If an AD group doesn’t show up via getent group GroupName, but users are resolving, it might be because the group has no gidNumber and you set ldap_id_mapping=false. In that case, SSSD might ignore groups without a GID. Solution: either assign a gidNumber in AD for that group (if using POSIX attrs) or use ldap_id_mapping=true (algorithmic) so it will generate one. We used mapping by default, so this shouldn’t happen – SSSD will generate a GID even if none in AD.

By following this guide and verifying each component (SSSD for logins, Kerberos for SSO, Samba for shares), you should achieve a seamless integration: Users authenticate with their AD accounts on the Linux server, their group memberships control access to Samba shares, and they get single sign-on via Kerberos for those shares (both Windows and Mac clients using SMB3). Offline authentication is supported through SSSD’s cache, and group changes in AD reflect on the server within minutes, meeting the requirements.

Throughout the setup, we referenced official documentation and best practices for each step – for further details, consult Red Hat’s documentation on direct AD integration (Chapter 1. Connecting RHEL systems directly to AD using SSSD | Red Hat Product Documentation) (13.2.16. Domain Options: Enabling Offline Authentication | Red Hat Product Documentation) and Samba’s wiki for AD integration. Good luck, and enjoy the integrated environment!

References:

Addendum (18-Feb-2025) Winbind vs SSSD for AD Integration (Analysis of @hortimech’s Comment)

Overview of @hortimech’s Position

In his latest comment, @hortimech argues that when a Linux system is joined to an Active Directory (AD) domain and acting as a Samba file server, using Winbind (the Samba-provided AD client) is preferable to using SSSD. He suggests that running SSSD alongside Winbind is unnecessary and duplicative. His key points can be summarized as follows:

  • Winbind is required for Samba: If the server runs the Samba smbd service (to share files in an AD domain), then Winbind must be running. In this scenario, SSSD becomes redundant because Winbind can fulfill the same identity/authentication roles.
  • Overlap in functionality: Winbind and SSSD perform similar functions (providing NSS and PAM integration for AD logins). SSSD was developed later (allegedly by the same engineer who wrote Winbind) and is heavily based on Winbind’s concepts. Thus, there’s no inherent advantage to running both – AD is the real source of identity data, and using two daemons to retrieve that data is duplicative.
  • Questioning the “sss” idmap backend: Samba can be configured with an idmap_sss plugin (provided by the sssd-winbind-idmap package on Red Hat systems) so that Samba consults SSSD for SID-to-UID/GID mapping. @hortimech notes this plugin is not part of upstream Samba (it’s a Red Hat-specific addition) and claims “better” built-in idmap backends exist. He argues that if you’re running Samba as a domain member, you’re effectively running Winbind anyway – so using the “sss” plugin doesn’t avoid a “full winbind” daemon.
  • Modern features and performance: He contends that Winbind already offers almost everything SSSD does. SSSD’s touted features (e.g. robust offline caching, fast group refresh, detailed logging) are either also present in Winbind or not critical for most users. In his view, any features SSSD alone provides beyond Winbind are required by only a very small subset of use-cases.
  • “Legacy vs modern”: The comment pushes back on the idea that Winbind is “legacy” and SSSD “modern.” Since SSSD’s design was influenced by Winbind (and shares some code concepts), he implies that if Winbind is considered legacy, then SSSD is as well – they are two sides of the same coin. The conclusion is that running only Winbind is the simplest and most effective approach when Samba file sharing is involved, whereas SSSD is fine for pure client authentication needs (no Samba shares).

To provide a fact-based analysis, let’s examine each of these claims in detail, using current documentation and source information for both Winbind and SSSD. We will also consider performance, security, and compatibility factors that support or refute @hortimech’s stance, and discuss any other considerations for choosing between Winbind and SSSD in this context (RHEL 9.5 with AD and Samba).

Winbind Requirement for Samba Domain Members

Claim: “If you are running the smbd daemon on a domain-joined machine, then you must run Winbind.” In other words, a Linux server joined to AD and serving SMB/CIFS shares cannot rely on SSSD alone – Samba effectively requires Winbind.

Analysis: This claim is accurate according to the Samba project’s own requirements and Red Hat’s documentation for enterprise Linux:

  • Starting with Samba 4.8 (and in all later versions), Samba made it mandatory for domain-member servers to have the Winbind daemon running when using AD integration (security = ads or security = domain). The older fallback mode where smbd could contact domain controllers directly for user info was removed ( Samba 4.8, Winbind and SSSD - sssd-users - Fedora mailing-lists ). Samba’s release notes explicitly state: “Setups with ‘security = ads’ require a running winbindd now. The fallback that smbd directly contacts domain controllers is gone.” ( Samba 4.8, Winbind and SSSD - sssd-users - Fedora mailing-lists ). In practice, if Winbind isn’t running, Samba will log errors and fail to authenticate AD users. For example, attempting to run Samba without Winbind in a domain environment triggers errors like “winbindd not running - but required as domain member: NT_STATUS_NO_LOGON_SERVERS” (SAMBA — Re: Samba 4 without winbind). This confirms that Winbind is a technical requirement for Samba in an AD domain member context.
  • Red Hat’s official support policy aligns with this. In RHEL 7.6 (with Samba 4.8) and onwards, Red Hat updated their docs to reflect that “installations with security = ads or domain now require that the winbindd service is running” ( Samba 4.8, Winbind and SSSD - sssd-users - Fedora mailing-lists ). Furthermore, Red Hat’s System Administration Guide explicitly states: “Red Hat only supports running Samba as a server with the winbindd service to provide domain users and groups to the local system.” SSSD is not supported as the sole domain client for a Samba server due to certain limitations ( Samba 4.8, Winbind and SSSD - sssd-users - Fedora mailing-lists ).

The limitations cited are important: Red Hat notes “missing Windows ACL support and NTLM fallback” as reasons SSSD is not supported for Samba servers ( Samba 4.8, Winbind and SSSD - sssd-users - Fedora mailing-lists ). In other words, a Samba file server that tried to use only SSSD would have trouble correctly handling Windows Access Control Lists on files and would not support NTLM authentication. This is because:

  • NTLM authentication (the challenge/response mechanism used by older Windows clients or when Kerberos isn’t available) is not implemented in SSSD’s AD provider. SSSD supports Kerberos and LDAP for AD, but does not support the NTLM protocol for authentication (SSSD vs Winbind) (4.2. Using SMB shares with SSSD and Winbind | Red Hat Product Documentation). Winbind does support NTLM (via the Samba ntlm_auth facility and communication with the domain controller). So without Winbind, a Samba server couldn’t authenticate certain clients or fallback scenarios.
  • Windows ACLs and SID resolution: Samba needs to translate Windows SIDs to POSIX UIDs/GIDs and vice versa. Winbind is built to do this and integrate with Samba’s ACL handling. SSSD on its own isn’t integrated into Samba’s ACL code. In earlier attempts to use SSSD for a Samba server, administrators encountered issues like seeing raw SIDs instead of usernames in file permissions ( Samba 4.8, Winbind and SSSD - sssd-users - Fedora mailing-lists ). This was a symptom of Samba not being able to resolve SIDs via SSSD in all contexts. The Winbind daemon is tightly coupled with Samba for these translations.

In summary, @hortimech is correct – for a Samba AD member server, Winbind is essentially mandatory. Samba upstream and vendors (like Red Hat) require or strongly recommend Winbind in this situation. SSSD alone cannot fully handle all the necessary functions (especially NTLM auth and complete SID/UID resolution for file sharing). Thus, in the context of “Winbind vs SSSD” on a domain-joined file server, Winbind isn’t just superior – it’s a required component for proper operation (SAMBA — Re: Samba 4 without winbind) ( Samba 4.8, Winbind and SSSD - sssd-users - Fedora mailing-lists ).

Supporting Evidence:

Overlap of Functionality and Origin of SSSD vs Winbind

Claim: “Winbind does what SSSD does… you are duplicating systems if you run both. SSSD was essentially based on Winbind (written by the same person who wrote Winbind originally).” @hortimech suggests that using both services is redundant because they serve the same purpose (providing identity/authentication from AD), and that historically SSSD’s development drew from Winbind’s concepts and code. He implies neither daemon has a magical capability the other completely lacks in an AD context, aside from some edge features.

Analysis: It is true that Winbind and SSSD have overlapping responsibilities when it comes to AD integration on a Linux system. Both can:

  • Connect to AD domain controllers (using Kerberos and/or LDAP) to authenticate users and fetch identity information (user/group attributes).
  • Provide Name Service Switch (NSS) modules to resolve Unix user and group queries (getent passwd, getent group) for AD accounts.
  • Provide PAM modules or integration for login authentication against AD.
  • Cache credentials and identity data for offline use.
  • Map Windows SIDs to Unix user/group IDs (UIDs/GIDs) in a consistent way across the system.

If both SSSD and Winbind are running on the same machine against the same AD domain, they are indeed duplicating work: each would maintain its own connection to AD, its own cache of users, and its own mechanisms to map identities. This can lead not only to redundancy but also potential conflicts (for example, each maintains a machine account password if not configured carefully – one reason running both requires special configuration to sync the machine secret, as @hortimech hinted). Red Hat’s best practices note that if one attempts to run both SSSD and Winbind on the same domain-joined host, they must be carefully configured to avoid clashing (e.g. using adcli --add-samba-data so that SSSD updates Samba’s machine password, or using separate machine accounts) ( Samba filesharing, ssh and sssd - sssd-users - Fedora mailing-lists ) ( Samba filesharing, ssh and sssd - sssd-users - Fedora mailing-lists ). Without such steps, the AD computer account password could get out of sync and “your domain could die after a month” (when the machine password rotates) – a known pitfall if running both daemons unsynchronized (In an AD based domain, does it make sense to use WinBind instead of SSSD for authentication? : r/linuxadmin).

Regarding the origin and shared code: The assertion that the same individual wrote Winbind and then later wrote a large portion of SSSD is a bit of an anecdote, but it aligns with known history. One of the Samba developers who significantly contributed to Winbind (for example, Sumit Bose and others) later joined Red Hat and worked on SSSD. In fact, posts on forums and mailing lists have noted that “winbind and sssd were initially written by the same person, winbind first, then sssd” (In an AD based domain, does it make sense to use WinBind instead of SSSD for authentication? : r/linuxadmin). SSSD was introduced around 2009–2010 by Red Hat to provide a more unified identity/authentication service for Linux (not only for AD, but also for LDAP, FreeIPA, etc.), but its design benefitted from experience with Winbind. Some of the algorithms (like how to map a Windows SID to a UNIX UID) and concepts in SSSD’s AD integration were inspired by Winbind’s approach (In an AD based domain, does it make sense to use WinBind instead of SSSD for authentication? : r/linuxadmin). There isn’t a complete code overlap (SSSD is a separate codebase, not a fork of Winbind), but the knowledge and design carried over. Essentially, SSSD’s AD provider can be seen as a reimplementation of the functionality Winbind provides, aiming to integrate with the system in a different manner (through SSSD’s frameworks and with multi-domain flexibility).

Key points of overlap and differences:

In summary, @hortimech’s point that SSSD and Winbind cover the same ground for AD is largely correct. They both authenticate users against AD and retrieve user/group info, so using both together is usually unnecessary. His statement about shared origins underlines that SSSD wasn’t developed in a vacuum – it leveraged Winbind’s prior art. Practically, if Winbind is running, it can provide all needed NSS/PAM services itself, making SSSD optional on that host. As one Red Hat engineer noted, it’s certainly possible to make Winbind and SSSD co-exist, but Samba itself does not need SSSD at all when Winbind is in use ( idmap_sss Backend for Winbind - sssd-users - Fedora mailing-lists ).

Supporting Evidence:

The “idmap_sss” Backend and Samba Integration

Claim: The idmap_sss plugin (“sss” idmap backend) that allows Samba to use SSSD for ID mapping is not part of upstream Samba, is a Red Hat-specific solution, and there are better native backends. Also, using idmap_sss doesn’t eliminate the need for Winbind – you’re still essentially running Winbind (just delegating one function to SSSD).

Analysis: This point is accurate. Here’s what we know about idmap_sss and Samba:

  • Not upstream: The idmap_sss module does not come with the standard Samba source code. It was developed by Red Hat and is shipped as part of Red Hat-based distributions (RHEL, CentOS Stream, Fedora) via the sssd-winbind-idmap package ( Samba 4.8, Winbind and SSSD - sssd-users - Fedora mailing-lists ). Upstream Samba’s official idmap backends (as of current versions) include options like idmap_rid, idmap_ad, idmap_autorid, idmap_tdb, etc., but not “sss” (In an AD based domain, does it make sense to use WinBind instead of SSSD for authentication? : r/linuxadmin). This means on non-Red Hat systems (Debian/Ubuntu, SUSE, etc.), idmap_sss is generally not available or supported. Samba’s team has not integrated it, likely because it ties Samba to SSSD which they consider outside Samba’s scope. In a Reddit discussion, @hortimech emphasizes that “idmap_sss… isn’t in the Samba tree and comes from Red Hat” (In an AD based domain, does it make sense to use WinBind instead of SSSD for authentication? : r/linuxadmin). This is confirmed by RHEL documentation that introduced it as a way to “re-enable Samba -> Winbind -> SSSD lookups” for ID consistency ( Samba 4.8, Winbind and SSSD - sssd-users - Fedora mailing-lists ).

  • Purpose of idmap_sss: This plugin’s goal is to unify UID/GID mappings between SSSD and Samba’s Winbind. Normally, if you ran SSSD for system logins and Winbind for Samba, each might produce different UIDs for the same AD user (depending on configuration), which is obviously undesirable (file ownership mismatches, etc.). idmap_sss addresses this by having Winbind ask SSSD to perform the SID<->UID mapping. According to its man page, “The idmap_sss module provides a way to call SSSD to map UIDs/GIDs and SIDs.” ( Samba 4.8, Winbind and SSSD - sssd-users - Fedora mailing-lists ). In effect, SSSD becomes the authority for the ID mapping, so both daemons agree on the same UID/GID for each AD account. Sumit Bose (SSSD developer) explained on the mailing list that “SSSD’s idmap plugin just provides the mapping from SID to UID/GID and back. All other data will be read by Winbind from AD.” ( idmap_sss Backend for Winbind - sssd-users - Fedora mailing-lists ). This is crucial: idmap_sss does not make Winbind obsolete – Winbind still must handle authentication, group memberships, and contacting AD for other info. The plugin only hooks into the ID mapping step. So indeed, as @hortimech says, even if you configure Samba to use idmap_sss, you are still running the full Winbind daemon (and it’s still communicating with AD for logons, group lookups, etc.) (Configure RHEL9.5 with sssd, samba and AD (by OpenAI Deep Research) · GitHub) (Configure RHEL9.5 with sssd, samba and AD (by OpenAI Deep Research) · GitHub). The only difference is that when Winbind needs to translate a Windows SID to a Unix UID, it asks SSSD instead of using its own algorithm or querying AD’s RFC2307 attributes.

  • Limitations of idmap_sss: This module is known to be read-only (as of its introduction in RHEL7.6). It will not create new ID mappings on its own; it relies on SSSD’s cache/config. For example, if a new user appears in AD and SSSD hasn’t cached/assigned an ID yet, Winbind might not get a mapping until SSSD sees the user. In practice, SSSD will assign IDs as needed (either using AD’s uidNumber if available, or an algorithmic mapping), so this might be a minor detail. But it means idmap_sss cannot allocate IDs independently – it defers entirely to SSSD. This was noted in a bug report: the config example in docs was slightly misleading because “sss is read only” for id mapping ( Samba 4.8, Winbind and SSSD - sssd-users - Fedora mailing-lists ).
    Red Hat’s Knowledgebase has even stated: “The idmap_sss module has some restrictions… it is currently not advised to utilize idmap_sss” on certain releases (How to configure a Samba server with SSSD in CentOS 7 or 8). In fact, Red Hat’s current recommendation (as of RHEL8/9) for Samba servers is to use Winbind (with a native idmap like ad or rid) rather than relying on idmap_sss. Their support article explicitly says: “Red Hat currently does not recommend using the idmap_sss module for Samba file server enrolled into an IdM or AD domain.” (What is the support status for Samba file server running on IdM ...). This aligns with @hortimech’s skepticism about idmap_sss.

  • Alternative “better” idmap backends: Depending on the environment, one can choose an idmap backend for Winbind that ensures consistent UID/GID assignment across systems without involving SSSD. Two commonly used ones:

    • idmap_ad: Winbind will read the POSIX attributes (uidNumber, gidNumber) from AD if they are populated for users/groups. This is often considered the best method if your AD is configured with Unix attributes (so you control the exact UIDs/GIDs centrally in AD). It provides consistency across all servers (Windows and Linux) and avoids algorithmic surprises.
    • idmap_rid (or idmap_autorid): Winbind computes UIDs from the user’s RID (the relative part of the SID) in a deterministic way. This requires choosing a UID range per domain, but once set, any server using the same formula will map the same SID to the same UID. It’s straightforward and doesn’t require AD schema extensions. These backends are well-tested and supported in upstream Samba, whereas idmap_sss is newer and specific to Red Hat environments. In many cases, using idmap_rid or idmap_ad with Winbind achieves the same goal of consistent IDs on all servers (provided all servers use the same method and configuration). If all Linux systems use Winbind, it’s easy to configure them identically. If some use SSSD and some use Winbind, one strategy is to use AD’s uidNumber attributes (so SSSD and Winbind both draw from the same source) instead of the idmap_sss indirection.

In summary, @hortimech is correct that the “sss” idmap plugin is a Red Hat-specific solution and not part of standard Samba. Its presence indicates Red Hat’s attempt to let SSSD and Winbind cooperate, but even Red Hat acknowledges certain limitations in that setup (4.2. Using SMB shares with SSSD and Winbind | Red Hat Product Documentation). Using idmap_sss does not mean you can stop running Winbind; it only centralizes ID mapping through SSSD. There are other proven idmap backends that many consider more straightforward (“better”) depending on the scenario – for example, idmap_ad for environments with POSIX attributes in AD, or idmap_rid for simpler deployments. Those eliminate the need for a dual-daemon approach altogether by just using Winbind for everything. This reinforces his stance: if you must run Winbind for Samba anyway, you might as well use Winbind fully (with a solid idmap backend) and not add SSSD to the mix unless you have a compelling reason.

Supporting Evidence:

Feature Comparisons: Modern Capabilities, Performance, and Caching

One of the original claims in the gist was that SSSD offers “modern features” and performance benefits (like robust offline caching, faster group refresh, better logging) compared to Winbind. @hortimech counter-argues that Winbind can do virtually everything SSSD does, and anything SSSD adds is rarely needed. Let’s break down some feature and performance considerations:

  • Offline caching and login: SSSD is well-known for its offline authentication support – if a laptop is disconnected from the domain, SSSD can cache credentials so users can still log in. Winbind also supports offline logins (it has a parameter winbind offline logon = yes which caches credentials). Both daemons cache user information and group memberships locally to reduce round-trips to the domain controllers. SSSD’s cache is very configurable (with explicit cache lifetime settings for different record types) and can be manually flushed or updated. Winbind’s caching is a bit less exposed to the admin (mostly internal, though wbinfo -t/–offline can test connectivity and caching). In terms of robustness, both will allow operation during short outages of the AD server, but SSSD is often considered more gracefully tuned for disconnected operation (perhaps because it’s used on client laptops frequently). However, on a server that rarely goes offline, this difference is minimal. It’s true that both provide offline capabilities, so this isn’t a decisive advantage for SSSD in a server scenario (Configure RHEL9.5 with sssd, samba and AD (by OpenAI Deep Research) · GitHub).

  • Group membership refresh: SSSD can be configured to periodically refresh its view of group memberships. It even has a feature to explicitly pull updated group info on a schedule or when certain PAM events occur. Winbind, by default, will update group membership when a user logs in or when a fresh query is made after cache expiry. In large AD environments, both SSSD and Winbind need tuning to handle thousands of group entries efficiently. Neither is inherently “faster” in all cases – performance depends on caching settings and how queries are done. If anything, since both ultimately rely on querying AD (LDAP or RPC) for group info, their throughput is comparable. SSSD uses LDAP queries to retrieve group membership (or tokenGroups via LDAP in AD), while Winbind might use MSRPC calls to a domain controller (or LDAP if configured for it). There isn’t clear data that SSSD universally outperforms Winbind in group lookup; it might log information in more detail which aids tuning. The “faster group membership refresh” claim for SSSD likely comes from anecdotal experiences, but we should note no formal benchmark is given. Both can be optimized to handle frequent group changes (e.g., by reducing cache TTLs or using AD change detection, which SSSD can do via the Global Catalog in some cases).

  • Logging and diagnostics: SSSD has a well-structured logging system (with log files per domain/service in /var/log/sssd/ and debug levels). Winbind logs through Samba’s logging system (which can also be set to per-component debug, typically in /var/log/samba/ or journal). While SSSD’s logs might be a bit more straightforward for just identity operations, Samba/Winbind logs are equally detailed about domain join and auth issues when debug is cranked up. Neither is “better” in logging, but admins familiar with SSSD might prefer its format. This is subjective – not a fundamental functional gap.

  • Authentication protocols: Kerberos is supported by both SSSD and Winbind for AD. Both will manage a machine keytab and obtain tickets as needed. However, as mentioned earlier, NTLM (NTLMv2) is only supported by Winbind. If a setup needs to handle NTLM-based clients (old systems or certain applications), Winbind is necessary (4.2. Using SMB shares with SSSD and Winbind | Red Hat Product Documentation). If an environment is strictly Kerberos-only, this might not matter – but many real-world AD environments still rely on NTLM fallback in some scenarios. So Winbind covers both Kerberos and NTLM, whereas SSSD covers only Kerberos-based auth in AD. This is a significant functional difference (though one might frame it as a security benefit for SSSD if you want to disallow NTLM – but that has to be a conscious choice and might break some clients).

  • Multiple domain/forest support: SSSD can be configured with multiple domains or trust relationships in one config (for example, if your server needs to handle logins from multiple AD domains or an AD forest with trusts, SSSD can enumerate and cache users from trusted domains as well). Winbind can also handle trusts – in an AD trust, Winbind is capable of resolving users from the trusted domain (one would configure additional idmap ranges for the trusted domains). Both can thus work in multi-domain scenarios, though the configuration differs. SSSD might have an edge in a multi-forest scenario where you don’t want to join multiple domains separately – it can use one AD site to discover others. But Samba’s design typically expects the server to join one domain and then handle trusts via that domain’s controllers. In practice, both can accommodate trusts; it’s not a one-sided advantage.

  • Extensibility (non-AD features): SSSD can retrieve additional user attributes from AD (for example, user’s email, SSH public keys stored in AD, sudo rules via LDAP, etc.) and even do some caching of those. Winbind is more limited to core identity data (username, UID, groups) and doesn’t fetch ancillary attributes that aren’t needed for login or file access. If your use-case involves pulling something like an SSH public key from an AD attribute for use in sshd (which SSSD can do via the ldap_access_order = ssh or similar configs), Winbind has no built-in facility for that. Those are corner cases – as @hortimech notes, most deployments don’t use the AD as a store for such data or could handle it via scripts. So yes, SSSD has some additional capabilities (e.g., managing sudoers from AD, reading user certs, policy, etc.), but these are indeed used by a small percentage of environments (Configure RHEL9.5 with sssd, samba and AD (by OpenAI Deep Research) · GitHub). For pure file serving and basic authentication, Winbind provides everything needed.

  • Performance and resource usage: Both SSSD and Winbind are lightweight in terms of CPU, but both will consume memory proportional to the number of cached users/groups. SSSD tends to spawn multiple processes/threads (sssd_be, sssd_nss, etc.), whereas Winbind is a single daemon (with multiple threads internally). On a modern system, the overhead of either is negligible. Some admins have observed that SSSD might be more efficient in handling a high rate of NSS lookups due to its nscd-like caching, but Winbind’s nss library also caches results. Again, differences are minor and not likely noticeable unless under extreme load (tens of thousands of lookups). The key performance consideration is more about simplicity: Running one daemon instead of two is inherently leaner. If you already run Winbind for Samba, adding SSSD means an extra service in memory and extra communication for identity lookups (especially if using idmap_sss, Samba’s Winbind will be querying SSSD for every ID mapping, adding IPC overhead). Keeping to one service (Winbind) avoids that potential overhead or latency.

In summary, SSSD vs Winbind feature-wise: For an AD file server, Winbind covers authentication and identity needs almost entirely. SSSD might offer a few “nice-to-have” features (like certain attribute retrieval or perhaps slightly friendlier configuration for purely Unix client scenarios), but those are not typically relevant to serving Windows/MS SMB clients. Importantly, SSSD’s lack of NTLM support is a functional gap in this context – meaning a Samba server using only SSSD would not support all authentication types by default (4.2. Using SMB shares with SSSD and Winbind | Red Hat Product Documentation). On the other hand, any “modern improvements” SSSD brings (better offline caching, logging, etc.) are incremental and often matched by Winbind’s capabilities or are not crucial on a server that is always online and well-connected to AD. @hortimech’s stance that “winbind does virtually everything that SSSD does” is backed by the overlap in core functionality (Configure RHEL9.5 with sssd, samba and AD (by OpenAI Deep Research) · GitHub). The few things Winbind doesn’t do (like manage non-auth data or talk to non-AD sources) generally don’t matter in a pure AD environment with file sharing (In an AD based domain, does it make sense to use WinBind instead of SSSD for authentication? : r/linuxadmin) (In an AD based domain, does it make sense to use WinBind instead of SSSD for authentication? : r/linuxadmin).

Supporting Evidence:

“Legacy vs Modern” – Are SSSD and Winbind Fundamentally Different?

Claim: The gist’s author portrayed Winbind as a “legacy” component made unnecessary by the “improved capabilities of SSSD” in modern deployments. @hortimech refutes this by pointing out that Winbind and SSSD share a lot of heritage – if one is considered old or legacy, so is the other. He implies that SSSD is not magically more advanced in the context of AD; it’s simply a different implementation of similar concepts, maintained in parallel.

Analysis: Framing Winbind as “legacy” and SSSD as “modern” is somewhat misleading. Here are some insights:

  • Maintenance and Updates: Both Winbind and SSSD are actively maintained projects. Samba (which includes Winbind) continues to release updates, security fixes, and new features regularly – Winbind evolves alongside changes in Windows/AD (e.g., supporting new encryption types, trust improvements, etc.). SSSD is also actively developed (especially by Red Hat and Fedora communities) to add features and improve integration (for example, recent SSSD versions added more support for smartcards, two-factor auth with AD, and improved performance for large domains). So, neither is abandonware; calling Winbind “legacy” is not accurate in the sense of being outdated or unmaintained. It’s legacy only in the sense that it’s the older approach for AD integration on Linux, whereas SSSD is newer. But newer doesn’t automatically mean better for every use-case.

  • Shared Concepts: As discussed, SSSD’s AD provider was created after Winbind had been around, and the developers leveraged knowledge from Winbind. Indeed, much of what SSSD does for AD (joining the domain via Kerberos keytabs, doing LDAP searches in AD, caching identities, etc.) parallels Winbind’s functionality. In some cases, SSSD even uses some of the same underlying libraries as Samba (for instance, for certain cryptographic operations or for interfacing with Kerberos libraries). The two projects aren’t using identical code, but they solve the same problem. Both are mature technologies by now – SSSD has been around for over a decade, and Winbind for about two decades.

  • “Modern” features: Often SSSD is called more modern because it was designed to unify multiple identity sources (one daemon for LDAP, AD, IPA, etc.) and to integrate nicely with things like Systemd, DBus, and modern Linux PAM/NSS frameworks. It also introduced conveniences like the realmd integration for easy domain join on RHEL/Fedora. Winbind, being part of Samba, sticks to its domain-focused design and the traditional Unix config style (smb.conf). However, these differences don’t necessarily make one technically superior; they’re more about use-case and admin preference. For example, if you needed to authenticate against two different AD domains and an LDAP server simultaneously, SSSD could handle that in one process (which is “modern” flexibility). Winbind, tied to one domain join at a time, would not do that (you’d need separate Samba instances or trusts). But on a single-domain file server, that flexibility isn’t needed. Conversely, Winbind’s closer tie to Windows protocols (NetBIOS, etc.) is “old school” but necessary for full Windows compatibility.

  • Code sharing: It’s worth noting that, on RHEL systems, there is some code sharing in the form of libwbclient – Samba provides a library that client programs (or SSSD) can use to talk to Winbind. In setups where SSSD and Winbind co-exist, SSSD can use adcli or libwbclient to maintain the machine account with Samba’s secrets. These interactions show that the boundary between the two isn’t a hard wall; they can interoperate when needed. This further supports the notion that they are complementary tools rather than generational replacements.

In essence, labeling Winbind “legacy” is incorrect if it implies it’s deprecated. Samba’s Winbind is fully supported and continuously improved, and as long as Active Directory exists, Winbind remains a first-class citizen for Linux integration. SSSD is “modern” in design philosophy, but it does not render Winbind obsolete, especially not for Samba itself. In fact, as we’ve seen, Samba relies on Winbind’s existence. @hortimech’s quip that “If winbind is legacy, then so is SSSD” highlights that both have been around and share lineage (Configure RHEL9.5 with sssd, samba and AD (by OpenAI Deep Research) · GitHub) (Configure RHEL9.5 with sssd, samba and AD (by OpenAI Deep Research) · GitHub). The difference lies in use-case focus rather than one being an outdated technology. A realistic view is: Use the right tool for the job – SSSD for a consistent client-side login experience in many scenarios, Winbind for deep Samba/AD integration – rather than treating one as an evolution of the other in all respects.

Supporting Evidence:

Security Considerations

When choosing between Winbind and SSSD (or deciding whether to run both), there are some security-related factors to consider, many of which bolster @hortimech’s viewpoint:

  • Attack surface & Complexity: Running only one daemon (Winbind) instead of two (Winbind + SSSD) reduces the overall attack surface and complexity. Each of these services runs as root and handles authentication material (tickets, credentials). Keeping the stack simpler (just Samba/Winbind) means fewer codebases that could have vulnerabilities. SSSD is fairly secure and sandboxed, but in principle, minimizing unnecessary services is good security practice. Additionally, configuring two services to talk to AD introduces complexity (like syncing machine passwords) – misconfiguration could lead to security issues (e.g., a machine account not updating could cause auth to fail, which is a availability concern, or conflicting configs could cause one service to bypass an intended restriction). Using one well-understood service (Winbind) avoids these pitfalls.

  • Protocol support and enforcement: If an organization’s security policy forbids NTLM and requires Kerberos only, one might think using SSSD (which only does Kerberos) enforces that. However, Samba’s smbd itself would still need to be configured to refuse NTLM connections in that case (via min protocol or other smb.conf settings) because even if SSSD is used for identity, Samba could attempt an NTLM auth if a client requested it. Without Winbind, Samba can’t actually perform the NTLM authentication, so the connection would fail – effectively achieving the goal of “no NTLM.” But note, this is not the recommended way to disable NTLM; Samba can directly be configured to disallow NTLM while still running Winbind (for example, ntlm auth = disabled in smb.conf). So security-wise, one can still maintain a Kerberos-only posture using Winbind – there’s no need to drop Winbind to improve security. Conversely, if NTLM is allowed or needed, SSSD alone cannot handle it, as discussed. So for completeness of authentication methods, Winbind is required. In terms of Kerberos key material, both Winbind and SSSD will manage machine Kerberos keys; running both could mean two copies of sensitive keys (keytab and secrets.tdb). Ensuring those remain in sync is crucial to avoid a situation where one service fails and perhaps prompts rejoining the domain (which could have security implications if not noticed).

  • Trust and support: Using the officially supported method (Winbind for Samba) can be seen as a security consideration too. If an issue arises (e.g., an auth bypass bug or a critical patch), Samba/Winbind will get direct attention and patches from both the Samba team and the distribution vendor. SSSD is also supported for client auth issues, but if one ventures into a configuration that is “not recommended” (like using SSSD for Samba), you may find yourself in unsupported territory for security fixes or guidance. For instance, if a vulnerability was found specifically in the idmap_sss integration, it might not be as high priority to fix since the vendor stance might be “don’t use that in production”. Sticking to supported practices (Winbind for file servers) ensures you’re covered by security updates in a timely fashion for that usage.

  • Integration with system security policies: Winbind and SSSD both integrate with Linux PAM for authentication. SSSD works with pam_sss and Winbind via pam_winbind. Each can enforce things like password policies from AD (account lockouts, etc.). In general they both honor AD’s security features (e.g., Kerberos policies, password expirations). SSSD might have an edge in some advanced policies (like if using AD group policy for Linux via an extension, though that’s rare). But essentially, both will adhere to AD’s security (like requiring smartcard login if AD demands it – though implementing that might be easier with SSSD’s PAM integration, it’s beyond typical file server needs).

In short, from a security perspective, there’s no inherent weakness in Winbind compared to SSSD. Both are designed to securely handle credentials. The key is to minimize complexity: if your scenario requires Samba, using Winbind alone avoids the complexities of running dual mechanisms. Also, Winbind ensures all authentication protocols (including older ones) are handled – which can be a double-edged sword (more compatibility vs. potentially enabling weaker auth if not configured carefully). But since you can configure Samba/Winbind to refuse weak protocols, it’s not an issue. @hortimech’s recommendation aligns with a secure-by-simplicity approach: use Winbind for an AD file server and drop SSSD on that system, thereby reducing moving parts that could misfire.

Supporting Evidence:

Compatibility and Additional Considerations

Beyond pure technical capability, there are practical factors that influence the decision between Winbind and SSSD in this context:

  • Client Compatibility (Windows, macOS): A Samba server with Winbind will accommodate the full range of Windows client behaviors, including older machines or scenarios using NTLM authentication or trusting NetBIOS name resolution. SSSD has no role in direct client compatibility because Samba handles that, but if one tried to use SSSD alone, those older client methods wouldn’t work. Furthermore, properly resolving Windows SIDs to names in file ACLs is known to work correctly with Winbind. As mentioned, when using SSSD without Winbind, administrators observed raw SIDs in Windows Security tabs ( Samba 4.8, Winbind and SSSD - sssd-users - Fedora mailing-lists ). The idmap_sss plugin was meant to address this, but it’s an extra link in the chain. Winbind by itself (with a proper idmap) will show friendly names for permissions and integrate with Windows Admin tools seamlessly. This can be a deciding factor for environments where Windows admins frequently manage share permissions – they expect to see user/group names resolved correctly.

  • Consistent UID/GID across systems: In a domain environment, if you have multiple Linux servers, you generally want an AD user to have the same UID on each server (so file ownerships remain consistent). Both Winbind and SSSD can achieve consistent ID mapping, but the strategy differs:

    • With Winbind: you configure each server with the same idmap backend and parameters (or use AD’s RFC2307 attributes with idmap_ad). Then all servers running Winbind will compute or fetch the same UID for a given user.
    • With SSSD: you configure each server’s sssd.conf similarly (and if using RID mapping, ensure the same algorithm/ranges, or if using AD attributes, it picks up the same uidNumber). SSSD will then produce consistent UIDs across those servers. If you mix Winbind and SSSD, you must ensure they align. The easiest way is to use AD’s uidNumber/gidNumber for users/groups defined in AD. Both Winbind (idmap_ad) and SSSD can consume those, yielding identical UIDs. If AD is not populated with Unix attributes, mixing becomes tricky. Red Hat’s solution is idmap_sss (making Winbind defer to SSSD’s mapping). Otherwise, you might use a purely algorithmic approach and attempt to configure SSSD and Winbind to the same algorithm – but by default they might differ (Winbind’s autorid vs SSSD’s default might not match). This is a strong argument to standardize on one method across your Linux estate. For a homogeneous approach, many choose SSSD for Linux workstations/servers without Samba, and Winbind for Samba servers – then ensure both are using AD’s RFC2307 attributes for ID mapping so that identities align. Another approach is to avoid SSSD entirely in AD setups and use Winbind everywhere (even on clients), but SSSD tends to have nicer integration on pure Linux clients (e.g., auto-create home directories, etc., via PAM). In any case, if considering the big picture, one must plan ID mapping carefully if diverging from the simple “Winbind everywhere” or “SSSD everywhere” approach.

  • Ease of configuration: This can influence decisions. Some admins find joining a domain and setting up SSSD via realm join (which handles a lot automatically) simpler than configuring Samba and Winbind. However, since our context specifically includes Samba, you have to configure Samba anyway (smb.conf, shares, etc.). Setting up Winbind at that point is not much additional work: it’s a few parameters in smb.conf and ensuring nsswitch.conf uses winbind for passwd/group lookups. Red Hat documentation provides step-by-step guides for either approach. It’s worth noting that RHEL’s default tools (realmd) will actually configure both SSSD and Winbind on a Samba server joined to AD: it uses SSSD as the domain client but also sets up Samba with winbindd and the sss idmap plugin, as a compromise approach (In an AD based domain, does it make sense to use WinBind instead of SSSD for authentication? : r/linuxadmin). This is perhaps meant to accommodate admins who use SSSD widely but also need Samba – they don’t have to completely switch to Winbind for system auth. However, as we’ve seen, this dual setup has caveats and is not universally recommended.

  • Use of AD-specific features: If the environment plans to use advanced AD features on Linux (like Group Policy for Linux via PAM, or querying user’s Global Catalog attributes, or integrating with Microsoft Identity Management for Unix), one should check support. Winbind has some integration with AD’s PAC (Privilege Attribute Certificate in Kerberos tickets) to quickly get group memberships, and SSSD also can read the PAC or perform tokenGroup queries. Both can handle large token sizes (for users in many groups). But if, say, Group Policy for Linux was desired, there’s an addon called gpupdate in Samba/Winbind (samba-client package) to apply some GPO settings, whereas SSSD doesn’t apply Windows GPOs. On the flip side, if using FreeIPA/IdM trust with AD, SSSD is the component used on IPA clients to handle that trust; Winbind is not used in IPA client scenarios. But that’s a different scenario (IdM trusts rather than direct AD join).

  • Future developments: It’s possible that in the future SSSD and Samba integration may improve. For instance, if Samba upstream were ever to incorporate a mode to directly utilize SSSD for all identity info, or if SSSD gained NTLM support (unlikely), the balance might shift. But as of the latest sources and documentation, that’s not the case. The trend has been Samba doubling-down on requiring Winbind, and Red Hat acknowledging that by supporting Winbind on servers. In fact, the Red Hat Customer Portal (updated Jan 2025) provides instructions on “How to configure a Samba server with SSSD in RHEL with Winbind handling AD Join”, indicating that even when SSSD is involved, Winbind is still handling the crucial domain join aspect (How to configure a Samba server with SSSD in RHEL with Winbind handling AD Join - Red Hat Customer Portal). Red Hat currently advises that if you use SSSD on a Samba server, you still let Winbind do the AD domain join and handle the low-level communication, essentially exactly what @hortimech suggests. This is a notable convergence of opinion between the vendor and the Samba community: Winbind remains integral in the Samba+AD equation.

  • Non-AD scenarios: It’s out of scope of @hortimech’s comment (since he specifically talks about AD), but for completeness: if one were dealing with a non-AD LDAP server for identity, Winbind wouldn’t apply at all (SSSD or other tools would be used). Winbind is specific to AD (or NT4 domains). SSSD is more general-purpose (LDAP, IPA, etc.). However, in “this specific context” (AD integration on RHEL9.5 with Samba), we are indeed in Winbind’s domain of applicability.

  • Community and Support: Samba’s community (mailing lists, wiki) predominantly documents solutions using Winbind for AD integration. Those resources are invaluable when troubleshooting. If you go the SSSD route for Samba, you may find fewer community guides (aside from Red Hat’s documentation for their distro). So from a practical standpoint, following the more common path (Winbind) can make it easier to find help or examples.

In light of all these factors, the decision for this scenario leans towards Winbind for the Samba server, as @hortimech advocates. The only time one might consider adding SSSD is if the server also had to serve some unusual purpose aside from Samba (e.g., it needed to authenticate against multiple sources or retrieve special attributes). But even then, it may be cleaner to separate roles (have one server handle Samba/AD with Winbind, another handle multi-source auth, etc.) rather than complicating a single system.

Supporting Evidence:

Conclusion

After examining @hortimech’s claims against current documentation and source code behavior, we find that his stance is well-supported for the scenario of a Samba file server in an AD domain. Key conclusions from this analysis:

In neutral terms, the best practice for a modern RHEL 9.5 deployment that includes Samba file sharing in an AD domain is to use Winbind (via Samba’s winbindd) as the primary domain integration service. SSSD can be omitted in that scenario unless there’s a specific requirement it alone can fulfill. Even Red Hat’s latest recommendations acknowledge this, despite SSSD’s improvements. SSSD is sufficient and recommended for pure client machines or scenarios without Samba, but when it comes to Samba servers, Winbind remains the recommended component ( Samba 4.8, Winbind and SSSD - sssd-users - Fedora mailing-lists ).

Thus, @hortimech’s commentary is grounded in current reality: in this particular situation (AD member file server), Winbind isn’t just superior – it’s essentially non-negotiable for full functionality. His points about avoiding a dual configuration are validated by the technical documentation and should be heeded to reduce complexity.

Bottom line: Use Winbind for the Samba/AD integration on the server, and reserve SSSD for where it shines (client-side integration or multi-source environments). This ensures a reliable, supportable setup with optimal performance and fewer moving parts – exactly as @hortimech advocated.

References:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment