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)

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

• --client-software=sssd tells realmd to configure SSSD for the client side.
• --membership-software=samba tells realmd to create a computer account compatible with Samba (it will prepare the machine for Samba use, similar to running net ads join) (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim)
• --automatic-id-mapping=yes allows SSSD to generate Unix UIDs/GIDs from AD SIDs if POSIX attributes are not defined in AD (see Section 6 for ID mapping details). If your AD does have POSIX attributes (uidNumber, gidNumber), you can use --automatic-id-mapping=no to have SSSD use those exact IDs (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)

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:

• realm list – should show the domain and that the client software is sssd.
• klist – should show a host keytab entries for the machine.
• Try resolving an AD user via NSS: getent passwd <ADusername> (or getent passwd [email protected]). It should return the user’s info, e.g. an entry with a domain UID/GID and home directory (Chapter 1. Connecting RHEL systems directly to AD using SSSD | Red Hat Product Documentation) For example:

# getent passwd [email protected]
administrator@EXAMPLE.COM:*: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.)

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.

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

• samba installs the SMB server (smbd and nmbd daemons).
• samba-winbind and its clients provide Winbind (needed for certain ADS functionality).
• sssd-winbind-idmap provides the idmap_sss plugin, which allows Samba to consult SSSD for ID mapping (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim) (On RHEL, installing sssd-winbind-idmap may automatically remove sssd-libwbclient if it’s incompatible – this is expected (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim) )

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:

• workgroup – Set this to your AD domain’s NetBIOS name. For example, if your AD domain is example.com, the default NetBIOS domain is EXAMPLE. This should match echo $realm | cut -d. -f1 in uppercase.

• realm – The Kerberos realm (your AD domain in uppercase) (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim)

• security = ads – Configures Samba to operate as a domain member in an Active Directory domain (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim) Samba will use Kerberos/NTLM via the AD domain for authentication.

• kerberos method = secrets and keytab – Tells Samba to use both its internal secret (machine account password stored in secrets.tdb) and the system keytab for Kerberos operations (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim) This is default for security=ads. We’ve enabled SSSD to update the machine password and keytab; setting this ensures Samba can use the updated keytab. We also set machine password timeout = 0 to prevent Samba from changing the machine password on its own (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim) With 0, Samba will not attempt periodic password changes, avoiding conflicts – SSSD will handle it.

• idmap config * – The * domain is the catch-all for unmapped SIDs (e.g., BUILTIN accounts like NT Authority\Authenticated Users). We set it to use the tdb backend with a small ID range (here 10000-19999) (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim) TDB is a local database just for any IDs not in AD (this prevents collisions and provides a default space).

• idmap config EXAMPLE – This is the idmap configuration for our AD domain (replace EXAMPLE with your domain short name). We choose the sss backend, which means Samba will ask SSSD for UID/GID for any given AD SID (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim) (active directory - Samba file server + AD + SSSD without Winbind - Unix & Linux Stack Exchange) We assign a range for these IDs (20000 and above in the example). Make sure this range covers the possible UID/GIDs that SSSD will produce. If you are using SSSD’s automatic mapping, SSSD typically generates very large IDs (in the 10^9 range) by combining the domain SID and RID. In such a case, set a range that includes those values (for example, range = 100000-2147483647 to cover the entire 32-bit UID space, as shown above and in sources (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim) (active directory - Samba file server + AD + SSSD without Winbind - Unix & Linux Stack Exchange) . If you use AD’s uidNumber/gidNumber (with ldap_id_mapping=false), then set the range to cover the values in AD. The range is a safeguard; it should be broad enough to include all possible IDs for your domain.

• template shell / template homedir – These provide defaults for the Unix account properties if not provided by the identity provider. Since we are using SSSD for NSS, these aren’t strictly necessary, but it doesn’t hurt to set them. For example, if Samba needs to create a home directory path for display, %U will be replaced with the username. In our case, SSSD already defines the home directory, so this is just a fallback.

• machine password timeout = 0 – (As noted) disables Samba’s automatic machine-password rotation (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim) This ensures that the machine account password is only rotated by SSSD (which follows the AD default, ~30 days) to avoid any race conditions.

• Printing settings (optional) – We disable printing services (load printers = no, etc.) because this server is intended for file sharing only, and removing printer announcements can slightly streamline operations and logs (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim)

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.

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.

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.

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.

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:

• Red Hat Enterprise Linux documentation on integrating with Active Directory (SSSD) (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) (13.2.16. Domain Options: Enabling Offline Authentication | Red Hat Product Documentation)
• Samba documentation and community guides on using SSSD for Samba ID mapping (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim) (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim) (active directory - Samba file server + AD + SSSD without Winbind - Unix & Linux Stack Exchange)
• Setup for SSSD SSH key retrieval from AD (Fedora/Red Hat guides) (Linux SSH Key + Password Auth for Users Stored in Active Directory) (Linux SSH Key + Password Auth for Users Stored in Active Directory)
• Discussion on SSSD caching and performance tuning for group lookups ( Public ssh key in AD - sssd-users - Fedora mailing-lists ) (SSSD Manual pages)
• “AltSecurityIdentities for SSH Keys” approach in AD (Linux SSH Key + Password Auth for Users Stored in Active Directory) (Linux SSH Key + Password Auth for Users Stored in Active Directory)
• Samba share configuration examples for similar setups (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim) (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim) (How to configure a Samba server with SSSD in CentOS 7 or 8 | SeiMaxim)
• Notes on disabling NT ACL support to use only POSIX perms (Chapter 1. No-Frills Samba Servers)