Configuring an LDAP Domain

An LDAP domain simply means that SSSD uses an LDAP directory as the identity provider (and, optionally, also as an authentication provider). SSSD supports several major directory services:

CentOS Directory Server

OpenLDAP
Microsoft Active Directory 2003 and 2003R2, with Services for UNIX
Microsoft Active Directory 2003 and 2003R2, with Subsystem for UNIX-based Applications

DNS service discovery allows the LDAP backend to find the appropriate DNS servers to connect to automatically using a special DNS query.

"Parameters for Configuring an LDAP Domain"

Parameters for Configuring an LDAP Domain

An LDAP directory can function as both an identity provider and an authentication provider. The configuration requires enough information to identify and connect to the user directory in the LDAP server. Other options are available to provide more fine-grained control, like specifying a user account to use to connect to the LDAP server or using different LDAP servers for password operations. The most common options are listed in Table 28.5, "LDAP Domain Configuration Parameters". All of the options listed in "General Rules and Options for Configuring a Domain" are also available for LDAP domains.

Many other options are listed in the man page for LDAP domain configuration, sssd-ldap(5).

Table 28.5. LDAP Domain Configuration Parameters

try requests a certificate and proceeds normally if no certificate is given, If a bad certificate is given, the session terminates.

demand and hard are the same option. This requires a valid certificate or the session is terminated.The default is hard.

For example, with RFC 2307bis, all groups are returned when using nested groups or primary/secondary groups.

$ id
uid=500(myserver) gid=500(myserver) groups=500(myserver),510(myothergroup)

If SSSD is using RFC 2307 schema, only the primary group is returned.

This setting only affects how SSSD determines the group members. It does not change the actual user data.

allow requests a certificate, but proceeds normally even if no certificate is given or a bad certificate is given.

Parameter	Description
ldap_uri	Gives a comma-separated list of the URIs of the LDAP servers to which SSSD will connect. The list is given in order of preference, so the first server in the list is tried first. Listing additional servers provides failover protection. This can be detected from the DNS SRV records if it is not given.
ldap_search_base	Gives the base DN to use for performing LDAP user operations.
ldap_tls_reqcert	Specifies how to check for SSL server certificates in a TLS session. There are four options: never disables requests for certificates.
ldap_tls_cacert	Gives the full path and file name to the file that contains the CA certificates for all of the CAs that SSSD recognizes. SSSD will accept any certificate issued by these CAs. This uses the OpenLDAP system defaults if it is not given explicitly.
ldap_referrals	Sets whether SSSD will use LDAP referrals, meaning forwarding queries from one LDAP database to another. SSSD supports database-level and subtree referrals. For referrals within the same LDAP server, SSSD will adjust the DN of the entry being queried. For referrals that go to different LDAP servers, SSSD does an exact match on the DN. Setting this value to `true` enables referrals; by default, referrals are enabled.
ldap_schema	Sets what version of schema to use when searching for user entries. This can be either `rfc2307` or `rfc2307bis`. The default is `rfc2307`. 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, group objects use the `member` attribute, which contains the full distinguished name (DN) of a user or group entry. RFC 2307bis allows nested groups usning the `member` attribute. Because these different schema use different definitions for group membership, using the wrong LDAP schema with SSSD can affect both viewing and managing network resources, even if the appropriate permissions are in place.
ldap_search_timeout	Sets the time, in seconds, that LDAP searches are allowed to run before they are canceled and cached results are returned. This defaults to five when the `enumerate` value is false and defaults to 30 when `enumerate` is true. When an LDAP search times out, SSSD automatically switches to offline mode.
ldap_network_timeout	Sets the time, in seconds, SSSD attempts to poll an LDAP server after a connection attempt fails. The default is six seconds.
ldap_opt_timeout	Sets the time, in seconds, to wait before aborting synchronous LDAP operations if no response is received from the server. This option also controls the timeout when communicating with the KDC in case of a SASL bind. The default is five seconds.

LDAP Domain Examples

