Product SiteDocumentation Site

8.2.5. Configuring Domains

A domain is a database of user information. SSSD can use more than one domain at the same time, but at least one must be configured for SSSD to start. Using SSSD domains, it is possible to use several LDAP servers providing several unique namespaces. You can specify not only where users' identity information is stored, but how users authenticate against each of the specified domains.
SSSD supports the following identity and authentication combinations:
  • This combination uses an LDAP back end as both the identity and authentication provider.
  • This combination uses an LDAP back end as the identity provider, and uses Kerberos to provide authentication.
  • proxy
    Specifying a proxy identity or authentication provider uses an existing NSS library or customized PAM stack, but takes advantage of the SSSD caching mechanism.
The following example assumes that SSSD is correctly configured and FOO is one of the domains in the [sssd] section. This example shows only the configuration of Kerberos authentication; it does not include any identity provider.
[domain/FOO]
auth_provider = krb5
krb5_kdcip = 192.168.1.1
krb5_realm = EXAMPLE.COM

8.2.5.1. Domain Configuration Options

You can add new domain configurations to the [domain/<NAME>] sections of the /etc/sssd/sssd.conf file, and then add the list of domains to the domains attribute of the [sssd] section, in the order you want them to be queried.
8.2.5.1.1. General Domain Configuration Options
You can use the following configuration options in a domain configuration section:
  • min_id,max_id (integer)
    Specifies the UID and GID limits for the domain. If a domain contains entries that are outside these limits, they are ignored.
    The default value for min_id is 1; the default value for max_id is 0 (unbounded).

    Important

    If min_id is unspecified, it defaults to 1 for any back end. This default was chosen to provide compatibility with existing systems and to ease any migration attempts. LDAP administrators should be aware that granting identities in this range may conflict with users in the local /etc/passwd file. To avoid these conflicts, min_id should be set to 1000 or higher wherever possible.
    The min_id option determines the minimum acceptable value for both UID and GID numbers. Accounts with either UID or GID values below the min_id value are filtered out and not made available on the client.
  • enumerate (Boolean)
    Specifies whether or not to enumerate (list) the users and groups of a domain.
    Enumeration means that the entire set of available users and groups on the remote source is cached on the local machine. When enumeration is disabled, users and groups are only cached as they are requested. For performance reasons, it is recommended that you disable enumeration for domains with many users and groups.
    The default value for this parameter is FALSE. Set this value to TRUE to enable enumeration of users and groups of a domain.
  • timeout (integer)
    Specifies the timeout in seconds for this particular domain.
    This is used to ensure that the backend process is alive and capable of answering requests. The default value for this parameter is 10 seconds. Raising this timeout might prove useful for slower back ends, such as distant LDAP servers.

    Note

    If you set timeout = 0, SSSD reverts to the default value; you cannot force a timeout value of zero, because this would force the sssd daemon into a loop.
  • cache_credentials (Boolean)
    Specifies whether or not to store user credentials in the local SSSD domain database cache.
    The default value for this parameter is FALSE. You should set this value to TRUE for domains other than local if you want to enable offline authentication.
  • id_provider (string)
    Specifies the data provider identity back end to use for this domain. Currently supported identity back ends are:
    • proxy — Support a legacy NSS provider (for example, nss_nis).

      Note

      SSSD needs to know which legacy NSS library to load in order to start successfully. If you set id_provider to proxy, ensure that you also specify a value for proxy_lib_name. Refer to Section 8.2.5.4, “Configuring a Proxy Domain” for information on this attribute.
    • local — SSSD internal local provider.
    • ldap — LDAP provider.
  • entry_cache_timeout (integer)
    Specifies for how long the domain's data provider should cache positive cache hits (that is, queries for valid database entries) before asking the database again.
  • use_fully_qualified_names (Boolean)
    Specifies whether or not requests to this domain require fully-qualified domain names.
    If set to TRUE, all requests to this domain must use fully-qualified domain names. It also means that the output from the request displays the fully-qualified name.
    The ability to restrict requests in this way means that if you know you have multiple domains with conflicting usernames, then there is no doubt about which username the query will resolve.
    Consider the following examples, in which the IPA domain database contains a user named ipauser01, and the use_fully_qualified_names attribute is set to TRUE:
    # getent passwd ipauser01
    [no output]
    # getent passwd ipauser01@IPA
    ipauser01@IPA:x:937315651:937315651:ipauser01:/home/ipauser01:/bin/sh
    
    In the following examples, using the same IPA domain and user, the use_fully_qualified_names attribute is set to FALSE:
    # getent passwd ipauser01
    ipauser01:x:937315651:937315651:ipauser01:/home/ipauser01:/bin/sh
    # getent passwd ipauser01@IPA
    ipauser01:x:937315651:937315651:ipauser01:/home/ipauser01:/bin/sh
    

    Note

    If use_fully_qualified_names is set to FALSE, you can continue to use the fully-qualified name in your requests, but only the simplified version is displayed in the output.
    SSSD can only parse name@domain, not name@realm. You can, however, use the same name for both your domain and your realm.
  • auth_provider (string)
    The authentication provider used for the domain. The default value for this option is the value of id_provider if it is set and can handle authentication requests.
    Currently supported authentication providers are:
    • ldap — for native LDAP authentication. Refer to the sssd-ldap(5) manual page for more information on configuring LDAP.
    • krb5 — for Kerberos authentication. Refer to the sssd-krb5(5) manual page for more information on configuring Kerberos.
    • proxy — for relaying authentication to some other PAM target.
    • none — explicitly disables authentication.
