Federated Authentication Service troubleshoot Windows logon issues

This article describes the logs and error messages Windows provides when a user logs on using certificates and/or smart cards. These logs provide information you can use to troubleshoot authentication failures.

Certificates and public key infrastructure

Windows Active Directory maintains several certificate stores that manage certificates for users logging on.

  • NTAuth certificate store: To authenticate to Windows, the CA immediately issuing user certificates (that is, no chaining is supported) must be placed in the NTAuth store. To see these certificates, from the certutil program, enter: certutil –viewstore –enterprise NTAuth.
  • Root and intermediate certificate stores: Usually, certificate logon systems can provide only a single certificate, so if a chain is in use, the intermediate certificate store on all machines must include these certificates. The root certificate must be in the Trusted Root Store, and the penultimate certificate must be in the NTAuth store.
  • Logon certificate extensions and Group Policy: Windows can be configured to enforce verification of EKUs and other certificate policies. See the Microsoft documentation: https://technet.microsoft.com/en-us/library/ff404287%28v=ws.10%29.aspx.
Registry policy Description
AllowCertificatesWithNoEKU When disabled, certificates must include the smart card logon Extended Key Usage (EKU).
AllowSignatureOnlyKeys By default, Windows filters out certificates private keys that do not allow RSA decryption. This option overrides that filter.
AllowTimeInvalidCertificates By default, Windows filters out expired certificates. This option overrides that filter.
EnumerateECCCerts Enables elliptic curve authentication.
X509HintsNeeded If a certificate does not contain a unique User Principal Name (UPN), or it could be ambiguous, this option allows users to manually specify their Windows logon account.
UseCachedCRLOnlyAnd, IgnoreRevocationUnknownErrors Disables revocation checking (usually set on the domain controller).
  • Domain controller certificates: To authenticate Kerberos connections, all servers must have appropriate “Domain Controller” certificates. These can be requested using the “Local Computer Certificate Personal Store” MMC snap-in menu.

UPN name and certificate mapping

It is recommended that user certificates include a unique User Principal Name (UPN) in the Subject Alternate Name extension.

UPN names in Active Directory

By default, every user in Active Directory has an implicit UPN based on the pattern <samUsername>@<domainNetBios> and <samUsername>@<domainFQDN>. The available domains and FQDNs are included in the RootDSE entry for the forest. Note that a single domain can have multiple FQDN addresses registered in the RootDSE.

Additionally, every user in Active Directory has an explicit UPN and altUserPrincipalNames. These are LDAP entries that specify the UPN for the user.

When searching for users by UPN, Windows looks first in the current domain (based on the identity of the process looking up the UPN) for explicit UPNs, then alterative UPNs. If there are no matches, it looks up the implicit UPN, which may resolve to different domains in the forest.

Certificate Mapping Service

If a certificate does not include an explicit UPN, Active Directory has the option to store an exact public certificate for each use in an “x509certificate” attribute. To resolve such a certificate to a user, a computer can query for this attribute directly (by default, in a single domain).

An option is provided for the user to specify a user account that speeds up this search, and also allows this feature to be used in a cross-domain environment.

If there are multiple domains in the forest, and the user does not explicitly specify a domain, the Active Directory rootDSE specifies the location of the Certificate Mapping Service. This is usually located on a global catalog machine, and has a cached view of all x509certificate attributes in the forest. This computer can be used to efficiently find a user account in any domain, based on only the certificate.

Control logon domain controller selection

When an environment contains multiple domain controllers, it is useful to see and restrict which domain controller is used for authentication, so that logs can be enabled and retrieved.

Control domain controller selection

To force Windows to use a particular Windows domain controller for logon, you can explicitly set the list of domain controllers that a Windows machine uses by configuring the lmhosts file: \Windows\System32\drivers\etc\lmhosts.

There is usually a sample file named “lmhosts.sam” in that location. Simply include a line:

1.2.3.4 dcnetbiosname #PRE #DOM:mydomai

Where “1.2.3.4” is the IP address of the domain controller named “dcnetbiosname” in the “mydomain” domain.

After a restart, the Windows machine uses that information to log on to mydomain. Note that this configuration must be reverted when debugging is complete.

Identify the domain controller in use

At logon, Windows sets an MSDOS environment variable with the domain controller that logged the user on. To see this, start the command prompt with the command: echo %LOGONSERVER%.

Logs relating to authentication are stored on the computer returned by this command.

Enable account audit events

By default, Windows domain controllers do not enable full account audit logs. This can be controlled through audit policies in the security settings in the Group Policy editor. After they are enabled, the domain controller produces extra event log information in the security log file.

localized image

Certificate validation logs

Check certificate validity

If a smartcard certificate is exported as a DER certificate (no private key required), you can validate it with the command: certutil –verify user.cer

Enable CAPI logging

On the domain controller and users machine, open the event viewer and enable logging for Microsoft/Windows/CAPI2/Operational Logs.

You can control CAPI logging with the registry keys at: CurrentControlSet\Services\crypt32.

Value Description
DiagLevel (DWORD) Verbosity level (0 to 5)
DiagMatchAnyMask (QUADWORD) Event filter (use 0xffffff for all)
DiagProcessName (MULTI_SZ) Filter by process name (for example, LSASS.exe)

