NAME
sssd-ad - SSSD Active Directory providerDESCRIPTION
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 setldap_id_mapping = False
CONFIGURATION OPTIONS
Refer to the section “DOMAIN SECTIONS” of the sssd.conf(5) manual page for details on the configuration of an SSSD domain. ad_domain (string)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.
ad_enabled_domains (string)
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:
The short domain name (also known as the NetBIOS or the flat name) will be
autodetected by SSSD.
Default: Not set
ad_server, ad_backup_server (string)
ad_enabled_domains = sales.example.com, eng.example.com
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.
ad_hostname (string)
Optional. On machines where the hostname(5)
does not reflect the fully qualified name, sssd will try to expand the short
name. If it is not possible or the short name should be really used instead,
set this parameter explicitly.
This field is used to determine the host principal in use in the keytab and to
perform dynamic DNS updates. It must match the hostname for which the keytab
was issued.
ad_enable_dns_sites (boolean)
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
ad_access_filter (string)
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[2]
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:
Default: Not set
ad_site (string)
# 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)
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
ad_enable_gc (boolean)
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
ad_gpo_access_control (string)
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 the host. For more
information on the supported policy settings please refer to the
“ad_gpo_map” options.
Please note that current version of SSSD does not support Active Directory's
built-in groups. Built-in groups (such as Administrators with SID
S-1-5-32-544) in GPO access control rules will be ignored by SSSD. See
upstream issue tracker https://github.com/SSSD/sssd/issues/5063 .
Before performing access control SSSD applies group policy security filtering on
the GPOs. For every single user login, the applicability of the GPOs that are
linked to the host is checked. In order for a GPO to apply to a user, the user
or at least one of the groups to which it belongs must have following
permissions on the GPO:
By default, the Authenticated Users group is present on a GPO and this group has
both Read and Apply Group Policy access rights. Since authentication of a user
must have been completed successfully before GPO security filtering and access
control are started, the Authenticated Users group permissions on the GPO
always apply also to the user.
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. For logging GPO-based access control debug level 'trace functions'
is required (see sssctl(8) manual page).
There are three supported values for this option:
Default: enforcing
ad_gpo_implicit_deny (boolean)
•Read: The user or one of its groups
must have read access to the properties of the GPO
(RIGHT_DS_READ_PROPERTY)
•Apply Group Policy: The user or at
least one of its groups must be allowed to apply the GPO
(RIGHT_DS_CONTROL_ACCESS).
•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.
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
The following 2 tables should illustrate when a user is allowed or rejected
based on the allow and deny login rights defined on the server-side and the
setting of ad_gpo_implicit_deny.
ad_gpo_ignore_unreadable (boolean)
ad_gpo_implicit_deny = False (default) | ||
allow-rules | deny-rules | results |
missing | missing | all users are allowed |
missing | present | only users not in deny-rules are allowed |
present | missing | only users in allow-rules are allowed |
present | present | only users in allow-rules and not in deny-rules are allowed |
ad_gpo_implicit_deny = True | ||
allow-rules | deny-rules | results |
missing | missing | no users are allowed |
missing | present | no users are allowed |
present | missing | only users in allow-rules are allowed |
present | present | only users in allow-rules and not in deny-rules are allowed |
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
ad_gpo_cache_timeout (integer)
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)
ad_gpo_map_interactive (string)
A comma-separated list of PAM service names
for which GPO-based access control is evaluated based on the
InteractiveLogonRight and DenyInteractiveLogonRight policy settings. Only
those GPOs are evaluated for which the user has Read and Apply Group Policy
permission (see option “ad_gpo_access_control”). If an evaluated
GPO contains the deny interactive logon setting for the user or one of its
groups, the user is denied local access. If none of the evaluated GPOs has an
interactive logon right defined, the user is granted local access. If at least
one evaluated GPO contains interactive logon right settings, the user is
granted local access only, if it or at least one of its groups is part of the
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:
Default: the default set of PAM service names includes:
ad_gpo_map_remote_interactive (string)
ad_gpo_map_interactive = +my_pam_service, -login
•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. Only those GPOs are evaluated for which the user has Read and Apply
Group Policy permission (see option “ad_gpo_access_control”). If
an evaluated GPO contains the deny remote logon setting for the user or one of
its groups, the user is denied remote interactive access. If none of the
evaluated GPOs has a remote interactive logon right defined, the user is
granted remote access. If at least one evaluated GPO contains remote
interactive logon right settings, the user is granted remote access only, if
it or at least one of its groups is part of the 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:
Default: the default set of PAM service names includes:
ad_gpo_map_network (string)
ad_gpo_map_remote_interactive = +my_pam_service, -sshd
•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. Only those GPOs are evaluated for
which the user has Read and Apply Group Policy permission (see option
“ad_gpo_access_control”). If an evaluated GPO contains the deny
network logon setting for the user or one of its groups, the user is denied
network logon access. If none of the evaluated GPOs has a network logon right
defined, the user is granted logon access. If at least one evaluated GPO
contains network logon right settings, the user is granted logon access only,
if it or at least one of its groups is part of the 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:
Default: the default set of PAM service names includes:
ad_gpo_map_batch (string)
ad_gpo_map_network = +my_pam_service, -ftp
•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. Only those GPOs are evaluated for
which the user has Read and Apply Group Policy permission (see option
“ad_gpo_access_control”). If an evaluated GPO contains the deny
batch logon setting for the user or one of its groups, the user is denied
batch logon access. If none of the evaluated GPOs has a batch logon right
defined, the user is granted logon access. If at least one evaluated GPO
contains batch logon right settings, the user is granted logon access only, if
it or at least one of its groups is part of the 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:
Note: Cron service name may differ depending on Linux distribution used.
Default: the default set of PAM service names includes:
ad_gpo_map_service (string)
ad_gpo_map_batch = +my_pam_service, -crond
•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. Only those GPOs are evaluated for
which the user has Read and Apply Group Policy permission (see option
“ad_gpo_access_control”). If an evaluated GPO contains the deny
service logon setting for the user or one of its groups, the user is denied
service logon access. If none of the evaluated GPOs has a service logon right
defined, the user is granted logon access. If at least one evaluated GPO
contains service logon right settings, the user is granted logon access only,
if it or at least one of its groups is part of the 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:
Default: not set
ad_gpo_map_permit (string)
ad_gpo_map_service = +my_pam_service
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:
Default: the default set of PAM service names includes:
ad_gpo_map_deny (string)
ad_gpo_map_permit = +my_pam_service, -sudo
•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:
Default: not set
ad_gpo_default_right (string)
ad_gpo_map_deny = +my_pam_service
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:
Default: deny
ad_maximum_machine_account_password_age (integer)
•interactive
•remote_interactive
•network
•batch
•service
•permit
•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
ad_machine_account_password_renewal_opts (string)
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)
ad_update_samba_machine_account_password (boolean)
If enabled, when SSSD renews the machine
account password, it will also be updated in Samba's database. This prevents
Samba's copy of the machine account password from getting out of date when it
is set up to use AD for authentication.
Default: false
ad_use_ldaps (bool)
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
ad_allow_remote_domain_local_groups (boolean)
If this option is set to “true”
SSSD will not filter out Domain Local groups from remote domains in the AD
forest. By default they are filtered out e.g. when following a nested group
hierarchy in remote domains because they are not valid in the local domain. To
be compatible with other solutions which make AD users and groups available on
Linux client this option was added.
Please note that setting this option to “true” will be against the
intention of Domain Local group in Active Directory and SHOULD ONLY BE USED
TO FACILITATE MIGRATION FROM OTHER SOLUTIONS. Although the group exists
and user can be member of the group the intention is that the group should be
only used in the domain it is defined and in no others. Since there is only
one type of POSIX groups the only way to achieve this on the Linux side is to
ignore those groups. This is also done by Active Directory as can be seen in
the PAC of the Kerberos ticket for a local service or in tokenGroups requests
where remote Domain Local groups are missing as well.
Given the comments above, if this option is set to “true” the
tokenGroups request must be disabled by setting
“ldap_use_tokengroups” to “false” to get
consistent group-memberships of a users. Additionally the Global Catalog
lookup should be skipped as well by setting “ad_enable_gc” to
“false”. Finally it might be necessary to modify
“ldap_group_nesting_level” if the remote Domain Local groups can
only be found with a deeper nesting level.
Default: False
dyndns_update (boolean)
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
dyndns_ttl (integer)
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)
dyndns_iface (string)
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
dyndns_refresh_interval (integer)
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)
dyndns_update_ptr (bool)
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
dyndns_force_tcp (bool)
Whether the nsupdate utility should default to
using TCP for communicating with the DNS server.
Default: False (let nsupdate choose the protocol)
dyndns_auth (string)
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
dyndns_auth_ptr (string)
Whether the nsupdate utility should use
GSS-TSIG authentication for secure PTR updates with the DNS server, insecure
updates can be sent by setting this option to 'none'.
Default: Same as dyndns_auth
dyndns_server (string)
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)
dyndns_update_per_family (boolean)
DNS update is by default performed in two
steps - IPv4 update and then IPv6 update. In some cases it might be desirable
to perform IPv4 and IPv6 update in single step.
Default: true
override_homedir (string)
Override the user's home directory. You can
either provide an absolute value or a template. In the template, the following
sequences are substituted:
%u
This option can also be set per-domain.
example:
Default: Not set (SSSD will use the value retrieved from LDAP)
Please note, the home directory from a specific override for the user, either
locally (see sss_override(8)) or centrally managed IPA id-overrides,
has a higher precedence and will be used instead of the value given by
override_homedir.
homedir_substring (string)
login name
%U
UID number
%d
domain name
%f
fully qualified user name (user@domain)
%l
The first letter of the login name.
%P
UPN - User Principal Name (name@REALM)
%o
The original home directory retrieved from the
identity provider.
%h
The original home directory retrieved from the
identity provider, but in lower case.
%H
The value of configure option
homedir_substring.
%%
a literal '%'
override_homedir = /home/%u
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
krb5_confd_path (string)
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)
MODIFIED DEFAULT OPTIONS
Certain option defaults do not match their respective backend provider defaults, these option names and AD provider-specific defaults are listed below:KRB5 Provider
•krb5_validate = true
•krb5_use_enterprise_principal =
true
LDAP Provider
•ldap_schema = ad
•ldap_force_upper_case_realm =
true
•ldap_id_mapping = true
•ldap_sasl_mech = GSS-SPNEGO
•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.
NSS configuration
•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".
Note that the system typically expects a home directory in /home/%u folder. If
you decide to use a different directory structure, some other parts of your
system may need adjustments.
For example automated creation of home directories in combination with selinux
requires selinux adjustment, otherwise the home directory will be created with
wrong selinux context.
FAILOVER
The failover feature allows back ends to automatically switch to a different server if the current server fails.Failover Syntax
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
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.Failover time outs and tuning
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. dns_resolver_server_timeoutTime in milliseconds that sets how long would
SSSD talk to a single DNS server before trying next one.
Default: 1000
dns_resolver_op_timeout
Time in seconds to tell how long would SSSD
try to resolve single DNS query (e.g. resolution of a hostname or an SRV
record) before trying the next hostname or discovery domain.
Default: 3
dns_resolver_timeout
How long 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.
Default: 6
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” which should be larger than
“dns_resolver_server_timeout”.
SERVICE DISCOVERY
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.Configuration
If no servers are specified, the back end automatically uses service discovery to try to find a server. Optionally, the user may choose to use both fixed server addresses and service discovery by inserting a special keyword, “_srv_”, 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.The domain name
Please refer to the “dns_discovery_domain” parameter in the sssd.conf(5) manual page for more details.The protocol
The queries usually specify _tcp as the protocol. Exceptions are documented in respective option description.See Also
For more information on the service discovery mechanism, refer to RFC 2782.ID MAPPING
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
Mapping Algorithm
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.Configuration
Minimum configuration (in the “[domain/DOMAINNAME]” section):ldap_id_mapping = True ldap_schema = ad
ldap_idmap_range_min (integer)
Specifies the lower (inclusive) bound of the
range of POSIX IDs to use for mapping Active Directory user and group SIDs. It
is the first POSIX ID which can be used for the mapping.
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
ldap_idmap_range_max (integer)
Specifies the upper (exclusive) bound of the
range of POSIX IDs to use for mapping Active Directory user and group SIDs. It
is the first POSIX ID which cannot be used for the mapping anymore, i.e. one
larger than the last one which can be used for the mapping.
NOTE: This option is different from “max_id” 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
ldap_idmap_range_size (integer)
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
ldap_idmap_default_domain_sid (string)
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
ldap_idmap_default_domain (string)
Specify the name of the default domain.
Default: not set
ldap_idmap_autorid_compat (boolean)
Changes the behavior of the ID-mapping
algorithm to behave more similarly to winbind's “idmap_autorid”
algorithm.
When this option is configured, domains 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
ldap_idmap_helper_table_size (integer)
Maximal number of secondary slices that is
tried when performing mapping from UNIX id to SID.
Note: Additional secondary slices might be generated when SID is being mapped to
UNIX id and 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
Well-Known SIDs
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
•Mandatory Label Authority
•Authentication Authority
•NT Authority
•Built-in
EXAMPLE
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
NOTES
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
SEE ALSO
sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), , sssd-files(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5) sssd-systemtap(5)AUTHORS
The SSSD upstream - https://github.com/SSSD/sssd/NOTES
- 1.
- Active Directory security groups
- 2.
- [MS-ADTS] section LDAP extensions
04/11/2023 | SSSD |