8.2.5.1.2. Proxy Configuration Options
  • proxy_pam_target (string)
    This option is only used when the auth_provider option is set to proxy, and specifies the target to which PAM must proxy.
    This option has no default value. If proxy authentication is required, you need to specify your own PAM target. This corresponds to a file containing PAM stack information in the system's default PAM configuration directory. On Red Hat Enterprise Linux-based systems, this is the /etc/pam.d/ directory.
  • proxy_lib_name (string)
    This option is only used when the id_provider option is set to proxy, and specifies which existing NSS library to proxy identity requests through.
    This option has no default value. You need to manually specify an existing library to take advantage of this option. For example, set this value to nis to use the existing libnss_nis.so file.

8.2.5.2. Configuring an LDAP Domain

An LDAP domain is one where the id_provider option is set to ldap (id_provider = ldap). Such a domain requires a running LDAP server against which to authenticate. This can be an open source LDAP server such as OpenLDAP or Microsoft Active Directory. SSSD currently supports Microsoft Active Directory 2003 (+Services For UNIX) and Active Directory 2008 (+Subsystem for UNIX-based applications). In all cases, the client configuration is stored in the /etc/sssd/sssd.conf file.
How to Authenticate Against an LDAP Server
SSSD does not support authentication over an unencrypted channel. Consequently, if you want to authenticate against an LDAP server, either TLS/SSL, LDAPS, or LDAP+GSSAPI is required. If the LDAP server is used only as an identity provider, an encrypted channel is not needed.
Edit your /etc/sssd/sssd.conf file to reflect the following example:
# A native LDAP domain
[domain/LDAP]
enumerate = false
cache_credentials = TRUE

id_provider = ldap
auth_provider = ldap
ldap_schema = rfc2307
chpass_provider = ldap

ldap_uri = ldap://ldap.mydomain.org
ldap_search_base = dc=mydomain,dc=org
tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
Selecting an LDAP Schema
You can set the ldap_schema attribute to either rfc2307 or rfc2307bis. These schema define how groups in LDAP are specified. In RFC 2307, group objects use a multi-valued attribute, memberuid, which lists the names of the users that belong to that group. In RFC 2307bis, instead of the memberuid, group objects use the member attribute. Rather than just the name of the user, this attribute contains the full Distinguished Name (DN) of another object in the LDAP database. This means that groups can have other groups as members. That is, it adds support for nested groups.
SSSD assumes that your LDAP server is using RFC 2307. If your LDAP server is using RFC 2307bis, and you do not update the /etc/sssd/sssd.conf file accordingly, this can impact how your users and groups are displayed. It also means that some groups will not be available and network resources may be inaccessible even though you have permissions to use them.
For example, when using RFC 2307bis and you have configured both primary and secondary groups, or are using nested groups, you can use the id command to display these groups:
[f12server@ipaserver ~]$ id
uid=500(f12server) gid=500(f12server) groups=500(f12server),510(f12tester)
If instead you have configured your client to use RFC 2307 then only the primary group is displayed.
Changes to this setting only affect how SSSD determines the groups to which a user belongs; there is no negative effect on the actual user data. If you do not know the correct value for this attribute, consult your System Administrator.
Specifying Timeout Values
SSSD supports a number of timeout values that apply when configuring an LDAP domain. These are described below.
  • ldap_search_timeout (integer) — Specifies the timeout (in seconds) that LDAP searches are allowed to run before they are cancelled and cached results are returned (and offline mode is entered). If not specified:
    Defaults to five when enumerate = False
    Defaults to 30 when enumerate = True. This option is forced to a minimum of 30 in this case.

    Note

    This option is subject to change in future versions of SSSD, where it may be replaced by a series of timeouts for specific look-up types.
  • ldap_network_timeout (integer) — Specifies the timeout (in seconds) after which the poll(2)/select(2) following a connect(2) returns in case of no activity.
    If not specified, defaults to five.
  • ldap_opt_timeout (integer) — Specifies the timeout (in seconds) after which calls to synchronous LDAP APIs will abort if no response is received. This option also controls the timeout when communicating with the KDC in case of a SASL bind.
    If not specified, defaults to five.

