Chatee ahora con Soporte
Chat con el soporte

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

Privileged Access Suite for Unix Introducing Safeguard Authentication Services for Smart Cards Installing Safeguard Authentication Services for Smart Cards Configuring Safeguard 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 Safeguard 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 Safeguard Authentication Services for Smart Cards uses certificates and CRLs

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.

Map certificate to user (implicit and explicit)

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

  1. 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.
  2. 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:

  1. Find the subject key identifier on the certificate.
  2. Locate the user in Active Directory that the subject key identifier is mapped to.
  3. Authenticate fred@example.com.

Bootstrapping trusted certificates

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.

Documentos relacionados

The document was helpful.

Seleccionar calificación

I easily found the information I needed.

Seleccionar calificación