SSSD-AD(5) File Formats and Conventions SSSD-AD(5)NAMEsssd-ad - the configuration file for SSSD
DESCRIPTION
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.
The AD provider supports connecting to Active Directory 2008 R2 or
later. Earlier versions may work, but are unsupported.
The AD provider accepts the same options used by the sssd-ldap(5)
identity provider and the sssd-krb5(5) authentication provider with
some exceptions described below.
However, it is neither necessary nor recommended to set these options.
The AD provider can also be used as an access and chpass provider. No
configuration of the access provider is required on the client side.
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
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.
ad_server, ad_backup_server (string)
The comma-separated list of IP addresses or 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.
ad_hostname (string)
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.
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
login name
%U
UID number
%d
domain name
%f
fully qualified user name (user@domain)
%%
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)
fallback_homedir (string)
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)
default_shell
The default shell to use if the provider does not return one during
lookup. 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 (Return NULL if no shell is specified and rely on
libc to substitute something sensible when necessary, usually
/bin/sh)
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.
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.
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
The default configuration results in configuring 10,000 slices, each
capable of holding up to 200,000 IDs, starting from 10,001 and going up
to 2,000,100,000. This should be sufficient for most deployments.
Advanced Configuration
ldap_idmap_range_min (integer)
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
ldap_idmap_range_max (integer)
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
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.
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
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 ALSOsssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5),
sssd-ipa(5), sssd-ad(5), sssd-sudo(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_knowhostsproxy(8),pam_sss(8).
AUTHORS
The SSSD upstream - http://fedorahosted.org/sssd
SSSD 04/23/2013 SSSD-AD(5)