8.2.5.3. Configuring a Microsoft Active Directory Domain

You can configure SSSD to use Microsoft Active Directory as an LDAP back end, providing both identity and authentication services. If you are using Active Directory 2003, SSSD requires that you install Windows Services for UNIX (SFU) on the machine where Active Directory is installed. If instead you are using Active Directory 2008, you need to install the Subsystem for UNIX-based Applications (SUA) on the Active Directory machine.

Note

SFU is not supported on 64-bit operating systems. Refer to http://support.microsoft.com/kb/920751 for more information about which Windows systems can provide a suitable platform for an SSSD LDAP back end.
8.2.5.3.1. Configuring Active Directory 2003 as an LDAP Back End
The example /etc/sssd/sssd.conf file that ships with SSSD contains the following sample configuration for Active Directory 2003:
# Example LDAP domain where the LDAP server is an Active Directory 2003 server.

[domain/AD]
description = LDAP domain with AD server
enumerate = false
min_id = 1000
;
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://your.ad.server.com
ldap_schema = rfc2307bis
ldap_search_base = dc=example,dc=com
ldap_default_bind_dn = cn=Administrator,cn=Users,dc=example,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = YOUR_PASSWORD
ldap_user_object_class = person
ldap_user_name = msSFU30Name
ldap_user_uid_number = msSFU30UidNumber
ldap_user_gid_number = msSFU30GidNumber
ldap_user_home_directory = msSFU30HomeDirectory
ldap_user_shell = msSFU30LoginShell
ldap_user_principal = userPrincipalName
ldap_group_object_class = group
ldap_group_name = msSFU30Name
ldap_group_gid_number = msSFU30GidNumber

Note

This configuration is specific to Windows Active Directory 2003. Refer to Section 8.2.5.3.2, “Configuring Active Directory 2003 R2 and 2008 as LDAP Back Ends” for information on how to configure Active Directory 2003 R2 and Active Directory 2008.

Note

The above configuration assumes that the certificates are stored in the default location (that is, in /etc/openldap/cacerts) and that the c_rehash function has been used to create the appropriate symlinks.
More Information
Refer to the sssd-ldap(5) manual page for a full description of all the options that apply to LDAP domains.
8.2.5.3.2. Configuring Active Directory 2003 R2 and 2008 as LDAP Back Ends
The configuration of /etc/sssd/sssd.conf to support Active Directory 2003 R2 or Active Directory 2008 as a back end is similar to that for AD 2003. The following example configuration highlights the necessary changes.
# Example LDAP domain where the LDAP server is an Active Directory 2003 R2 or an Active Directory 2008 server.

[domain/AD]
description = LDAP domain with AD server
; debug_level = 9
enumerate = false

id_provider = ldap
auth_provider = ldap
chpass_provider = ldap

ldap_uri = ldap://your.ad.server.com
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_tls_cacert = /etc/openldap/cacerts/test.cer
ldap_search_base = dc=example,dc=com
ldap_default_bind_dn = cn=Administrator,cn=Users,dc=example,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = YOUR_PASSWORD
ldap_pwd_policy = none
ldap_user_object_class = user
ldap_group_object_class = group

Note

The above configuration assumes that the certificates are stored in the default location (that is, in /etc/openldap/cacerts) and that the c_rehash function has been used to create the appropriate symlinks.

8.2.5.4. Configuring a Proxy Domain

SSSD currently only supports LDAP and Kerberos as authentication providers. If you prefer to use SSSD (for example, to take advantage of its caching functionality), but SSSD does not support your authentication method, you can set up a proxy authentication provider. This could be the case if you use fingerprint scanners or smart cards as part of your authentication process.
  • proxy_pam_target (string)
    This option is only used when the auth_provider option is set to proxy, and specifies the proxy target that PAM proxies to.
    This option has no default value. If proxy authentication is required, you need to specify your own PAM target. This corresponds to a file containing PAM stack information in the system's default PAM configuration directory. On Red Hat Enterprise Linux—based systems, this is the /etc/pam.d/ directory.

    Important

    Ensure that your proxy PAM stack does not recursively include pam_sss.so.
  • proxy_lib_name (string)
    This option is only used when the id_provider option is set to proxy, and specifies which existing NSS library to proxy identity requests through.
    This option has no default value. You need to manually specify an existing library to take advantage of this option. For example, set this value to nis to use the existing libnss_nis.so file.