= THIS PAGE IS UNMAINTAINED = **PLEASE CONSIDER FOLLOWING https://ubuntu.com/server/docs/service-sssd INSTEAD** = SSSD Authentication = ||<>|| The System Security Services Daemon works in Ubuntu to allow authentication on directory-style backends, including OpenLDAP, Kerberos, RedHat's FreeIPA, Microsoft's Active Directory, and Samba4 Active Directory. It provides a cross-domain compatible method for users to sign in with configurable UID, GID, extended groups, home directory and login shell. You can use it for single-server deployments with plain LDAP with servers or workstations (where you could as well go with `pam-ldap` and `nss-ldap`), but also for larger or sophisticated setups. = Installation = To begin, install (see InstallingSoftware) the following packages: {{{ sudo apt-get install sssd libpam-sss libnss-sss }}} SSSD automatically modifies the PAM files and `/etc/nsswitch.conf` with `pam-auth-update`. You do not need any other NSS or PAM backend such as `pam-ldap`. For debugging, install the optional tools package: {{{ sudo apt-get install sssd-tools }}} == Configuration == All options can be configured in `/etc/sssd/sssd.conf`. Each domain you configure should be listed in the domains option, e.g. `domains = testdomain.com, nextdomain.com`, and have its own section where LDAP parameters are configured, like `[domain/testdomain.com]`. This section is pending a more thorough writeup of general options available to you, however the sample configuration below will cover most cases. === Schema === The option `ldap_schema = rfc2307bis` is related to Active Directory's LDAP schema, and is compatible with Windows Server 2003 R2 and newer. If you are using OpenLDAP or similar, `ldap_schema = rfc2307` should be used instead. From the FedoraHosted wiki: When using the rfc2307 schema, group members are listed by name in the memberUid attribute. When using the rfc2307bis schema, group members are listed by DN and stored in the member (or sometimes uniqueMember) attribute. === Active Directory === Below is an example configuration of `/etc/sssd/sssd.conf` compatible with SSSD version 1.8 and above. This config is for Microsoft Active Directory, Windows 2003 R2 and newer. ==== Attributes ==== You will need to give each user who is intended to login `uidNumber`, `gidNumber`, `unixHomeDirectory` and `loginShell` attributes. To do this, you can either specify defaults in your `sssd.conf` or install the [[http://msdn.microsoft.com/en-us/library/cc731178.aspx|Identity Management for UNIX]] schema extensions on Microsoft AD. Samba4 AD comes with this pre-packaged. By default, SSSD does not generate its own UID and GIDs. It can do this if you add `ldap_id_mapping = true` to a domain section of your configuration, and will be the same across all instances of SSSD that are tied to the same domain, as they are generated from the unique SID attribute. In addition, you can specify a default home directory format using `fallback_homedir = /home/%d/%u` and a default shell using `default_shell = /bin/bash`. If you do this, and have no need to manually specify UID/GID, homedir or login shell per-user, then you are not required to install the Identity Management for Unix schema extensions to specify these attributes. Ensure that the `userPrincipalName` is in the correct format. It should be `samaccountname@domainname`, e.g. `myusername@europe.example.com`, not email-style like `myusername@example.com` or `name.surname@example.com`. ==== Password Changing ==== To allow users to change their password, the domain controller must be configured for SSL/TLS. Samba4 comes with a self-signed certificate that it will use if accessed via `ldaps`, but Microsoft AD requires additional configuration, either via [[http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx|self-signed certificate]] or [[http://support.microsoft.com/KB/321051|third-party certificate]]. When that is configured, the host URIs should use the `ldaps` protocol (such as ldaps://my-dc.example.com). To use a third-party certificate for Samba4, put the key and cert in `/var/lib/samba/private/tls` as `key.pem` and `cert.pem`. The certificate chain file should go in `ca.pem` as a combined certificate in reverse order, the root CA being last. "(is this correct?)" = Example Configuration = {{{ [nss] filter_groups = root filter_users = root reconnection_retries = 3 [pam] reconnection_retries = 3 [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = europe.example.com,asia.example.com [domain/europe.example.com] #With this as false, a simple "getent passwd" for testing won't work. You must do getent passwd user@domain.com enumerate = false cache_credentials = true id_provider = ldap access_provider = ldap auth_provider = krb5 chpass_provider = krb5 ldap_uri = ldaps://dc1.europe.example.com,ldaps://dc2.europe.example.com ldap_search_base = dc=europe,dc=example,dc=com ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt #This parameter requires that the DC present a completely validated certificate chain. If you're testing or don't care, use 'allow' or 'never'. ldap_tls_reqcert = demand krb5_realm = EUROPE.EXAMPLE.COM dns_discovery_domain = EUROPE.EXAMPLE.COM ldap_schema = rfc2307bis ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true ldap_user_search_base = dc=europe,dc=example,dc=com ldap_group_search_base = dc=europe,dc=example,dc=com ldap_user_object_class = user ldap_user_name = sAMAccountName ldap_user_fullname = displayName ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName ldap_group_object_class = group ldap_group_name = sAMAccountName #Bind credentials ldap_default_bind_dn = cn=europe-ldap-reader,cn=Users,dc=europe,dc=example,dc=com ldap_default_authtok = secret [domain/asia.example.com] #With this as false, a simple "getent passwd" for testing won't work. You must do getent passwd user@domain.com enumerate = false cache_credentials = true id_provider = ldap access_provider = ldap auth_provider = krb5 chpass_provider = krb5 ldap_uri = ldaps://dc1.asia.example.com,ldaps://dc2.asia.example.com ldap_search_base = dc=asia,dc=example,dc=com ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt #This parameter requires that the DC present a completely validated certificate chain. If you're testing or don't care, use 'allow' or 'never'. ldap_tls_reqcert = demand krb5_realm = ASIA.EXAMPLE.COM dns_discovery_domain = ASIA.EXAMPLE.COM ldap_schema = rfc2307bis ldap_access_order = expire ldap_account_expire_policy = ad ldap_force_upper_case_realm = true ldap_user_search_base = dc=asia,dc=example,dc=com ldap_group_search_base = dc=asia,dc=example,dc=com ldap_user_object_class = user ldap_user_name = sAMAccountName ldap_user_fullname = displayName ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName ldap_group_object_class = group ldap_group_name = sAMAccountName #Bind credentials ldap_default_bind_dn = cn=asia-ldap-reader,cn=Users,dc=asia,dc=example,dc=com ldap_default_authtok = secret }}} === MIT Kerberos and OpenLDAP === The following configuration is used in a small [[SingleSignOn|Single Sign-On environment]] using MIT Kerberos for authentication and OpenLDAP for account information. Kerberos is used both for authenticating user and authenticating hosts to the OpenLDAP directory. {{{ [sssd] config_file_version = 2 services = nss,pam domains = EXAMPLE [nss] #debug_level = 0xFFF0 filter_users = root filter_groups = root [pam] [domain/EXAMPLE] #debug_level = 0xFFF0 auth_provider = krb5 krb5_server = kdc.example.com krb5_realm = EXAMPLE.COM cache_credentials = true access_provider = simple chpass_provider = krb5 id_provider = ldap ldap_uri = ldap://ldap.example.com ldap_search_base = dc=example,dc=com ldap_id_use_start_tls = true ldap_sasl_mech = GSSAPI sudo_provider = none }}} = Debugging = More on this section about using sssd-tools and such. Use debug_level=7 ---- CategoryEnterprise CategoryEnterprise