SSSD-LDAP(5)

๐Ÿ’– NAME ๐Ÿ’–

sssd-ldap โ€” the SSSD LDAP provider ๐Ÿ’… welcome to SSSD-LDAP(5), bestie, you're gonna love it here โœจ


๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

okay so. this whole page is about configuring LDAP domains for sssd(8) ๐Ÿ’œ if you want the full syntax tea, hop over to the โ€œFILE FORMATโ€ section of the sssd.conf(5) manual page, mwah ๐Ÿซถ

and yes โ€” you can configure SSSD to use more than one LDAP domain. iconic behavior, honestly ๐Ÿ‘‘

the LDAP back end supports the id, auth, access and chpass providers. now here's the part where you gotta listen, bestie ๐Ÿ“: if you want to authenticate against an LDAP server, either TLS/SSL or LDAPS is required. sssd does NOT support authentication over an unencrypted channel. periodt. ๐Ÿ’€ even if the LDAP server is used only as an identity provider, an encrypted channel is strongly recommended โ€” do not skip this. please refer to the โ€œldap_access_filterโ€ config option for more info about using LDAP as an access provider ๐Ÿ’–


โœจ CONFIGURATION OPTIONS โœจ

all the common configuration options that apply to SSSD domains also apply to LDAP domains, fr fr. refer to the โ€œDOMAIN SECTIONSโ€ section of the sssd.conf(5) manual page for the full details. also!! just so you know โ€” SSSD LDAP mapping attributes are described in the sssd-ldap-attributes(5) manual page ๐ŸŽ€


  • ldap_uri, ldap_backup_uri (string) โ€” specifies the comma-separated list of URIs of the LDAP servers to which SSSD should connect, in the order of preference ๐Ÿซถ refer to the โ€œFAILOVERโ€ section for the full deets on failover and server redundancy. if neither option is specified, service discovery is enabled โ€” more on that in the โ€œSERVICE DISCOVERYโ€ section ๐Ÿ‘€

the format of the URI must match the format defined in RFC 2732:

ldap[s]://<host>[:port]

for explicit IPv6 addresses, <host> must be enclosed in brackets [] โœจ

example: ldap://[fc00::126:25]:389

  • ldap_chpass_uri, ldap_chpass_backup_uri (string) โ€” specifies the comma-separated list of URIs of the LDAP servers to which SSSD should connect, in the order of preference, to change the password of a user ๐Ÿ” refer to the โ€œFAILOVERโ€ section for more on failover and server redundancy.

to enable service discovery, ldap_chpass_dns_service_name must be set ๐Ÿ‘€

Default: empty, i.e. ldap_uri is used.

  • ldap_search_base (string) โ€” the default base DN to use for performing LDAP user operations ๐Ÿ’…

starting with SSSD 1.7.0, SSSD supports multiple search bases using this syntax:

search_base[?scope?[filter][?search_base?scope?[filter]]*]

the scope can be one of base, onelevel or subtree.

the filter must be a valid LDAP search filter as specified by http://www.ietf.org/rfc/rfc2254.txt ๐Ÿ“œ

Examples:

ldap_search_base = dc=example,dc=com (which is equivalent to)
ldap_search_base = dc=example,dc=com?subtree?
ldap_search_base = cn=host_specific,dc=example,dc=com?subtree?(host=thishost)?dc=example.com?subtree?
Note: it is unsupported to have multiple search bases which reference identically-named objects (for example, groups with the same name in two different search bases). this will lead to unpredictable behavior on client machines. not the vibe, bestie ๐Ÿ™ˆ

Default: if not set, the value of the defaultNamingContext or namingContexts attribute from the RootDSE of the LDAP server is used. if defaultNamingContext does not exist or has an empty value, namingContexts is used. the namingContexts attribute must have a single value with the DN of the search base of the LDAP server to make this work. multiple values are not supported.

  • ldap_read_rootdse (string) โ€” SSSD reads RootDSE to get info about LDAP and its capabilities ๐Ÿ” by default this is done anonymously. however, the LDAP server might not permit that ๐Ÿ˜ญ and in such cases we can use this option to influence SSSD behavior.

allowed values are:

  • anonymous
  • authenticated
  • never

by default, using the "anonymous" option, SSSD tries to read RootDSE anonymously. if this fails, SSSD retries the attempt with authentication ๐Ÿซถ

Default: anonymous

  • ldap_schema (string) โ€” specifies the Schema Type in use on the target LDAP server. depending on the selected schema, the default attribute names retrieved from the servers may vary, and the way some attributes are handled may also differ ๐Ÿ‘€

four schema types are currently supported:

  • rfc2307
  • rfc2307bis
  • IPA
  • AD

the main difference between these schema types is how group memberships are recorded in the server. with rfc2307, group members are listed by name in the memberUid attribute. with rfc2307bis and IPA, group members are listed by DN and stored in the member attribute. the AD schema type sets the attributes to correspond with Active Directory 2008r2 values.

Default: rfc2307

  • ldap_pwmodify_mode (string) โ€” specify the operation that is used to modify user password ๐Ÿ”

two modes are currently supported:

  • exop โ€” Password Modify Extended Operation (RFC 3062)
  • ldap_modify โ€” Direct modification of userPassword (not recommended)
  • exop_force โ€” Try Password Modify Extended Operation (RFC 3062) even if there are no grace logins left. depending on the type and configuration of the LDAP server, the password change might fail because an authenticated bind is not possible.
Note: first, a new connection is established to verify the current password by binding as the user that requested the password change. if successful, this connection is used to change the password, therefore the user must have write access to the userPassword attribute ๐Ÿ‘‘

Default: exop

  • ldap_default_bind_dn (string) โ€” the default bind DN to use for performing LDAP operations ๐Ÿซถ
  • ldap_default_authtok_type (string) โ€” the type of the authentication token of the default bind DN.

the two mechanisms currently supported are:

  • password
  • obfuscated_password

Default: password

see the sss_obfuscate(8) manual page for more information ๐Ÿ’…

  • ldap_default_authtok (string) โ€” the authentication token of the default bind DN.
  • ldap_force_upper_case_realm (boolean) โ€” some directory servers, for example Active Directory, might deliver the realm part of the UPN in lower case, which might cause the authentication to fail ๐Ÿ˜ญ set this option to a non-zero value if you want to use an upper-case realm.

Default: false

  • ldap_enumeration_refresh_timeout (integer) โ€” specifies how many seconds SSSD has to wait before refreshing its cache of enumerated records โณ

Default: 300

  • ldap_purge_cache_timeout (integer) โ€” determine how often to check the cache for inactive entries (like groups with no members and users who have never logged in) and remove them to save space ๐Ÿงน

setting this option to zero will disable the cache cleanup operation. please note that if enumeration is enabled, the cleanup task is required in order to detect entries removed from the server and can't be disabled. by default, the cleanup task will run every 3 hours with enumeration enabled.

this option can be also set per subdomain or inherited via subdomain_inherit.

Default: 0 (disabled)

  • ldap_group_nesting_level (integer) โ€” if ldap_schema is set to a schema format that supports nested groups (e.g. RFC2307bis), then this option controls how many levels of nesting SSSD will follow ๐Ÿช† this option has no effect on the RFC2307 schema.
Note: this option specifies the guaranteed level of nested groups to be processed for any lookup. however, nested groups beyond this limit may be returned if previous lookups already resolved the deeper nesting levels. also, subsequent lookups for other groups may enlarge the result set for the original lookup if re-queried. ๐Ÿ™ˆ

if ldap_group_nesting_level is set to 0 then no nested groups are processed at all. however, when connected to Active-Directory Server 2008 and later using id_provider=ad, it is furthermore required to disable usage of Token-Groups by setting ldap_use_tokengroups to false in order to restrict group nesting.

Default: 2

  • ldap_use_tokengroups โ€” this option enables or disables use of the Token-Groups attribute when performing initgroup for users from Active Directory Server 2008 and later ๐Ÿ‘‘

this option can be also set per subdomain or inherited via subdomain_inherit.

Default: True for AD and IPA otherwise False.

  • ldap_host_search_base (string) โ€” optional ๐ŸŽ€ use the given string as search base for host objects.

see โ€œldap_search_baseโ€ for information about configuring multiple search bases.

Default: the value of ldap_search_base

  • ldap_subid_ranges_search_base (string) โ€” optional ๐ŸŽ€ use the given string as search base for subordinate ranges related objects.

Default: the value of cn=subids,%basedn for IPA otherwise ldap_search_base.

  • ldap_service_search_base (string) โ€” an optional base DN, search scope and LDAP filter to restrict LDAP searches for this attribute type.

syntax:

search_base[?scope?[filter][?search_base?scope?[filter]]*]

the scope can be one of base, onelevel or subtree. the scope functions as specified in section 4.5.1.2 of http://tools.ietf.org/html/rfc4511 ๐Ÿ“œ

the filter must be a valid LDAP search filter as specified by http://www.ietf.org/rfc/rfc2254.txt

for examples of this syntax, please refer to the โ€œldap_search_baseโ€ examples section.

Default: the value of ldap_search_base

please note that specifying scope or filter is not supported for searches against an Active Directory Server that might yield a large number of results and trigger the Range Retrieval extension in the response ๐Ÿ‘€

  • ldap_iphost_search_base (string) โ€” an optional base DN, search scope and LDAP filter to restrict LDAP searches for this attribute type.

syntax:

search_base[?scope?[filter][?search_base?scope?[filter]]*]

the scope can be one of base, onelevel or subtree. the scope functions as specified in section 4.5.1.2 of http://tools.ietf.org/html/rfc4511

the filter must be a valid LDAP search filter as specified by http://www.ietf.org/rfc/rfc2254.txt

for examples of this syntax, please refer to the โ€œldap_search_baseโ€ examples section.

Default: the value of ldap_search_base

heads up bestie โ€” if you're searching an Active Directory server that might yeet a huge pile of results back at you and trigger the Range Retrieval extension in the response, then specifying a scope or a filter is not supported. Fr fr, don't do it. ๐Ÿ’€

  • ldap_ipnetwork_search_base (string) โ€” an optional base DN, search scope and LDAP filter situation to keep LDAP searches for this attribute type on a leash. ๐Ÿฆ‹

the syntax is giving:

search_base[?scope?[filter][?search_base?scope?[filter]]*]

scope can be one of base, onelevel or subtree. It does exactly what section 4.5.1.2 of http://tools.ietf.org/html/rfc4511 says it does, no cap.

the filter has to be a legit LDAP search filter, as specified by http://www.ietf.org/rfc/rfc2254.txt โœจ

for examples of this syntax, go peek at the โ€œldap_search_baseโ€ examples section, it's all there.

Default: the value of ldap_search_base

again bestie, listen โ€” specifying scope or filter is not supported for searches against an Active Directory Server that might yield a large number of results and trigger the Range Retrieval extension in the response. ๐Ÿ’…
  • ldap_search_timeout (integer) โ€” how long (in seconds) ldap searches are allowed to run before they get cancelled and cached results get returned instead (and, yep, you slide into offline mode). ๐Ÿ˜ญ
Note: this option is subject to change in future versions of the SSSD. It will likely be replaced at some point by a series of timeouts for specific lookup types. So don't get too attached. ๐Ÿ™ˆ

You can also set this per subdomain, or inherit it via subdomain_inherit.

Default: 6

  • ldap_enumeration_search_timeout (integer) โ€” the timeout (in seconds) that ldap searches for user and group enumerations are allowed to run before they're cancelled, cached results come back, and offline mode enters the chat.

Default: 60

  • ldap_network_timeout (integer) โ€” the timeout (in seconds) after which the poll(2)/select(2) following a connect(2) just returns if nothing's happening. no activity, no waiting. โœ‹

You can also set this per subdomain, or inherit it via subdomain_inherit.

Default: 6

  • ldap_opt_timeout (integer) โ€” a timeout (in seconds) after which calls to synchronous LDAP APIs will abort if no response is received. It also runs the timeout when talking to the KDC in case of SASL bind, plus the timeout of an LDAP bind operation, password change extended operation and the StartTLS operation. she does it all. ๐Ÿ‘‘

You can also set this per subdomain, or inherit it via subdomain_inherit.

Default: 8

  • ldap_connection_expire_timeout (integer) โ€” how long (in seconds) a connection to an LDAP server gets maintained. After that time, the connection gets re-established. If you're running this in parallel with SASL/GSSAPI, whichever of the two values is sooner (this value vs. the TGT lifetime) wins. ๐Ÿ

If the connection is idle (not actively running an operation) within ldap_opt_timeout seconds of expiration, then it will be closed early to make sure a new query can't require the connection to stay open past its expiration. This implies that connections will always be closed immediately and will never be reused if ldap_connection_expire_timeout <= ldap_opt_timout

This timeout can be extended of a random value specified by ldap_connection_expire_offset

You can also set this per subdomain, or inherit it via subdomain_inherit.

Default: 900 (15 minutes) โฐ

  • ldap_connection_expire_offset (integer) โ€” a random offset between 0 and the configured value gets added to ldap_connection_expire_timeout. keeps things spicy. ๐ŸŒˆ

You can also set this per subdomain, or inherit it via subdomain_inherit.

Default: 0

  • ldap_connection_idle_timeout (integer) โ€” a timeout (in seconds) that an idle connection to an LDAP server will be maintained. If the connection sits idle for longer than this, it gets closed. bye bestie ๐Ÿ‘‹

You can disable this timeout by setting the value to 0.

You can also set this per subdomain, or inherit it via subdomain_inherit.

