9.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.
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.
9.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.
9.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).
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.
If a client has enumeration enabled, reinitialization of the client results in a complete refresh of the entire set of available users and groups from the remote source. Similarly, when SSSD is connected to a new server, the entire set of available users and groups from the remote source is pulled and cached on the local machine. In a domain with a large amount of clients connected to a remote source, both aforementioned cases can affect the network performance due to frequent queries from the clients. If the set of available users and groups is large enough, it will affect the performance of clients as well. 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 back end 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.
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:
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
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.
9.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 Fedora-based systems, this is the
/etc/pam.d/ directory.
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.
9.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.
SSSD does not support authentication over an unencrypted channel. Consequently, if you want to authenticate against an LDAP server, either TLS/SSL or LDAPS 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 include the following settings:
# 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
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt
If you wish to use an IP address in the ldap_uri option instead of the server name, for example, if GSSAPI is used to avoid time consuming DNS lookups, the TSL/SSL setup might fail. This is due to the fact that TSL/SSL certificates contain the server name only. However, a special field in the certificate, called Subject Alternative Name (subjectAltName), can be used to additionally set the IP address of the server.
The following steps show how to create a certificate with a Subject Alternative Name being the IP address of your server:
Using your command line, execute the following command to convert an existing certificate (previously signed by the key.pem key) into a certificate request:
openssl x509 -x509toreq -in old_cert.pem -out req.pem -signkey key.pem
Alternatively, if you are using a self-signed certificate(for example, one created by the Fedora OpenLDAP package in /etc/pki/tls/certs/slapd.pem), execute the following command:
openssl x509 -x509toreq -in old_cert.pem -out req.pem -signkey old_cert.pem
Edit your /etc/pki/tls/openssl.cnf configuration file to include the following line under the [ v3_ca ] section:
subjectAltName = IP:10.0.0.10
Replace the IP address with one of your choice.
By executing the following command, use the previously generated certificate request to generate a new self-signed certificate that will contain your desired IP address:
openssl x509 -req -in req.pem -out new_cert.pem -extfile ./openssl.cnf -extensions v3_ca -signkey old_cert.pem
where:
The openssl x509 command creates the new certificate.
The -req option tells the command to expect a certificate request as an input.
The -in and -out options specify the input and output files.
The -extfile option expects a file containing certificate extensions to use (in our case the subjectAltName extension).
The -extensions option specifies the section of the openssl.cnf file to add certificate extensions from (in this case, the [ v3_ca ] section).
The -signkey option tells the command to self-sign the input file using the supplied private key.
For more information on the x509 utility and its parameters, refer to man x509.
Lastly, copy the private key block from the old_cert.pem file into the new_cert.pem file to keep all relevant information in one file.
When creating a certificate through the certutil utility provided by the nss-utils package, note that certutil supports DNS subject alternative names for certificate creation only.
It is advisable to use a Certificate Authority to issue your certificate. Consider using the Red Hat Certificate System; for more information on managing subject names and subject alternative names in your certificate, refer to the
Red Hat Certificate System Admin Guide.
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.
The
DNS service discovery feature allows the LDAP back end to automatically find the appropriate
DNS servers to connect to using a special
DNS query. For more information on the
DNS service discovery feature, refer to
Section 9.2.3.2.4.1, “Using SRV Records with Failover”.
9.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.
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.
9.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 that 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.
9.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 that 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.
