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.
Safeguard 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 Safeguard Authentication Services for Smart Cards.
This mutual authentication is critical to the security of the PKINIT protocol, and requires that Safeguard 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 Safeguard Authentication Services are stored in the /var/opt/quest/vas/certs directory.
Mapping certificates to users can be done implicitly or explicitly. Authentication Services supports mapping one cert to one user or mapping multiple certs to one user. Mapping one cert to multiple users is not supported.
Implicit mapping
The user's subjectAlternativeName (SAN) on the certificate typically matches the user's userPrincipalName (UPN) or Kerberos v5 principal name. The match is implicit and no additional mapping effort is needed. In the following example, the user fred has certificate where the SAN matches the user's UPN in Active Directory. The match is implicit and the user is authenticated.
AD Attribute:
$ /opt/quest/bin/vastool -u host/ attrs fred userPrincipalName
userPrincipalName: fred@example.com
Smart Card attribute:
UPN: fred@example.com
Explict mapping
If the user's SAN on the certificate does not match the user's UPN or Kerberos v5 principal name, you can explicitly map a certificate to a user using any one of several certificate attributes, including:
- Subject and Issuer fields
altSecurityIdentities: X509:<I>DC=local,DC=dod,CN=SpatDoD Root CA<S>CN=gman
- Subject DN
altSecurityIdentities: X509:<S>CN=gman
- Subject Key Identifier
altSecurityIdentities: X509:<SKI>ddde2ca4b86db8a908b95c6cbcc8bb1ac7a09a41
- Issuer, and Serial Number
altSecurityIdentities: X509:<I>DC=local,DC=dod,CN=SpatDoD Root CA<SR>32000000000003bde810
- SHA1 Hash
altSecurityIdentities: X509:<SHA1-PUKEY>ed913fa41377dbfb8eac2bc6fcae71ecd4a974fd
- RFC822 name
altSecurityIdentities: X509:<RFC822>efedman@fedid.gov
For details see: HowTo: Map a user to a certificate via all the methods available in the altSecurityIdentities attribute.
To explicitly map a certificate to a user
- If necessary, disable UPN mapping behavior. For details, HowTo: Disable UPN mapping for SmartCard logon and How to disable the Subject Alternative Name for UPN mapping.
- View the user's altSecurityIdentites attributes to see the certificates mapped to a user then map to one of the attributes.
You can define explicit mapping in Active Directory by importing a cert and mapping it to a user object. For details, see Defining the Mapping in Active Directory, Enable Explicit Mapping section.
Alternatively, you can look at the certificates mapped to a user, as shown in the following example.
Example: View the certificates mapped to a user
The user's altSecurityIdentites attributes shows the certificates mapped to a user.
For example, the following command line displayed the list of certificates mapped to the user fred. As we will see later, the subject key identifier (in bold below) can be used to map.
$ /opt/quest/bin/vastool -u host/ attrs fred altSecurityIdentities
altSecurityIdentities: X509:<SKI>983678656A4CF815843B4491BDD7B71784F2256E
altSecurityIdentities: X509:<SKI>45C700F77ACA71414AAA2D6C9FF9D93825B4F54A
altSecurityIdentities: X509:<SHA1-PUKEY>D628703850294D437A301ADFFD0D48FE2842F424
altSecurityIdentities: X509:<I>C=US,S=Example State,L=Example Location,O=Example Organization,OU=Example OU,CN=User Bob,E=user.bob@example.com<SR>78563412
altSecurityIdentities: X509:<S>C=US,L=Example,O=Example Organization,OU=Example OU,CN=subject-dn-mapping
altSecurityIdentities: X509:<SKI>05A7DAD104DA8FEDB8B9200F415D1719F483BF9F
altSecurityIdentities: X509:<RFC822>certmapping@smartcard.com
altSecurityIdentities: X509:<I>C=US,S=Example State,L=Example Location,O=Example Organization,OU=Example OU,CN=User Bob,E=user.bob@example.com<S>CN=subject-issuer-mapping
As shown in the example below, the smart card attributes do not correspond to a user in Active Directory (AD). However, the subject key identifier (bolded below) can be used to map to the altSecurityIdentites (bolded in the above example).
Smart card attributes:
subjectAlternativeName: skimapping@smartcard.com
Subject = CN=subject-key-identifier-mapping
Issuer = emailAddress=bob@example.com,CN=User Bob,OU=Example OU,O=Example Organization,L=Example Location,S=Example State,C=US
Serial Number = 16
Not valid before = 2019-12-02 23:54:26
Not valid after = 2020-12-01 23:54:26
Signature algorithm = md5WithRSAEncryption
Key algorithm = rsaEncryption
Key usage = keyEncipherment, digitalSignature
Extended key usage = Microsoft Smartcardlogin, 1.3.6.1.5.2.3.4, TLS Web Client Authentication
Subject key identifier = 05A7DAD104DA8FEDB8B9200F415D1719F483BF9F
SHA1 hash = b009a0019b0a31125dcd0e80238ef7a263578a36
At this point, once the smart card is inserted into a reader, Authentication Services will:
- Find the subject key identifier on the certificate.
- Locate the user in Active Directory that the subject key identifier is mapped to.
- Authenticate fred@example.com.
By default Safeguard 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 Safeguard 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 Safeguard Authentication Services for Smart Cards clients.
Safeguard 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.