The LDAP configuration is very flexible, depending on your specific environment and how general or specific you need the SSSD behavior to be. These are some common examples of an LDAP domain, but the SSSD configuration is not limited to these examples.

Along with creating the domain entry, add the new domain to the list of domains for SSSD to query in the sssd.conf file. For example:

domains = LOCAL,LDAP1,AD,PROXYNIS

Example 28.1. A Basic LDAP Domain Configuration

An LDAP domain requires three things:

An LDAP server

The search base

A way to establish a secure connection

The last item depends on the LDAP environment. SSSD requires a secure connection since it handles sensitive information. This connection can be a dedicated TLS/SSL connection or it can use Start TLS.

Using a dedicated TLS/SSL connection simply uses an LDAPS connection to connect to the server and is therefore set as part of the ldap_uri option:

# An LDAP domain
[domain/LDAP]
enumerate = false
cache_credentials = TRUE
id_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://ldap.example.com:636
ldap_search_base = dc=example,dc=com

Using Start TLS requires a way to input the certificate information to establish a secure connection dynamically over an insecure port. This is done using the ldap_id_use_start_tls option to use Start TLS and then ldap_tls_cacert to identify the CA certificate which issued the SSL server certificates.

# An LDAP domain
[domain/LDAP]
enumerate = false
cache_credentials = TRUE
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://ldap.example.com
ldap_search_base = dc=example,dc=com
ldap_id_use_start_tls = True
ldap_tls_reqcert = demand
ldap_tls_cacert = /etc/pki/tls/certs/ca-bundle.crt

To configure any Active Directory server as an LDAP domain requires two things:

Installing Windows Services for UNIX (2003 and 2003 R2) or the Subsystem for UNIX-based Applications (2008).

Services for Unix is not supported on 64-bit operating systems.

Running the cacertdir_rehash function to create the appropriate symlinks.

Example 28.2. An Active Directory 2003 Domain

As with an OpenLDAP or Directory Server domain, Active Directory requires the search base and the LDAP URI of the Active Directory server, but SSSD requires more information about directory entries and the user account to use to connect because of the differences between an Active Directory-style database and an OpenLDAP/Directory Server-style database.

These options are described in the man page for LDAP domain configuration, sssd-ldap(5).

# Example LDAP domain where the LDAP server is an Active Directory 2003 server.
[domain/AD]
description = LDAP domain with AD server
enumerate = false
;
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 = secret
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

Example 28.3. A Basic Active Directory 2003 R2 or 2008 Domain

Configuring a Microsoft Active Directory 2003 R2 or 2008 domain is similar, but not identical, to configuring an Active Directory 2003 domain. Using later Active Directory servers requires less group configuration information.

These options are described in the man page for LDAP domain configuration, sssd-ldap(5).

# 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 = secret
ldap_pwd_policy = none
ldap_user_object_class = user
ldap_group_object_class = group

Using IP Addresses in Certificate Subject Names

Using an IP address in the ldap_uri option instead of the server name may cause the TLS/SSL connection to fail. TLS/SSL certificates contain the server name, not the IP address. However, the subject alternative name field in the certificate can be used to include the IP address of the server, which allows a successful secure connection using an IP address.

Convert an existing certificate into a certificate request. The signing key (-signkey) is the key of the issuer of whatever CA originally issued the certificate. If this is done by an external CA, it requires a separate PEM file; if the certificate is self-signed, then this is the certificate itself. For example:

openssl x509 -x509toreq -in old_cert.pem -out req.pem -signkey key.pem

With a self-signed certificate:

openssl x509 -x509toreq -in old_cert.pem -out req.pem -signkey old_cert.pem

Edit the /etc/pki/tls/openssl.cnf configuration file to include the server's IP address under the [ v3_ca ] section:
```
subjectAltName = IP:10.0.0.10
```
Use the generated certificate request to generate a new self-signed certificate with the specified IP address:
```
openssl x509 -req -in req.pem -out new_cert.pem -extfile ./openssl.cnf -extensions v3_ca -signkey old_cert.pem
```
The -extensions option sets which extensions to use with the certificate. For this, it should be v3_ca to load the appropriate section.
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.