SSH Rejects an AD User: Check SSSD Access Filters

Technical review: 26 October 2026. Product names, licensing references and procedures reflect this review; check the linked documentation for your release.

An Active Directory username can resolve correctly on Ubuntu while SSH still rejects the session. Creating a home directory or changing its permissions may not help, because identity lookup and permission to sign in are separate checks. Diagnose the account decision before editing PAM or expanding access.

Confirm the exact user identity

Ask for the precise sign-in name and whether the user has a separate privileged account. Similar names are not interchangeable. Run read-only lookup checks using the same name the person actually supplied to SSH:

id 'user@example.com'
getent passwd 'user@example.com'
realm list

The name and domain are fictitious; use the naming convention configured in your environment. A working lookup shows that identity information is available, not that SSSD or sshd permits login. Also confirm the destination host and whether the failure happens before authentication, during the account phase or while opening the session.

Inspect the access policy before home permissions

Review the active SSSD access provider, any AD access filter, applicable GPO access control and sshd user/group restrictions. Make a protected copy of the configuration first, and do not publish real group distinguished names or directory structure in a troubleshooting article.

Where the installed SSSD diagnostic tools support it, an account check can help isolate the policy decision:

sudo sssctl user-checks 'user@example.com' -a acct -s sshd

Compare the result with the intended access rule. LDAP memberOf behavior and nested group handling depend on the filter and directory semantics; do not assume that every nested membership matches a simple direct-membership condition. Keep access-provider decisions separate from general group lookup output.

Check the session layer separately

If authorization succeeds, inspect the configured home path, ownership, shell, filesystem availability and PAM session setup. A missing home directory can matter at this stage, but manually creating a directory for the wrong account only adds confusion. Use the organization’s supported home-directory provisioning method.

Review the SSH service and authentication logs for the specific attempt and timestamp. Ubuntu service names and logging destinations can differ from RHEL examples. Avoid blindly clearing caches, replacing generated PAM files, disabling GPO enforcement or enabling passwordless sudo as supposed SSH fixes.

Test the intended boundary

If an approved group must be added to the access filter, save the exact prior rule and change only that membership allowance. Validate configuration using the tools available in the installed release, retain console access and apply the supported reload/restart sequence. Do not close the working administrative session prematurely.

Test an intended allowed user and a representative user who should remain denied. Confirm the shell session and home behavior, then document the rule and recovery path without exposing directory details. This is distinct from low-UID PAM classification: adding broad access or changing UID thresholds should not be used to mask a group-policy mismatch.

References

• Ubuntu: SSSD with Active Directory
• SSSD: access and authentication troubleshooting
• SSSD: AD provider configuration reference