From ad3c2c6f89d3d07c5e901706c796de41d160d3bb Mon Sep 17 00:00:00 2001 From: Sumit Bose Date: Mon, 3 Sep 2018 18:38:42 +0200 Subject: [PATCH 13/19] doc: add certificate mapping section to man page Related to https://pagure.io/SSSD/sssd/issue/3500 Reviewed-by: Jakub Hrozek (cherry picked from commit 0c739e969a617bdb4c06cdfd63772bf6d283c518) --- src/man/sssd.conf.5.xml | 149 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 149 insertions(+) diff --git a/src/man/sssd.conf.5.xml b/src/man/sssd.conf.5.xml index 881ffc6ab389fec2b85d675f43b951ca5fa0f2fc..04143f199685b7703abe1b5bb82b6c33230e6c72 100644 --- a/src/man/sssd.conf.5.xml +++ b/src/man/sssd.conf.5.xml @@ -3299,6 +3299,135 @@ ldap_user_extra_attrs = phone:telephoneNumber + + CERTIFICATE MAPPING SECTION + + To allow authentication with Smartcards and certificates SSSD must + be able to map certificates to users. This can be done by adding the + full certificate to the LDAP object of the user or to a local + override. While using the full certificate is required to use the + Smartcard authentication feature of SSH (see + + sss_ssh_authorizedkeys + 8 + + for details) it might be cumbersome or not even possible to do this + for the general case where local services use PAM for + authentication. + + + To make the mapping more flexible mapping and matching rules were + added to SSSD (see + + sss-certmap + 5 + + for details). + + + A mapping and matching rule can be added to the SSSD configuration + in a section on its own with a name like + [certmap/DOMAIN_NAME/RULE_NAME]. + In this section the following options are allowed: + + + + matchrule (string) + + + Only certificates from the Smartcard which matches this + rule will be processed, all others are ignored. + + + Default: KRB5:<EKU>clientAuth, i.e. only + certificates which have the Extended Key Usage + clientAuth + + + + + maprule (string) + + + Defines how the user is found for a given certificate. + + + Default: + + + LDAP:(userCertificate;binary={cert!bin}) + for LDAP based providers like + ldap, AD or + ipa. + + + The RULE_NAME for the files + provider which tries to find a user with the + same name. + + + + + + + domains (string) + + + Comma separated list of domain names the rule should be + applied. By default a rule is only valid in the domain + configured in sssd.conf. If the provider supports + subdomains this option can be used to add the rule to + subdomains as well. + + + Default: the configured domain in sssd.conf + + + + + priority (integer) + + + Unsigned integer value defining the priority of the + rule. The higher the number the lower the priority. + 0 stands for the highest priority while + 4294967295 is the lowest. + + + Default: the lowest priority + + + + + + To make the configuration simple and reduce the amount of + configuration options the files provider has some + special properties: + + + + if maprule is not set the RULE_NAME name is assumed to + be the name of the matching user + + + + + if a maprule is used both a single user name or a + template like + {subject_rfc822_name.short_name} must + be in braces like e.g. (username) or + ({subject_rfc822_name.short_name}) + + + + + the domains option is ignored + + + + + + EXAMPLES @@ -3341,6 +3470,26 @@ enumerate = False [domain/ipa.com/child.ad.com] use_fully_qualified_names = false + + + + 3. The following example shows the configuration for two certificate + mapping rules. The first is valid for the configured domain + my.domain and additionally for the subdomains + your.domain and uses the full certificate in the + search filter. The second example is valid for the domain + files where it is assumed the files provider is used + for this domain and contains a matching rule for the local user + myname. + +[certmap/my.domain/rule_name] +matchrule = <ISSUER>^CN=My-CA,DC=MY,DC=DOMAIN$ +maprule = (userCertificate;binary={cert!bin}) +domains = my.domain, your.domain +priority = 10 + +[certmap/files/myname] +matchrule = <ISSUER>^CN=My-CA,DC=MY,DC=DOMAIN$<SUBJECT>^CN=User.Name,DC=MY,DC=DOMAIN$ -- 2.14.4