Default: 900 (15 minutes)

  • ldap_page_size (integer) โ€” how many records to grab from LDAP in a single request. Some LDAP servers enforce a maximum limit per-request, so mind your business accordingly.

Default: 1000

  • ldap_disable_paging (boolean) โ€” turns off the LDAP paging control. Use this if the LDAP server claims in its RootDSE that it supports the LDAP paging control but it's not enabled or it doesn't behave properly. basically it's lying. ๐Ÿ’€

Example: OpenLDAP servers with the paging control module installed on the server but not enabled will report it in the RootDSE but be unable to use it.

Example: 389 DS has a bug where it can only support a one paging control at a time on a single connection. On busy clients, this can result in some requests being denied.

Default: False

  • ldap_disable_range_retrieval (boolean) โ€” turns off Active Directory range retrieval.

Active Directory limits the number of members that can be retrieved in a single lookup using the MaxValRange policy, which defaults to 1500 members. If a group contains more than 1500 members, the reply includes an AD-specific range extension. When enabled, this option stops SSSD from parsing the range extension. As a result, large groups will appear as they have no members. ๐Ÿ˜ญ This option does not enable SSSD to read subsequent ranges. To retrieve all members of a group, you must increase the MaxValRange setting in Active Directory. That's the only way, periodt.

Default: False

  • ldap_sasl_minssf (integer) โ€” when you're communicating with an LDAP server using SASL, this specifies the minimum security level necessary to establish the connection. The values of this option are defined by OpenLDAP.

Default: Use the system default (usually specified by ldap.conf)

  • ldap_sasl_maxssf (integer) โ€” when communicating with an LDAP server using SASL, this specifies the maximal security level necessary to establish the connection. The values of this option are defined by OpenLDAP.

Default: Use the system default (usually specified by ldap.conf)

  • ldap_deref_threshold (integer) โ€” how many group members must be missing from the internal cache before a dereference lookup gets triggered. If fewer members are missing than that, they just get looked up individually. โœจ

You can turn off dereference lookups completely by setting the value to 0. But bestie, please note that there are some codepaths in SSSD, like the IPA HBAC provider, that are only implemented using the dereference call โ€” so even with dereference explicitly disabled, those parts will still use dereference if the server supports it and advertises the dereference control in the rootDSE object. she said "not today". ๐Ÿ™ˆ

A dereference lookup is a means of fetching all group members in a single LDAP call. Different LDAP servers may implement different dereference methods. The currently supported servers are 389/RHDS, OpenLDAP and Active Directory. ๐Ÿ‘‘

Note: If any of the search bases specifies a search filter, then the dereference lookup performance enhancement will be disabled regardless of this setting. so annoying honestly.

Default: 10

  • ldap_ignore_unreadable_references (bool) โ€” ignore unreadable LDAP entries referenced in group's member attribute. If this parameter is set to false, an error will be returned and the operation will fail instead of just ignoring the unreadable entry. ๐Ÿซถ

This parameter may be useful when using the AD provider and the computer account that sssd uses to connect to AD does not have access to a particular entry or LDAP sub-tree for security reasons.

Default: False

  • ldap_tls_reqcert (string) โ€” what checks to perform on server certificates in a TLS session, if any. It can be specified as one of the following values:
    • never โ€” The client will not request or check any server certificate. living dangerously, no thoughts head empty.
    • allow โ€” The server certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, it will be ignored and the session proceeds normally.
    • try โ€” The server certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, the session is immediately terminated. โœ‹
    • demand โ€” The server certificate is requested. If no certificate is provided, or a bad certificate is provided, the session is immediately terminated.
    • hard โ€” Same as โ€œdemandโ€

Default: hard

  • ldap_tls_cacert (string) โ€” the file that contains certificates for all of the Certificate Authorities that sssd will recognize. ๐ŸŽ€

Default: use OpenLDAP defaults, typically in /etc/openldap/ldap.conf

  • ldap_tls_cacertdir (string) โ€” the path of a directory that contains Certificate Authority certificates in separate individual files. Typically the file names need to be the hash of the certificate followed by '.0'. If available, openssl rehash or c_rehash can be used to create the correct names. ๐ŸŒธ

Default: use OpenLDAP defaults, typically in /etc/openldap/ldap.conf

  • ldap_tls_cert (string) โ€” the file that contains the certificate for the client's key.

Default: not set

  • ldap_tls_key (string) โ€” the file that contains the client's key. ๐Ÿ”‘

Default: not set

  • ldap_tls_cipher_suite (string) โ€” acceptable cipher suites. Typically this is a colon separated list. See ldap.conf(5) for format.

Default: use OpenLDAP defaults, typically in /etc/openldap/ldap.conf

  • ldap_id_use_start_tls (boolean) โ€” specifies that the id_provider connection must also use tls to protect the channel. true is strongly recommended for security reasons, and I mean strongly. ๐Ÿ’…

Default: true

  • ldap_id_mapping (boolean) โ€” specifies that SSSD should attempt to map user and group IDs from the ldap_user_objectsid and ldap_group_objectsid attributes instead of relying on ldap_user_uid_number and ldap_group_gid_number. ๐Ÿฆ‹

Currently this feature supports only ActiveDirectory objectSID mapping.

Default: false

  • ldap_min_id, ldap_max_id (integer) โ€” okay so when ldap_id_mapping is set to true, you get SID-based ID mapping, and the allowed ID range for ldap_user_uid_number and ldap_group_gid_number is unbound. But in a setup with sub/trusted-domains, that might lead to ID collisions. To avoid collisions, you can set ldap_min_id and ldap_max_id to restrict the allowed range for IDs read directly from the server. Then sub-domains can pick other ranges to map IDs. ๐Ÿ’…

Default: not set (both options are set to 0)

  • ldap_sasl_mech (string) โ€” specify the SASL mechanism to use. Currently only GSSAPI and GSS-SPNEGO are tested and supported. No cap.

If the backend supports sub-domains, the value of ldap_sasl_mech is automatically inherited to the sub-domains. If a different value is needed for a sub-domain, it can be overwritten by setting ldap_sasl_mech for this sub-domain explicitly. Please see TRUSTED DOMAIN SECTION in sssd.conf(5) for details.

Default: not set

  • ldap_sasl_authid (string) โ€” specify the SASL authorization id to use. When GSSAPI/GSS-SPNEGO are used, this represents the Kerberos principal used for authentication to the directory. This option can either contain the full principal (for example host/myhost@EXAMPLE.COM) or just the principal name (for example host/myhost). By default, the value is not set and the following principals are used:
