Chat now with support
Chat with Support

Safeguard Authentication Services 4.2 - Authentication Services for Smart Cards Administration Guide

One Identity Privileged Access Suite for Unix Introducing Authentication Services for Smart Cards Installing Authentication Services for Smart Cards Configuring Authentication Services for Smart Cards
Configuring the vendor’s PKCS#11 library Configuring the card slot for your PKCS#11 library Configuring PAM applications for smart card login Configuring certificates and CRLs Locking the screen saver upon card removal (macOS)
Testing Authentication Services for Smart Cards Troubleshooting

Certificates and CRLs

A Certificate authenticates public keys by binding the key with information associated with its user. A certificate also contains other information such as when the key is valid, what the key may be used for, and whether the key may be used to sign other certificates.

A Certificate Revocation List (CRL) is issued by a CA at regular intervals and lists certificates that have been invalidated or revoked before their expiry date.

When verifying whether a certificate is valid, a user must check both the certificate signature, and the current valid CRL to ensure that the certificate is not listed on it.

Reasons for revocation can include:

  • Compromise of the private key
  • Loss of the key or token
  • Invalid or out of date information in the certificate

An example might be when a user leaves a company.

How Authentication Services for Smart Cards uses certificates and CRLs

Authentication Services for Smart Cards uses Public Key cryptography to authenticate users to Active Directory. It uses keys and certificates stored on the smart card to perform a version of the Kerberos authentication protocol called PKINIT. When Active Directory has authenticated the user, it in turn authenticates itself back to Authentication Services for Smart Cards.

This mutual authentication is critical to the security of the PKINIT protocol, and requires that Authentication Services for Smart Cards verify the certificate presented by Active Directory as part of this exchange against one or more trusted certificates and CRLs.

Trusted certificates used by Authentication Services are stored in the /var/opt/quest/vas/certs directory.

Bootstrapping trusted certificates

By default Authentication Services for Smart Cards is configured to automatically retrieve trusted certificates and CRLs from Active Directory. It is possible to do this securely because Authentication Services sets up a secure communication channel at join time using the symmetric host key that it uses to join itself to the domain.

Active Directory stores trusted certificates for smart card login in the NtAuthCertificates container which is located by the LDAP distinguished name.

CN=NtAuthCertificates,CN=Public Key Services,CN=Configuration,
DC=<domain>,DC=<domain>,…

By default, any certificates placed in this location in Active Directory are automatically distributed to both Windows and Authentication Services for Smart Cards clients.

Authentication Services for Smart Cards places these trusted certificates in the NtAuth subdirectory of the /var/opt/quest/vas/certs directory.

Note: You should not place any additional certificates in this subdirectory as they may be deleted from time to time. You may however place additional trusted certificates directly in the /var/opt/quest/vas/certs directory.

Automatic CRL retrieval

By default Authentication Services for Smart Cards retrieves any CRLs that are required to verify the certificates presented by Active Directory and automatically updates these as they expire and new certificates are issued. To be able to retrieve CRLs, the certificates to which they correspond must contain a CRL distribution points extension that contains an LDAP URI from which to download the CRL.

CRLs are stored in the /var/opt/quest/vas/crls directory.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating