Local user management and authentication/sssd

From SambaWiki
Jump to: navigation, search


Advantages and disadvantages of sssd

Because people may find that some of the disadvantages are advantages or vice versa in their environment, we won't classify here.

  • Easy to configure. Moreover, tools such as realmd can be used to simplify the configuration even further.
  • Very fast.
  • sssd can retrieve posix data (UID/GID, home directory, shell, etc.) from AD, if you domain was provisioned with the --rfc2307 option. At the same time, RFC2307 isn't a requirement, SSSD also supports algorithmic ID-mapping. Moreover, certain POSIX attributes such as home directory or shell can be set on the client side. For futher information about RFC2307, see the Using RFC2307 on a Samba DC HowTo. This allows for central management of posix data in AD with the common tools and gives the same IDs on every machine.
  • Can handle multiple backends for user/group management and authentication.
  • Rapid development.
  • Does not need a KDC to authenticate.
  • sssd provides many options for failover management (e. g. multi-DC support).
  • Doesn't require the machine to be joined to the domain when using the LDAP provider. Only an LDAP and Kerberos (if used) connection is used. The AD provider mandates a keytab to be used.
  • Requires sssd to be installed on your system.
  • sssd 1.9.0 and later version support the AD id_provider, which brings several features for AD support for easier and shorter configuration. Older version can use the LDAP id_provider instead.
  • Non-Linux platforms, such as the BSD distributions, are not fully supported by sssd yet. Also, the SSSD currently requires the MIT Kerberos libraries. Heimdal support is highly experimental and not supported by upstream.


  • If you plan to use sssd in combination with Kerberos, it is required to have Cyrus SASL (cyrus-sasl-gssapi) installed. Most distribution packages should already bring in Cyrus SASL as a dependency.

Installing with distribution package manager

  • Most distributions already ship sssd in their default repositories.

Building from source

  • sssd requires to have some dependencies installed. For RHEL6 this are the following:
# yum install libini_config check-devel pam-devel libtalloc-devel libtdb-devel \
  libtevent-devel libldb-devel libldb-devel libdhash-devel libcollection-devel \
  libini_config-devel libpcre pcre-devel c-ares-devel glib2-devel dbus-devel \
  libxslt-devel libxml2-devel xml-common docbook-style-xsl libsemanage-devel \
  • If you have compiled Samba 4 yourself, you have to set the PKG_CONFIG_PATH variable, pointing to the directory containing the ndr_nbt.pc file. Otherwise ./configure will stop by „configure: error: "Please install Samba 4 development libraries"“.
  • Build sssd:
# ./configure
# make
# make install
See ./configure --help for options you can set to adapt the build to your environment.
  • If not already done by default, add the path containing the sssd libraries (e. g. libsss_idmap.so) to your library path and run the following command to validate that the libraries are loaded:
# ldconfig -v | grep sss
        libnss_sss.so.2 -> libnss_sss.so.2
        libsss_nss_idmap.so.0 -> libsss_nss_idmap.so.0.0.1
        libsss_idmap.so.0 -> libsss_idmap.so.0.1.0
        libsss_sudo.so -> libsss_sudo.so
        libnsssysinit.so -> libnsssysinit.so
  • If you plan to authenticate against sssd via PAM, it's necessary that PAM finds the module in it's module_path. The recommended way is to use the --enable-pammoddir configuration option. If you haven't adapted the ./configure options, you can link the module to the corresponding directory. If your PAM installation searches for its modules in a different location or you are on a 32-bit platform, adapt the path accordingly.
# ln -s /usr/local/lib/security/pam_sss.so /lib64/security/

Configuring sssd

Method 1: Connecting to AD via Kerberos (recommended)

The following basic example of a sssd.conf let sssd retrieve it's information by using Kerberos. The connection will be encrypted.

  • Extract the keytab for a domain account (you can use the machines account for that, too) and make sure, it is readable only for root. The following example uses the machine account of the host „DC1“
# samba-tool domain exportkeytab /etc/krb5.sssd.keytab --principal=dc1$
# chown root:root /etc/krb5.sssd.keytab 
# chmod 600 /etc/krb5.sssd.keytab
  • If you are running sssd 1.10.0 or a later version, you can use the AD id_provider. In this case, use the following sssd.conf:
services = nss, pam
config_file_version = 2
domains = samdom.example.com



# Using id_provider=ad sets the best defaults on its own
id_provider = ad
# In sssd, the default access provider is always 'permit'. The AD access
# provider by default checks for account expiration
access_provider = ad

# Uncomment to use POSIX attributes on the server
# ldap_id_mapping=false

# Uncomment if the client machine hostname doesn't match the computer object on the DC.
# ad_hostname = dc1.samdom.example.com

# Uncomment if DNS SRV resolution is not working
# ad_server = dc1.samdom.example.com

# Uncomment if the domain section is named differently than your Samba domain
# ad_domain = samdom.example.com

# Enumeration is discouraged for performance reasons.
# enumerate = true

