13.2.12. Creating Domains: Identity Management (IdM)
The Identity Management (IdM or IPA) identity provider is an extension of a generic LDAP provider. All of the configuration options for an LDAP provider are available to the IdM provider, as well as some additional parameters which allow SSSD to work as a client of the IdM domain and extend IdM functionality.
Identity Management can work as a provider for identities, authentication, access control rules, and passwords, all of the
*_provider parameters for a domain. Additionally, Identity Management has configuration options within its own domain to manage SELinux policies, automount information, and host-based access control. All of those features in IdM domains can be tied to SSSD configuraiton, allowing those security-related policies to be applied and cached for system users.
Example 13.3. Basic IdM Provider
An IdM provider, like an LDAP provider, can be set to serve several different services, including identity, authentication, and access control
For IdM servers, there are two additional settings which are very useful (although not required):
- Use the specific IdM schema rather than the default RFC 2307 schema.
- Set SSSD to update the Identity Management domain's DNS server with the IP address of this client when the client first connects to the IdM domain.
[sssd] domains = local,example.com ... [domain/example.com] id_provider = ipa ipa_server = ipaserver.example.com ipa_hostname = ipa1.example.com auth_provider = ipa access_provider = ipa chpass_provider = ipa # set which schema to use ldap_schema = ipa # automatically update IdM DNS records ipa_dyndns_update = true
Identity Management defines and maintains security policies and identities for users across a Linux domain. This includes access control policies, SELinux policies, and other rules. Some of these elements in the IdM domain interact directly with SSSD, using SSSD as an IdM client — and those features can be managed in the IdM domain entry in
sssd.conf.
Most of the configuration parameters relate to setting schema elements (which is not relevant in most deployments because IdM uses a fixed schema) and never need to be changed. In fact, none of the features in IdM require client-side settings. But there may be circumstances where tweaking the behavior is helpful.
Example 13.4. IdM Provider with SELinux
IdM can define SELinux user policies for system users, so it can work as an SELinux provider for SSSD. This is set in the
selinux_provider parameter. The provider defaults to the id_provider value, so this is not necessary to set explicitly to support SELinux rules. However, it can be useful to explicitly disable SELinux support for the IdM provider in SSSD.
selinux_provider = ipa
Example 13.5. IdM Provider with Host-Based Access Control
IdM can define host-based access controls, restricting access to services or entire systems based on what host a user is using to connect or attempting to connect to. This rules can be evaluated and enforced by SSSD as part of the access provider behavior.
For host-based access controls to be in effect, the Identity Management server must be the access provider, at a minimum.
There are two options which can be set for how SSSD evaluates host-based access control rules:
- SSSD can evaluate what machine (source host) the user is using to connect to the IdM resource; this is disabled by default, so that only the target host part of the rule is evaluated.
- SSSD can refresh the host-based access control rules in its cache at a specified interval.
For example:
access_provider = ipa ipa_hbac_refresh = 120 # check for source machine rules; disabled by default ipa_hbac_support_srchost = true
Example 13.6. Identity Management with Cross-Realm Kerberos Trusts
Identity Management (IdM or IPA) can be configured with trusted relationships between Active Directory DNS domains and Kerberos realms. This allows Active Directory users to access services and hosts on Linux systems.
There are two configuration settings in SSSD that are used with cross-realm trusts:
- A service that adds required data to Kerberos tickets
- A setting to support subdomains
Kerberos Ticket Data
Microsoft uses a special authorization structure called privileged access certificates or MS-PAC. A PAC is embedded in a Kerberos ticket as a way of identifying the entity to other Windows clients and servers in the Windows domain.
SSSD has a special PAC service which generates the additional data for Kerberos tickets. When using an Active Directory domain, it may be necessary to include the PAC data for Windows users. In that case, enable the
pac service in SSSD:
[sssd]
services = nss, pam, pac
...
Windows Subdomains
Normally, a domain entry in SSSD corresponds directly to a single identity provider. However, with IdM cross-realm trusts, the IdM domain can trust another domain, so that the domains are transparent to each other. SSSD can follow that trusted relationship, so that if an IdM domain is configured, any Windows domain is also automatically searched and supported by SSSD — without having to be configured in a domain section in SSSD.
This is configured by adding the
subdomains_provider parameter to the IdM domain section. This is actually an optional parameter; if a subdomain is discovered, then SSSD defaults to using the ipa provider type. However, this parameter can also be used to disable subdomain fetches by setting a value of none.
[domain/IDM] ... subdomains_provider = ipa get_domains_timeout = 300
