7.1

n
Using Certicate Revocation Checking on page 107
You can congure certicate revocation checking to prevent users who have their user certicates
revoked from authenticating. Certicates are often revoked when a user leaves an organization, loses a
smart card, or moves from one department to another.
n
Congure Certicate Authentication for Directories Management on page 108
You enable and congure certicate authentication from the vRealize Automation administration
console Directories Management feature.
Using User Principal Name for Certificate Authentication
You can use certicate mapping in Active Directory. Certicate and smart card logins uses the user principal
name (UPN) from Active Directory to validate user accounts. The Active Directory accounts of users
aempting to authenticate in the Directories Management service must have a valid UPN that corresponds
to the UPN in the certicate.
You can congure the Directories Management to use an email address to validate the user account if the
UPN does not exist in the certicate.
You can also enable an alternate UPN type to be used.
Certificate Authority Required for Authentication
To enable logging in using certicate authentication, root certicates and intermediate certicates must be
uploaded to the Directories Management.
The certicates are copied to the local certicate store on the user's computer. The certicates in the local
certicate store are available to all the browsers running on this user's computer, with some exceptions, and
therefore, are available to a Directories Management instance in the browser.
For smart-card authentication, when a user initiates a connection to a the Directories Management instance,
the Directories Management service sends a list of trusted certicate authorities (CA) to the browser. The
browser checks the list of trusted CAs against the available user certicates, selects a suitable certicate, and
then prompts the user to enter a smart card PIN. If multiple valid user certicates are available, the browser
prompts the user to select a certicate.
If a user cannot authenticate, the root CA and intermediate CA might not be set up correctly, or the service
has not been restarted after the root and intermediate CAs were uploaded to the server. In these cases, the
browser cannot show the installed certicates, the user cannot select the correct certicate, and certicate
authentication fails.
Using Certificate Revocation Checking
You can congure certicate revocation checking to prevent users who have their user certicates revoked
from authenticating. Certicates are often revoked when a user leaves an organization, loses a smart card, or
moves from one department to another.
Certicate revocation checking with certicate revocation lists (CRLs) and with the Online Certicate Status
Protocol (OCSP) is supported. A CRL is a list of revoked certicates published by the CA that issued the
certicates. OCSP is a certicate validation protocol that is used to get the revocation status of a certicate.
You can congure certicate revocation checking in the administration console Connectors > Auth Adapters
> CerticateAuthAdapter page when you congure certicate authentication.
You can congure both CRL and OCSP in the same certicate authentication adapter conguration. When
you congure both types of certicate revocation checking and the Use CRL in case of OCSP failure
checkbox is enabled, OCSP is checked rst and if OCSP fails, revocation checking falls back to CRL.
Revocation checking does not fall back to OCSP if CRL fails.
Chapter 2 Configuring Tenant Settings
VMware, Inc. 107