# location of the keytab

  • If you are running a sssd version before 1.10.0, you must use the LDAP id_provider. In this case, use the following sssd.conf content instead:
services = nss, pam
config_file_version = 2
domains = default


id_provider = ldap
ldap_schema = rfc2307bis
ldap_referrals = false
ldap_uri = ldap://dc1.samdom.example.com
ldap_search_base = dc=samdom,dc=example,dc=com
ldap_force_upper_case_realm = true

# See man sssd-simple
access_provider = simple
# Uncomment to check for account expiration in DC
# access_provider = ldap
# ldap_access_order = expire
# ldap_account_expire_policy = ad

# Enumeration is discouraged for performance reasons.
# enumerate = true

auth_provider = krb5
chpass_provider = krb5
ldap_sasl_mech = gssapi
ldap_sasl_authid = dc1$@SAMDOM.EXAMPLE.COM
krb5_server = dc1.samdom.example.com
krb5_kpasswd = dc1.samdom.example.com
ldap_krb5_keytab = /etc/krb5.sssd.keytab

ldap_user_object_class = user
ldap_user_name = samAccountName
ldap_user_home_directory = unixHomeDirectory
ldap_user_principal = userPrincipalName
ldap_user_shell = loginShell

ldap_group_object_class = group
  • Append sss to the passwd and group entry of your /etc/nsswitch.conf, to let the system query sssd for these databases.
passwd:     files sss
group:      files sss
  • Start the sssd daemon.
  • All domain accounts/groups are now available to the local system.

Method 2: Connecting to AD via Bind DN and password

The following basic example of an sssd.conf let the daemon retrieve it's information by binding via an AD account. Connections with this setup will be unencrypted, unless you have setup LDAP over SSL on your DC and change the following example sssd.conf accordingly!

  • Create a new user account in your AD that sssd will use to bind via LDAP and retrieve it's information. Make sure, that you configure this account with the „Password never expires“ option! It's recommended also to set „User cannot change password“. Remember the DN (distinguished name) of the new account. The following example uses the DN „cn=ldap-connect,cn=Users,dc=SAMDOM,dc=example,dc=com“.
  • Use the following content in your sssd.conf:
config_file_version = 2
domains = samdom.example.com
services = nss, pam
debug_level = 0



id_provider = ldap

ldap_uri = ldap://dc1.samdom.example.com
ldap_schema = rfc2307bis
ldap_referrals = false
ldap_default_bind_dn = CN=ldap-connect,cn=Users,dc=SAMDOM,dc=example,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = xxxxxx

ldap_user_search_base = dc=SAMDOM,dc=example,dc=com
ldap_user_object_class = user
ldap_user_home_directory = unixHomeDirectory
ldap_user_principal = userPrincipalName
ldap_user_shell = loginShell

ldap_group_search_base = dc=SAMDOM,dc=example,dc=com
ldap_group_object_class = group

access_provider = ldap
ldap_access_order = expire
ldap_account_expire_policy = ad
  • Start the sssd daemon.
  • All domain accounts/groups are now available to the local system.

Testing identity lookups

Hint: If you do changes to sssd.conf, you should clear the cache, to make sure, that the new results really come from the source and not from the cache. Instead of removing the cache completely, you can also mark the cache entries as expired with sss_cache:

# sss_cache -UG
  • Test 1: Retrieving accounts via getent. This should show local and domain accounts with posix attributes. Please check that all fields contain the values set in AD (UID, primaryGroup, homeDirectory, shell).
# getent passwd Administrator
  • Test 2: Retrieving groups via getent. This should show local and domain groups with posix attributes. Please check that the output contains all fields set in AD (GID, members).
# getent group demo-group
  • Test 3: Change owner/group of of a file to a domain user/group:
# touch /tmp/testfile
# chown Administrator:"Domain Users" /tmp/testfile
# ls -l /tmp/testfile 
-rw-r--r-- 1   Administrator   Domain Users   0   30. Aug 19:30 /tmp/testfile

Configuring PAM

  • Make sure, that PAM finds the required modules (pam_sss.la and pam_sss.so. Typically the PAM module_path points to /lib64/security/ or /lib/security/, depending on your plattform.
  • If your distribution is shipped with a tool for doing changes on PAM configurations, you should use them, instead of editing manually. E. g. SLES provides pam-config, Debian pam-auth-update and Fedora/RHEL uses authconfig for that.
  • Edit your PAM configuration file(s) corresponding to the services you want to hook up. The following is an example for a PAM configuration, that can be used e. g. for ssh (/etc/pam.d/sshd). But be carefull: Changes take effect immediately! It is recommended to keep a root terminal open while you're editing the PAM configuration so that you have somewhere to fix the problems from.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_sss.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so


  • Test: Try accessing a service or log into a service, you have configured to use pam_sss. Example for ssh:
# ssh demo1@DC1
demo1@dc1's password: 
Last login: Mon Sep  2 01:09:10 2013 from dc1.samdom.example.com
[demo1@DC1 ~]$
Personal tools