SSSD Help!

Does anyone out there have sssd working on SLES 12-SP0?

This is a frightening post to me:

We have a Server 2012R2 AD domain. We want to use AD provider and leverage Kerberos auth. I have an open SR with Novell in an attempt to get a working config for sssd.conf including PAM/NSS accordingly. I have had no luck to date. Does anyone have a sssd.conf that works with their AD domain (preferably 2012R2) and changes to /etc/pam.d files and /etc/nsswitch.conf, /etc/krb5.conf and/or anything else I am missing? Here are the “sssd” packages I currently have installed:


Thanks in advance.

I’ve forwarded this on to the SSSD guru I know, so hopefully he’ll drop in
and answer soon. In the meantime, it may be worthwhile to include more
details on the docs followed, steps taken, etc. If you happen to be at
SUSECon, I can introduce you to him and he can probably give you some
materials or have you join in on a class he’s giving on the topic to
dozens of other attendees.

Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

ruination, ab referenced me to you and I can certainly help! I am currently at SUSECON with an expiring laptop battery and as soon as I sort it I will be back online and will help in painful detail. ab will explain .

– lawrence


Note the following instructions, especially concerning whether you are reading posix attributes from AD or generating them dynamically.

  • Configure the hostname on the linux server to be used for the computer object in AD.

  • Provision forward and reverse lookup DNS records in the DNS service used by the target Windows domain using the configured hostname.

  • Verify DNS and time sync sources for the linux box are the same as used for the target Windows domain and are both working properly (extremely important!). Kerberos operations and the AD autodiscovery and DNS features of the AD provider will benefot greatly from both working crrectly/

  • Install the kerberos client, samba and SSSD packages:



Technically the kerberos and samba (samba is only required for domain joining really) are not required but assist in troubleshooting kerberos, AD connectivity and GSSAPI issues out of band from SSSD.

sssd-tools (recommended)

  • Configure the kerberos and samba clients manually and join the server to the domain. Although YaST can be used to perform all of these tasks, if the right options are not chosen YaST will also configure and implement the pam_krb5, pam_ldap, possibly the winbind module and their related PAM configurations. None of which are required when the SSSD AD provider is used.


default_realm = <WINDOWS_DOMAIN_FQDN>
clockskew = 300

kdc = <>
default_domain = <windows_domain_fqdn>
admin_server = <Windows_ADMIN/>

kdc = FILE:/var/log/krb5/krb5kdc.log
admin_server = FILE:/var/log/krb5/kadmind.log

[domain_realm] = DVC.DARKVIXEN.COM

pam = {
ticket_lifetime = 1d
renew_lifetime = 1d
forwardable = true
proxiable = false
minimum_uid = 10000
clockskew = 300
external = sshd
use_shmem = sshd

** “minimum_uid =” depends on the SSSD id mapping settings used (see more info below) and the settings used by Identity Management for Unix configuration for the AD instance. If this does not apply, omit the directive.


Modify the [GLOBAL] section as described.

passdb backend = tdbsam
printing = cups
printcap name = cups
printcap cache time = 750
cups options = raw
map to guest = Bad User
include = /etc/samba/dhcp.conf
logon path = \\%L\profiles\.msprofile
logon home = \\%L\%U\.9xprofile
logon drive = P:
usershare allow guests = No
kerberos method = secrets and keytab
security = ADS
client use spnego = yes
template homedir = /home/%D/%U

Initiate a kerberos connection using an account that can perform the domain joining operations and join the domain:


View that a kerberos ticket granting ticket was granted:


Join the domain and create a keytab file

net ads join -k

Verify the join and AD connectivity

net ads testjoin
net ads info

  • Invoke the YaST authentication client module

yast auth-client

Add a new SSSD domain using the FQDN of the target domain for the name and select ad as the identity and authentication provider. The resultant /etc/sssd/sssd.conf will be very basic but should work if you are using dynamic id mapping. Meaning that the posix attributes are not being read from AD.

If the posix attributes are to be read from AD implement a sssd.conf file similar to the one below, delete the cache files in the /var/lib/sss/db directory and restart the daemon.

If you start with a id mapping configuration, which is the default, you will have to delete the cache files before the new configuration that disables id mapping will work.

config_file_version = 2
services = nss, pam

filter_users = root
filter_groups = root

reconnection_retries = 3

cache_credentials = True

id_provider = ad
auth_provider = ad

ldap_id_mapping = False

This is a basic config should get you up and going. If home directories will be used it is recommended to implement them using a new path, like /home/<WINDOWS_DOMAIN_FQDN> and include the following directive in the domain configuration stanza:

override_homedir = /home/%d/%u

After creating the /home/<WINDOWS_DOMAIN_FQDN> path this will redirect home directories to the new path.

Be sure to enable home directory creation on user login by issuing the following command as root:

pam-config --query --mkhomedir

Host level access control using group membership can be accomplished by adding the following directives to the domain configuration stanza:

access_provider = ad

ad_access_filter = DOM:<WINDOWS_DOMAIN_FQDN>:(memberOf=<GROUP_LDAP_FDN>)

To ensure the kerberos, ldap and winbind PAM modules are not being loaded disable them with the following commands:

pam-config --delete --ldap
pam-config --delete --krb5
pam-config --delete --winbind

Hope this helps and let me if I can assist further,

– lawrence