Certificate mapping
Requires the ca module. How a client certificate or smart card is matched to a user: matching and mapping rule syntax, priority, the global "prompt for username" switch, and checking a rule on the match page.
Requires the ca module. On a certificate login (smart card, PKINIT, the console's "Log in with certificate") sssd holds a certificate and has to answer "which user is this". Three ways: the whole certificate is stored on the user (exact match); the user's ipacertmapdata holds its issuer + subject; or a certificate mapping rule turns certificate fields into an LDAP query.
Rule
| Field | Meaning |
|---|---|
| Matching rule | which certificates the rule applies to. <ISSUER>CN=Certificate Authority,O=LINUX.IPA.TEST matches IPA CA issued ones; <SUBJECT>.*,DC=ad,DC=example,DC=com matches an AD CA. Empty = all |
| Mapping rule | how to look up the user on a match. Placeholders {subject_dn}, {issuer_dn}, {subject_rfc822_name} (e-mail SAN), {subject_principal} (UPN SAN)…; conversions such as !nss_x500 put the DN in LDAP order |
| Domain name | where to look. Empty = this domain; an AD domain name searches AD (smart-card logins for AD users) |
| Priority | lower number tried first; the first rule that matches and finds a user ends the search |
| Enabled | disabled rules are skipped |
Common mappings:
| Case | Mapping rule |
|---|---|
certificate stored in the user's ipacertmapdata | (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500}) |
| subject CN is the login | (uid={subject_cn}) |
| e-mail SAN matches the user's mail | (mail={subject_rfc822_name}) |
| AD smart card, UPN matches the AD user | (userPrincipalName={subject_principal}) with the AD domain, or (altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}) |
A mapping query returning more than one user counts as a failure and the login is refused.
Global configuration
"Prompt for username": when ticked, a certificate login also asks for the login name and the mapping result must agree with it. Unticked, the certificate alone decides. Tick it when several certificates belong to one person or a mapping could be ambiguous.
Checking a rule
The match page takes a PEM certificate, decodes issuer, subject, serial, validity and fingerprint on the right, and Match lists the users the current rules resolve to. Same as ipa certmap-match cert.pem. Try a rule here before relying on it.
Boundaries
- Rule changes reach clients after
sss_cache -E; sssd fetches rules on every certificate login, but user lookups are cached. - Matching AD users needs the ad-trust module and an established trust.
- Certificate validity itself (chain, revocation) is decided by the client's sssd
certificate_verification, not by the rules.
Identity Provider references
Register an external OIDC identity source (Keycloak, Okta, Azure AD, GitHub…) in IPA so users log in through the device authorization flow and still obtain a Kerberos ticket.
DNS
Requires the dns module. IPA's own DNS: zones, records, forward zones and forward policy, per-server forwarders, global config; how host records are maintained automatically, and why this group is meaningless with IPA_SETUP_DNS=false.