Local user management and authentication/sssd
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
- Download the latest version from https://fedorahosted.org/sssd/ and unpack it.
- 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 \ nss-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/
- You can also refer to the upstream document on building the 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:
[sssd] services = nss, pam config_file_version = 2 domains = samdom.example.com [nss] [pam] [domain/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 krb5_keytab=/etc/krb5.sssd.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:
[sssd] services = nss, pam config_file_version = 2 domains = default [nss] [pam] [domain/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_realm = 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:
[sssd] config_file_version = 2 domains = samdom.example.com services = nss, pam debug_level = 0 [nss] [pam] [domain/samdom.example.com] 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 demo1:*:10008:10513:demo1:/home/demo1:/bin/bash
- 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 demo-group:*:10015:demo1
- 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
- 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.
#%PAM-1.0 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 ~]$