CAPI logs

Message Description
Build Chain LSA called CertGetCertificateChain (includes result)
Verify Revocation LSA called CertVerifyRevocation (includes result)
X509 Objects In verbose mode, certificates and Certificate Revocation Lists (CRLs) are dumped to AppData\LocalLow\Microsoft\X509Objects
Verify Chain Policy LSA called CertVerifyChainPolicy (includes parameters)

Error messages

Error code Description
Certificate not trusted The smart card certificate could not be built using certificates in the computer’s intermediate and trusted root certificate stores.
Certificate revocation check error The CRL for the smart card could not be downloaded from the address specified by the certificate CRL distribution point. If revocation checking is mandated, this prevents logon from succeeding. See the Certificates and public key infrastructure section.
Certificate Usage errors The certificate is not suitable for logon. For example, it might be a server certificate or a signing certificate.

Kerberos logs

To enable Kerberos logging, on the domain controller and the end user machine, create the following registry values:

Hive Value name Value [DWORD]
CurrentControlSet\Control\Lsa\Kerberos\Parameters LogLevel 0x1
CurrentControlSet\Control\Lsa\Kerberos\Parameters KerbDebuglevel 0xffffffff
CurrentControlSet\Services\Kdc KdcDebugLevel 0x1
CurrentControlSet\Services\Kdc KdcExtraLogLevel 0x1f

Kerberos logging is output to the System event log.

  • Messages such as “untrusted certificate” should be easy to diagnose.
  • Two error codes are informational, and can be safely ignored:
    • KDC_ERR_PREAUTH_REQUIRED (used for backward compatibility with older domain controllers)
    • Unknown error 0x4b

Event log messages

This section describes the expected log entries on the domain controller and workstation when the user logs on with a certificate.

  • Domain controller CAPI2 log
  • Domain controller security logs
  • VDA security log
  • VDA CAPI log
  • VDA system log

Domain controller CAPI2 log

During a logon, the domain controller validates the caller’s certificate, producing a sequence of log entries in the following form.

localized image

The final event log message shows lsass.exe on the domain controller constructing a chain based on the certificate provided by the VDA, and verifying it for validity (including revocation). The result is returned as “ERROR_SUCCESS”.

localized image

Domain controller security log

The domain controller shows a sequence of logon events, the key event being 4768, where the certificate is used to issue the Kerberos Ticket Granting Ticket (krbtgt).

The messages before this show the machine account of the server authenticating to the domain controller. The messages following this show the user account belonging to the new krbtgt being used to authenticate to the domain controller.

localized image

VDA security log

The VDA security audit log corresponding to the logon event is the entry with event ID 4648, originating from winlogon.exe.

localized image

VDA CAPI log

This example VDA CAPI log shows a single chain build and verification sequence from lsass.exe, validating the domain controller certificate (dc.citrixtest.net).

localized image

localized image

VDA system log

When Kerberos logging is enabled, the system log shows the error KDC_ERR_PREAUTH_REQUIRED (which can be ignored), and an entry from Winlogon showing that the Kerberos logon was successful.

localized image

End user error messages

This section lists common error messages displayed to a user on the Windows logon page.

Error message displayed Description and reference
Invalid Username or Password The computer believes that you have a valid certificate and private key, but the Kerberos domain controller has rejected the connection. See the Kerberos logs section of this article.
The system could not log you on. Your credentials could not be verified. The domain controller cannot be contacted, or the domain controller does not have appropriate certificates installed.
The request is not supported Re-enroll the “Domain Controller” and “Domain Controller Authentication” certificates on the domain controller, as described in CTX206156. This is usually worth trying, even when the existing certificates appear to be valid.
The system could not log you on. The smartcard certificate used for authentication was not trusted. The intermediate and root certificates are not installed on the local computer. See CTX206156 for instructions on installing smart card certificates on non-domain joined computers. Also, see the Certificates and public key infrastructure section in this article.
You cannot logon because smart card logon is not supported for your account. A workgroup user account has not been fully configured for smart card logon.
The requested key does not exist A certificate references a private key that is not accessible. This can happen when a PIV card is not completely configured and is missing the CHUID or CCC file.
An error occurred when trying to use the smart card The smart card middleware was not installed correctly. See CTX206156 for smart card installation instructions.
Insert a smart card The smart card or reader was not detected. If the smart card is inserted, this message indicates a hardware or middleware issue. See CTX206156 for smart card installation instructions.
The PIN is incorrect The smart card rejected a PIN entered by the user.
No valid smart card certificate could be found. The extensions on the certificate might not be set correctly, or the RSA key is too short (<2048 bits). See CTX206901 for information about generating valid smart card certificates.
The smart card is blocked A smart card has been locked (for example, the user entered an incorrect pin multiple times). An administrator may have access to the pin unlock (puk) code for the card, and can reset the user pin using a tool provided by the smart card vendor. If the puk code is not available, or locked out, the card must be reset to factory settings.
Bad Request A smart card private key does not support the cryptography required by the domain controller. For example, the domain controller might have requested a “private key decryption,” but the smart card supports only signing. This usually indicates that the extensions on the certificate are not set correctly, or the RSA key is too short (<2048 bits). See CTX206901 for information about generating valid smart card certificates.