Chapter 14. Configuring certificate mapping if AD user entry contains no certificate or mapping data

Procedure

1. Log into the IdM web UI as an administrator.
2. Navigate to Authentication Certificate Identity Mapping Rules Certificate Identity Mapping Rules.

3. Click Add.

   Adding a new certificate mapping rule in the IdM web UI image::new-certmaprule-add.png[Screenshot of the IdM Web UI displaying the "Certificate Identity Mapping Rules" sub-page from the Authentication tab. The "Add" button to the right is highlighted]

4. Enter the rule name.

5. Enter the mapping rule. To have the whole certificate that is presented to IdM for authentication compared to the certificate stored in the user ID override entry of the AD user entry in IdM:

   (userCertificate;binary={cert!bin})

   Copy to Clipboard Toggle word wrap
   Note

   As the certificate also contains the user principal name as the SAN, or with the latest updates, the SID of the user in the SID extension of the certificate, you can also use these fields to map the certificate to the user. For example, if using the SID of the user, replace this mapping rule with LDAPU1:(objectsid={sid}). For more information on certificate mapping, see the sss-certmap man page on your system.

6. Enter the matching rule. For example, to only allow certificates issued by the AD-ROOT-CA of the AD.EXAMPLE.COM domain to authenticate:

   <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com

   Copy to Clipboard Toggle word wrap

7. Enter the domain name. For example, to search for users in the ad.example.com domain:

   Certificate mapping rule for a user with no certificate or mapping data stored in AD image::certmaprule-add-details-ad-cert.png[Screenshot of the "Add Certificate Identity Mapping Rule" pop-up window with the following fields filled in: Rule name (which is required) - Mapping rule - Matching rule. The "Priority" field is blank and there is also an Add button next to the "Domain name" label.]

8. Click Add.

9. The System Security Services Daemon (SSSD) periodically re-reads the certificate mapping rules. To force the newly-created rule to be loaded immediately, restart SSSD in the CLI:

   # systemctl restart sssd

   Copy to Clipboard Toggle word wrap

Procedure

1. Obtain the administrator’s credentials:

   # kinit admin

   Copy to Clipboard Toggle word wrap

2. Enter the mapping rule and the matching rule the mapping rule is based on. To have the whole certificate that is presented for authentication compared to the certificate stored in the user ID override entry of the AD user entry in IdM, only allowing certificates issued by the AD-ROOT-CA of the AD.EXAMPLE.COM domain to authenticate:

   # ipa certmaprule-add simpleADrule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(userCertificate;binary={cert!bin})' --domain ad.example.com

   Copy to Clipboard Toggle word wrap

   -------------------------------------------------------
   Added Certificate Identity Mapping Rule "simpleADrule"
   -------------------------------------------------------
     Rule name: simpleADrule
     Mapping rule: (userCertificate;binary={cert!bin})
     Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
     Domain name: ad.example.com
     Enabled: TRUE

   Copy to Clipboard Toggle word wrap
   Note

   As the certificate also contains the user principal name as the SAN, or with the latest updates, the SID of the user in the SID extension of the certificate, you can also use these fields to map the certificate to the user. For example, if using the SID of the user, replace this mapping rule with LDAPU1:(objectsid={sid}). For more information on certificate mapping, see the sss-certmap man page on your system.

3. The System Security Services Daemon (SSSD) periodically re-reads the certificate mapping rules. To force the newly-created rule to be loaded immediately, restart SSSD:

   # systemctl restart sssd

   Copy to Clipboard Toggle word wrap

Procedure

1. Navigate to Identity ID Views Default Trust View.

2. Click Add.

   Adding a new user ID override in the IdM web UI image::new-useridoverride-add.png[Screenshot of the IdM Web UI displaying the "ID Views" page from the Identity tab. The Add button on the right is highlighted.]

3. In the User to override field, enter ad_user@ad.example.com.

4. Copy and paste the certificate of ad_user into the Certificate field.

   Configuring the User ID override for an AD user image::useridoverride-add-details.png[Screenshot displaying the "Add User ID override" pop-up window with the following fields: User to override (which is required) - User login - GECOS - UID - GID - Certificate (which has been filled in with the plaintext version of a certificate).]

5. Click Add.

Verification

1. Use the sss_cache utility to invalidate the record of ad_user@ad.example.com in the SSSD cache and force a reload of the ad_user@ad.example.com information:

   # sss_cache -u ad_user@ad.example.com

   Copy to Clipboard Toggle word wrap

2. Run the ipa certmap-match command with the name of the file containing the certificate of the AD user:

   # ipa certmap-match ad_user_cert.pem

   Copy to Clipboard Toggle word wrap

   --------------
   1 user matched
   --------------
    Domain: AD.EXAMPLE.COM
    User logins: ad_user@ad.example.com
   ----------------------------
   Number of entries returned 1
   ----------------------------

   Copy to Clipboard Toggle word wrap

   The output confirms that you have certificate mapping data added to ad_user@ad.example.com and that a corresponding mapping rule defined in Adding a certificate mapping rule if the AD user entry contains no certificate or mapping data exists. This means that you can use any certificate that matches the defined certificate mapping data to authenticate as ad_user@ad.example.com.

Procedure

1. Obtain the administrator’s credentials:

   # kinit admin

   Copy to Clipboard Toggle word wrap

2. Store the certificate blob in a new variable called CERT:

   # CERT=$(openssl x509 -in /path/to/certificate -outform der|base64 -w0)

   Copy to Clipboard Toggle word wrap

3. Add the certificate of ad_user@ad.example.com to the user account using the ipa idoverrideuser-add-cert command:

   # ipa idoverrideuser-add-cert ad_user@ad.example.com --certificate $CERT

   Copy to Clipboard Toggle word wrap

Verification

1. Use the sss_cache utility to invalidate the record of ad_user@ad.example.com in the SSSD cache and force a reload of the ad_user@ad.example.com information:

   # sss_cache -u ad_user@ad.example.com

   Copy to Clipboard Toggle word wrap

2. Run the ipa certmap-match command with the name of the file containing the certificate of the AD user:

   # ipa certmap-match ad_user_cert.pem

   Copy to Clipboard Toggle word wrap

   --------------
   1 user matched
   --------------
    Domain: AD.EXAMPLE.COM
    User logins: ad_user@ad.example.com
   ----------------------------
   Number of entries returned 1
   ----------------------------

   Copy to Clipboard Toggle word wrap

   The output confirms that you have certificate mapping data added to ad_user@ad.example.com and that a corresponding mapping rule defined in Adding a certificate mapping rule if the AD user entry contains no certificate or mapping data exists. This means that you can use any certificate that matches the defined certificate mapping data to authenticate as ad_user@ad.example.com.