Table of Contents
pam_sss.so [
quiet
] [
forward_pass
] [
use_first_pass
] [
use_authtok
] [
retry=N
] [
ignore_unknown_user
] [
ignore_authinfo_unavail
] [
domains=X
] [
allow_missing_name
] [
prompt_always
]
pam_sss.so is the PAM interface to the System Security Services daemon (SSSD). Errors and results are logged through syslog(3) with the LOG_AUTHPRIV facility.
quiet
Suppress log messages for unknown users.
forward_pass
If forward_pass is set the entered
password is put on the stack for other PAM modules to use.
use_first_pass
The argument use_first_pass forces the module to use a previous stacked modules password and will never prompt the user - if no password is available or the password is not appropriate, the user will be denied access.
use_authtok
When password changing enforce the module to set the new password to the one provided by a previously stacked password module.
retry=N
If specified the user is asked another N times for a password if authentication fails. Default is 0.
Please note that this option might not work as
expected if the application calling PAM handles the user
dialog on its own. A typical example is
sshd with
PasswordAuthentication.
ignore_unknown_user
If this option is specified and the user does not exist, the PAM module will return PAM_IGNORE. This causes the PAM framework to ignore this module.
ignore_authinfo_unavail
Specifies that the PAM module should return PAM_IGNORE if it cannot contact the SSSD daemon. This causes the PAM framework to ignore this module.
domains
Allows the administrator to restrict the domains a particular PAM service is allowed to authenticate against. The format is a comma-separated list of SSSD domain names, as specified in the sssd.conf file.
NOTE: Must be used in conjunction with the “pam_trusted_users” and “pam_public_domains” options. Please see the sssd.conf(5) manual page for more information on these two PAM responder options.
allow_missing_name
The main purpose of this option is to let SSSD determine the user name based on additional information, e.g. the certificate from a Smartcard.
The current use case are login managers which can monitor a Smartcard reader for card events. In case a Smartcard is inserted the login manager will call a PAM stack which includes a line like
auth sufficient pam_sss.so allow_missing_name
In this case SSSD will try to determine the user name based on the content of the Smartcard, returns it to pam_sss which will finally put it on the PAM stack.
prompt_always
Always prompt the user for credentials. With this option credentials requested by other PAM modules, typically a password, will be ignored and pam_sss will prompt for credentials again. Based on the pre-auth reply by SSSD pam_sss might prompt for a password, a Smartcard PIN or other credentials.
If a password reset by root fails, because the corresponding SSSD provider does not support password resets, an individual message can be displayed. This message can e.g. contain instructions about how to reset a password.
The message is read from the file
pam_sss_pw_reset_message.LOC where LOC stands for a
locale string returned by setlocale(3). If there is no matching file the content of
pam_sss_pw_reset_message.txt is displayed. Root
must be the owner of the files and only root may have read and write
permissions while all other users must have only read
permissions.
These files are searched in the directory
/etc/sssd/customize/DOMAIN_NAME/. If no matching
file is present a generic message is displayed.
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sssd-secrets(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8), sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)
Table of Contents
sss_cache invalidates records in SSSD cache. Invalidated records are forced to be reloaded from server as soon as related SSSD backend is online. Options that invalidate a single object only accept a single provided argument.
-E,--everything
Invalidate all cached entries.
-u,--user
login
Invalidate specific user.
-U,--users
Invalidate all user records. This option overrides invalidation of specific user if it was also set.
-g,--group
group
Invalidate specific group.
-G,--groups
Invalidate all group records. This option overrides invalidation of specific group if it was also set.
-n,--netgroup
netgroup
Invalidate specific netgroup.
-N,--netgroups
Invalidate all netgroup records. This option overrides invalidation of specific netgroup if it was also set.
-s,--service
service
Invalidate specific service.
-S,--services
Invalidate all service records. This option overrides invalidation of specific service if it was also set.
-a,--autofs-map
autofs-map
Invalidate specific autofs maps.
-A,--autofs-maps
Invalidate all autofs maps. This option overrides invalidation of specific map if it was also set.
-h,--ssh-host
hostname
Invalidate SSH public keys of a specific host.
-H,--ssh-hosts
Invalidate SSH public keys of all hosts. This option overrides invalidation of SSH public keys of specific host if it was also set.
-r,--sudo-rule
rule
Invalidate particular sudo rule.
-R,--sudo-rules
Invalidate all cached sudo rules. This option overrides invalidation of specific sudo rule if it was also set.
-d,--domain
domain
Restrict invalidation process only to a particular domain.
-?,--help
Display help message and exit.
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sssd-secrets(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8), sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)
Table of Contents
The manual page describes the rules which can be used by SSSD and other components to match X.509 certificates and map them to accounts.
Each rule has four components, a “priority”, a “matching rule”, a “mapping rule” and a “domain list”. All components are optional. A missing “priority” will add the rule with the lowest priority. The default “matching rule” will match certificates with the digitalSignature key usage and clientAuth extended key usage. If the “mapping rule” is empty the certificates will be searched in the userCertificate attribute as DER encoded binary. If no domains are given only the local domain will be searched.
The rules are processed by priority while the number '0' (zero) indicates the highest priority. The higher the number the lower is the priority. A missing value indicates the lowest priority. The rules processing is stopped when a matched rule is found and no further rules are checked.
Internally the priority is treated as unsigned 32bit integer, using a priority value larger than 4294967295 will cause an error.
The matching rule is used to select a certificate to which the mapping rule should be applied. It uses a system similar to the one used by “pkinit_cert_match” option of MIT Kerberos. It consists of a keyword enclosed by '<' and '>' which identified a certain part of the certificate and a pattern which should be found for the rule to match. Multiple keyword pattern pairs can be either joined with '&&' (and) or '||' (or).
The available options are:
With this a part or the whole subject name of the certificate can be matched. For the matching POSIX Extended Regular Expression syntax is used, see regex(7) for details.
For the matching the subject name stored in the certificate in DER encoded ASN.1 is converted into a string according to RFC 4514. This means the most specific name component comes first. Please note that not all possible attribute names are covered by RFC 4514. The names included are 'CN', 'L', 'ST', 'O', 'OU', 'C', 'STREET', 'DC' and 'UID'. Other attribute names might be shown differently on different platform and by different tools. To avoid confusion those attribute names are best not used or covered by a suitable regular-expression.
Example: <SUBJECT>.*,DC=MY,DC=DOMAIN
With this a part or the whole issuer name of the certificate can be matched. All comments for <SUBJECT> apply her as well.
Example: <ISSUER>^CN=My-CA,DC=MY,DC=DOMAIN$
This option can be used to specify which key usage values the certificate should have. The following values can be used in a comma separated list:
digitalSignature
nonRepudiation
keyEncipherment
dataEncipherment
keyAgreement
keyCertSign
cRLSign
encipherOnly
decipherOnly
A numerical value in the range of a 32bit unsigned integer can be used as well to cover special use cases.
Example: <KU>digitalSignature,keyEncipherment
This option can be used to specify which extended key usage the certificate should have. The following value can be used in a comma separated list:
serverAuth
clientAuth
codeSigning
emailProtection
timeStamping
OCSPSigning
KPClientAuth
pkinit
msScLogin
Extended key usages which are not listed above can be specified with their OID in dotted-decimal notation.
Example: <EKU>clientAuth,1.3.6.1.5.2.3.4
To be compatible with the usage of MIT Kerberos this option will match the Kerberos principals in the PKINIT or AD NT Principal SAN as <SAN:Principal> does.
Example: <SAN>.*@MY\.REALM
Match the Kerberos principals in the PKINIT or AD NT Principal SAN.
Example: <SAN:Principal>.*@MY\.REALM
Match the Kerberos principals from the AD NT Principal SAN.
Example: <SAN:ntPrincipalName>.*@MY.AD.REALM
Match the Kerberos principals from the PKINIT SAN.
Example: <SAN:ntPrincipalName>.*@MY\.PKINIT\.REALM
Take the value of the otherName SAN component given by the OID in dotted-decimal notation, interpret it as string and try to match it against the regular expression.
Example: <SAN:1.2.3.4>test
Do a binary match with the base64 encoded blob against all otherName SAN components. With this option it is possible to match against custom otherName components with special encodings which could not be treated as strings.
Example: <SAN:otherName>MTIz
Match the value of the rfc822Name SAN.
Example: <SAN:rfc822Name>.*@email\.domain
Match the value of the dNSName SAN.
Example: <SAN:dNSName>.*\.my\.dns\.domain
Binary match the value of the x400Address SAN.
Example: <SAN:x400Address>MTIz
Match the value of the directoryName SAN. The same comments as given for <ISSUER> and <SUBJECT> apply here as well.
Example: <SAN:directoryName>.*,DC=com
Binary match the value of the ediPartyName SAN.
Example: <SAN:ediPartyName>MTIz
Match the value of the uniformResourceIdentifier SAN.
Example: <SAN:uniformResourceIdentifier>URN:.*
Match the value of the iPAddress SAN.
Example: <SAN:iPAddress>192\.168\..*
Match the value of the registeredID SAN as dotted-decimal string.
Example: <SAN:registeredID>1\.2\.3\..*
The mapping rule is used to associate a certificate with one or more accounts. A Smartcard with the certificate and the matching private key can then be used to authenticate as one of those accounts.
Currently SSSD basically only supports LDAP to lookup user information (the exception is the proxy provider which is not of relevance here). Because of this the mapping rule is based on LDAP search filter syntax with templates to add certificate content to the filter. It is expected that the filter will only contain the specific data needed for the mapping and that the caller will embed it in another filter to do the actual search. Because of this the filter string should start and stop with '(' and ')' respectively.
In general it is recommended to use attributes from the certificate and add them to special attributes to the LDAP user object. E.g. the 'altSecurityIdentities' attribute in AD or the 'ipaCertMapData' attribute for IPA can be used.
This should be preferred to read user specific data from the certificate like e.g. an email address and search for it in the LDAP server. The reason is that the user specific data in LDAP might change for various reasons would break the mapping. On the other hand it would be hard to break the mapping on purpose for a specific user.
The templates to add certificate data to the search filter are based on Python-style formatting strings. They consist of a keyword in curly braces with an optional sub-component specifier separated by a '.' or an optional conversion/formatting option separated by a '!'. Allowed values are:
This template will add the full issuer DN converted to a string according to RFC 4514. If X.500 ordering (most specific RDN comes last) an option with the '_x500' prefix should be used.
The conversion options starting with 'ad_' will use attribute names as used by AD, e.g. 'S' instead of 'ST'.
The conversion options starting with 'nss_' will use attribute names as used by NSS.
The default conversion option is 'nss', i.e. attribute names according to NSS and LDAP/RFC 4514 ordering.
Example: (ipacertmapdata=X509:<I>{issuer_dn!ad}<S>{subject_dn!ad})
This template will add the full subject DN converted to string according to RFC 4514. If X.500 ordering (most specific RDN comes last) an option with the '_x500' prefix should be used.
The conversion options starting with 'ad_' will use attribute names as used by AD, e.g. 'S' instead of 'ST'.
The conversion options starting with 'nss_' will use attribute names as used by NSS.
The default conversion option is 'nss', i.e. attribute names according to NSS and LDAP/RFC 4514 ordering.
Example: (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
This template will add the whole DER encoded certificate as a string to the search filter. Depending on the conversion option the binary certificate is either converted to an escaped hex sequence '\xx' or base64. The escaped hex sequence is the default and can e.g. be used with the LDAP attribute 'userCertificate;binary'.
Example: (userCertificate;binary={cert!bin})
This template will add the Kerberos principal which is taken either from the SAN used by pkinit or the one used by AD. The 'short_name' component represents the first part of the principal before the '@' sign.
Example: (|(userPrincipal={subject_principal})(samAccountName={subject_principal.short_name}))
This template will add the Kerberos principal which is given by the SAN used by pkinit. The 'short_name' component represents the first part of the principal before the '@' sign.
Example: (|(userPrincipal={subject_pkinit_principal})(uid={subject_pkinit_principal.short_name}))
This template will add the Kerberos principal which is given by the SAN used by AD. The 'short_name' component represent the first part of the principal before the '@' sign.
Example: (|(userPrincipal={subject_principal})(samAccountName={subject_principal.short_name}))
This template will add the string which is stored in the rfc822Name component of the SAN, typically an email address. The 'short_name' component represents the first part of the address before the '@' sign.
Example: (|(mail={subject_rfc822_name})(uid={subject_rfc822_name.short_name}))
This template will add the string which is stored in the dNSName component of the SAN, typically a fully-qualified host name. The 'short_name' component represents the first part of the name before the first '.' sign.
Example: (|(fqdn={subject_dns_name})(host={subject_dns_name.short_name}))
This template will add the string which is stored in the uniformResourceIdentifier component of the SAN.
Example: (uri={subject_uri})
This template will add the string which is stored in the iPAddress component of the SAN.
Example: (ip={subject_ip_address})
This template will add the value which is stored in the x400Address component of the SAN as escaped hex sequence.
Example: (attr:binary={subject_x400_address})
This template will add the DN string of the value which is stored in the directoryName component of the SAN.
Example: (orig_dn={subject_directory_name})
This template will add the value which is stored in the ediPartyName component of the SAN as escaped hex sequence.
Example: (attr:binary={subject_ediparty_name})
This template will add the OID which is stored in the registeredID component of the SAN as a dotted-decimal string.
Example: (oid={subject_registered_id})
Table of Contents
sssctl provides a simple and unified way to obtain information about SSSD status, such as active server, auto-discovered servers, domains and cached objects. In addition, it can manage SSSD data files for troubleshooting in such a way that is safe to manipulate while SSSD is running.
To list all available commands run sssctl without any parameters. To print help for selected command run sssctl COMMAND --help.
Those options are available with all commands.
--debug
LEVEL
SSSD supports two representations for specifying the debug level. The simplest is to specify a decimal value from 0-9, which represents enabling that level and all lower-level debug messages. The more comprehensive option is to specify a hexadecimal bitmask to enable or disable specific levels (such as if you wish to suppress a level).
Currently supported debug levels:
0, 0x0010: Fatal failures. Anything that would prevent SSSD from starting up or causes it to cease running.
1, 0x0020: Critical failures. An error that doesn't kill SSSD, but one that indicates that at least one major feature is not going to work properly.
2, 0x0040: Serious failures. An error announcing that a particular request or operation has failed.
3, 0x0080: Minor failures. These are the errors that would percolate down to cause the operation failure of 2.
4, 0x0100: Configuration settings.
5, 0x0200: Function data.
6, 0x0400: Trace messages for operation functions.
7, 0x1000: Trace messages for internal control functions.
8, 0x2000: Contents of function-internal variables that may be interesting.
9, 0x4000: Extremely low-level tracing information.
To log required bitmask debug levels, simply add their numbers together as shown in following examples:
Example: To log fatal failures, critical failures, serious failures and function data use 0x0270.
Example: To log fatal failures, configuration settings, function data, trace messages for internal control functions use 0x1310.
Note: The bitmask format of debug levels was introduced in 1.7.0.
Default: 0
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sssd-secrets(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8), sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)
Table of Contents
SSSD provides a set of daemons to manage access to remote directories and authentication mechanisms. It provides an NSS and PAM interface toward the system and a pluggable backend system to connect to multiple different account sources as well as D-Bus interface. It is also the basis to provide client auditing and policy services for projects like FreeIPA. It provides a more robust database to store local users as well as extended user data.
-d,--debug-level
LEVEL
SSSD supports two representations for specifying the debug level. The simplest is to specify a decimal value from 0-9, which represents enabling that level and all lower-level debug messages. The more comprehensive option is to specify a hexadecimal bitmask to enable or disable specific levels (such as if you wish to suppress a level).
Please note that each SSSD service logs into its own log file. Also please note that enabling “debug_level” in the “[sssd]” section only enables debugging just for the sssd process itself, not for the responder or provider processes. The “debug_level” parameter should be added to all sections that you wish to produce debug logs from.
In addition to changing the log level in the config file using the “debug_level” parameter, which is persistent, but requires SSSD restart, it is also possible to change the debug level on the fly using the sss_debuglevel(8) tool.
Currently supported debug levels:
0, 0x0010: Fatal failures. Anything that would prevent SSSD from starting up or causes it to cease running.
1, 0x0020: Critical failures. An error that doesn't kill SSSD, but one that indicates that at least one major feature is not going to work properly.
2, 0x0040: Serious failures. An error announcing that a particular request or operation has failed.
3, 0x0080: Minor failures. These are the errors that would percolate down to cause the operation failure of 2.
4, 0x0100: Configuration settings.
5, 0x0200: Function data.
6, 0x0400: Trace messages for operation functions.
7, 0x1000: Trace messages for internal control functions.
8, 0x2000: Contents of function-internal variables that may be interesting.
9, 0x4000: Extremely low-level tracing information.
To log required bitmask debug levels, simply add their numbers together as shown in following examples:
Example: To log fatal failures, critical failures, serious failures and function data use 0x0270.
Example: To log fatal failures, configuration settings, function data, trace messages for internal control functions use 0x1310.
Note: The bitmask format of debug levels was introduced in 1.7.0.
Default: 0
--debug-timestamps=mode
1: Add a timestamp to the debug messages
0: Disable timestamp in the debug messages
Default: 1
--debug-microseconds=mode
1: Add microseconds to the timestamp in debug messages
0: Disable microseconds in timestamp
Default: 0
-f,--debug-to-files
Send the debug output to files instead of stderr. By default, the
log files are stored in /var/log/sssd and
there are separate log files for every SSSD service and domain.
This option is deprecated. It is replaced by
--logger=files.
--logger=value
Location where SSSD will send log messages. This option
overrides the value of the deprecated option
--debug-to-files. The deprecated
option will still work if the --logger
is not used.
stderr: Redirect debug messages to standard error output.
files: Redirect debug messages to
the log files. By default, the log files are stored in
/var/log/sssd and there are
separate log files for every SSSD service and domain.
journald: Redirect debug messages to systemd-journald
Default: not set
-D,--daemon
Become a daemon after starting up.
-i,--interactive
Run in the foreground, don't become a daemon.
-c,--config
Specify a non-default config file. The default is
/etc/sssd/sssd.conf. For reference
on the config file syntax and options, consult the
sssd.conf(5)
manual page.
-?,--help
Display help message and exit.
--version
Print version number and exit.
Informs the SSSD to gracefully terminate all of its child processes and then shut down the monitor.
Tells the SSSD to stop writing to its current debug file descriptors and to close and reopen them. This is meant to facilitate log rolling with programs like logrotate.
Tells the SSSD to simulate offline operation for the duration of the “offline_timeout” parameter. This is useful for testing. The signal can be sent to either the sssd process or any sssd_be process directly.
Tells the SSSD to go online immediately. This is useful for testing. The signal can be sent to either the sssd process or any sssd_be process directly.
If the environment variable SSS_NSS_USE_MEMCACHE is set to "NO", client applications will not use the fast in memory cache.
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sssd-secrets(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8), sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)
Table of Contents
This manual page describes the configuration of the AD provider for sssd(8). For a detailed syntax reference, refer to the “FILE FORMAT” section of the sssd.conf(5) manual page.
The AD provider is a back end used to connect to an Active Directory server. This provider requires that the machine be joined to the AD domain and a keytab is available. Back end communication occurs over a GSSAPI-encrypted channel, SSL/TLS options should not be used with the AD provider and will be superseded by Kerberos usage.
The AD provider supports connecting to Active Directory 2008 R2 or later. Earlier versions may work, but are unsupported.
The AD provider can be used to get user information and authenticate users from trusted domains. Currently only trusted domains in the same forest are recognized. In addition servers from trusted domains are always auto-discovered.
The AD provider enables SSSD to use the sssd-ldap(5) identity provider and the sssd-krb5(5) authentication provider with optimizations for Active Directory environments. The AD provider accepts the same options used by the sssd-ldap and sssd-krb5 providers with some exceptions. However, it is neither necessary nor recommended to set these options.
The AD provider primarily copies the traditional ldap and krb5 provider default options with some exceptions, the differences are listed in the “MODIFIED DEFAULT OPTIONS” section.
The AD provider can also be used as an access, chpass, sudo and autofs provider. No configuration of the access provider is required on the client side.
If “auth_provider=ad” or “access_provider=ad” is configured in sssd.conf then the id_provider must also be set to “ad”.
By default, the AD provider will map UID and GID values from the objectSID parameter in Active Directory. For details on this, see the “ID MAPPING” section below. If you want to disable ID mapping and instead rely on POSIX attributes defined in Active Directory, you should set
ldap_id_mapping = False
If POSIX attributes should be used, it is recommended for performance reasons that the attributes are also replicated to the Global Catalog. If POSIX attributes are replicated, SSSD will attempt to locate the domain of a requested numerical ID with the help of the Global Catalog and only search that domain. In contrast, if POSIX attributes are not replicated to the Global Catalog, SSSD must search all the domains in the forest sequentially. Please note that the “cache_first” option might be also helpful in speeding up domainless searches. Note that if only a subset of POSIX attributes is present in the Global Catalog, the non-replicated attributes are currently not read from the LDAP port.
Users, groups and other entities served by SSSD are always treated as case-insensitive in the AD provider for compatibility with Active Directory's LDAP implementation.
Refer to the section “DOMAIN SECTIONS” of the sssd.conf(5) manual page for details on the configuration of an SSSD domain.
Specifies the name of the Active Directory domain. This is optional. If not provided, the configuration domain name is used.
For proper operation, this option should be specified as the lower-case version of the long version of the Active Directory domain.
The short domain name (also known as the NetBIOS or the flat name) is autodetected by the SSSD.
A comma-separated list of enabled Active Directory domains. If provided, SSSD will ignore any domains not listed in this option. If left unset, all domains from the AD forest will be available.
For proper operation, this option must be specified in all lower-case and as the fully qualified domain name of the Active Directory domain. For example:
ad_enabled_domains = sales.example.com, eng.example.com
The short domain name (also known as the NetBIOS or the flat name) will be autodetected by SSSD.
Default: Not set
The comma-separated list of hostnames of the AD servers to which SSSD should connect in order of preference. For more information on failover and server redundancy, see the “FAILOVER” section.
This is optional if autodiscovery is enabled. For more information on service discovery, refer to the “SERVICE DISCOVERY” section.
Note: Trusted domains will always auto-discover servers even if the primary server is explicitly defined in the ad_server option.
Optional. May be set on machines where the hostname(5) does not reflect the fully qualified name used in the Active Directory domain to identify this host.
This field is used to determine the host principal in use in the keytab. It must match the hostname for which the keytab was issued.
Enables DNS sites - location based service discovery.
If true and service discovery (see Service Discovery paragraph at the bottom of the man page) is enabled, the SSSD will first attempt to discover the Active Directory server to connect to using the Active Directory Site Discovery and fall back to the DNS SRV records if no AD site is found. The DNS SRV configuration, including the discovery domain, is used during site discovery as well.
Default: true
This option specifies LDAP access control filter that the user must match in order to be allowed access. Please note that the “access_provider” option must be explicitly set to “ad” in order for this option to have an effect.
The option also supports specifying different filters per domain or forest. This extended filter would consist of: “KEYWORD:NAME:FILTER”. The keyword can be either “DOM”, “FOREST” or missing.
If the keyword equals to “DOM” or is missing, then “NAME” specifies the domain or subdomain the filter applies to. If the keyword equals to “FOREST”, then the filter equals to all domains from the forest specified by “NAME”.
Multiple filters can be separated with the “?” character, similarly to how search bases work.
Nested group membership must be searched for using a special OID “:1.2.840.113556.1.4.1941:” in addition to the full DOM:domain.example.org: syntax to ensure the parser does not attempt to interpret the colon characters associated with the OID. If you do not use this OID then nested group membership will not be resolved. See usage example below and refer here for further information about the OID: [MS-ADTS] section LDAP extensions
The most specific match is always used. For example, if the option specified filter for a domain the user is a member of and a global filter, the per-domain filter would be applied. If there are more matches with the same specification, the first one is used.
Examples:
# apply filter on domain called dom1 only:
dom1:(memberOf=cn=admins,ou=groups,dc=dom1,dc=com)
# apply filter on domain called dom2 only:
DOM:dom2:(memberOf=cn=admins,ou=groups,dc=dom2,dc=com)
# apply filter on forest called EXAMPLE.COM only:
FOREST:EXAMPLE.COM:(memberOf=cn=admins,ou=groups,dc=example,dc=com)
# apply filter for a member of a nested group in dom1:
DOM:dom1:(memberOf:1.2.840.113556.1.4.1941:=cn=nestedgroup,ou=groups,dc=example,dc=com)
Default: Not set
Specify AD site to which client should try to connect. If this option is not provided, the AD site will be auto-discovered.
Default: Not set
By default, the SSSD connects to the Global Catalog first to retrieve users from trusted domains and uses the LDAP port to retrieve group memberships or as a fallback. Disabling this option makes the SSSD only connect to the LDAP port of the current AD server.
Please note that disabling Global Catalog support does not disable retrieving users from trusted domains. The SSSD would connect to the LDAP port of trusted domains instead. However, Global Catalog must be used in order to resolve cross-domain group memberships.
Default: true
This option specifies the operation mode for GPO-based access control functionality: whether it operates in disabled mode, enforcing mode, or permissive mode. Please note that the “access_provider” option must be explicitly set to “ad” in order for this option to have an effect.
GPO-based access control functionality uses GPO policy settings to determine whether or not a particular user is allowed to logon to a particular host.
NOTE: The current version of SSSD does not support host (computer) entries in the GPO 'Security Filtering' list. Only user and group entries are supported. Host entries in the list have no effect.
NOTE: If the operation mode is set to enforcing, it is possible that users that were previously allowed logon access will now be denied logon access (as dictated by the GPO policy settings). In order to facilitate a smooth transition for administrators, a permissive mode is available that will not enforce the access control rules, but will evaluate them and will output a syslog message if access would have been denied. By examining the logs, administrators can then make the necessary changes before setting the mode to enforcing.
There are three supported values for this option:
disabled: GPO-based access control rules are neither evaluated nor enforced.
enforcing: GPO-based access control rules are evaluated and enforced.
permissive: GPO-based access control rules are evaluated, but not enforced. Instead, a syslog message will be emitted indicating that the user would have been denied access if this option's value were set to enforcing.
Default: permissive
Default: enforcing
Normally when no applicable GPOs are found the users are allowed access. When this option is set to True users will be allowed access only when explicitly allowed by a GPO rule. Otherwise users will be denied access. This can be used to harden security but be careful when using this option because it can deny access even to users in the built-in Administrators group if no GPO rules apply to them.
Default: False (seconds)
Normally when some group policy containers (AD object) of applicable group policy objects are not readable by SSSD then users are denied access. This option allows to ignore group policy containers and with them associated policies if their attributes in group policy containers are not readable for SSSD.
Default: False
The amount of time between lookups of GPO policy files against the AD server. This will reduce the latency and load on the AD server if there are many access-control requests made in a short period.
Default: 5 (seconds)
A comma-separated list of PAM service names for which GPO-based access control is evaluated based on the InteractiveLogonRight and DenyInteractiveLogonRight policy settings.
Note: Using the Group Policy Management Editor this value is called "Allow log on locally" and "Deny log on locally".
It is possible to add another PAM service name to the default set by using “+service_name” or to explicitly remove a PAM service name from the default set by using “-service_name”. For example, in order to replace a default PAM service name for this logon right (e.g. “login”) with a custom pam service name (e.g. “my_pam_service”), you would use the following configuration:
ad_gpo_map_interactive = +my_pam_service, -login
Default: the default set of PAM service names includes:
login
su
su-l
gdm-fingerprint
gdm-password
gdm-smartcard
kdm
lightdm
lxdm
sddm
unity
xdm
A comma-separated list of PAM service names for which GPO-based access control is evaluated based on the RemoteInteractiveLogonRight and DenyRemoteInteractiveLogonRight policy settings.
Note: Using the Group Policy Management Editor this value is called "Allow log on through Remote Desktop Services" and "Deny log on through Remote Desktop Services".
It is possible to add another PAM service name to the default set by using “+service_name” or to explicitly remove a PAM service name from the default set by using “-service_name”. For example, in order to replace a default PAM service name for this logon right (e.g. “sshd”) with a custom pam service name (e.g. “my_pam_service”), you would use the following configuration:
ad_gpo_map_remote_interactive = +my_pam_service, -sshd
Default: the default set of PAM service names includes:
sshd
cockpit
A comma-separated list of PAM service names for which GPO-based access control is evaluated based on the NetworkLogonRight and DenyNetworkLogonRight policy settings.
Note: Using the Group Policy Management Editor this value is called "Access this computer from the network" and "Deny access to this computer from the network".
It is possible to add another PAM service name to the default set by using “+service_name” or to explicitly remove a PAM service name from the default set by using “-service_name”. For example, in order to replace a default PAM service name for this logon right (e.g. “ftp”) with a custom pam service name (e.g. “my_pam_service”), you would use the following configuration:
ad_gpo_map_network = +my_pam_service, -ftp
Default: the default set of PAM service names includes:
ftp
samba
A comma-separated list of PAM service names for which GPO-based access control is evaluated based on the BatchLogonRight and DenyBatchLogonRight policy settings.
Note: Using the Group Policy Management Editor this value is called "Allow log on as a batch job" and "Deny log on as a batch job".
It is possible to add another PAM service name to the default set by using “+service_name” or to explicitly remove a PAM service name from the default set by using “-service_name”. For example, in order to replace a default PAM service name for this logon right (e.g. “crond”) with a custom pam service name (e.g. “my_pam_service”), you would use the following configuration:
ad_gpo_map_batch = +my_pam_service, -crond
Note: Cron service name may differ depending on Linux distribution used.
Default: the default set of PAM service names includes:
crond
A comma-separated list of PAM service names for which GPO-based access control is evaluated based on the ServiceLogonRight and DenyServiceLogonRight policy settings.
Note: Using the Group Policy Management Editor this value is called "Allow log on as a service" and "Deny log on as a service".
It is possible to add a PAM service name to the default set by using “+service_name”. Since the default set is empty, it is not possible to remove a PAM service name from the default set. For example, in order to add a custom pam service name (e.g. “my_pam_service”), you would use the following configuration:
ad_gpo_map_service = +my_pam_service
Default: not set
A comma-separated list of PAM service names for which GPO-based access is always granted, regardless of any GPO Logon Rights.
It is possible to add another PAM service name to the default set by using “+service_name” or to explicitly remove a PAM service name from the default set by using “-service_name”. For example, in order to replace a default PAM service name for unconditionally permitted access (e.g. “sudo”) with a custom pam service name (e.g. “my_pam_service”), you would use the following configuration:
ad_gpo_map_permit = +my_pam_service, -sudo
Default: the default set of PAM service names includes:
polkit-1
sudo
sudo-i
systemd-user
A comma-separated list of PAM service names for which GPO-based access is always denied, regardless of any GPO Logon Rights.
It is possible to add a PAM service name to the default set by using “+service_name”. Since the default set is empty, it is not possible to remove a PAM service name from the default set. For example, in order to add a custom pam service name (e.g. “my_pam_service”), you would use the following configuration:
ad_gpo_map_deny = +my_pam_service
Default: not set
This option defines how access control is evaluated for PAM service names that are not explicitly listed in one of the ad_gpo_map_* options. This option can be set in two different manners. First, this option can be set to use a default logon right. For example, if this option is set to 'interactive', it means that unmapped PAM service names will be processed based on the InteractiveLogonRight and DenyInteractiveLogonRight policy settings. Alternatively, this option can be set to either always permit or always deny access for unmapped PAM service names.
Supported values for this option include:
interactive
remote_interactive
network
batch
service
permit
deny
Default: deny
SSSD will check once a day if the machine account password is older than the given age in days and try to renew it. A value of 0 will disable the renewal attempt.
Default: 30 days
This option should only be used to test the machine account renewal task. The option expects 2 integers separated by a colon (':'). The first integer defines the interval in seconds how often the task is run. The second specifies the initial timeout in seconds before the task is run for the first time after startup.
Default: 86400:750 (24h and 15m)
By default SSSD uses the plain LDAP port 389 and the Global Catalog port 3628. If this option is set to True SSSD will use the LDAPS port 636 and Global Catalog port 3629 with LDAPS protection. Since AD does not allow to have multiple encryption layers on a single connection and we still want to use SASL/GSSAPI or SASL/GSS-SPNEGO for authentication the SASL security property maxssf is set to 0 (zero) for those connections.
Default: False
Optional. This option tells SSSD to automatically update the Active Directory DNS server with the IP address of this client. The update is secured using GSS-TSIG. As a consequence, the Active Directory administrator only needs to allow secure updates for the DNS zone. The IP address of the AD LDAP connection is used for the updates, if it is not otherwise specified by using the “dyndns_iface” option.
NOTE: On older systems (such as RHEL 5), for this behavior to work reliably, the default Kerberos realm must be set properly in /etc/krb5.conf
Default: true
The TTL to apply to the client DNS record when updating it. If dyndns_update is false this has no effect. This will override the TTL serverside if set by an administrator.
Default: 3600 (seconds)
Optional. Applicable only when dyndns_update is true. Choose the interface or a list of interfaces whose IP addresses should be used for dynamic DNS updates. Special value “*” implies that IPs from all interfaces should be used.
Default: Use the IP addresses of the interface which is used for AD LDAP connection
Example: dyndns_iface = em1, vnet1, vnet2
How often should the back end perform periodic DNS update in addition to the automatic update performed when the back end goes online. This option is optional and applicable only when dyndns_update is true. Note that the lowest possible value is 60 seconds in-case if value is provided less than 60, parameter will assume lowest value only.
Default: 86400 (24 hours)
Whether the PTR record should also be explicitly updated when updating the client's DNS records. Applicable only when dyndns_update is true.
Default: True
Whether the nsupdate utility should default to using TCP for communicating with the DNS server.
Default: False (let nsupdate choose the protocol)
Whether the nsupdate utility should use GSS-TSIG authentication for secure updates with the DNS server, insecure updates can be sent by setting this option to 'none'.
Default: GSS-TSIG
The DNS server to use when performing a DNS update. In most setups, it's recommended to leave this option unset.
Setting this option makes sense for environments where the DNS server is different from the identity server.
Please note that this option will be only used in fallback attempt when previous attempt using autodetected settings failed.
Default: None (let nsupdate choose the server)
Override the user's home directory. You can either provide an absolute value or a template. In the template, the following sequences are substituted:
login name
UID number
domain name
fully qualified user name (user@domain)
The first letter of the login name.
UPN - User Principal Name (name@REALM)
The original home directory retrieved from the identity provider.
The value of configure option homedir_substring.
a literal '%'
This option can also be set per-domain.
example:
override_homedir = /home/%u
Default: Not set (SSSD will use the value retrieved from LDAP)
The value of this option will be used in the expansion of the override_homedir option if the template contains the format string %H. An LDAP directory entry can directly contain this template so that this option can be used to expand the home directory path for each client machine (or operating system). It can be set per-domain or globally in the [nss] section. A value specified in a domain section will override one set in the [nss] section.
Default: /home
Absolute path of a directory where SSSD should place Kerberos configuration snippets.
To disable the creation of the configuration snippets set the parameter to 'none'.
Default: not set (krb5.include.d subdirectory of SSSD's pubconf directory)
Certain option defaults do not match their respective backend provider defaults, these option names and AD provider-specific defaults are listed below:
ldap_schema = ad
ldap_force_upper_case_realm = true
ldap_id_mapping = true
ldap_sasl_mech = gssapi
ldap_referrals = false
ldap_account_expire_policy = ad
ldap_use_tokengroups = true
ldap_sasl_authid = sAMAccountName@REALM (typically SHORTNAME$@REALM)
The AD provider looks for a different principal than the LDAP provider by default, because in an Active Directory environment the principals are divided into two groups - User Principals and Service Principals. Only User Principal can be used to obtain a TGT and by default, computer object's principal is constructed from its sAMAccountName and the AD realm. The well-known host/hostname@REALM principal is a Service Principal and thus cannot be used to get a TGT with.
fallback_homedir = /home/%d/%u
The AD provider automatically sets "fallback_homedir = /home/%d/%u" to provide personal home directories for users without the homeDirectory attribute. If your AD Domain is properly populated with Posix attributes, and you want to avoid this fallback behavior, you can explicitly set "fallback_homedir = %o".
The failover feature allows back ends to automatically switch to a different server if the current server fails.
The list of servers is given as a comma-separated list; any number of spaces is allowed around the comma. The servers are listed in order of preference. The list can contain any number of servers.
For each failover-enabled config option, two variants exist: primary and backup. The idea is that servers in the primary list are preferred and backup servers are only searched if no primary servers can be reached. If a backup server is selected, a timeout of 31 seconds is set. After this timeout SSSD will periodically try to reconnect to one of the primary servers. If it succeeds, it will replace the current active (backup) server.
The failover mechanism distinguishes between a machine and a service. The back end first tries to resolve the hostname of a given machine; if this resolution attempt fails, the machine is considered offline. No further attempts are made to connect to this 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.
Further connection attempts are made to machines or services marked as offline after a specified period of time; 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.
Resolving a server to connect to can be as simple as running a single DNS query or can involve several steps, such as finding the correct site or trying out multiple host names in case some of the configured servers are not reachable. The more complex scenarios can take some time and SSSD needs to balance between providing enough time to finish the resolution process but on the other hand, not trying for too long before falling back to offline mode. If the 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.
How long would SSSD talk to a single DNS server.
How long would SSSD try to resolve a failover service. This service resolution internally might include several steps, such as resolving DNS SRV queries or locating the site.
For LDAP-based providers, the resolve operation is performed as part of an LDAP connection operation. 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”.
The service discovery feature allows back ends to automatically find the appropriate servers to connect to using a special DNS query. This feature is not supported for backup servers.
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_”, in 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.
Please refer to the “dns_discovery_domain” parameter in the sssd.conf(5) manual page for more details.
The ID-mapping feature allows SSSD to act as a client of Active Directory without requiring administrators to extend user attributes to support POSIX attributes for user and group identifiers.
NOTE: When ID-mapping is enabled, the uidNumber and gidNumber attributes are ignored. This is to avoid the possibility of conflicts between automatically-assigned and manually-assigned values. If you need to use manually-assigned values, ALL values must be manually-assigned.
Please note that changing the ID mapping related configuration options will cause user and group IDs to change. At the moment, SSSD does not support changing IDs, so the SSSD database must be removed. Because cached passwords are also stored in the database, removing the database should only be performed while the authentication servers are reachable, otherwise users might get locked out. In order to cache the password, an authentication must be performed. It is not sufficient to use sss_cache(8) to remove the database, rather the process consists of:
Making sure the remote servers are reachable
Stopping the SSSD service
Removing the database
Starting the SSSD service
Moreover, as the change of IDs might necessitate the adjustment of other system properties such as file and directory ownership, it's advisable to plan ahead and test the ID mapping configuration thoroughly.
Active Directory provides an objectSID for every user and group object in the directory. This 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 - called "slices"-. Each slice represents the space available to an Active Directory domain.
When a user or group entry for a particular domain is encountered for the first time, the SSSD allocates one of the available slices for that domain. In order to make this slice-assignment repeatable on different client machines, we select the slice based on the following algorithm:
The SID string is passed through the murmurhash3 algorithm to convert it to a 32-bit hashed value. We then take the modulus of this value with the total number of available slices to pick the slice.
NOTE: It is possible to encounter collisions in the hash and subsequent modulus. In these situations, we will select the next available slice, but it may not be possible to reproduce the same exact set of slices on other machines (since the order that they are encountered will determine their slice). In this situation, it is recommended to either switch to using explicit POSIX attributes in Active Directory (disabling ID-mapping) or configure a default domain to guarantee that at least one is always consistent. See “Configuration” for details.
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. This should be sufficient for most deployments.
Specifies the lower bound of the range of POSIX IDs to use for mapping Active Directory user and group SIDs.
NOTE: This option is different from “min_id” in that “min_id” acts to filter the output of requests to this domain, whereas this option controls the range of ID assignment. This is a subtle distinction, but the good general advice would be to have “min_id” be less-than or equal to “ldap_idmap_range_min”
Default: 200000
Specifies the upper bound of the range of POSIX IDs to use for mapping Active Directory user and group SIDs.
NOTE: This option is different from “max_id” in that “max_id” acts to filter the output of requests to this domain, whereas this option controls the range of ID assignment. This is a subtle distinction, but the good general advice would be to have “max_id” be greater-than or equal to “ldap_idmap_range_max”
Default: 2000200000
Specifies the number of IDs available for each slice. If the range size does not divide evenly into the min and max values, it will 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 login 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, “ldap_idmap_range_size” must be at least 1108 as range size is equal to maximal SID minus minimal SID plus one (e.g. 1108 = 1107 - 0 + 1).
It is important to plan ahead for future expansion, as changing this value will result in changing all of the ID mappings on the system, leading to users with different local IDs than they previously had.
Default: 200000
Specify the domain SID of the default domain. This will guarantee that this domain will always be assigned to slice zero in the ID map, bypassing the murmurhash algorithm described above.
Default: not set
Specify the name of the default domain.
Default: not set
Changes the behavior of the ID-mapping algorithm to behave more similarly to winbind's “idmap_autorid” algorithm.
When this option is configured, domains will be allocated starting with slice zero and increasing monatomically 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 is 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
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 RID part of SID is out of range for secondary slices generated so far. If value of ldap_idmap_helper_table_size is equal to 0 then no additional secondary slices are generated.
Default: 10
SSSD supports to look up the names of Well-Known SIDs, i.e. SIDs with a special hardcoded meaning. 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
NT Authority
Built-in
The capitalized version of these names are used as domain names when returning the fully qualified name of a Well-Known SID.
Since some utilities allow to modify SID based access control
information with the help of a name instead of using the SID
directly SSSD supports to look up the SID by the 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”, “NT
AUTHORITY” and “BUILTIN” should not be used as
domain names in sssd.conf.
The following example assumes that SSSD is correctly
configured and example.com is one of the domains in the
[sssd] section. This example shows only
the AD provider-specific options.
[domain/EXAMPLE] id_provider = ad auth_provider = ad access_provider = ad chpass_provider = ad ad_server = dc1.example.com ad_hostname = client.example.com ad_domain = example.com
The AD access control provider checks if the account is expired. It has the same effect as the following configuration of the LDAP provider:
access_provider = ldap ldap_access_order = expire ldap_account_expire_policy = ad
However, unless the “ad” access control provider is explicitly configured, the default access provider is “permit”. Please note that if you configure an access provider other than “ad”, you need to set all the connection parameters (such as LDAP URIs and encryption details) manually.
When the autofs provider is set to “ad”, the RFC2307 schema attribute mapping (nisMap, nisObject, ...) is used, because these attributes are included in the default Active Directory schema.
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sssd-secrets(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8), sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)
Table of Contents
The file has an ini-style syntax and consists of sections and parameters. A section begins with the name of the section in square brackets and continues until the next section begins. An example of section with single and multi-valued parameters:
[section]key=valuekey2=value2,value3
The data types used are string (no quotes needed), integer and bool (with values of “TRUE/FALSE”).
A comment line starts with a hash sign (“#”) or a semicolon (“;”). Inline comments are not supported.
All sections can have an optional
description parameter. Its function
is only as a label for the section.
sssd.conf must be a regular file, owned by
root and only root may read from or write to the file.
The configuration file sssd.conf will
include configuration snippets using the include directory
conf.d. This feature is available if
SSSD was compiled with libini version 1.3.0 or later.
Any file placed in conf.d
that ends in “.conf”
and does not begin with a dot (“.”) will
be used together with sssd.conf
to configure SSSD.
The configuration snippets from conf.d
have higher priority than sssd.conf
and will override sssd.conf when
conflicts occur. If several snippets are present in
conf.d, then they are included in
alphabetical order (based on locale).
Files included later have higher priority. Numerical
prefixes (01_snippet.conf,
02_snippet.conf etc.) can help
visualize the priority (higher number means higher
priority).
The snippet files require the same owner and permissions
as sssd.conf. Which are by default
root:root and 0600.
Following options are usable in more than one configuration sections.
SSSD supports two representations for specifying the debug level. The simplest is to specify a decimal value from 0-9, which represents enabling that level and all lower-level debug messages. The more comprehensive option is to specify a hexadecimal bitmask to enable or disable specific levels (such as if you wish to suppress a level).
Please note that each SSSD service logs into its own log file. Also please note that enabling “debug_level” in the “[sssd]” section only enables debugging just for the sssd process itself, not for the responder or provider processes. The “debug_level” parameter should be added to all sections that you wish to produce debug logs from.
In addition to changing the log level in the config file using the “debug_level” parameter, which is persistent, but requires SSSD restart, it is also possible to change the debug level on the fly using the sss_debuglevel(8) tool.
Currently supported debug levels:
0, 0x0010: Fatal failures. Anything that would prevent SSSD from starting up or causes it to cease running.
1, 0x0020: Critical failures. An error that doesn't kill SSSD, but one that indicates that at least one major feature is not going to work properly.
2, 0x0040: Serious failures. An error announcing that a particular request or operation has failed.
3, 0x0080: Minor failures. These are the errors that would percolate down to cause the operation failure of 2.
4, 0x0100: Configuration settings.
5, 0x0200: Function data.
6, 0x0400: Trace messages for operation functions.
7, 0x1000: Trace messages for internal control functions.
8, 0x2000: Contents of function-internal variables that may be interesting.
9, 0x4000: Extremely low-level tracing information.
To log required bitmask debug levels, simply add their numbers together as shown in following examples:
Example: To log fatal failures, critical failures, serious failures and function data use 0x0270.
Example: To log fatal failures, configuration settings, function data, trace messages for internal control functions use 0x1310.
Note: The bitmask format of debug levels was introduced in 1.7.0.
Default: 0
SSSD 1.14 and later also includes the
debug alias for
debug_level as a
convenience feature. If both are specified, the
value of debug_level
will be used.
Add a timestamp to the debug messages. If journald is enabled for SSSD debug logging this option is ignored.
Default: true
Add microseconds to the timestamp in debug messages. If journald is enabled for SSSD debug logging this option is ignored.
Default: false
Individual pieces of SSSD functionality are provided by special SSSD services that are started and stopped together with SSSD. The services are managed by a special service frequently called “monitor”. The “[sssd]” section is used to configure the monitor as well as some other important options like the identity domains.
Section parameters
Indicates what is the syntax of the config file. SSSD 0.6.0 and later use version 2.
Comma separated list of services that are started when sssd itself starts. The services' list is optional on platforms where systemd is supported, as they will either be socket or D-Bus activated when needed.
Supported services: nss, pam , sudo , autofs , ssh , pac , ifp
By default, all services are disabled and the administrator must enable the ones allowed to be used by executing: "systemctl enable sssd-@service@.socket".
Number of times services should attempt to reconnect in the event of a Data Provider crash or restart before they give up
Default: 3
A domain is a database containing user information. SSSD can use more domains at the same time, but at least one must be configured or SSSD won't start. This parameter describes the list of domains in the order you want them to be queried. A domain name should only consist of alphanumeric ASCII characters, dashes, dots and underscores.
Default regular expression that describes how to parse the string containing user name and domain into these components.
Each domain can have an individual regular expression configured. For some ID providers there are also default regular expressions. See DOMAIN SECTIONS for more info on these regular expressions.
A printf(3)-compatible format that describes how to compose a fully qualified name from user name and domain name components.
The following expansions are supported:
user name
domain name as specified in the SSSD config file.
domain flat name. Mostly usable for Active Directory domains, both directly configured or discovered via IPA trusts.
Each domain can have an individual format string configured. see DOMAIN SECTIONS for more info on this option.
SSSD monitors the state of resolv.conf to identify when it needs to update its internal DNS resolver. By default, we will attempt to use inotify for this, and will fall back to polling resolv.conf every five seconds if inotify cannot be used.
There are some limited situations where it is preferred that we should skip even trying to use inotify. In these rare cases, this option should be set to 'false'
Default: true on platforms where inotify is supported. False on other platforms.
Note: this option will have no effect on platforms where inotify is unavailable. On these platforms, polling will always be used.
Directory on the filesystem where SSSD should store Kerberos replay cache files.
This option accepts a special value __LIBKRB5_DEFAULTS__ that will instruct SSSD to let libkrb5 decide the appropriate location for the replay cache.
Default: Distribution-specific and specified at build-time. (__LIBKRB5_DEFAULTS__ if not configured)
The user to drop the privileges to where appropriate to avoid running as the root user. This option does not work when running socket-activated services, as the user set up to run the processes is set up during compilation time. The way to override the systemd unit files is by creating the appropriate files in /etc/systemd/system/. Keep in mind that any change in the socket user, group or permissions may result in a non-usable SSSD. The same may occur in case of changes of the user running the NSS responder.
Default: not set, process will run as root
This string will be used as a default domain name for all names without a domain name component. The main use case is environments where the primary domain is intended for managing host policies and all users are located in a trusted domain. The option allows those users to log in just with their user name without giving a domain name as well.
Please note that if this option is set all users from the primary domain have to use their fully qualified name, e.g. user@domain.name, to log in. Setting this option changes default of use_fully_qualified_names to True. It is not allowed to use this option together with use_fully_qualified_names set to False.
Default: not set
This parameter will replace spaces (space bar) with the given character for user and group names. e.g. (_). User name "john doe" will be "john_doe" This feature was added to help compatibility with shell scripts that have difficulty handling spaces, due to the default field separator in the shell.
Please note it is a configuration error to use a replacement character that might be used in user or group names. If a name contains the replacement character SSSD tries to return the unmodified name but in general the result of a lookup is undefined.
Default: not set (spaces will not be replaced)
With this parameter the certificate verification can be tuned with a comma separated list of options. Supported options are:
Disables Online Certificate Status Protocol (OCSP) checks. This might be needed if the OCSP servers defined in the certificate are not reachable from the client.
Disables verification completely. This option should only be used for testing.
Sets the OCSP default responder which should be used instead of the one mentioned in the certificate. URL must be replaced with the URL of the OCSP default responder e.g. http://example.com:80/ocsp.
This option must be used together with ocsp_default_responder_signing_cert.
The nickname of the cert to trust (expected) to sign the OCSP responses. The certificate with the given nickname must be available in the systems NSS database.
This option must be used together with ocsp_default_responder.
Unknown options are reported but ignored.
Default: not set, i.e. do not restrict certificate verification
SSSD hooks into the netlink interface to monitor changes to routes, addresses, links and trigger certain actions.
The SSSD state changes caused by netlink events may be undesirable and can be disabled by setting this option to 'true'
Default: false (netlink changes are detected)
When this option is enabled, SSSD prepends an implicit domain with “id_provider=files” before any explicitly configured domains.
Default: false
Default: true
Comma separated list of domains and subdomains representing the lookup order that will be followed. The list doesn't have to include all possible domains as the missing domains will be looked up based on the order they're presented in the “domains” configuration option. The subdomains which are not listed as part of “lookup_order” will be looked up in a random order for each parent domain.
Please, note that when this option is set the output format of all commands is always fully-qualified even when using short names for input, for all users but the ones managed by the files provider. In case the administrator wants the output not fully-qualified, the full_name_format option can be used as shown below: “full_name_format=%1$s” However, keep in mind that during login, login applications often canonicalize the username by calling getpwnam(3) which, if a shortname is returned for a qualified input (while trying to reach a user which exists in multiple domains) might re-route the login attempt into the domain which uses shortnames, making this workaround totally not recommended in cases where usernames may overlap between domains.
Default: Not set
Settings that can be used to configure different services
are described in this section. They should reside in the
[$NAME] section, for example,
for NSS service, the section would be “[nss]”
These options can be used to configure any service.
Number of times services should attempt to reconnect in the event of a Data Provider crash or restart before they give up
Default: 3
This option specifies the maximum number of file descriptors that may be opened at one time by this SSSD process. On systems where SSSD is granted the CAP_SYS_RESOURCE capability, this will be an absolute setting. On systems without this capability, the resulting value will be the lower value of this or the limits.conf "hard" limit.
Default: 8192 (or limits.conf "hard" limit)
This option specifies the number of seconds that a client of an SSSD process can hold onto a file descriptor without communicating on it. This value is limited in order to avoid resource exhaustion on the system. The timeout can't be shorter than 10 seconds. If a lower value is configured, it will be adjusted to 10 seconds.
Default: 60
When SSSD switches to offline mode the amount of time before it tries to go back online will increase based upon the time spent disconnected. This value is in seconds and calculated by the following:
offline_timeout + random_offset
The random offset can increment up to 30 seconds. After each unsuccessful attempt to go online, the new interval is recalculated by the following:
new_interval = old_interval*2 + random_offset
Note that the maximum length of each interval is currently limited to one hour. If the calculated length of new_interval is greater than an hour, it will be forced to one hour.
Default: 60
This option specifies the number of seconds that an SSSD responder process can be up without being used. This value is limited in order to avoid resource exhaustion on the system. The minimum acceptable value for this option is 60 seconds. Setting this option to 0 (zero) means that no timeout will be set up to the responder. This option only has effect when SSSD is built with systemd support and when services are either socket or D-Bus activated.
Default: 300
This option specifies whether the responder should query all caches before querying the Data Providers.
Default: false
These options can be used to configure the Name Service Switch (NSS) service.
How many seconds should nss_sss cache enumerations (requests for info about all users)
Default: 120
The entry cache can be set to automatically update entries in the background if they are requested beyond a percentage of the entry_cache_timeout value for the domain.
For example, if the domain's entry_cache_timeout is set to 30s and entry_cache_nowait_percentage is set to 50 (percent), entries that come in after 15 seconds past the last cache update will be returned immediately, but the SSSD will go and update the cache on its own, so that future requests will not need to block waiting for a cache update.
Valid values for this option are 0-99 and represent a percentage of the entry_cache_timeout for each domain. For performance reasons, this percentage will never reduce the nowait timeout to less than 10 seconds. (0 disables this feature)
Default: 50
Specifies for how many seconds nss_sss should cache negative cache hits (that is, queries for invalid database entries, like nonexistent ones) before asking the back end again.
Default: 15
Specifies for how many seconds nss_sss should keep local users and groups in negative cache before trying to look it up in the back end again. Setting the option to 0 disables this feature.
Default: 14400 (4 hours)
Exclude certain users or groups from being fetched from the sss NSS database. This is particularly useful for system accounts. This option can also be set per-domain or include fully-qualified names to filter only users from the particular domain or by a user principal name (UPN).
NOTE: The filter_groups option doesn't affect inheritance of nested group members, since filtering happens after they are propagated for returning via NSS. E.g. a group having a member group filtered out will still have the member users of the latter listed.
Default: root
If you want filtered user still be group members set this option to false.
Default: true
Override the user's home directory. You can either provide an absolute value or a template. In the template, the following sequences are substituted:
login name
UID number
domain name
fully qualified user name (user@domain)
The first letter of the login name.
UPN - User Principal Name (name@REALM)
The original home directory retrieved from the identity provider.
The value of configure option homedir_substring.
a literal '%'
This option can also be set per-domain.
example:
override_homedir = /home/%u
Default: Not set (SSSD will use the value retrieved from LDAP)
The value of this option will be used in the expansion of the override_homedir option if the template contains the format string %H. An LDAP directory entry can directly contain this template so that this option can be used to expand the home directory path for each client machine (or operating system). It can be set per-domain or globally in the [nss] section. A value specified in a domain section will override one set in the [nss] section.
Default: /home
Set a default template for a user's home directory if one is not specified explicitly by the domain's data provider.
The available values for this option are the same as for override_homedir.
example:
fallback_homedir = /home/%u
Default: not set (no substitution for unset home directories)
Override the login shell for all users. This option supersedes any other shell options if it takes effect and can be set either in the [nss] section or per-domain.
Default: not set (SSSD will use the value retrieved from LDAP)
Restrict user shell to one of the listed values. The order of evaluation is:
1. If the shell is present in “/etc/shells”, it is used.
2. If the shell is in the allowed_shells list but not in “/etc/shells”, use the value of the shell_fallback parameter.
3. If the shell is not in the allowed_shells list and not in “/etc/shells”, a nologin shell is used.
The wildcard (*) can be used to allow any shell.
The (*) is useful if you want to use shell_fallback in case that user's shell is not in “/etc/shells” and maintaining list of all allowed shells in allowed_shells would be to much overhead.
An empty string for shell is passed as-is to libc.
The “/etc/shells” is only read on SSSD start up, which means that a restart of the SSSD is required in case a new shell is installed.
Default: Not set. The user shell is automatically used.
Replace any instance of these shells with the shell_fallback
The default shell to use if an allowed shell is not installed on the machine.
Default: /bin/sh
The default shell to use if the provider does not return one during lookup. This option can be specified globally in the [nss] section or per-domain.
Default: not set (Return NULL if no shell is specified and rely on libc to substitute something sensible when necessary, usually /bin/sh)
Specifies time in seconds for which the list of subdomains will be considered valid.
Default: 60
Specifies time in seconds for which records in the in-memory cache will be valid. Setting this option to zero will disable the in-memory cache.
Default: 300
WARNING: Disabling the in-memory cache will have significant negative impact on SSSD's performance and should only be used for testing.
NOTE: If the environment variable SSS_NSS_USE_MEMCACHE is set to "NO", client applications will not use the fast in-memory cache.
Some of the additional NSS responder requests can return more attributes than just the POSIX ones defined by the NSS interface. The list of attributes is controlled by this option. It is handled the same way as the “user_attributes” option of the InfoPipe responder (see sssd-ifp(5) for details) but with no default values.
To make configuration more easy the NSS responder will check the InfoPipe option if it is not set for the NSS responder.
Default: not set, fallback to InfoPipe option
The value that NSS operations that return users or groups will return for the “password” field.
This option can also be set per-domain.
Default: “*” (remote domains) or “x” (the files domain)
These options can be used to configure the Pluggable Authentication Module (PAM) service.
If the authentication provider is offline, how long should we allow cached logins (in days since the last successful online login).
Default: 0 (No limit)
If the authentication provider is offline, how many failed login attempts are allowed.
Default: 0 (No limit)
The time in minutes which has to pass after offline_failed_login_attempts has been reached before a new login attempt is possible.
If set to 0 the user cannot authenticate offline if offline_failed_login_attempts has been reached. Only a successful online authentication can enable offline authentication again.
Default: 5
Controls what kind of messages are shown to the user during authentication. The higher the number to more messages are displayed.
Currently sssd supports the following values:
0: do not show any message
1: show only important messages
2: show informational messages
3: show all messages and debug information
Default: 1
A comma separated list of strings which allows to remove (filter) data sent by the PAM responder to pam_sss PAM module. There are different kind of responses sent to pam_sss e.g. messages displayed to the user or environment variables which should be set by pam_sss.
While messages already can be controlled with the help of the pam_verbosity option this option allows to filter out other kind of responses as well.
Currently the following filters are supported:
Do not send any environment variables to any service.
Do not send environment variable var_name to any service.
Do not send environment variable var_name to service.
Default: not set
Example: ENV:KRB5CCNAME:sudo-i
For any PAM request while SSSD is online, the SSSD will attempt to immediately update the cached identity information for the user in order to ensure that authentication takes place with the latest information.
A complete PAM conversation may perform multiple PAM requests, such as account management and session opening. This option controls (on a per-client-application basis) how long (in seconds) we can cache the identity information to avoid excessive round-trips to the identity provider.
Default: 5
Display a warning N days before the password expires.
Please note that the backend server has to provide information about the expiration time of the password. If this information is missing, sssd cannot display a warning.
If zero is set, then this filter is not applied, i.e. if the expiration warning was received from backend server, it will automatically be displayed.
This setting can be overridden by setting pwd_expiration_warning for a particular domain.
Default: 0
Specifies time in seconds for which the list of subdomains will be considered valid.
Default: 60
Specifies the comma-separated list of UID values or user names that are allowed to run PAM conversations against trusted domains. Users not included in this list can only access domains marked as public with “pam_public_domains”. User names are resolved to UIDs at startup.
Default: All users are considered trusted by default
Please note that UID 0 is always allowed to access the PAM responder even in case it is not in the pam_trusted_users list.
Specifies the comma-separated list of domain names that are accessible even to untrusted users.
Two special values for pam_public_domains option are defined:
all (Untrusted users are allowed to access all domains in PAM responder.)
none (Untrusted users are not allowed to access any domains PAM in responder.)
Default: none
Allows a custom expiration message to be set, replacing the default 'Permission denied' message.
Note: Please be aware that message is only printed for the SSH service unless pam_verbosity is set to 3 (show all messages and debug information).
example:
pam_account_expired_message = Account expired, please contact help desk.
Default: none
Allows a custom lockout message to be set, replacing the default 'Permission denied' message.
example:
pam_account_locked_message = Account locked, please contact help desk.
Default: none
Enable certificate based Smartcard authentication. Since this requires additional communication with the Smartcard which will delay the authentication process this option is disabled by default.
Default: False
The path to the certificate database which contain the PKCS#11 modules to access the Smartcard.
Default:
/etc/pki/nssdb (NSS version, path to a NSS database)
/etc/sssd/pki/sssd_auth_ca_db.pem (OpenSSL version, path to a file with trusted CA certificates in PEM format)
This man page was generated for the NSS version.
This man page was generated for the OpenSSL version.
How many seconds will pam_sss wait for p11_child to finish.
Default: 10
Which PAM services are permitted to contact domains of type “application”
Default: Not set
A comma-separated list of PAM service names for which it will be allowed to use Smartcards.
It is possible to add another PAM service name to the default set by using “+service_name” or to explicitly remove a PAM service name from the default set by using “-service_name”. For example, in order to replace a default PAM service name for authentication with Smartcards (e.g. “login”) with a custom PAM service name (e.g. “my_pam_service”), you would use the following configuration:
pam_p11_allowed_services = +my_pam_service, -login
Default: the default set of PAM service names includes:
login
su
su-l
gdm-smartcard
gdm-password
kdm
sudo
sudo-i
gnome-screensaver
These options can be used to configure the sudo service. The detailed instructions for configuration of sudo(8) to work with sssd(8) are in the manual page sssd-sudo(5).
Whether or not to evaluate the sudoNotBefore and sudoNotAfter attributes that implement time-dependent sudoers entries.
Default: false
Maximum number of expired rules that can be refreshed at once. If number of expired rules is below threshold, those rules are refreshed with “rules refresh” mechanism. If the threshold is exceeded a “full refresh” of sudo rules is triggered instead. This threshold number also applies to IPA sudo command and command group searches.
Default: 50
These options can be used to configure the autofs service.
Specifies for how many seconds should the autofs responder negative cache hits (that is, queries for invalid map entries, like nonexistent ones) before asking the back end again.
Default: 15
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.
These options can be used to configure the SSH service.
Whether or not to hash host names and addresses in the managed known_hosts file.
Default: true
How many seconds to keep a host in the managed known_hosts file after its host keys were requested.
Default: 180
If set to true the sss_ssh_authorizedkeys will return ssh keys derived from the public key of X.509 certificates stored in the user entry as well. See sss_ssh_authorizedkeys(1) for details.
Default: true
Path to a storage of trusted CA certificates. The option is used to validate user certificates before deriving public ssh keys from them.
Default:
/etc/pki/nssdb (NSS version, path to a NSS database)
/etc/sssd/pki/sssd_auth_ca_db.pem (OpenSSL version, path to a file with trusted CA certificates in PEM format)
This man page was generated for the NSS version.
This man page was generated for the OpenSSL version.
The PAC responder works together with the authorization data plugin for MIT Kerberos sssd_pac_plugin.so and a sub-domain provider. The plugin sends the PAC data during a GSSAPI authentication to the PAC responder. The sub-domain provider collects domain SID and ID ranges of the domain the client is joined to and of remote trusted domains from the local domain controller. If the PAC is decoded and evaluated some of the following operations are done:
If the remote user does not exist in the cache, it is created. The UID is determined with the help of the SID, trusted domains will have UPGs and the GID will have the same value as the UID. The home directory is set based on the subdomain_homedir parameter. The shell will be empty by default, i.e. the system defaults are used, but can be overwritten with the default_shell parameter.
If there are SIDs of groups from domains sssd knows about, the user will be added to those groups.
These options can be used to configure the PAC responder.
Specifies the comma-separated list of UID values or user names that are allowed to access the PAC responder. User names are resolved to UIDs at startup.
Default: 0 (only the root user is allowed to access the PAC responder)
Please note that although the UID 0 is used as the default it will be overwritten with this option. If you still want to allow the root user to access the PAC responder, which would be the typical case, you have to add 0 to the list of allowed UIDs as well.
Lifetime of the PAC entry in seconds. As long as the PAC is valid the PAC data can be used to determine the group memberships of a user.
Default: 300
Session recording works in conjunction with tlog-rec-session(8), a part of tlog package, to log what users see and type when they log in on a text terminal. See also sssd-session-recording(5).
These options can be used to configure session recording.
One of the following strings specifying the scope of session recording:
No users are recorded.
Users/groups specified by
users
and
groups
options are recorded.
All users are recorded.
Default: "none"
A comma-separated list of users which should have session recording enabled. Matches user names as returned by NSS. I.e. after the possible space replacement, case changes, etc.
Default: Empty. Matches no users.
A comma-separated list of groups, members of which should have session recording enabled. Matches group names as returned by NSS. I.e. after the possible space replacement, case changes, etc.
NOTE: using this option (having it set to anything) has a considerable performance cost, because each uncached request for a user requires retrieving and matching the groups the user is member of.
Default: Empty. Matches no groups.
These configuration options can be present in a domain
configuration section, that is, in a section called
“[domain/NAME]”
Specifies whether the domain is meant to be used by POSIX-aware clients such as the Name Service Switch or by applications that do not need POSIX data to be present or generated. Only objects from POSIX domains are available to the operating system interfaces and utilities.
Allowed values for this option are “posix” and “application”.
POSIX domains are reachable by all services. Application domains are only reachable from the InfoPipe responder (see sssd-ifp(5)) and the PAM responder.
NOTE: The application domains are currently well tested with “id_provider=ldap” only.
For an easy way to configure a non-POSIX domains, please see the “Application domains” section.
Default: posix
UID and GID limits for the domain. If a domain contains an entry that is outside these limits, it is ignored.
For users, this affects the primary GID limit. The user will not be returned to NSS if either the UID or the primary GID is outside the range. For non-primary group memberships, those that are in range will be reported as expected.
These ID limits affect even saving entries to cache, not only returning them by name or ID.
Default: 1 for min_id, 0 (no limit) for max_id
Determines if a domain can be enumerated, that is, whether the domain can list all the users and group it contains. Note that it is not required to enable enumeration in order for secondary groups to be displayed. This parameter can have one of the following values:
TRUE = Users and groups are enumerated
FALSE = No enumerations for this domain
Default: FALSE
Enumerating a domain requires SSSD to download and store ALL user and group entries from the remote server.
Note: Enabling enumeration has a moderate performance impact on SSSD while enumeration is running. It may take up to several minutes after SSSD startup to fully complete enumerations. During this time, individual requests for information will go directly to LDAP, though it may be slow, due to the heavy enumeration processing. Saving a large number of entries to cache after the enumeration completes might also be CPU intensive as the memberships have to be recomputed. This can lead to the “sssd_be” process becoming unresponsive or even restarted by the internal watchdog.
While the first enumeration is running, requests for the complete user or group lists may return no results until it completes.
Further, enabling enumeration may increase the time necessary to detect network disconnection, as longer timeouts are required to ensure that enumeration lookups are completed successfully. For more information, refer to the man pages for the specific id_provider in use.
For the reasons cited above, enabling enumeration is not recommended, especially in large environments.
Whether any of autodetected trusted domains should be enumerated. The supported values are:
All discovered trusted domains will be enumerated
No discovered trusted domains will be enumerated
Optionally, a list of one or more domain names can enable enumeration just for these trusted domains.
Default: none
How many seconds should nss_sss consider entries valid before asking the backend again
The cache expiration timestamps are stored as attributes of individual objects in the cache. Therefore, changing the cache timeout only has effect for newly added or expired entries. You should run the sss_cache(8) tool in order to force refresh of entries that have already been cached.
Default: 5400
How many seconds should nss_sss consider user entries valid before asking the backend again
Default: entry_cache_timeout
How many seconds should nss_sss consider group entries valid before asking the backend again
Default: entry_cache_timeout
How many seconds should nss_sss consider netgroup entries valid before asking the backend again
Default: entry_cache_timeout
How many seconds should nss_sss consider service entries valid before asking the backend again
Default: entry_cache_timeout
How many seconds should sudo consider rules valid before asking the backend again
Default: entry_cache_timeout
How many seconds should the autofs service consider automounter maps valid before asking the backend again
Default: entry_cache_timeout
How many seconds to keep a host ssh key after refresh. IE how long to cache the host key for.
Default: entry_cache_timeout
Specifies how many seconds SSSD has to wait before triggering a background refresh task which will refresh all expired or nearly expired records.
The background refresh will process users, groups and netgroups in the cache. For users who have performed the initgroups (get group membership for user, typically ran at login) operation in the past, both the user entry and the group membership are updated.
This option is automatically inherited for all trusted domains.
You can consider setting this value to 3/4 * entry_cache_timeout.
Default: 0 (disabled)
Determines if user credentials are also cached in the local LDB cache
User credentials are stored in a SHA512 hash, not in plaintext
Default: FALSE
If 2-Factor-Authentication (2FA) is used and credentials should be saved this value determines the minimal length the first authentication factor (long term password) must have to be saved as SHA512 hash into the cache.
This should avoid that the short PINs of a PIN based 2FA scheme are saved in the cache which would make them easy targets for brute-force attacks.
Default: 8
Number of days entries are left in cache after last successful login before being removed during a cleanup of the cache. 0 means keep forever. The value of this parameter must be greater than or equal to offline_credentials_expiration.
Default: 0 (unlimited)
Display a warning N days before the password expires.
If zero is set, then this filter is not applied, i.e. if the expiration warning was received from backend server, it will automatically be displayed.
Please note that the backend server has to provide information about the expiration time of the password. If this information is missing, sssd cannot display a warning. Also an auth provider has to be configured for the backend.
Default: 7 (Kerberos), 0 (LDAP)
The identification provider used for the domain. Supported ID providers are:
“proxy”: Support a legacy NSS provider.
“local”: SSSD internal provider for local users (DEPRECATED).
“files”: FILES provider. See sssd-files(5) for more information on how to mirror local users and groups into SSSD.
“ldap”: LDAP provider. See sssd-ldap(5) for more information on configuring LDAP.
“ipa”: FreeIPA and Red Hat Enterprise Identity Management provider. See sssd-ipa(5) for more information on configuring FreeIPA.
“ad”: Active Directory provider. See sssd-ad(5) for more information on configuring Active Directory.
Use the full name and domain (as formatted by the domain's full_name_format) as the user's login name reported to NSS.
If set to TRUE, all requests to this domain must use fully qualified names. For example, if used in LOCAL domain that contains a "test" user, getent passwd test wouldn't find the user while getent passwd test@LOCAL would.
NOTE: This option has no effect on netgroup lookups due to their tendency to include nested netgroups without qualified names. For netgroups, all domains will be searched when an unqualified name is requested.
Default: FALSE (TRUE if default_domain_suffix is used)
Do not return group members for group lookups.
If set to TRUE, the group membership attribute is not requested from the ldap server, and group members are not returned when processing group lookup calls, such as getgrnam(3) or getgrgid(3). As an effect, “getent group $groupname” would return the requested group as if it was empty.
Enabling this option can also make access provider checks for group membership significantly faster, especially for groups containing many members.
Default: FALSE
The authentication provider used for the domain. Supported auth providers are:
“ldap” for native LDAP authentication. See sssd-ldap(5) for more information on configuring LDAP.
“krb5” for Kerberos authentication. See sssd-krb5(5) for more information on configuring Kerberos.
“ipa”: FreeIPA and Red Hat Enterprise Identity Management provider. See sssd-ipa(5) for more information on configuring FreeIPA.
“ad”: Active Directory provider. See sssd-ad(5) for more information on configuring Active Directory.
“proxy” for relaying authentication to some other PAM target.
“local”: SSSD internal provider for local users
“none” disables authentication explicitly.
Default: “id_provider” is used if it is set and can handle authentication requests.
The access control provider used for the domain. There are two built-in access providers (in addition to any included in installed backends) Internal special providers are:
“permit” always allow access. It's the only permitted access provider for a local domain.
“deny” always deny access.
“ldap” for native LDAP authentication. See sssd-ldap(5) for more information on configuring LDAP.
“ipa”: FreeIPA and Red Hat Enterprise Identity Management provider. See sssd-ipa(5) for more information on configuring FreeIPA.
“ad”: Active Directory provider. See sssd-ad(5) for more information on configuring Active Directory.
“simple” access control based on access or deny lists. See sssd-simple(5) for more information on configuring the simple access module.
“krb5”: .k5login based access control. See sssd-krb5(5) for more information on configuring Kerberos.
“proxy” for relaying access control to another PAM module.
Default: “permit”
The provider which should handle change password operations for the domain. Supported change password providers are:
“ldap” to change a password stored in a LDAP server. See sssd-ldap(5) for more information on configuring LDAP.
“krb5” to change the Kerberos password. See sssd-krb5(5) for more information on configuring Kerberos.
“ipa”: FreeIPA and Red Hat Enterprise Identity Management provider. See sssd-ipa(5) for more information on configuring FreeIPA.
“ad”: Active Directory provider. See sssd-ad(5) for more information on configuring Active Directory.
“proxy” for relaying password changes to some other PAM target.
“none” disallows password changes explicitly.
Default: “auth_provider” is used if it is set and can handle change password requests.
The SUDO provider used for the domain. Supported SUDO providers are:
“ldap” for rules stored in LDAP. See sssd-ldap(5) for more information on configuring LDAP.
“ipa” the same as “ldap” but with IPA default settings.
“ad” the same as “ldap” but with AD default settings.
“none” disables SUDO explicitly.
Default: The value of “id_provider” is used if it is set.
The detailed instructions for configuration of sudo_provider are in the manual page sssd-sudo(5). There are many configuration options that can be used to adjust the behavior. Please refer to "ldap_sudo_*" in sssd-ldap(5).
NOTE: Sudo rules are periodically downloaded in the background unless the sudo provider is explicitly disabled. Set sudo_provider = None to disable all sudo-related activity in SSSD if you do not want to use sudo with SSSD at all.
The provider which should handle loading of selinux settings. Note that this provider will be called right after access provider ends. Supported selinux providers are:
“ipa” to load selinux settings from an IPA server. See sssd-ipa(5) for more information on configuring IPA.
“none” disallows fetching selinux settings explicitly.
Default: “id_provider” is used if it is set and can handle selinux loading requests.
The provider which should handle fetching of subdomains. This value should be always the same as id_provider. Supported subdomain providers are:
“ipa” to load a list of subdomains from an IPA server. See sssd-ipa(5) for more information on configuring IPA.
“ad” to load a list of subdomains from an Active Directory server. See sssd-ad(5) for more information on configuring the AD provider.
“none” disallows fetching subdomains explicitly.
Default: The value of “id_provider” is used if it is set.
The provider which configures and manages user session related tasks. The only user session task currently provided is the integration with Fleet Commander, which works only with IPA. Supported session providers are:
“ipa” to allow performing user session related tasks.
“none” does not perform any kind of user session related tasks.
Default: “id_provider” is used if it is set and can perform session related tasks.
NOTE: In order to have this feature working as expected SSSD must be running as "root" and not as the unprivileged user.
The autofs provider used for the domain. Supported autofs providers are:
“ldap” to load maps stored in LDAP. See sssd-ldap(5) for more information on configuring LDAP.
“ipa” to load maps stored in an IPA server. See sssd-ipa(5) for more information on configuring IPA.
“ad” to load maps stored in an AD server. See sssd-ad(5) for more information on configuring the AD provider.
“none” disables autofs explicitly.
Default: The value of “id_provider” is used if it is set.
The provider used for retrieving host identity information. Supported hostid providers are:
“ipa” to load host identity stored in an IPA server. See sssd-ipa(5) for more information on configuring IPA.
“none” disables hostid explicitly.
Default: The value of “id_provider” is used if it is set.
Regular expression for this domain that describes how to parse the string containing user name and domain into these components. The "domain" can match either the SSSD configuration domain name, or, in the case of IPA trust subdomains and Active Directory domains, the flat (NetBIOS) name of the domain.
Default for the AD and IPA provider: “(((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))” which allows three different styles for user names:
username
username@domain.name
domain\username
While the first two correspond to the general default the third one is introduced to allow easy integration of users from Windows domains.
Default: “(?P<name>[^@]+)@?(?P<domain>[^@]*$)” which translates to "the name is everything up to the “@” sign, the domain everything after that"
NOTE: Some Active Directory groups, typically those used for MS Exchange contain an “@” sign in the name, which clashes with the default re_expression value for the AD and IPA providers. To support these groups, consider changing the re_expression value to: “((?P<name>.+)@(?P<domain>[^@]+$))”.
A printf(3)-compatible format that describes how to compose a fully qualified name from user name and domain name components.
The following expansions are supported:
user name
domain name as specified in the SSSD config file.
domain flat name. Mostly usable for Active Directory domains, both directly configured or discovered via IPA trusts.
Default: “%1$s@%2$s”.
Provides the ability to select preferred address family to use when performing DNS lookups.
Supported values:
ipv4_first: Try looking up IPv4 address, if that fails, try IPv6
ipv4_only: Only attempt to resolve hostnames to IPv4 addresses.
ipv6_first: Try looking up IPv6 address, if that fails, try IPv4
ipv6_only: Only attempt to resolve hostnames to IPv6 addresses.
Default: ipv4_first
Defines the amount of time (in seconds) to wait for a reply from the internal fail over service before assuming that the service is unreachable. If this timeout is reached, the domain will continue to operate in offline mode.
Please see the section “FAILOVER” for more information about the service resolution.
Default: 6
If service discovery is used in the back end, specifies the domain part of the service discovery DNS query.
Default: Use the domain part of machine's hostname
Override the primary GID value with the one specified.
Treat user and group names as case sensitive. At the moment, this option is not supported in the local provider. Possible option values are:
Case sensitive. This value is invalid for AD provider.
Case insensitive.
Same as False (case insensitive), but does not lowercase names in the result of NSS operations. Note that name aliases (and in case of services also protocol names) are still lowercased in the output.
Default: True (False for AD provider)
Specifies a list of configuration parameters that should be inherited by a subdomain. Please note that only selected parameters can be inherited. Currently the following options can be inherited:
ignore_group_members
ldap_purge_cache_timeout
ldap_use_tokengroups
ldap_user_principal
ldap_krb5_keytab (the value of krb5_keytab will be used if ldap_krb5_keytab is not set explicitly)
Example:
subdomain_inherit = ldap_purge_cache_timeout
Default: none
Note: This option only works with the IPA and AD provider.
Use this homedir as default value for all subdomains within this domain in IPA AD trust. See override_homedir for info about possible values. In addition to those, the expansion below can only be used with subdomain_homedir.
flat (NetBIOS) name of a subdomain.
The value can be overridden by override_homedir option.
Default: /home/%d/%u
Various tags stored by the realmd configuration service for this domain.
Specifies time in seconds since last successful online authentication for which user will be authenticated using cached credentials while SSSD is in the online mode. If the credentials are incorrect, SSSD falls back to online authentication.
This option's value is inherited by all trusted domains. At the moment it is not possible to set a different value per trusted domain.
Special value 0 implies that this feature is disabled.
Please note that if “cached_auth_timeout” is longer than “pam_id_timeout” then the back end could be called to handle “initgroups.”
Default: 0
This option takes any of three available values:
Create user's private group unconditionally from user's UID number. The GID number is ignored in this case.
NOTE: Because the GID number and the user private group are inferred from the UID number, it is not supported to have multiple entries with the same UID or GID number with this option. In other words, enabling this option enforces uniqueness across the ID space.
Always use the user's primary GID number. The GID number must refer to a group object in the LDAP database.
A primary group is autogenerated for user entries whose UID and GID numbers have the same value and at the same time the GID number does not correspond to a real group object in LDAP If the values are the same, but the primary GID in the user entry is also used by a group object, the primary GID of the user resolves to that group object.
If the UID and GID of a user are different, then the GID must correspond to a group entry, otherwise the GID is simply not resolvable.
This feature is useful for environments that wish to stop maintaining a separate group objects for the user private groups, but also wish to retain the existing user private groups.
For subdomains, the default value is False for subdomains that use assigned POSIX IDs and True for subdomains that use automatic ID-mapping.
The value of auto_private_groups can either be set per subdomains in a subsection, for example:
[domain/forest.domain/sub.domain] auto_private_groups = false
or globally for all subdomains in the main domain section using the subdomain_inherit option:
[domain/forest.domain] subdomain_inherit = auto_private_groups auto_private_groups = false
Options valid for proxy domains.
The proxy target PAM proxies to.
Default: not set by default, you have to take an existing pam configuration or create a new one and add the service name here.
The name of the NSS library to use in proxy domains. The NSS functions searched for in the library are in the form of _nss_$(libName)_$(function), for example _nss_files_getpwent.
When a user or group is looked up by name in the proxy provider, a second lookup by ID is performed to "canonicalize" the name in case the requested name was an alias. Setting this option to true would cause the SSSD to perform the ID lookup from cache for performance reasons.
Default: false
This option specifies the number of pre-forked proxy children. It is useful for high-load SSSD environments where sssd may run out of available child slots, which would cause some issues due to the requests being queued.
Default: 10
SSSD, with its D-Bus interface (see
sssd-ifp(5)) is appealing to applications
as a gateway to an LDAP directory where users and groups
are stored. However, contrary to the traditional SSSD
deployment where all users and groups either have POSIX
attributes or those attributes can be inferred from the
Windows SIDs, in many cases the users and groups in the
application support scenario have no POSIX attributes.
Instead of setting a
“[domain/NAME]”
section, the administrator can set up an
“[application/NAME]”
section that internally represents a domain with type
“application” optionally inherits settings
from a tradition SSSD domain.
Please note that the application domain must still be explicitly enabled in the “domains” parameter so that the lookup order between the application domain and its POSIX sibling domain is set correctly.
Application domain parameters
The SSSD POSIX-type domain the application domain inherits all settings from. The application domain can moreover add its own settings to the application settings that augment or override the “sibling” domain settings.
Default: Not set
The following example illustrates the use of an application domain. In this setup, the POSIX domain is connected to an LDAP server and is used by the OS through the NSS responder. In addition, the application domain also requests the telephoneNumber attribute, stores it as the phone attribute in the cache and makes the phone attribute reachable through the D-Bus interface.
[sssd] domains = appdom, posixdom [ifp] user_attributes = +phone [domain/posixdom] id_provider = ldap ldap_uri = ldap://ldap.example.com ldap_search_base = dc=example,dc=com [application/appdom] inherit_from = posixdom ldap_user_extra_attrs = phone:telephoneNumber
This section contains settings for domain that stores users and
groups in SSSD native database, that is, a domain that uses
id_provider=local.
Section parameters
The default shell for users created with SSSD userspace tools.
Default: /bin/bash
The tools append the login name to
base_directory and
use that as the home directory.
Default: /home
Indicate if a home directory should be created by default for new users. Can be overridden on command line.
Default: TRUE
Indicate if a home directory should be removed by default for deleted users. Can be overridden on command line.
Default: TRUE
Used by sss_useradd(8) to specify the default permissions on a newly created home directory.
Default: 077
The skeleton directory, which contains files and directories to be copied in the user's home directory, when the home directory is created by sss_useradd(8)
Default: /etc/skel
The mail spool directory. This is needed to manipulate the mailbox when its corresponding user account is modified or deleted. If not specified, a default value is used.
Default: /var/mail
The command that is run after a user is removed. The command us passed the username of the user being removed as the first and only parameter. The return code of the command is not taken into account.
Default: None, no command is run
Some options used in the domain section can also be used in the
trusted domain section, that is, in a section called
“[domain/DOMAIN_NAME/TRUSTED_DOMAIN_NAME]”.
Where DOMAIN_NAME is the actual joined-to base domain. Please refer
to examples below for explanation.
Currently supported options in the trusted domain section are:
ldap_search_base,
ldap_user_search_base,
ldap_group_search_base,
ldap_netgroup_search_base,
ldap_service_search_base,
ldap_sasl_mech,
ad_server,
ad_backup_server,
ad_site,
use_fully_qualified_names
For more details about these options see their individual description in the manual page.
If a special file
(/var/lib/sss/pubconf/pam_preauth_available)
exists SSSD's PAM module pam_sss will ask SSSD to figure out which
authentication methods are available for the user trying to log in.
Based on the results pam_sss will prompt the user for appropriate
credentials.
With the growing number of authentication methods and the possibility that there are multiple ones for a single user the heuristic used by pam_sss to select the prompting might not be suitable for all use cases. To following options should provide a better flexibility here.
Each supported authentication method has it's own configuration sub-section under “[prompting/...]”. Currently there are:
to configure password prompting, allowed options are:
to change the string of the password prompt
to configure two-factor authentication prompting, allowed options are:
to change the string of the prompt for the first factor
to change the string of the prompt for the second factor
boolean value, if True there will be only a single prompt using the value of first_prompt where it is expected that both factor are entered as a single string
It is possible to add a sub-section for specific PAM services like e.g. “[prompting/password/sshd]” to individual change the prompting for this service.
1. The following example shows a typical SSSD config. It does not describe configuration of the domains themselves - refer to documentation on configuring domains for more details.
[sssd] domains = LDAP services = nss, pam config_file_version = 2 [nss] filter_groups = root filter_users = root [pam] [domain/LDAP] id_provider = ldap ldap_uri = ldap://ldap.example.com ldap_search_base = dc=example,dc=com auth_provider = krb5 krb5_server = kerberos.example.com krb5_realm = EXAMPLE.COM cache_credentials = true min_id = 10000 max_id = 20000 enumerate = False
2. The following example shows configuration of IPA AD trust where the AD forest consists of two domains in a parent-child structure. Suppose IPA domain (ipa.com) has trust with AD domain(ad.com). ad.com has child domain (child.ad.com). To enable shortnames in the child domain the following configuration should be used.
[domain/ipa.com/child.ad.com] use_fully_qualified_names = false
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sssd-secrets(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8), sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)
Table of Contents
sss_debuglevel is deprecated and replaced by the sssctl debug-level command. Please refer to the sssctl man page for more information on sssctl usage.
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sssd-secrets(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8), sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)
Table of Contents
This manual page describes the files provider for sssd(8). For a detailed syntax reference, refer to the “FILE FORMAT” section of the sssd.conf(5) manual page.
The files provider mirrors the content of the passwd(5) and group(5) files. The purpose of the files provider is to make the users and groups traditionally only accessible with NSS interfaces also available through the SSSD interfaces such as sssd-ifp(5).
In addition to the options listed below, generic SSSD domain options can be set where applicable. Refer to the section “DOMAIN SECTIONS” of the sssd.conf(5) manual page for details on the configuration of an SSSD domain.
Comma-separated list of one or multiple password filenames to be read and enumerated by the files provider, inotify monitor watches will be set on each file to detect changes dynamically.
Default: /etc/passwd
Comma-separated list of one or multiple group filenames to be read and enumerated by the files provider, inotify monitor watches will be set on each file to detect changes dynamically.
Default: /etc/group
The following example assumes that SSSD is correctly
configured and files is one of the domains in the
[sssd] section.
[domain/files] id_provider = files
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sssd-secrets(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8), sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)
Table of Contents
This manual page describes the configuration of the InfoPipe responder for sssd(8). For a detailed syntax reference, refer to the “FILE FORMAT” section of the sssd.conf(5) manual page.
The InfoPipe responder provides a public D-Bus interface accessible over the system bus. The interface allows the user to query information about remote users and groups over the system bus.
These options can be used to configure the InfoPipe responder.
Specifies the comma-separated list of UID values or user names that are allowed to access the InfoPipe responder. User names are resolved to UIDs at startup.
Default: 0 (only the root user is allowed to access the InfoPipe responder)
Please note that although the UID 0 is used as the default it will be overwritten with this option. If you still want to allow the root user to access the InfoPipe responder, which would be the typical case, you have to add 0 to the list of allowed UIDs as well.
Specifies the comma-separated list of white or blacklisted attributes.
By default, the InfoPipe responder only allows the default set of POSIX attributes to be requested. This set is the same as returned by getpwnam(3) and includes:
user's login name
user ID
primary group ID
user information, typically full name
home directory
user shell
It is possible to add another attribute to this set by using “+attr_name” or explicitly remove an attribute using “-attr_name”. For example, to allow “telephoneNumber” but deny “loginShell”, you would use the following configuration:
user_attributes = +telephoneNumber, -loginShell
Default: not set. Only the default set of POSIX attributes is allowed.
Specifies an upper limit on the number of entries that are downloaded during a wildcard lookup that overrides caller-supplied limit.
Default: 0 (let the caller set an upper limit)
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sssd-secrets(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8), sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)
Table of Contents
This manual page describes the configuration of the IPA provider for sssd(8). For a detailed syntax reference, refer to the “FILE FORMAT” section of the sssd.conf(5) manual page.
The IPA provider is a back end used to connect to an IPA server. (Refer to the freeipa.org web site for information about IPA servers.) This provider requires that the machine be joined to the IPA domain; configuration is almost entirely self-discovered and obtained directly from the server.
The IPA provider enables SSSD to use the sssd-ldap(5) identity provider and the sssd-krb5(5) authentication provider with optimizations for IPA environments. The IPA provider accepts the same options used by the sssd-ldap and sssd-krb5 providers with some exceptions. However, it is neither necessary nor recommended to set these options.
The IPA provider primarily copies the traditional ldap and krb5 provider default options with some exceptions, the differences are listed in the “MODIFIED DEFAULT OPTIONS” section.
As an access provider, the IPA provider uses HBAC (host-based access control) rules. Please refer to freeipa.org for more information about HBAC. No configuration of access provider is required on the client side.
If “auth_provider=ipa” or “access_provider=ipa” is configured in sssd.conf then the id_provider must also be set to “ipa”.
The IPA provider will use the PAC responder if the Kerberos tickets of users from trusted realms contain a PAC. To make configuration easier the PAC responder is started automatically if the IPA ID provider is configured.
Refer to the section “DOMAIN SECTIONS” of the sssd.conf(5) manual page for details on the configuration of an SSSD domain.
Specifies the name of the IPA domain. This is optional. If not provided, the configuration domain name is used.
The comma-separated list of IP addresses or hostnames of the IPA servers to which SSSD should connect in the order of preference. For more information on failover and server redundancy, see the “FAILOVER” section. This is optional if autodiscovery is enabled. For more information on service discovery, refer to the “SERVICE DISCOVERY” section.
Optional. May be set on machines where the hostname(5) does not reflect the fully qualified name used in the IPA domain to identify this host. The hostname must be fully qualified.
Optional. This option tells SSSD to automatically update the DNS server built into FreeIPA with the IP address of this client. The update is secured using GSS-TSIG. The IP address of the IPA LDAP connection is used for the updates, if it is not otherwise specified by using the “dyndns_iface” option.
NOTE: On older systems (such as RHEL 5), for this behavior to work reliably, the default Kerberos realm must be set properly in /etc/krb5.conf
NOTE: While it is still possible to use the old ipa_dyndns_update option, users should migrate to using dyndns_update in their config file.
Default: false
The TTL to apply to the client DNS record when updating it. If dyndns_update is false this has no effect. This will override the TTL serverside if set by an administrator.
NOTE: While it is still possible to use the old ipa_dyndns_ttl option, users should migrate to using dyndns_ttl in their config file.
Default: 1200 (seconds)
Optional. Applicable only when dyndns_update is true. Choose the interface or a list of interfaces whose IP addresses should be used for dynamic DNS updates. Special value “*” implies that IPs from all interfaces should be used.
NOTE: While it is still possible to use the old ipa_dyndns_iface option, users should migrate to using dyndns_iface in their config file.
Default: Use the IP addresses of the interface which is used for IPA LDAP connection
Example: dyndns_iface = em1, vnet1, vnet2
Whether the nsupdate utility should use GSS-TSIG authentication for secure updates with the DNS server, insecure updates can be sent by setting this option to 'none'.
Default: GSS-TSIG
Enables DNS sites - location based service discovery.
If true and service discovery (see Service Discovery paragraph at the bottom of the man page) is enabled, then the SSSD will first attempt location based discovery using a query that contains "_location.hostname.example.com" and then fall back to traditional SRV discovery. If the location based discovery succeeds, the IPA servers located with the location based discovery are treated as primary servers and the IPA servers located using the traditional SRV discovery are used as back up servers
Default: false
How often should the back end perform periodic DNS update in addition to the automatic update performed when the back end goes online. This option is optional and applicable only when dyndns_update is true.
Default: 0 (disabled)
Whether the PTR record should also be explicitly updated when updating the client's DNS records. Applicable only when dyndns_update is true.
This option should be False in most IPA deployments as the IPA server generates the PTR records automatically when forward records are changed.
Default: False (disabled)
Whether the nsupdate utility should default to using TCP for communicating with the DNS server.
Default: False (let nsupdate choose the protocol)
The DNS server to use when performing a DNS update. In most setups, it's recommended to leave this option unset.
Setting this option makes sense for environments where the DNS server is different from the identity server.
Please note that this option will be only used in fallback attempt when previous attempt using autodetected settings failed.
Default: None (let nsupdate choose the server)
Optional. Use the given string as search base for Desktop Profile related objects.
Default: Use base DN
Optional. Use the given string as search base for HBAC related objects.
Default: Use base DN
Deprecated. Use ldap_host_search_base instead.
Optional. Use the given string as search base for SELinux user maps.
See “ldap_search_base” for information about configuring multiple search bases.
Default: the value of ldap_search_base
Optional. Use the given string as search base for trusted domains.
See “ldap_search_base” for information about configuring multiple search bases.
Default: the value of cn=trusts,%basedn
Optional. Use the given string as search base for master domain object.
See “ldap_search_base” for information about configuring multiple search bases.
Default: the value of cn=ad,cn=etc,%basedn
Optional. Use the given string as search base for views containers.
See “ldap_search_base” for information about configuring multiple search bases.
Default: the value of cn=views,cn=accounts,%basedn
The name of the Kerberos realm. This is optional and defaults to the value of “ipa_domain”.
The name of the Kerberos realm has a special meaning in IPA - it is converted into the base DN to use for performing LDAP operations.
Absolute path of a directory where SSSD should place Kerberos configuration snippets.
To disable the creation of the configuration snippets set the parameter to 'none'.
Default: not set (krb5.include.d subdirectory of SSSD's pubconf directory)
The amount of time between lookups of the Desktop Profile rules against the IPA server. This will reduce the latency and load on the IPA server if there are many desktop profiles requests made in a short period.
Default: 5 (seconds)
The amount of time between lookups of the Desktop Profile rules against the IPA server in case the last request did not return any rule.
Default: 60 (minutes)
The amount of time between lookups of the HBAC rules against the IPA server. This will reduce the latency and load on the IPA server if there are many access-control requests made in a short period.
Default: 5 (seconds)
The amount of time between lookups of the SELinux maps against the IPA server. This will reduce the latency and load on the IPA server if there are many user login requests made in a short period.
Default: 5 (seconds)
This option will be set by the IPA installer (ipa-server-install) automatically and denotes if SSSD is running on an IPA server or not.
On an IPA server SSSD will lookup users and groups from trusted domains directly while on a client it will ask an IPA server.
NOTE: There are currently some assumptions that must be met when SSSD is running on an IPA server.
The “ipa_server” option must be configured to point to the IPA server itself. This is already the default set by the IPA installer, so no manual change is required.
The “full_name_format” option must not be tweaked to only print short names for users from trusted domains.
Default: false
The automounter location this IPA client will be using
Default: The location named "default"
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.
SSSD can handle views and overrides which are offered by FreeIPA 4.1 and later version. Since all paths and objectclasses are fixed on the server side there is basically no need to configure anything. For completeness the related options are listed here with their default values.
Objectclass of the view container.
Default: nsContainer
Name of the attribute holding the name of the view.
Default: cn
Objectclass of the override objects.
Default: ipaOverrideAnchor
Name of the attribute containing the reference to the original object in a remote domain.
Default: ipaAnchorUUID
Name of the objectclass for user overrides. It is used to determine if the found override object is related to a user or a group.
User overrides can contain attributes given by
ldap_user_name
ldap_user_uid_number
ldap_user_gid_number
ldap_user_gecos
ldap_user_home_directory
ldap_user_shell
ldap_user_ssh_public_key
Default: ipaUserOverride
Name of the objectclass for group overrides. It is used to determine if the found override object is related to a user or a group.
Group overrides can contain attributes given by
ldap_group_name
ldap_group_gid_number
Default: ipaGroupOverride
Certain option defaults do not match their respective backend provider defaults, these option names and IPA provider-specific defaults are listed below:
ldap_schema = ipa_v1
ldap_force_upper_case_realm = true
ldap_sasl_mech = GSSAPI
ldap_sasl_minssf = 56
ldap_account_expire_policy = ipa
ldap_use_tokengroups = true
The IPA subdomains provider behaves slightly differently if it is configured explicitly or implicitly.
If the option 'subdomains_provider = ipa' is found in the domain section of sssd.conf, the IPA subdomains provider is configured explicitly, and all subdomain requests are sent to the IPA server if necessary.
If the option 'subdomains_provider' is not set in the domain section of sssd.conf but there is the option 'id_provider = ipa', the IPA subdomains provider is configured implicitly. In this case, if a subdomain request fails and indicates that the server does not support subdomains, i.e. is not configured for trusts, the IPA subdomains provider is disabled. After an hour or after the IPA provider goes online, the subdomains provider is enabled again.
Some configuration options can be also set for a trusted domain. A trusted domain configuration can either be done using a subsection, for example:
[domain/ipa.domain.com/ad.domain.com] ad_server = dc.ad.domain.com
In addition, some options can be set in the parent domain and inherited by the trusted domain using the “subdomain_inherit” option. For more details, see the sssd.conf(5) manual page.
Different configuration options are tunable for a trusted domain depending on whether you are configuring SSSD on an IPA server or an IPA client.
The following options can be set in a subdomain section on an IPA master:
ad_server
ad_backup_server
ad_site
ldap_search_base
ldap_user_search_base
ldap_group_search_base
use_fully_qualified_names
The following options can be set in a subdomain section on an IPA client:
ad_server
ad_site
Note that if both options are set, only “ad_server” is evaluated.
Since any request for a user or a group identity from a trusted domain triggered from an IPA client is resolved by the IPA server, the “ad_server” and “ad_site” options only affect which AD DC will the authentication be performed against. In particular, the addresses resolved from these lists will be written to “kdcinfo” files read by the Kerberos locator plugin. Please refer to the sssd_krb5_locator_plugin(8) manual page for more details on the Kerberos locator plugin.
The failover feature allows back ends to automatically switch to a different server if the current server fails.
The list of servers is given as a comma-separated list; any number of spaces is allowed around the comma. The servers are listed in order of preference. The list can contain any number of servers.
For each failover-enabled config option, two variants exist: primary and backup. The idea is that servers in the primary list are preferred and backup servers are only searched if no primary servers can be reached. If a backup server is selected, a timeout of 31 seconds is set. After this timeout SSSD will periodically try to reconnect to one of the primary servers. If it succeeds, it will replace the current active (backup) server.
The failover mechanism distinguishes between a machine and a service. The back end first tries to resolve the hostname of a given machine; if this resolution attempt fails, the machine is considered offline. No further attempts are made to connect to this 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.
Further connection attempts are made to machines or services marked as offline after a specified period of time; 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.
Resolving a server to connect to can be as simple as running a single DNS query or can involve several steps, such as finding the correct site or trying out multiple host names in case some of the configured servers are not reachable. The more complex scenarios can take some time and SSSD needs to balance between providing enough time to finish the resolution process but on the other hand, not trying for too long before falling back to offline mode. If the 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.
How long would SSSD talk to a single DNS server.
How long would SSSD try to resolve a failover service. This service resolution internally might include several steps, such as resolving DNS SRV queries or locating the site.
For LDAP-based providers, the resolve operation is performed as part of an LDAP connection operation. 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”.
The service discovery feature allows back ends to automatically find the appropriate servers to connect to using a special DNS query. This feature is not supported for backup servers.
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_”, in 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.
Please refer to the “dns_discovery_domain” parameter in the sssd.conf(5) manual page for more details.
The following example assumes that SSSD is correctly
configured and example.com is one of the domains in the
[sssd] section. This examples shows only
the ipa provider-specific options.
[domain/example.com] id_provider = ipa ipa_server = ipaserver.example.com ipa_hostname = myhost.example.com
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sssd-secrets(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8), sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)
Table of Contents
This manual page describes the configuration of the SSSD Kerberos Cache Manager (KCM). KCM is a process that stores, tracks and manages Kerberos credential caches. It originates in the Heimdal Kerberos project, although the MIT Kerberos library also provides client side (more details on that below) support for the KCM credential cache.
In a setup where Kerberos caches are managed by KCM, the Kerberos library (typically used through an application, like e.g., kinit(1), is a “"KCM client"” and the KCM daemon is being referred to as a “"KCM server"”. The client and server communicate over a UNIX socket.
The KCM server keeps track of each credential caches's owner and performs access check control based on the UID and GID of the KCM client. The root user has access to all credential caches.
The KCM credential cache has several interesting properties:
since the process runs in userspace, it is subject to UID namespacing, unlike the kernel keyring
unlike the kernel keyring-based cache, which is shared between all containers, the KCM server is a separate process whose entry point is a UNIX socket
the SSSD implementation stores the ccaches in the SSSD sssd-secrets(5) secrets store, allowing the ccaches to survive KCM server restarts or machine reboots.
This allows the system to use a collection-aware credential cache, yet share the credential cache between some or no containers by bind-mounting the socket.
In order to use KCM credential cache, it must be selected as the default credential type in krb5.conf(5), The credentials cache name must be only “KCM:” without any template expansions. For example:
[libdefaults]
default_ccache_name = KCM:
Next, make sure the Kerberos client libraries and the KCM server must agree
on the UNIX socket path. By default, both use the same path
/var/run/.heim_org.h5l.kcm-socket. To configure
the Kerberos library, change its “kcm_socket” option which
is described in the
krb5.conf(5)
manual page.
Finally, make sure the SSSD KCM server can be contacted. The KCM service is typically socket-activated by systemd(1). Unlike other SSSD services, it cannot be started by adding the “kcm” string to the “service” directive.
systemctl start sssd-kcm.socket
systemctl enable sssd-kcm.socket
Please note your distribution may already configure the units for you.
The credential caches are stored in the SSSD secrets service (see sssd-secrets(5) for more details). Therefore it is important that also the sssd-secrets service is enabled and its socket is started:
systemctl start sssd-secrets.socket
systemctl enable sssd-secrets.socket
Your distribution should already set the dependencies between the services.
The KCM service is configured in the “kcm” section of the sssd.conf file. Please note that currently, is it not sufficient to restart the sssd-kcm service, because the sssd configuration is only parsed and read to an internal configuration database by the sssd service. Therefore you must restart the sssd service if you change anything in the “kcm” section of sssd.conf. For a detailed syntax reference, refer to the “FILE FORMAT” section of the sssd.conf(5) manual page.
The generic SSSD service options such as “debug_level” or “fd_limit” are accepted by the kcm service. Please refer to the sssd.conf(5) manual page for a complete list. In addition, there are some KCM-specific options as well.
The socket the KCM service will listen on.
Default: /var/run/.heim_org.h5l.kcm-socket
Table of Contents
This manual page describes the configuration of the Kerberos 5 authentication backend for sssd(8). For a detailed syntax reference, please refer to the “FILE FORMAT” section of the sssd.conf(5) manual page.
The Kerberos 5 authentication backend contains auth and chpass providers. It must be paired with an identity provider in order to function properly (for example, id_provider = ldap). Some information required by the Kerberos 5 authentication backend must be provided by the identity provider, such as the user's Kerberos Principal Name (UPN). The configuration of the identity provider should have an entry to specify the UPN. Please refer to the man page for the applicable identity provider for details on how to configure this.
This backend also provides access control based on the .k5login file in the home directory of the user. See .k5login(5) for more details. Please note that an empty .k5login file will deny all access to this user. To activate this feature, use 'access_provider = krb5' in your SSSD configuration.
In the case where the UPN is not available in the identity backend,
sssd will construct a UPN using the format
username@krb5_realm.
If the auth-module krb5 is used in an SSSD domain, the following options must be used. See the sssd.conf(5) manual page, section “DOMAIN SECTIONS”, for details on the configuration of an SSSD domain.
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.
The name of the Kerberos realm. This option is required and must be specified.
If the change password service is not running on the KDC, alternative servers can be defined here. An optional port number (preceded by a colon) may be appended to the addresses or hostnames.
For more information on failover and server redundancy, see the “FAILOVER” section. NOTE: Even if there are no more kpasswd servers to try, the backend is not switched to operate offline if authentication against the KDC is still possible.
Default: Use the KDC
Directory to store credential caches. All the substitution sequences of krb5_ccname_template can be used here, too, except %d and %P. The directory is created as private and owned by the user, with permissions set to 0700.
Default: /tmp
Location of the user's credential cache. Three
credential cache types are currently supported:
“FILE”, “DIR” and
“KEYRING:persistent”. The cache can
be specified either as
TYPE:RESIDUAL, or as an
absolute path, which implies the
“FILE” type. In the template, the
following sequences are substituted:
login name
login UID
principal name
realm name
home directory
value of krb5_ccachedir
the process ID of the SSSD client
a literal '%'
If the template ends with 'XXXXXX' mkstemp(3) is used to create a unique filename in a safe way.
When using KEYRING types, the only supported mechanism is “KEYRING:persistent:%U”, which uses the Linux kernel keyring to store credentials on a per-UID basis. This is also the recommended choice, as it is the most secure and predictable method.
The default value for the credential cache name is sourced from the profile stored in the system wide krb5.conf configuration file in the [libdefaults] section. The option name is default_ccache_name. See krb5.conf(5)'s PARAMETER EXPANSION paragraph for additional information on the expansion format defined by krb5.conf.
NOTE: Please be aware that libkrb5 ccache expansion template from krb5.conf(5) uses different expansion sequences than SSSD.
Default: (from libkrb5)
Timeout in seconds after an online authentication request or change password request is aborted. If possible, the authentication request is continued offline.
Default: 6
Verify with the help of krb5_keytab that the TGT obtained has not been spoofed. The keytab is checked for entries sequentially, and the first entry with a matching realm is used for validation. If no entry matches the realm, the last entry in the keytab is used. This process can be used to validate environments using cross-realm trust by placing the appropriate keytab entry as the last entry or the only entry in the keytab file.
Default: false
The location of the keytab to use when validating credentials obtained from KDCs.
Default: /etc/krb5.keytab
Store the password of the user if the provider is offline and use it to request a TGT when the provider comes online again.
NOTE: this feature is only available on Linux. Passwords stored in this way are kept in plaintext in the kernel keyring and are potentially accessible by the root user (with difficulty).
Default: false
Request a renewable ticket with a total lifetime, given as an integer immediately followed by a time unit:
s for seconds
m for minutes
h for hours
d for days.
If there is no unit given, s is assumed.
NOTE: It is not possible to mix units. To set the renewable lifetime to one and a half hours, use '90m' instead of '1h30m'.
Default: not set, i.e. the TGT is not renewable
Request ticket with a lifetime, given as an integer immediately followed by a time unit:
s for seconds
m for minutes
h for hours
d for days.
If there is no unit given s is assumed.
NOTE: It is not possible to mix units. To set the lifetime to one and a half hours please use '90m' instead of '1h30m'.
Default: not set, i.e. the default ticket lifetime configured on the KDC.
The time in seconds between two checks if the TGT should be renewed. TGTs are renewed if about half of their lifetime is exceeded, given as an integer immediately followed by a time unit:
s for seconds
m for minutes
h for hours
d for days.
If there is no unit given, s is assumed.
NOTE: It is not possible to mix units. To set the renewable lifetime to one and a half hours, use '90m' instead of '1h30m'.
If this option is not set or is 0 the automatic renewal is disabled.
Default: not set
Enables flexible authentication secure tunneling (FAST) for Kerberos pre-authentication. The following options are supported:
never use FAST. This is equivalent to not setting this option at all.
try to use FAST. If the server does not support FAST, continue the authentication without it.
demand to use FAST. The authentication fails if the server does not require fast.
Default: not set, i.e. FAST is not used.
NOTE: a keytab is required to use FAST.
NOTE: SSSD supports FAST only with MIT Kerberos version 1.8 and later. If SSSD is used with an older version of MIT Kerberos, using this option is a configuration error.
Specifies the server principal to use for FAST.
Specifies if the host and user principal should be canonicalized. This feature is available with MIT Kerberos 1.7 and later versions.
Default: false
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
When krb5_use_kdcinfo is set to true, you can limit the amount of servers handed to sssd_krb5_locator_plugin(8). This might be helpful when there are too many servers discovered using SRV record.
The krb5_kdcinfo_lookahead option contains two numbers seperated by a colon. The first number represents number of primary servers used and the second number specifies the number of backup servers.
For example 10:0 means that up to 10 primary servers will be handed to sssd_krb5_locator_plugin(8). but no backup servers.
Default: 3:1
Specifies if the user principal should be treated as enterprise principal. See section 5 of RFC 6806 for more details about enterprise principals.
Default: false (AD provider: true)
The IPA provider will set to option to 'true' if it detects that the server is capable of handling enterprise principals and the option is not set explicitly in the config file.
The list of mappings is given as a comma-separated list of pairs “username:primary” where “username” is a UNIX user name and “primary” is a user part of a kerberos principal. This mapping is used when user is authenticating using “auth_provider = krb5”.
example:
krb5_realm = REALM krb5_map_user = joe:juser,dick:richard
“joe” and “dick” are UNIX user names and “juser” and “richard” are primaries of kerberos principals. For user “joe” resp. “dick” SSSD will try to kinit as “juser@REALM” resp. “richard@REALM”.
Default: not set
The failover feature allows back ends to automatically switch to a different server if the current server fails.
The list of servers is given as a comma-separated list; any number of spaces is allowed around the comma. The servers are listed in order of preference. The list can contain any number of servers.
For each failover-enabled config option, two variants exist: primary and backup. The idea is that servers in the primary list are preferred and backup servers are only searched if no primary servers can be reached. If a backup server is selected, a timeout of 31 seconds is set. After this timeout SSSD will periodically try to reconnect to one of the primary servers. If it succeeds, it will replace the current active (backup) server.
The failover mechanism distinguishes between a machine and a service. The back end first tries to resolve the hostname of a given machine; if this resolution attempt fails, the machine is considered offline. No further attempts are made to connect to this 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.
Further connection attempts are made to machines or services marked as offline after a specified period of time; 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.
Resolving a server to connect to can be as simple as running a single DNS query or can involve several steps, such as finding the correct site or trying out multiple host names in case some of the configured servers are not reachable. The more complex scenarios can take some time and SSSD needs to balance between providing enough time to finish the resolution process but on the other hand, not trying for too long before falling back to offline mode. If the 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.
How long would SSSD talk to a single DNS server.
How long would SSSD try to resolve a failover service. This service resolution internally might include several steps, such as resolving DNS SRV queries or locating the site.
For LDAP-based providers, the resolve operation is performed as part of an LDAP connection operation. 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”.
The service discovery feature allows back ends to automatically find the appropriate servers to connect to using a special DNS query. This feature is not supported for backup servers.
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_”, in 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.
Please refer to the “dns_discovery_domain” parameter in the sssd.conf(5) manual page for more details.
The following example assumes that SSSD is correctly
configured and FOO is one of the domains in the
[sssd] section. This example shows
only configuration of Kerberos authentication; it does not include
any identity provider.
[domain/FOO] auth_provider = krb5 krb5_server = 192.168.1.1 krb5_realm = EXAMPLE.COM
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sssd-secrets(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8), sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)
Table of Contents
The Kerberos locator plugin sssd_krb5_locator_plugin is used by libkrb5 to find KDCs for a given Kerberos realm. SSSD provides such a plugin to guide all Kerberos clients on a system to a single KDC. In general it should not matter to which KDC a client process is talking to. But there are cases, e.g. after a password change, where not all KDCs are in the same state because the new data has to be replicated first. To avoid unexpected authentication failures and maybe even account lockings it would be good to talk to a single KDC as long as possible.
libkrb5 will search the locator plugin in the libkrb5 sub-directory of the Kerberos plugin directory, see plugin_base_dir in krb5.conf(5) for details. The plugin can only be disabled by removing the plugin file. There is no option in the Kerberos configuration to disable it. But the SSSD_KRB5_LOCATOR_DISABLE environment variable can be used to disable the plugin for individual commands. Alternatively the SSSD option krb5_use_kdcinfo=False can be used to not generate the data needed by the plugin. With this the plugin is still called but will provide no data to the caller so that libkrb5 can fall back to other methods defined in krb5.conf.
The plugin reads the information about the KDCs of a given realm
from a file called kdcinfo.REALM. The file
should contain one or more DNS names or IP addresses either in
dotted-decimal IPv4 notation or the hexadecimal IPv6 notation.
An optional port number can be added to the end separated with
a colon, the IPv6 address has to be enclosed in squared brackets
in this case as usual. Valid entries are:
kdc.example.com
kdc.example.com:321
1.2.3.4
5.6.7.8:99
2001:db8:85a3::8a2e:370:7334
[2001:db8:85a3::8a2e:370:7334]:321
SSSD's krb5 auth-provider which is used by the IPA and AD providers as well adds the address of the current KDC or domain controller SSSD is using to this file.
In environments with read-only and read-write KDCs where clients are
expected to use the read-only instances for the general operations
and only the read-write KDC for config changes like password changes
a kpasswdinfo.REALM is used as well to identify
read-write KDCs. If this file exists for the given realm the content
will be used by the plugin to reply to requests for a kpasswd or
kadmin server or for the MIT Kerberos specific master KDC. If the
address contains a port number the default KDC port 88 will be used
for the latter.
Not all Kerberos implementations support the use of plugins. If sssd_krb5_locator_plugin is not available on your system you have to edit /etc/krb5.conf to reflect your Kerberos setup.
If the environment variable SSSD_KRB5_LOCATOR_DEBUG is set to any value debug messages will be sent to stderr.
If the environment variable SSSD_KRB5_LOCATOR_DISABLE is set to any value the plugin is disabled and will just return KRB5_PLUGIN_NO_HANDLE to the caller.
If the environment variable SSSD_KRB5_LOCATOR_IGNORE_DNS_FAILURES is set to any value plugin will try to resolve all DNS names in kdcinfo file. By default plugin returns KRB5_PLUGIN_NO_HANDLE to the caller immediately on first DNS resolving failure.
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sssd-secrets(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8), sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)
Table of Contents
This manual page describes the configuration of LDAP domains for sssd(8). Refer to the “FILE FORMAT” section of the sssd.conf(5) manual page for detailed syntax information.
You can configure SSSD to use more than one LDAP domain.
LDAP back end supports id, auth, access and chpass providers. 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. If the LDAP server is used only as an identity provider, an encrypted channel is not needed. Please refer to “ldap_access_filter” config option for more information about using LDAP as an access provider.
All of the common configuration options that apply to SSSD domains also apply to LDAP domains. Refer to the “DOMAIN SECTIONS” section of the sssd.conf(5) manual page for full details.
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 more information on failover and server redundancy. If neither option is specified, service discovery is enabled. For more information, refer to 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
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 information 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.
The default base DN to use for performing LDAP user operations.
Starting with SSSD 1.7.0, SSSD supports multiple search bases using the 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.
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 are not supported.
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. The way that 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
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).
Note: First, a new connection is established to verify current password by binding as the user that requested password change. If successful, this connection is used to change the password therefore the user must have write access to userPassword attribute.
Default: exop
The default bind DN to use for performing LDAP operations.
The type of the authentication token of the default bind DN.
The two mechanisms currently supported are:
password
obfuscated_password
Default: password
The authentication token of the default bind DN. Only clear text passwords are currently supported.
The object class of a user entry in LDAP.
Default: posixAccount
The LDAP attribute that corresponds to the user's login name.
Default: uid (rfc2307, rfc2307bis and IPA), sAMAccountName (AD)
The LDAP attribute that corresponds to the user's id.
Default: uidNumber
The LDAP attribute that corresponds to the user's primary group id.
Default: gidNumber
Active Directory primary group attribute for ID-mapping. Note that this attribute should only be set manually if you are running the “ldap” provider with ID mapping.
Default: unset (LDAP), primaryGroupID (AD)
The LDAP attribute that corresponds to the user's gecos field.
Default: gecos
The LDAP attribute that contains the name of the user's home directory.
Default: homeDirectory
The LDAP attribute that contains the path to the user's default shell.
Default: loginShell
The LDAP attribute that contains the UUID/GUID of an LDAP user object.
Default: not set in the general case, objectGUID for AD and ipaUniqueID for IPA
The LDAP attribute that contains the objectSID of an LDAP user object. This is usually only necessary for ActiveDirectory servers.
Default: objectSid for ActiveDirectory, not set for other servers.
The LDAP attribute that contains timestamp of the last modification of the parent object.
Default: modifyTimestamp
When using ldap_pwd_policy=shadow, this parameter contains the name of an LDAP attribute corresponding to its shadow(5) counterpart (date of the last password change).
Default: shadowLastChange
When using ldap_pwd_policy=shadow, this parameter contains the name of an LDAP attribute corresponding to its shadow(5) counterpart (minimum password age).
Default: shadowMin
When using ldap_pwd_policy=shadow, this parameter contains the name of an LDAP attribute corresponding to its shadow(5) counterpart (maximum password age).
Default: shadowMax
When using ldap_pwd_policy=shadow, this parameter contains the name of an LDAP attribute corresponding to its shadow(5) counterpart (password warning period).
Default: shadowWarning
When using ldap_pwd_policy=shadow, this parameter contains the name of an LDAP attribute corresponding to its shadow(5) counterpart (password inactivity period).
Default: shadowInactive
When using ldap_pwd_policy=shadow or ldap_account_expire_policy=shadow, this parameter contains the name of an LDAP attribute corresponding to its shadow(5) counterpart (account expiration date).
Default: shadowExpire
When using ldap_pwd_policy=mit_kerberos, this parameter contains the name of an LDAP attribute storing the date and time of last password change in kerberos.
Default: krbLastPwdChange
When using ldap_pwd_policy=mit_kerberos, this parameter contains the name of an LDAP attribute storing the date and time when current password expires.
Default: krbPasswordExpiration
When using ldap_account_expire_policy=ad, this parameter contains the name of an LDAP attribute storing the expiration time of the account.
Default: accountExpires
When using ldap_account_expire_policy=ad, this parameter contains the name of an LDAP attribute storing the user account control bit field.
Default: userAccountControl
When using ldap_account_expire_policy=rhds or equivalent, this parameter determines if access is allowed or not.
Default: nsAccountLock
When using ldap_account_expire_policy=nds, this attribute determines if access is allowed or not.
Default: loginDisabled
When using ldap_account_expire_policy=nds, this attribute determines until which date access is granted.
Default: loginDisabled
When using ldap_account_expire_policy=nds, this attribute determines the hours of a day in a week when access is granted.
Default: loginAllowedTimeMap
The LDAP attribute that contains the user's Kerberos User Principal Name (UPN).
Default: krbPrincipalName
Comma-separated list of LDAP attributes that SSSD would fetch along with the usual set of user attributes.
The list can either contain LDAP attribute names only, or colon-separated tuples of SSSD cache attribute name and LDAP attribute name. In case only LDAP attribute name is specified, the attribute is saved to the cache verbatim. Using a custom SSSD attribute name might be required by environments that configure several SSSD domains with different LDAP schemas.
Please note that several attribute names are reserved by SSSD, notably the “name” attribute. SSSD would report an error if any of the reserved attribute names is used as an extra attribute name.
Examples:
ldap_user_extra_attrs = telephoneNumber
Save the “telephoneNumber” attribute from LDAP as “telephoneNumber” to the cache.
ldap_user_extra_attrs = phone:telephoneNumber
Save the “telephoneNumber” attribute from LDAP as “phone” to the cache.
Default: not set
The LDAP attribute that contains the user's SSH public keys.
Default: sshPublicKey
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
Specifies how many seconds SSSD has to wait before refreshing its cache of enumerated records.
Default: 300
Determine how often to check the cache for inactive entries (such as 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.
Default: 0 (disabled)
The LDAP attribute that corresponds to the user's full name.
Default: cn
The LDAP attribute that lists the user's group memberships.
Default: memberOf
If access_provider=ldap and ldap_access_order=authorized_service, SSSD will use the presence of the authorizedService attribute in the user's LDAP entry to determine access privilege.
An explicit deny (!svc) is resolved first. Second, SSSD searches for explicit allow (svc) and finally for allow_all (*).
Please note that the ldap_access_order configuration option must include “authorized_service” in order for the ldap_user_authorized_service option to work.
Default: authorizedService
If access_provider=ldap and ldap_access_order=host, SSSD will use the presence of the host attribute in the user's LDAP entry to determine access privilege.
An explicit deny (!host) is resolved first. Second, SSSD searches for explicit allow (host) and finally for allow_all (*).
Please note that the ldap_access_order configuration option must include “host” in order for the ldap_user_authorized_host option to work.
Default: host
If access_provider=ldap and ldap_access_order=rhost, SSSD will use the presence of the rhost attribute in the user's LDAP entry to determine access privilege. Similarly to host verification process.
An explicit deny (!rhost) is resolved first. Second, SSSD searches for explicit allow (rhost) and finally for allow_all (*).
Please note that the ldap_access_order configuration option must include “rhost” in order for the ldap_user_authorized_rhost option to work.
Default: rhost
Name of the LDAP attribute containing the X509 certificate of the user.
Default: userCertificate;binary
Name of the LDAP attribute containing the email address of the user.
Note: If an email address of a user conflicts with an email address or fully qualified name of another user, then SSSD will not be able to serve those users properly. If for some reason several users need to share the same email address then set this option to a nonexistent attribute name in order to disable user lookup/login by email.
Default: mail
The object class of a group entry in LDAP.
Default: posixGroup
The LDAP attribute that corresponds to the group name.
Default: cn (rfc2307, rfc2307bis and IPA), sAMAccountName (AD)
The LDAP attribute that corresponds to the group's id.
Default: gidNumber
The LDAP attribute that contains the names of the group's members.
Default: memberuid (rfc2307) / member (rfc2307bis)
The LDAP attribute that contains the UUID/GUID of an LDAP group object.
Default: not set in the general case, objectGUID for AD and ipaUniqueID for IPA
The LDAP attribute that contains the objectSID of an LDAP group object. This is usually only necessary for ActiveDirectory servers.
Default: objectSid for ActiveDirectory, not set for other servers.
The LDAP attribute that contains timestamp of the last modification of the parent object.
Default: modifyTimestamp
The LDAP attribute that contains an integer value indicating the type of the group and maybe other flags.
This attribute is currently only used by the AD provider to determine if a group is a domain local groups and has to be filtered out for trusted domains.
Default: groupType in the AD provider, otherwise not set
The LDAP attribute that references group members that are defined in an external domain. At the moment, only IPA's external members are supported.
Default: ipaExternalMember in the IPA provider, otherwise unset.
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 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
This option tells SSSD to take advantage of an Active Directory-specific feature which may speed up group lookup operations on deployments with complex or deep nested groups.
In most common cases, it is best to leave this option disabled. It generally only provides a performance increase on very complex nestings.
If this option is enabled, SSSD will use it if it detects that the server supports it during initial connection. So "True" here essentially means "auto-detect".
Note: This feature is currently known to work only with Active Directory 2008 R1 and later. See MSDN(TM) documentation for more details.
Default: False
This option tells SSSD to take advantage of an Active Directory-specific feature which might speed up initgroups operations (most notably when dealing with complex or deep nested groups).
If this option is enabled, SSSD will use it if it detects that the server supports it during initial connection. So "True" here essentially means "auto-detect".
Note: This feature is currently known to work only with Active Directory 2008 R1 and later. See MSDN(TM) documentation for more details.
Default: False
This options enables or disables use of Token-Groups attribute when performing initgroup for users from Active Directory Server 2008 and later.
Default: True for AD and IPA otherwise False.
The object class of a netgroup entry in LDAP.
In IPA provider, ipa_netgroup_object_class should be used instead.
Default: nisNetgroup
The LDAP attribute that corresponds to the netgroup name.
In IPA provider, ipa_netgroup_name should be used instead.
Default: cn
The LDAP attribute that contains the names of the netgroup's members.
In IPA provider, ipa_netgroup_member should be used instead.
Default: memberNisNetgroup
The LDAP attribute that contains the (host, user, domain) netgroup triples.
This option is not available in IPA provider.
Default: nisNetgroupTriple
The LDAP attribute that contains timestamp of the last modification of the parent object.
This option is not available in IPA provider.
Default: modifyTimestamp
The object class of a host entry in LDAP.
Default: ipService
The LDAP attribute that corresponds to the host's name.
Default: cn
The LDAP attribute that corresponds to the host's fully-qualified domain name.
Default: fqdn
The LDAP attribute that corresponds to the host's name.
Default: serverHostname
The LDAP attribute that lists the host's group memberships.
Default: memberOf
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
The LDAP attribute that contains the host's SSH public keys.
Default: sshPublicKey
The LDAP attribute that contains the UUID/GUID of an LDAP host object.
Default: not set
The object class of a service entry in LDAP.
Default: ipService
The LDAP attribute that contains the name of service attributes and their aliases.
Default: cn
The LDAP attribute that contains the port managed by this service.
Default: ipServicePort
The LDAP attribute that contains the protocols understood by this service.
Default: ipServiceProtocol
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.
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)
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.
Default: 6
Specifies the timeout (in seconds) that ldap searches for user and group enumerations are allowed to run before they are cancelled and cached results are returned (and offline mode is entered)
Default: 60
Specifies the timeout (in seconds) after which the poll(2)/select(2) following a connect(2) returns in case of no activity.
Default: 6
Specifies a timeout (in seconds) after which calls to synchronous LDAP APIs will abort if no response is received. Also controls the timeout when communicating with the KDC in case of SASL bind, the timeout of an LDAP bind operation, password change extended operation and the StartTLS operation.
Default: 6
Specifies a timeout (in seconds) that a connection to an LDAP server will be maintained. After this time, the connection will be re-established. If used in parallel with SASL/GSSAPI, the sooner of the two values (this value vs. the TGT lifetime) will be used.
Default: 900 (15 minutes)
Specify the number of records to retrieve from LDAP in a single request. Some LDAP servers enforce a maximum limit per-request.
Default: 1000
Disable the LDAP paging control. This option should be used if the LDAP server reports that it supports the LDAP paging control in its RootDSE but it is not enabled or does not behave properly.
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
Disable Active Directory range retrieval.
Active Directory limits the number of members to be retrieved in a single lookup using the MaxValRange policy (which defaults to 1500 members). If a group contains more members, the reply would include an AD-specific range extension. This option disables parsing of the range extension, therefore large groups will appear as having no members.
Default: False
When communicating with an LDAP server using SASL, specify 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)
When communicating with an LDAP server using SASL, specify 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)
Specify the number of group members that must be missing from the internal cache in order to trigger a dereference lookup. If less members are missing, they are looked up individually.
You can turn off dereference lookups completely by setting the value to 0. 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.
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.
Default: 10
Specifies 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.
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
Specifies 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
Specifies 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, cacertdir_rehash can be used to create the correct names.
Default: use OpenLDAP defaults, typically in
/etc/openldap/ldap.conf
Specifies the file that contains the certificate for the client's key.
Default: not set
Specifies the file that contains the client's key.
Default: not set
Specifies 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
Specifies that the id_provider connection must also
use tls to protect the channel.
Default: false
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
In contrast to the SID based ID mapping which is used if ldap_id_mapping is set to true the allowed ID range for ldap_user_uid_number and ldap_group_gid_number is unbound. In a setup with sub/trusted-domains this might lead to ID collisions. To avoid collisions ldap_min_id and ldap_max_id can be set to restrict the allowed range for the IDs which are read directly from the server. Sub-domains can then pick other ranges to map IDs.
Default: not set (both options are set to 0)
Specify the SASL mechanism to use. Currently only GSSAPI and GSS-SPNEGO are tested and supported.
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
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
host/*
If none of them are found, the first principal in keytab is returned.
Default: host/hostname@REALM
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.
Default: the value of krb5_realm.
If set to true, the LDAP library would perform a reverse lookup to canonicalize the host name during a SASL bind.
Default: false;
Specify the keytab to use when using SASL/GSSAPI/GSS-SPNEGO.
Default: System keytab, normally /etc/krb5.keytab
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
Specifies the lifetime in seconds of the TGT if GSSAPI or GSS-SPNEGO is used.
Default: 86400 (24 hours)
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.
Specify the Kerberos REALM (for SASL/GSSAPI/GSS-SPNEGO auth).
Default: System defaults, see /etc/krb5.conf
Specifies if the host principal should be canonicalized when connecting to LDAP server. This feature is available with MIT Kerberos >= 1.7
Default: false
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
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.
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.
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.
Default: true
Specifies the service name to use when service discovery is enabled.
Default: ldap
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
Specifies whether to update the ldap_user_shadow_last_change attribute with days since the Epoch after a password change operation.
Default: False
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).
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
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.
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. This is an experimental feature, please use https://pagure.io/SSSD/sssd/ to report any issues.
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
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: These options are useful if users are interested in being warned that password is about to expire and authentication is based on using a different method than passwords - for example SSH keys.
The difference between these options is the action taken if user password is expired: pwd_expire_policy_reject - user is denied to log in, pwd_expire_policy_warn - user is still able to log in, pwd_expire_policy_renew - user is prompted to change his password immediately.
Note If user password is expired no explicit message is prompted by SSSD.
Please note that 'access_provider = ldap' must be set for this feature to work. Also 'ldap_pwd_policy' must be set to an appropriate password policy.
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
Please note, rhost field in pam is set by application, it is better to check what the application sends to pam, before enabling this access control option
Default: filter
Please note that it is a configuration error if a value is used more than once.
This option specifies the DN of password policy entry on LDAP server. Please note that absence of this option in sssd.conf in case of enabled account lockout checking will yield access denied as ppolicy attributes on LDAP server cannot be checked properly.
Example: cn=ppolicy,ou=policies,dc=example,dc=com
Default: cn=ppolicy,ou=policies,$ldap_search_base
Specifies how alias dereferencing is done when performing a search. The following options are allowed:
never: Aliases are never dereferenced.
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.
Default: Empty (this is handled as never by the LDAP client libraries)
Allows to retain local users as members of an LDAP group for servers that use the RFC2307 schema.
In some environments where the RFC2307 schema is used, local users are made members of LDAP groups by adding their names to the memberUid attribute. The self-consistency of the domain is compromised when this is done, so SSSD would normally remove the "missing" users from the cached group memberships as soon as nsswitch tries to fetch information about the user via getpw*() or initgroups() calls.
This option falls back to checking if local users are referenced, and caches them so that later initgroups() calls will augment the local users with the additional LDAP groups.
Default: false
Specifies an upper limit on the number of entries that are downloaded during a wildcard lookup.
At the moment, only the InfoPipe responder supports wildcard lookups.
Default: 1000 (often the size of one page)
The detailed instructions for configuration of sudo_provider are in the manual page sssd-sudo(5).
The object class of a sudo rule entry in LDAP.
Default: sudoRole
The LDAP attribute that corresponds to the sudo rule name.
Default: cn
The LDAP attribute that corresponds to the command name.
Default: sudoCommand
The LDAP attribute that corresponds to the host name (or host IP address, host IP network, or host netgroup)
Default: sudoHost
The LDAP attribute that corresponds to the user name (or UID, group name or user's netgroup)
Default: sudoUser
The LDAP attribute that corresponds to the sudo options.
Default: sudoOption
The LDAP attribute that corresponds to the user name that commands may be run as.
Default: sudoRunAsUser
The LDAP attribute that corresponds to the group name or group GID that commands may be run as.
Default: sudoRunAsGroup
The LDAP attribute that corresponds to the start date/time for when the sudo rule is valid.
Default: sudoNotBefore
The LDAP attribute that corresponds to the expiration date/time, after which the sudo rule will no longer be valid.
Default: sudoNotAfter
The LDAP attribute that corresponds to the ordering index of the rule.
Default: sudoOrder
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 value must be greater than ldap_sudo_smart_refresh_interval
Default: 21600 (6 hours)
How many seconds SSSD has to wait before executing a smart refresh of sudo rules (which downloads all rules that have USN higher than the highest server USN value that is currently known by SSSD).
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) and 3) by reconnecting to the server (by default every 15 minutes, see ldap_connection_expire_timeout).
Default: 900 (15 minutes)
If true, SSSD will download only rules that are applicable to this machine (using the IPv4 or IPv6 host/network addresses and hostnames).
Default: true
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.
If ldap_sudo_use_host_filter is false then this option has no effect.
Default: not specified
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
If true then SSSD will download every rule that contains a netgroup in sudoHost attribute.
If ldap_sudo_use_host_filter is false then this option has no effect.
Default: true
If true then SSSD will download every rule that contains a wildcard in sudoHost attribute.
If ldap_sudo_use_host_filter is false then this option has no effect.
Default: true
This manual page only describes attribute name mapping. For detailed explanation of sudo related attribute semantics, see sudoers.ldap(5)
Some of the defaults for the parameters below are dependent on the LDAP schema.
The name of the automount master map in LDAP.
Default: auto.master
The object class of an automount map entry in LDAP.
Default: nisMap (rfc2307, autofs_provider=ad), otherwise automountMap
The name of an automount map entry in LDAP.
Default: nisMapName (rfc2307, autofs_provider=ad), otherwise automountMapName
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
The key of an automount entry in LDAP. The entry usually corresponds to a mount point.
Default: cn (rfc2307, autofs_provider=ad), otherwise automountKey
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.
These options are supported by LDAP domains, but they should be used with caution. Please include them in your configuration only if you know what you are doing.
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.
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.
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.
If the option “ldap_use_tokengroups” is enabled, the searches against Active Directory will not be restricted and return all groups memberships, even with no GID mapping. It is recommended to disable this feature, if group names are not being displayed correctly.
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.
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.
The failover feature allows back ends to automatically switch to a different server if the current server fails.
The list of servers is given as a comma-separated list; any number of spaces is allowed around the comma. The servers are listed in order of preference. The list can contain any number of servers.
For each failover-enabled config option, two variants exist: primary and backup. The idea is that servers in the primary list are preferred and backup servers are only searched if no primary servers can be reached. If a backup server is selected, a timeout of 31 seconds is set. After this timeout SSSD will periodically try to reconnect to one of the primary servers. If it succeeds, it will replace the current active (backup) server.
The failover mechanism distinguishes between a machine and a service. The back end first tries to resolve the hostname of a given machine; if this resolution attempt fails, the machine is considered offline. No further attempts are made to connect to this 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.
Further connection attempts are made to machines or services marked as offline after a specified period of time; 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.
Resolving a server to connect to can be as simple as running a single DNS query or can involve several steps, such as finding the correct site or trying out multiple host names in case some of the configured servers are not reachable. The more complex scenarios can take some time and SSSD needs to balance between providing enough time to finish the resolution process but on the other hand, not trying for too long before falling back to offline mode. If the 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.
How long would SSSD talk to a single DNS server.
How long would SSSD try to resolve a failover service. This service resolution internally might include several steps, such as resolving DNS SRV queries or locating the site.
For LDAP-based providers, the resolve operation is performed as part of an LDAP connection operation. 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”.
The service discovery feature allows back ends to automatically find the appropriate servers to connect to using a special DNS query. This feature is not supported for backup servers.
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_”, in 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.
Please refer to the “dns_discovery_domain” parameter in the sssd.conf(5) manual page for more details.
The ID-mapping feature allows SSSD to act as a client of Active Directory without requiring administrators to extend user attributes to support POSIX attributes for user and group identifiers.
NOTE: When ID-mapping is enabled, the uidNumber and gidNumber attributes are ignored. This is to avoid the possibility of conflicts between automatically-assigned and manually-assigned values. If you need to use manually-assigned values, ALL values must be manually-assigned.
Please note that changing the ID mapping related configuration options will cause user and group IDs to change. At the moment, SSSD does not support changing IDs, so the SSSD database must be removed. Because cached passwords are also stored in the database, removing the database should only be performed while the authentication servers are reachable, otherwise users might get locked out. In order to cache the password, an authentication must be performed. It is not sufficient to use sss_cache(8) to remove the database, rather the process consists of:
Making sure the remote servers are reachable
Stopping the SSSD service
Removing the database
Starting the SSSD service
Moreover, as the change of IDs might necessitate the adjustment of other system properties such as file and directory ownership, it's advisable to plan ahead and test the ID mapping configuration thoroughly.
Active Directory provides an objectSID for every user and group object in the directory. This 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 - called "slices"-. Each slice represents the space available to an Active Directory domain.
When a user or group entry for a particular domain is encountered for the first time, the SSSD allocates one of the available slices for that domain. In order to make this slice-assignment repeatable on different client machines, we select the slice based on the following algorithm:
The SID string is passed through the murmurhash3 algorithm to convert it to a 32-bit hashed value. We then take the modulus of this value with the total number of available slices to pick the slice.
NOTE: It is possible to encounter collisions in the hash and subsequent modulus. In these situations, we will select the next available slice, but it may not be possible to reproduce the same exact set of slices on other machines (since the order that they are encountered will determine their slice). In this situation, it is recommended to either switch to using explicit POSIX attributes in Active Directory (disabling ID-mapping) or configure a default domain to guarantee that at least one is always consistent. See “Configuration” for details.
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. This should be sufficient for most deployments.
Specifies the lower bound of the range of POSIX IDs to use for mapping Active Directory user and group SIDs.
NOTE: This option is different from “min_id” in that “min_id” acts to filter the output of requests to this domain, whereas this option controls the range of ID assignment. This is a subtle distinction, but the good general advice would be to have “min_id” be less-than or equal to “ldap_idmap_range_min”
Default: 200000
Specifies the upper bound of the range of POSIX IDs to use for mapping Active Directory user and group SIDs.
NOTE: This option is different from “max_id” in that “max_id” acts to filter the output of requests to this domain, whereas this option controls the range of ID assignment. This is a subtle distinction, but the good general advice would be to have “max_id” be greater-than or equal to “ldap_idmap_range_max”
Default: 2000200000
Specifies the number of IDs available for each slice. If the range size does not divide evenly into the min and max values, it will 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 login 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, “ldap_idmap_range_size” must be at least 1108 as range size is equal to maximal SID minus minimal SID plus one (e.g. 1108 = 1107 - 0 + 1).
It is important to plan ahead for future expansion, as changing this value will result in changing all of the ID mappings on the system, leading to users with different local IDs than they previously had.
Default: 200000
Specify the domain SID of the default domain. This will guarantee that this domain will always be assigned to slice zero in the ID map, bypassing the murmurhash algorithm described above.
Default: not set
Specify the name of the default domain.
Default: not set
Changes the behavior of the ID-mapping algorithm to behave more similarly to winbind's “idmap_autorid” algorithm.
When this option is configured, domains will be allocated starting with slice zero and increasing monatomically 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 is 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
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 RID part of SID is out of range for secondary slices generated so far. If value of ldap_idmap_helper_table_size is equal to 0 then no additional secondary slices are generated.
Default: 10
SSSD supports to look up the names of Well-Known SIDs, i.e. SIDs with a special hardcoded meaning. 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
NT Authority
Built-in
The capitalized version of these names are used as domain names when returning the fully qualified name of a Well-Known SID.
Since some utilities allow to modify SID based access control
information with the help of a name instead of using the SID
directly SSSD supports to look up the SID by the 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”, “NT
AUTHORITY” and “BUILTIN” should not be used as
domain names in sssd.conf.
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
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
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.
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sssd-secrets(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8), sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)