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


This user story describes the steps necessary for enabling certificate mapping in IdM if the IdM deployment is in trust with Active Directory (AD), the user is stored in AD and the user entry in AD contains neither the whole certificate nor certificate mapping data.

14.1. Prerequisites

  • The user does not have an account in IdM.
  • The user has an account in AD which contains neither the whole certificate nor the altSecurityIdentities attribute, the AD equivalent of the IdM certmapdata attribute.
  • The IdM administrator has done one of the following:

    • Added the whole AD user certificate to the AD user’s user ID override in IdM.
    • Created a certificate mapping rule that maps to an alternative field in the certificate, such as Subject Alternative Name or the SID of the user.
  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.

    Figure 14.1. Adding a new certificate mapping rule in the IdM web UI

  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:

    Figure 14.2. Certificate mapping rule for a user with no certificate or mapping data stored in AD

  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
  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
    -------------------------------------------------------
    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
  1. Navigate to Identity ID Views Default Trust View.
  2. Click Add.

    Figure 14.3. Adding a new user ID override in the IdM web UI

  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.

    Figure 14.4. Configuring the User ID override for an AD user

  5. Click Add.

Verification

Verify that the user and certificate are linked:

  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
    --------------
    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.

  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

Verify that the user and certificate are linked:

  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
    --------------
    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.

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat