Chat now with support
Chat with Support

Safeguard Authentication Services 6.0 LTS - 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

Log shows "Failed authentication attempt: cannot verify certificate"

You will get a log error message that says, Failed authentication attempt: cannot verify certificate when Active Directory is verifying the user's certificate, or when Safeguard Authentication Services for Smart Cards is verifying the KDC certificate returned by Active Directory. The most likely causes are either that the CA certificate that was used to issue that certificate is not in the NtAuthCertificates container in Active Directory, or Safeguard Authentication Services for Smart Cards was unable to automatically bootstrap the trusted certificates.

Check the user's account settings in in Active Directory. For more information, see Checking login.

See also Bootstrapping trusted certificates.

Troubleshooting "Client not trusted" issue


An error displays, similar to the following:

ERROR: could not establish initial credentials
ERROR: VAS_ERR_KRB5: at ticket.c:72 in ticket_generate_good_error
Failed to obtain credentials. Client: vas-user@SC.VAS, Service:
Caused by:
KRB5_KDC_ERR_CLIENT_NOT_TRUSTED (-1765328322): Client not trusted

You will get an error message that says Client not trusted if Active Directoryy cannot determine the validity of the client certificate supplied by the smart card, or the validity of any certificate that issued the client certificate.

This may occur for a number of reasons:

  1. The Certification Authority service (CA) is not running on the domain controller.

    Active Directory passes the certificate to the CA for verification. If the CA is not running, the certificate cannot be verified and is therefore not trusted.

  2. The CA is running, but the Certificate Revocation List (CRL) contained in the certificate is out of date and a new CRL cannot be obtained.

    Typically, the CRL is obtained by means of LDAP calls to an external revocation server, and if this server is unreachable or cannot supply a new CRL, the CA cannot check the revocation status of the certificate and the client is therefore not trusted.

  1. Confirm that the Certification Authority service is running on the domain controller. Navigate to Start > Administrative Tools > Certification Authority, and verify that there is a small green tick attached to the "CA" property in the left-hand side of the panel. If there is a small red dot for this property, right click on CA, and select All Tasks > Start Service.

  2. Confirm that the revocation server is reachable:

    1. Attach a smart card reader to the Windows machine for which login is required.

    2. Insert the smart card into the reader.

    3. Open up a command prompt, and run the command certutil –SCInfo. This command attempts to verify the client certificate on the smart card, including CRL checks.

    4. Check the output for the following:

      The revocation function was unable to check revocation
      because the revocation server was offline. 0x80092013
      Revocation check skipped -- server offline

Troubleshooting certificate lookups


Certificate lookups fail.


This failure occurs because the default IPC timeout of 5 seconds is insufficient to handle some referrals.


Set a sufficient value for the vascache-ipc-timeout property in vas.conf, as follows:

vascache-ipc-timeout = 10
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating