We are in the process of setting up sssd to be used with active directory using the config below.

We do not use attribute mapping as we want to use attributes defined in the AD ldap objects such as custom uid, unixHomeDirectory and public keys etc..


domains = company.domain
config_file_version = 2
services = nss, pam, sudo, ssh
debug_level = 6

ad_hostname = EXAMPLESERVER01 #This is templated using ansible
ad_domain = company.domain
krb5_realm = COMPANY.DOMAIN
krb5_store_password_if_offline = true
use_fully_qualified_names = false
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad
lookup_family_order = ipv4_only
cache_credentials = true
dns_discovery_domain = {{ prod_domain_name }}
create_homedir = true
auto_private_groups = true
ad_gpo_access_control = permissive
ad_gpo_cache_timeout = 30
ad_site = SITENAME
case_sensitive = false
enumerate = false
default_shell = /bin/bash
ldap_schema = ad
ldap_id_mapping = False
ldap_user_shell = loginShell
ldap_user_principal = samAccountName
ldap_user_ssh_public_key = altSecurityIdentities
ldap_user_home_directory = unixHomeDirectory
fallback_homedir = /home/%u

ldap_force_upper_case_realm = true
ldap_purge_cache_timeout = 0
ldap_account_expire_policy = ad
ldap_group_search_base = DN=etc...
ldap_user_search_base = DN=etc...
debug_level = 6

fallback_homedir = /home/%u
reconnection_retries = 3
debug_level = 6

offline_credentials_expiration = 3
offline_failed_login_attempts = 10
offline_failed_login_delay = 30
pam_verbosity = 3
pam_id_timeout = 10
pam_pwd_expiration_warning = 30
reconnection_retries = 3
debug_level = 6


default = FILE:/var/log/krb5libs.log

default_realm = COMPANY.DOMAIN
ticket_lifetime = 1d
renew_lifetime = 7d
dns_lookup_realm = true
dns_lookup_kdc = true
rdns = false
allow_weak_crypto = false
permitted_enctypes = aes256-cts-hmac-sha1-96
default_tkt_enctypes = aes256-cts
default_tgs_enctypes = aes256-cts
kdc_timesync = 1
kdc_timeout = 3000
forwardable = true
renewable = true
proxiable = true
udp_preference_limit = 1
rnds = false

Here is a pastebin of the various sssd log files: https://pastebin.com/2P58uybg

The logs show a domain user who has already successfully logged in (via sshd and public key auth) try to run sudo bash

Other than passwords the ad integration works as desired:

  • users can log in using their sAMAccountName
  • if I run id username you can see usernames's groups with their gid's from active directory
  • the computer object (added using adcli) shows in active directory
  • there appears to be a valid kerberos ticket witht the computers SPN

As a troubleshooting step i configured LDAPS on the domain controllers with an internally trusted certificate added to ubuntu's ca store.

I have gone through the sudo logs (very verbose) and it shows the group successfully being matched and allowing the user sudo.

Any help appreciated.


Host OS: Ubuntu 18.04


# /etc/nsswitch.conf
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat systemd sss
group:          compat systemd sss
shadow:         compat sss
gshadow:        files

hosts:          files dns
networks:       files

protocols:      db files
services:       db files sss
ethers:         db files
rpc:            db files

netgroup:       nis sss
sudoers:        files sss

Packages installed for the ansible role:

  • adcli
  • krb5-user
  • sssd
  • sssd-tools
  • sssd-ad
  • sssd-krb5
  • python3-sss
  • libpam-sss
  • libnss-sss
  • libsss-sudo
  • I have a feeling this is related to kerberos SPN mismatch but have nothing to compare my current config to. The servers in question belong to verious teams all with their own domains and PKI so I cannot change the hostname of the machine, instead i set it via ansible in the sssd.conf, hosts file and ensure the kerberos ticket has the same hostname as the ad object. Also, user accounts need to be in the format sAMAccountName not sAMAccountName@domain for login, so the home dir is /home/%u and the user used to login to the server via SSH is sAMAccountName.
    – ZZ9
    Feb 20, 2020 at 14:12
  • 1
    Did you also find this troubleshooting guide from sssd for sudo? (docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html). What strikes me at first glance is that the logs mention user@domain@domain a couple of times.
    – Gerrit
    Feb 20, 2020 at 16:02
  • 1
    I'm unclear what the actual problem / question is.
    – David W
    Feb 20, 2020 at 17:11
  • Ah, I think I understand. Users are able to SSH using public keys, but not their AD passwords?
    – David W
    Feb 20, 2020 at 17:13
  • Thats correct. SSSD is able to get their public key from LDAP Global Catalog no problem and allow them to login via their group and GPO login right but they cannot use sudo which requres their password
    – ZZ9
    Feb 21, 2020 at 14:26

1 Answer 1


Looking at the configuration provided sssd tries to get the sudo rules from LDAP/AD, but seems to not receive any according entries.

    13:38:35 [sssd[sudo]] [sudosrv_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=example_user@company.domain)(sudoUser=#1010101)(sudoUser=%example_leadership@company.domain)(sudoUser=%acl_win_admins@company.domain)(sudoUser=%example_team@company.domain)(sudoUser=%meta_managed_by_ansible@company.domain)(sudoUser=%example_web@company.domain)(sudoUser=%example_ols@company.domain)(sudoUser=%acl_jump_access@company.domain)))]
    13:38:35 [sssd[sudo]] [sudosrv_fetch_rules] (0x0400): Returning 0 rules for [example_user@company.domain@company.domain]

The Ubuntu sssd sudo troubleshooting guide states several tips on how to verify the query for sudo rules. https://docs.pagure.org/SSSD.sssd/users/sudo_troubleshooting.html#what-to-look-for-in-the-logs

In looks like your configuration is missing the according sections for configuring the ldap details for the sudo rules. Since sssd version 1.11.5 it should be possible to use sssd_provider = ad.


Recent man pages state: https://linux.die.net/man/5/sssd.conf

sudo_provider (string) 
Default: The value of "id_provider" is used if it is set. 
"none" disables SUDO explicitly.

In case your used sssd version is new enough, it should be configured for sudo_provider=ad.

As per Ubuntu sssd version 1.16 it seems that the options are taken from the sssd-ldap options when using ad as sudo provider: https://github.com/SSSD/sssd/blob/sssd-1_16_4/src/providers/ad/ad_sudo.c#L49

    ad_options->id->sudorule_map = ldap_options->sudorule_map;

Thefore documentation for sudo rule maps from sssd-sudo man page should apply: https://linux.die.net/man/5/sssd-sudo

Suggest to set: ldap_sudo_search_base = according to your needs.

In case you want to use file-based sudo suggest to try disabling the provider using: sudo_provider=none Additionally it would be good to explicitly disable sssd lookups in /etc/nssswitch.conf adding/modifying the line sudoers: files.

  • Thanks, I will test this out and get back to you :)
    – ZZ9
    Feb 26, 2020 at 10:44
  • Ill mark this as correct so you get the bounty as the time limit is approaching but not had a chance to test yet. I think the bounty disappears if i dont apply it
    – ZZ9
    Feb 27, 2020 at 14:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.