hostname@REALM
netbiosname$@REALM
host/hostname@REALM
*$@REALM
host/*@REALM
netbiosname$@*
host/*

If none of them are found, the first principal in keytab is returned.

Default: host/hostname@REALM

  • ldap_sasl_realm (string) โ€” specify the SASL realm to use. When not specified, this option defaults to the value of krb5_realm. If the ldap_sasl_authid contains the realm as well, this option is ignored. iykyk

Default: the value of krb5_realm.

  • ldap_sasl_canonicalize (boolean) โ€” if set to true, the LDAP library would perform a reverse lookup to canonicalize the host name during a SASL bind.

Default: false;

  • ldap_krb5_keytab (string) โ€” specify the keytab to use when using SASL/GSSAPI/GSS-SPNEGO.

This option can be also set per subdomain or inherited via subdomain_inherit.

Default: System keytab, normally /etc/krb5.keytab

  • ldap_krb5_init_creds (boolean) โ€” specifies that the id_provider should init Kerberos credentials (TGT). This action is performed only if SASL is used and the mechanism selected is GSSAPI or GSS-SPNEGO.

Default: true

  • ldap_krb5_ticket_lifetime (integer) โ€” specifies the lifetime in seconds of the TGT if GSSAPI or GSS-SPNEGO is used.

This option can be also set per subdomain or inherited via subdomain_inherit.

Default: 86400 (24 hours)

  • krb5_server, krb5_backup_server (string) โ€” specifies the comma-separated list of IP addresses or hostnames of the Kerberos servers to which SSSD should connect in the order of preference. For more information on failover and server redundancy, see the โ€œFAILOVERโ€ section. An optional port number (preceded by a colon) may be appended to the addresses or hostnames. If empty, service discovery is enabled โ€” for more information, refer to the โ€œSERVICE DISCOVERYโ€ section. โœจ

When using service discovery for KDC or kpasswd servers, SSSD first searches for DNS entries that specify _udp as the protocol and falls back to _tcp if none are found.

This option was named โ€œkrb5_kdcipโ€ in earlier releases of SSSD. While the legacy name is recognized for the time being, users are advised to migrate their config files to use โ€œkrb5_serverโ€ instead.

  • krb5_realm (string) โ€” specify the Kerberos REALM (for SASL/GSSAPI/GSS-SPNEGO auth).

Default: System defaults, see /etc/krb5.conf

  • krb5_canonicalize (boolean) โ€” specifies if the host principal should be canonicalized when connecting to LDAP server. This feature is available with MIT Kerberos >= 1.7

Default: false

  • krb5_use_kdcinfo (boolean) โ€” specifies if the SSSD should instruct the Kerberos libraries what realm and which KDCs to use. This option is on by default, if you disable it, you need to configure the Kerberos library using the krb5.conf(5) configuration file.

See the sssd_krb5_locator_plugin(8) manual page for more information on the locator plugin.

Default: true

  • ldap_pwd_policy (string) โ€” select the policy to evaluate the password expiration on the client side. The following values are allowed:
    • none โ€” No evaluation on the client side. This option cannot disable server-side password policies.
    • shadow โ€” Use shadow(5) style attributes to evaluate if the password has expired. Please see option ldap_chpass_update_last_change as well.
    • mit_kerberos โ€” Use the attributes used by MIT Kerberos to determine if the password has expired. Use chpass_provider=krb5 to update these attributes when the password is changed.

Default: none

Note: if a password policy is configured on server side, it always takes precedence over policy set with this option. periodt.

  • ldap_referrals (boolean) โ€” specifies whether automatic referral chasing should be enabled.

Please note that sssd only supports referral chasing when it is compiled with OpenLDAP version 2.4.13 or higher.

Chasing referrals may incur a performance penalty in environments that use them heavily, a notable example is Microsoft Active Directory. If your setup does not in fact require the use of referrals, setting this option to false might bring a noticeable performance improvement. Setting this option to false is therefore recommended in case the SSSD LDAP provider is used together with Microsoft Active Directory as a backend. Even if SSSD would be able to follow the referral to a different AD DC no additional data would be available.

Default: true

  • ldap_dns_service_name (string) โ€” specifies the service name to use when service discovery is enabled.

Default: ldap

  • ldap_chpass_dns_service_name (string) โ€” specifies the service name to use to find an LDAP server which allows password changes when service discovery is enabled.

Default: not set, i.e. service discovery is disabled

  • ldap_chpass_update_last_change (bool) โ€” specifies whether to update the ldap_user_shadow_last_change attribute with days since the Epoch after a password change operation.

It is recommended to set this option explicitly if "ldap_pwd_policy = shadow" is used to let SSSD know if the LDAP server will update shadowLastChange LDAP attribute automatically after a password change or if SSSD has to update it.

Default: False

  • ldap_access_filter (string) โ€” if using access_provider = ldap and ldap_access_order = filter (default), this option is mandatory. It specifies an LDAP search filter criteria that must be met for the user to be granted access on this host. If access_provider = ldap, ldap_access_order = filter and this option is not set, it will result in all users being denied access. Use access_provider = permit to change this default behavior. Please note that this filter is applied on the LDAP user entry only and thus filtering based on nested groups may not work (e.g. memberOf attribute on AD entries points only to direct parents). If filtering based on nested groups is required, please see sssd-simple(5). mandatory, no cap.

Example:

access_provider = ldap
ldap_access_filter = (employeeType=admin)

This example means that access to this host is restricted to users whose employeeType attribute is set to "admin".

Offline caching for this feature is limited to determining whether the user's last online login was granted access permission. If they were granted access during their last login, they will continue to be granted access while offline and vice versa.

Default: Empty

  • ldap_account_expire_policy (string) โ€” with this option a client side evaluation of access control attributes can be enabled.

Please note that it is always recommended to use server side access control, i.e. the LDAP server should deny the bind request with a suitable error code even if the password is correct. This is important!

The following values are allowed:

  • shadow: use the value of ldap_user_shadow_expire to determine if the account is expired.
  • ad: use the value of the 32bit field ldap_user_ad_user_account_control and allow access if the second bit is not set. If the attribute is missing access is granted. Also the expiration time of the account is checked.
  • rhds, ipa, 389ds: use the value of ldap_ns_account_lock to check if access is allowed or not.
  • nds: the values of ldap_user_nds_login_allowed_time_map, ldap_user_nds_login_disabled and ldap_user_nds_login_expiration_time are used to check if access is allowed. If both attributes are missing access is granted.

Please note that the ldap_access_order configuration option must include โ€œexpireโ€ in order for the ldap_account_expire_policy option to work.

Default: Empty

  • ldap_access_order (string) โ€” comma separated list of access control options. Allowed values are:
    • filter: use ldap_access_filter
    • lockout: use account locking. If set, this option denies access in case that ldap attribute 'pwdAccountLockedTime' is present and has value of '000001010000Z'. Please see the option ldap_pwdlockout_dn. Please note that 'access_provider = ldap' must be set for this feature to work.

Please note that this option is superseded by the โ€œppolicyโ€ option and might be removed in a future release.

  • ppolicy: use account locking. If set, this option denies access in case that ldap attribute 'pwdAccountLockedTime' is present and has value of '000001010000Z' or represents any time in the past. The value of the 'pwdAccountLockedTime' attribute must end with 'Z', which denotes the UTC time zone. Other time zones are not currently supported and will result in "access-denied" when users attempt to log in. Please see the option ldap_pwdlockout_dn. Please note that 'access_provider = ldap' must be set for this feature to work.
  • expire: use ldap_account_expire_policy
  • pwd_expire_policy_reject, pwd_expire_policy_warn, pwd_expire_policy_renew โ€” okay so these three are for when your users are logging in with something that isn't a password (think SSH keys, bestie) but they still deserve a lil heads up that their password is about to expire ๐Ÿ’…

All three are about the same situation โ€” user's password is expired โ€” but they do different things:

  • pwd_expire_policy_reject โ€” user is denied to log in. blocked. no entry. ๐Ÿ’€
  • pwd_expire_policy_warn โ€” user is still able to log in, just gets the warning โœจ
  • pwd_expire_policy_renew โ€” user is prompted to change their password immediately ๐Ÿ”ฅ
Heads up bestie: for this whole feature to work you must have access_provider = ldap set. And ldap_pwd_policy has to be shadow or mit_kerberos โ€” these options literally do not work with server-side password policies. periodt.

So the next chunk is the access-control check types you can throw in the list:

  • authorized_service โ€” use the authorizedService attribute to determine access ๐Ÿ‘‘
  • host โ€” use the host attribute to determine access ๐Ÿ 
  • rhost โ€” use the rhost attribute to determine whether remote host can access ๐ŸŒ
ngl about rhost: the rhost field in pam is set by the application, so before you turn this access control option on, it's genuinely better to go check what your application actually sends to pam. vibe check your app first, fr fr ๐Ÿ™ˆ

Default: filter

Also!! It is a configuration error if a value is used more than once. Not me finding out the hard way ๐Ÿ˜ญ

๐Ÿ” ldap_pwdlockout_dn (string)

This one is the DN of the password policy entry on the LDAP server. And listen โ€” if you've got account lockout checking enabled but this option is missing from sssd.conf, you get access denied, because the ppolicy attributes on the LDAP server can't be checked properly. it's giving locked out for no reason ๐Ÿ˜ญ

Example: cn=ppolicy,ou=policies,dc=example,dc=com

Default: cn=ppolicy,ou=policies,$ldap_search_base


๐Ÿฆ‹ ldap_deref (string)

This tells SSSD how alias dereferencing goes down when it's performing a search. Here's the menu, pick your fighter:

  • never โ€” Aliases are never dereferenced. just. no. ๐Ÿ™…
  • searching โ€” Aliases are dereferenced in subordinates of the base object, but not in locating the base object of the search.
  • finding โ€” Aliases are only dereferenced when locating the base object of the search.
  • always โ€” Aliases are dereferenced both in searching and in locating the base object of the search. go big or go home โœจ

Default: Empty (this is handled as never by the LDAP client libraries)


๐ŸŒธ ldap_rfc2307_fallback_to_local_users (boolean)

Okay so this one lets you keep local users as members of an LDAP group, for servers using the RFC2307 schema. super specific, i know, but stay with me ๐Ÿซถ

Here's the tea: in some environments using RFC2307, local users get made members of LDAP groups by adding their names to the memberUid attribute. But that compromises the self-consistency of the domain ๐Ÿ˜ฌ so SSSD would normally yeet those "missing" users out of the cached group memberships the second nsswitch tries to fetch info about the user via getpw*() or initgroups() calls.

This option instead falls back to checking whether local users are referenced, and caches them โ€” so that later initgroups() calls will augment the local users with the additional LDAP groups. iconic behaviour honestly ๐Ÿ’…

Default: false


๐ŸŽ€ wildcard_limit (integer)

Sets an upper limit on how many entries get downloaded during a wildcard lookup.

At the moment, only the InfoPipe responder supports wildcard lookups. just the one. the chosen one. ๐Ÿ‘‘

Default: 1000 (often the size of one page)


๐Ÿ’œ ldap_library_debug_level (integer)

Switches on libldap debugging at the level you give it. Important: the libldap debug messages get written independent of the general debug_level. they do not care. they're their own thing ๐Ÿ”ฅ

OpenLDAP uses a bitmap to enable debugging for specific components, so -1 will enable full debug output. everything. all of it. ๐ŸŒˆ

Default: 0 (libldap debugging disabled)


โœจ ldap_use_ppolicy (boolean)

Turns on requesting and relying on the server-side password policy controls.

Disabling this lets you interact with services that send back an invalid ppolicy extension. sometimes you gotta work with what you've got ๐Ÿ™ˆ

Default: true


๐Ÿ“ ldap_ppolicy_pwd_change_threshold (integer)

This forces a password change when server side password policy controls are enabled and the remaining grace logins returned by the server after authentication reach or go below the threshold. lowkey dramatic but necessary.

Note that the minimum useful value is 2, because changing the password consumes 2 additional grace logins โ€” one to verify the current password and a second one to perform the password change. math is math ๐Ÿ’€

Default: 0


๐Ÿ‘‘ SUDO OPTIONS ๐Ÿ‘‘

The detailed instructions for configuration of sudo_provider live over in the manual page sssd-sudo(5). go read that one too bestie ๐Ÿซถ


๐Ÿ”ฅ ldap_sudo_full_refresh_interval (integer)

How many seconds SSSD will wait between executing a full refresh of sudo rules โ€” which downloads all rules that are stored on the server. the whole entire thing.

The value must be greater than ldap_sudo_smart_refresh_interval.

You can disable full refresh by setting this option to 0. BUT โ€” either smart or full refresh must be enabled. you cannot have neither. pick one, bestie ๐Ÿ’…

Default: 21600 (6 hours)


๐ŸŒˆ ldap_sudo_smart_refresh_interval (integer)

How many seconds SSSD has to wait before executing a smart refresh of sudo rules โ€” which downloads all rules that have a USN higher than the highest server USN value that is currently known by SSSD. so like, only the new stuff โœจ

If USN attributes are not supported by the server, the modifyTimestamp attribute is used instead.

Note: the highest USN value can be updated by three tasks: 1. By sudo full and smart refresh (if updated rules are found) 2. by enumeration of users and groups (if enabled and updated users or groups are found) 3. by reconnecting to the server (by default every 15 minutes, see ldap_connection_expire_timeout).

You can disable smart refresh by setting this option to 0. However โ€” again โ€” either smart or full refresh must be enabled ๐Ÿซ 

Default: 900 (15 minutes)


๐Ÿฆ‹ ldap_sudo_random_offset (integer)

A random offset between 0 and the configured value gets added to the smart and full refresh periods each time the periodic task is scheduled. The value is in seconds.

Note that this random offset is also applied on the first SSSD start, which delays the first sudo rules refresh. This prolongs the time when the sudo rules are not available for use. so like, patience ๐Ÿงš

You can disable this offset by setting the value to 0.

Default: 0 (disabled)


๐Ÿ’– ldap_sudo_use_host_filter (boolean)

If true, SSSD will download only rules that are applicable to this machine โ€” using the IPv4 or IPv6 host/network addresses and hostnames. only the relevant ones, we don't do clutter here ๐Ÿ’…

Default: true


๐ŸŒธ ldap_sudo_hostnames (string)

A space separated list of hostnames or fully qualified domain names that should be used to filter the rules.

If this option is empty, SSSD will try to discover the hostname and the fully qualified domain name automatically. it's got this, don't worry ๐Ÿซถ

If ldap_sudo_use_host_filter is false then this option has no effect.

Default: not specified


๐ŸŽ€ ldap_sudo_ip (string)

A space separated list of IPv4 or IPv6 host/network addresses that should be used to filter the rules.

If this option is empty, SSSD will try to discover the addresses automatically.

If ldap_sudo_use_host_filter is false then this option has no effect.

Default: not specified


๐Ÿ’œ ldap_sudo_include_netgroups (boolean)

If true then SSSD will download every rule that contains a netgroup in the sudoHost attribute.

If ldap_sudo_use_host_filter is false then this option has no effect.

Default: true


๐Ÿ“ ldap_sudo_include_regexp (boolean)

If true then SSSD will download every rule that contains a wildcard in the sudoHost attribute.

If ldap_sudo_use_host_filter is false then this option has no effect.

Note โ€” Using wildcard is an operation that is very costly to evaluate on the LDAP server side! not me casually melting the LDAP server ๐Ÿ’€๐Ÿ”ฅ

Default: false


This manual page only describes attribute name mapping. For a detailed explanation of sudo related attribute semantics, see sudoers.ldap(5). iykyk ๐Ÿ“–


๐ŸŒŸ AUTOFS OPTIONS ๐ŸŒŸ

Some of the defaults for the parameters below are dependent on the LDAP schema. so like, they change based on the vibe of your schema ๐Ÿ’…


๐Ÿงš ldap_autofs_map_master_name (string)

The name of the automount master map in LDAP.

Default: auto.master


โœจ ldap_autofs_map_object_class (string)

The object class of an automount map entry in LDAP.

Default: nisMap (rfc2307, autofs_provider=ad), otherwise automountMap


๐ŸŽ€ ldap_autofs_map_name (string)

The name of an automount map entry in LDAP.

Default: nisMapName (rfc2307, autofs_provider=ad), otherwise automountMapName


๐Ÿฆ‹ ldap_autofs_entry_object_class (string)

The object class of an automount entry in LDAP. The entry usually corresponds to a mount point.

Default: nisObject (rfc2307, autofs_provider=ad), otherwise automount


๐Ÿ’œ ldap_autofs_entry_key (string)

The key of an automount entry in LDAP. The entry usually corresponds to a mount point.

Default: cn (rfc2307, autofs_provider=ad), otherwise automountKey


๐ŸŒธ ldap_autofs_entry_value (string)

The key of an automount entry in LDAP. The entry usually corresponds to a mount point.

Default: nisMapEntry (rfc2307, autofs_provider=ad), otherwise automountInformation


Please note that the automounter only reads the master map on startup ๐ŸŒˆ so if any autofs-related changes are made to the sssd.conf, you typically also need to restart the automounter daemon after restarting the SSSD. two restarts. that's the price bestie ๐Ÿ˜ญ

๐Ÿ’… ADVANCED OPTIONS ๐Ÿ’…

Okay bestie, these ones are for LDAP domains too, but likeโ€ฆ handle with care. Only drop these into your config if you genuinely know what you're doing, fr fr. ๐Ÿ™ˆ


  • ldap_netgroup_search_base (string) โ€” an optional base DN, plus search scope and LDAP filter, that narrows down the LDAP searches for this attribute type.

the syntax goes like this:

search_base[?scope?[filter][?search_base?scope?[filter]]*]

the scope can be one of "base", "onelevel" or "subtree". The scope does its thing exactly as laid out in section 4.5.1.2 of http://tools.ietf.org/html/rfc4511

the filter has to be a legit LDAP search filter, as specified by http://www.ietf.org/rfc/rfc2254.txt

for examples of this syntax, go peek at the โ€œldap_search_baseโ€ examples section.

Default: the value of ldap_search_base

heads up: specifying scope or filter is not supported for searches against an Active Directory Server that might yield a huge number of results and trigger the Range Retrieval extension in the response. ๐Ÿ‘€
  • ldap_user_search_base (string) โ€” an optional base DN, search scope and LDAP filter to restrict LDAP searches for this attribute type.

syntax:

search_base[?scope?[filter][?search_base?scope?[filter]]*]

scope can be "base", "onelevel" or "subtree". It behaves as specified in section 4.5.1.2 of http://tools.ietf.org/html/rfc4511

the filter must be a valid LDAP search filter per http://www.ietf.org/rfc/rfc2254.txt

want examples of this syntax? they're in the โ€œldap_search_baseโ€ examples section. ๐Ÿซถ

Default: the value of ldap_search_base

reminder: specifying scope or filter is not supported for searches against an Active Directory Server that might return a large number of results and trigger the Range Retrieval extension in the response.
  • ldap_group_search_base (string) โ€” an optional base DN, search scope and LDAP filter to restrict LDAP searches for this attribute type.

syntax:

search_base[?scope?[filter][?search_base?scope?[filter]]*]

scope = one of "base", "onelevel" or "subtree", functioning as specified in section 4.5.1.2 of http://tools.ietf.org/html/rfc4511

filter = a valid LDAP search filter as specified by http://www.ietf.org/rfc/rfc2254.txt

examples of this syntax live in the โ€œldap_search_baseโ€ examples section. โœจ

Default: the value of ldap_search_base

yes, same warning: specifying scope or filter is not supported for searches against an Active Directory Server that might yield a large number of results and trigger the Range Retrieval extension in the response.

Note ๐Ÿ“Œ

If the option โ€œldap_use_tokengroupsโ€ is enabled, the searches against Active Directory will not be restricted and will return all group memberships, even with no GID mapping. It's recommended to disable this feature if group names aren't displaying correctly. (iykyk, it's giving chaos otherwise.)

  • ldap_sudo_search_base (string) โ€” an optional base DN, search scope and LDAP filter to restrict LDAP searches for this attribute type.

syntax:

search_base[?scope?[filter][?search_base?scope?[filter]]*]

scope is one of "base", "onelevel" or "subtree", working as specified in section 4.5.1.2 of http://tools.ietf.org/html/rfc4511

the filter must be a valid LDAP search filter, as specified by http://www.ietf.org/rfc/rfc2254.txt

for examples of this syntax, refer to the โ€œldap_search_baseโ€ examples section.

Default: the value of ldap_search_base

and again: specifying scope or filter is not supported for searches against an Active Directory Server that might yield a large number of results and trigger the Range Retrieval extension in the response.
  • ldap_autofs_search_base (string) โ€” an optional base DN, search scope and LDAP filter to restrict LDAP searches for this attribute type.

syntax:

search_base[?scope?[filter][?search_base?scope?[filter]]*]

scope can be "base", "onelevel" or "subtree" and functions as specified in section 4.5.1.2 of http://tools.ietf.org/html/rfc4511

the filter must be a valid LDAP search filter as specified by http://www.ietf.org/rfc/rfc2254.txt

examples of this syntax are in the โ€œldap_search_baseโ€ examples section, bestie.

Default: the value of ldap_search_base

last one, promise: specifying scope or filter is not supported for searches against an Active Directory Server that might yield a large number of results and trigger the Range Retrieval extension in the response.

โœจ FAILOVER โœจ

So the failover feature is literally the back ends being like "this server is doing the most, lemme switch to a different one" whenever the current server fails. Iconic behaviour honestly. ๐Ÿ’…

Failover Syntax

The list of servers comes as a comma-separated list, and any number of spaces is allowed around the comma. Servers are listed in order of preference, and the list can hold any number of servers. Periodt.

For each failover-enabled config option, there are two variants: primary and backup. The whole idea is that servers in the primary list are the preferred ones, and backup servers only get searched if no primary servers can be reached. If a backup server does get selected, a timeout of 31 seconds is set. After that timeout, SSSD will periodically try to reconnect to one of the primary servers. And if it succeeds? It replaces the current active (backup) server. Slay. โœจ

The Failover Mechanism

The failover mechanism distinguishes between a machine and a service. Here's the tea: the back end first tries to resolve the hostname of a given machine. If that resolution attempt fails, the machine is considered offline โ€” and no further attempts are made to connect to that machine for any other service. If the resolution attempt succeeds, the back end tries to connect to a service on this machine. If the service connection attempt fails, then only this particular service is considered offline and the back end automatically switches over to the next service. The machine is still considered online and might still be tried for another service. Main character machine energy. ๐Ÿ‘‘

Further connection attempts get made to machines or services marked as offline after a specified period of time โ€” and this is currently hard coded to 30 seconds.

If there are no more machines to try, the back end as a whole switches to offline mode, and then attempts to reconnect every 30 seconds.

Failover time outs and tuning

Resolving a server to connect to can be as simple as running a single DNS query, or it can involve several steps, like finding the correct site or trying out multiple host names in case some of the configured servers aren't reachable. The more complex scenarios can take some time, and SSSD needs to balance between providing enough time to finish the resolution process while โ€” on the other hand โ€” not trying for too long before falling back to offline mode. If your SSSD debug logs show that the server resolution is timing out before a live server is contacted, you can consider changing the time outs.

This section lists the available tunables. Please refer to their description in the sssd.conf(5) manual page.

  • dns_resolver_server_timeout โ€” time in milliseconds that sets how long SSSD would talk to a single DNS server before trying the next one.

Default: 1000

  • dns_resolver_op_timeout โ€” time in seconds to tell how long SSSD would try to resolve a single DNS query (e.g. resolution of a hostname or an SRV record) before trying the next hostname or discovery domain.

Default: 3

  • dns_resolver_timeout โ€” how long SSSD would try to resolve a failover service. This service resolution internally might include several steps, such as resolving DNS SRV queries or locating the site.

Default: 6

For LDAP-based providers, the resolve operation is performed as part of an LDAP connection operation. So therefore, also the โ€œldap_opt_timeoutโ€ timeout should be set to a larger value than โ€œdns_resolver_timeoutโ€ โ€” which in turn should be set to a larger value than โ€œdns_resolver_op_timeoutโ€ โ€” which should be larger than โ€œdns_resolver_server_timeoutโ€. It's giving nested dolls but make it timeouts. ๐Ÿช†


๐ŸŒˆ SERVICE DISCOVERY ๐ŸŒˆ

The service discovery feature lets back ends automatically find the appropriate servers to connect to using a special DNS query. Bestie, note: this feature is not supported for backup servers.

Configuration

If no servers are specified, the back end automatically uses service discovery to try to find a server. Optionally, the user may choose to use both fixed server addresses and service discovery by inserting a special keyword, โ€œ_srv_โ€, into the list of servers. The order of preference is maintained. This feature is useful if, for example, the user prefers to use service discovery whenever possible and fall back to a specific server when no servers can be discovered using DNS. ๐Ÿ’–

The domain name

Please refer to the โ€œdns_discovery_domainโ€ parameter in the sssd.conf(5) manual page for more details. ๐Ÿฆ‹

The protocol

The queries usually specify _tcp as the protocol. Exceptions are documented in the respective option description.

See Also

For more information on the service discovery mechanism, refer to RFC 2782. ๐Ÿ“š

๐Ÿ—บ๏ธ ID MAPPING ๐Ÿ’ซ

okay bestie, this is the part where SSSD pulls off an absolute magic trick: it can be a client of Active Directory without making your admins go extend a bunch of user attributes just to fake POSIX attributes for user and group identifiers. iconic behavior, honestly.

NOTE: the SECOND you turn ID-mapping on, the uidNumber and gidNumber attributes get ignored. completely. not even a little bit. this is so we never end up with a messy collision between automatically-assigned and manually-assigned values. and if you do need manually-assigned values? then ALL values must be manually-assigned. no mixing, no halfsies, no "just this one user". periodt.

also, heads up bestie, changing the ID-mapping-related config options will change your user and group IDs. and right now SSSD straight up does not support changing IDs, so the SSSD database has to be removed. ๐Ÿซ  and because cached passwords live in that same database, you should only ever remove it while the authentication servers are reachable โ€” otherwise your users might get locked out. and to cache a password, an authentication actually has to be performed. using sss_cache(8) is not sufficient to remove the database. so the whole process is:

  • Making sure the remote servers are reachable
  • Stopping the SSSD service
  • Removing the database
  • Starting the SSSD service

and also, since changing IDs might mean you have to go adjust other system properties like file and directory ownership, plan ahead and test your ID mapping config thoroughly. fr fr. no vibe-checking this one on the fly. ๐Ÿ˜ญ


Mapping Algorithm โœจ

Active Directory hands out an objectSID for every single user and group object in the directory. that objectSID can be broken up into components that represent the Active Directory domain identity and the relative identifier (RID) of the user or group object.

The SSSD ID-mapping algorithm takes a range of available UIDs and divides it into equally-sized component sections โ€” we call them "slices". ๐Ÿฐ each slice represents the space available to an Active Directory domain.

When a user or group entry for a particular domain shows up for the first time, SSSD allocates one of the available slices to that domain. and to make this slice-assignment repeatable across different client machines, we pick the slice like this:

The SID string gets passed through the murmurhash3 algorithm to convert it to a 32-bit hashed value. then we take the modulus of that value with the total number of available slices to pick the slice. ๐ŸŽฏ

NOTE: it is possible to hit collisions in the hash and the subsequent modulus. in those situations we select the next available slice, but it may not be possible to reproduce the same exact set of slices on other machines (because the order they're encountered in is what determines their slice). in that situation, the recommendation is either switch to using explicit POSIX attributes in Active Directory (so, disabling ID-mapping) or configure a default domain to guarantee that at least one is always consistent. see "Configuration" for details. ๐Ÿ‘€

Configuration ๐ŸŽ€

Minimum configuration (in the [domain/DOMAINNAME] section):

ldap_id_mapping = True
ldap_schema = ad

The default configuration results in configuring 10,000 slices, each capable of holding up to 200,000 IDs, starting from 200,000 and going up to 2,000,200,000. that should be plenty for most deployments, bestie. ๐Ÿ’…

Advanced Configuration ๐ŸŒธ

  • ldap_idmap_range_min (integer) โ€” Specifies the lower (inclusive) bound of the range of POSIX IDs to use for mapping Active Directory user and group SIDs. It's the first POSIX ID that can be used for the mapping.
NOTE: this option is different from min_id โ€” min_id acts to filter the output of requests to this domain, whereas this option controls the range of ID assignment. subtle distinction, but the good general advice is to have min_id be less-than or equal to ldap_idmap_range_min. Default: 200000
  • ldap_idmap_range_max (integer) โ€” Specifies the upper (exclusive) bound of the range of POSIX IDs to use for mapping Active Directory user and group SIDs. It's the first POSIX ID which cannot be used for the mapping anymore, i.e. one larger than the last one which can be used for the mapping.
NOTE: this option is different from max_id โ€” max_id acts to filter the output of requests to this domain, whereas this option controls the range of ID assignment. subtle distinction, but the good general advice is to have max_id be greater-than or equal to ldap_idmap_range_max. Default: 2000200000
  • ldap_idmap_range_size (integer) โ€” Specifies the number of IDs available for each slice. If the range size doesn't divide evenly into the min and max values, it'll create as many complete slices as it can. ๐Ÿฐ
NOTE: the value of this option must be at least as large as the highest user RID planned for use on the Active Directory server. user lookups and logins will fail for any user whose RID is greater than this value. ๐Ÿ’€ for example, if your most recently-added Active Directory user has objectSid=S-1-5-21-2153326666-2176343378-3404031434-1107, then ldap_idmap_range_size must be at least 1108, since range size equals maximal RID minus minimal RID plus one (e.g. 1108 = 1107 - 0 + 1). it is important to plan ahead for future expansion, because changing this value will result in changing all of the ID mappings on the system, leading to users having different local IDs than they previously had. ๐Ÿ˜ฌ Default: 200000
  • ldap_idmap_default_domain_sid (string) โ€” Specify the domain SID of the default domain. This guarantees that this domain will always be assigned to slice zero in the ID map, bypassing the murmurhash algorithm described above. ๐ŸŽฏ
Default: not set
  • ldap_idmap_default_domain (string) โ€” Specify the name of the default domain.
Default: not set
  • ldap_idmap_autorid_compat (boolean) โ€” Changes the behavior of the ID-mapping algorithm to behave more similarly to winbind's idmap_autorid algorithm.
when this option is configured, domains get allocated starting with slice zero and increasing monotonically with each additional domain. NOTE: this algorithm is non-deterministic (it depends on the order that users and groups are requested). if this mode is required for compatibility with machines running winbind, it's recommended to also use the ldap_idmap_default_domain_sid option to guarantee that at least one domain is consistently allocated to slice zero. Default: False
  • ldap_idmap_helper_table_size (integer) โ€” Maximal number of secondary slices that is tried when performing mapping from UNIX id to SID.
Note: additional secondary slices might be generated when SID is being mapped to UNIX id and the RID part of SID is out of range for the secondary slices generated so far. if the value of ldap_idmap_helper_table_size is equal to 0, then no additional secondary slices are generated. Default: 10

Well-Known SIDs ๐Ÿ‘‘

SSSD supports looking up the names of Well-Known SIDs, i.e. SIDs with a special hardcoded meaning. and since the generic users and groups related to those Well-Known SIDs have no equivalent in a Linux/UNIX environment, no POSIX IDs are available for those objects.

The SID name space is organized in authorities, which can be seen as different domains. the authorities for the Well-Known SIDs are:

  • Null Authority
  • World Authority
  • Local Authority
  • Creator Authority
  • Mandatory Label Authority
  • Authentication Authority
  • NT Authority
  • Built-in

The capitalized version of these names is used as domain names when returning the fully qualified name of a Well-Known SID.

And since some utilities let you modify SID-based access control information with the help of a name instead of using the SID directly, SSSD supports looking up the SID by name as well. ๐Ÿซถ to avoid collisions, only the fully qualified names can be used to look up Well-Known SIDs. as a result, the domain names NULL AUTHORITY, WORLD AUTHORITY, LOCAL AUTHORITY, CREATOR AUTHORITY, MANDATORY LABEL AUTHORITY, AUTHENTICATION AUTHORITY, NT AUTHORITY and BUILTIN should not be used as domain names in sssd.conf. ๐Ÿšซ


๐Ÿงช EXAMPLE ๐ŸŒˆ

The following example assumes that SSSD is correctly configured and LDAP is set to one of the domains in the [domains] section.

[domain/LDAP]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://ldap.mydomain.org
ldap_search_base = dc=mydomain,dc=org
ldap_tls_reqcert = demand
cache_credentials = true

๐Ÿ” LDAP ACCESS FILTER EXAMPLE โœจ

The following example assumes that SSSD is correctly configured and to use the ldap_access_order=lockout.

[domain/LDAP]
id_provider = ldap
auth_provider = ldap
access_provider = ldap
ldap_access_order = lockout
ldap_pwdlockout_dn = cn=ppolicy,ou=policies,dc=mydomain,dc=org
ldap_uri = ldap://ldap.mydomain.org
ldap_search_base = dc=mydomain,dc=org
ldap_tls_reqcert = demand
cache_credentials = true

๐Ÿ“ NOTES ๐ŸŽ€

The descriptions of some of the configuration options in this manual page are based on the ldap.conf(5) manual page from the OpenLDAP 2.4 distribution. (credit where credit's due, bestie ๐Ÿ’œ)


๐Ÿ‘€ SEE ALSO ๐Ÿฆ‹

sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-idp(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(1), sss_ssh_knownhosts(1), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)


๐Ÿ’– AUTHORS ๐Ÿ‘‘

The SSSD upstream - https://github.com/SSSD/sssd/


and that's the whole page, bestie!! you made it to the end, we're so proud of you ๐Ÿฅนโœจ this little masterpiece comes to you from the SSSD crew, dated 07/08/2026, and it's page SSSD-LDAP(5) โ€” go forth and map those IDs responsibly, mwah ๐Ÿ’…๐Ÿซถ

๐Ÿ“ฆ where this page comes from