How to Determine if Smart Card Authentication Provider Was Used

Hey folks, Keith Brewer here to discuss how to determine how a user has authenticated. Recently I was onsite with a Microsoft Premier Customer and they asked if there was a way for them to determine if a user had used username and password or their issued smart card for logon.

Problem:

IT Organization has been provisioning smart cards for all users but not enforcing its use. The IT organization would like to get a better picture if users are actually using their smartcards for authentication purposes prior to implementing smart card enforcement options.

Solution:

A fellow PFE Fabian Müller has written on this topic on TechNet WIKI here:

http://social.technet.microsoft.com/wiki/contents/articles/11844.find-out-if-a-smart-card-was-used-for-logon.aspx

On Fabian’s WIKI page you will find more information on the different approaches but I will summarize them here:

Server Side:

Using server side (Domain Controller) auditing alongside centralized managed storage of events such as System Center Operations Monitoring Audit Collection Service (ACS). ACS together with System Center Operation Manger 2012 can be deployed to gather, evaluate and report on the occurrences of events specific to user logon.

Client Side:

Authentication Mechanism Assurance (AMA) is an added capability in Windows Server 2008 R2 AD DS that you can use when the domain functional level is set to Windows Server 2008 R2. When it is enabled, authentication mechanism assurance adds an administrator-designated global group membership to a user’s Kerberos token when the user’s credentials are authenticated during logon using a certificate-based logon method.

The last alternative approach discussed was the “quick-and-dirty” approach leveraging data stored within registry on the client machine.

In deploying an enterprise solution I would generally lean towards the server side solution as this would provide authoritative information on the logon from the domain controller where the logon was processed. However to effectively implement you would need to be logging the appropriate events on all domain controllers and centrally storing all the events for analysis. If you do not meet these requirements then a client side approach may be warranted.

Now headed down the client side approach the preferred method would be leveraging Authentication Mechanism Assurance (AMA). However this requires that AMA be setup and configured.

The above 2 methods report with certainty that a Smart Card was used for logon.

The Event targeted with the server side (Domain Controller) solution will identify that PKINIT was used for logon and as mentioned on the WIKI currently the only built-in logon method that uses PKINIT is Smart Card Logon

AMA method would identify a group in the users token that would only be present if authenticated with the configured certificate.

If you cannot currently meet these requirements then as an alternative approach we can try to determine the provider used on the client side via the local machine registry.

The challenges with these methods are that the provider information is only written at logon. For example the provider information in this area of the registry is not updated when a user locks/unlocks their workstation.

The UserTile approach works very well for client machines running Windows 8 or later operating systems. The default behavior of Windows 8 and later is to present the user the same credential provider used during logon on subsequent attempts (unlock). This is what is stored in the UserTile branch. We can use this information to determine what provider was used the last time this user logged on. This will be accurate if a user changes credential provider in an unlock operation as the new provider will be stored in the UserTile branch.

However this customer’s client machines were mostly Windows 7 and administrators wanted to capture user’s credential providers utilizing terminal servers on both Windows Server 2008 and Windows Server 2008 R2. As such the solution could not consistently rely on the presence of the UserTile registry branch.

Fabian did show us the SessionData sub key of the LOGONUI registry branch. This was crucial to gathering the information we needed both for Windows 7 clients but also for remote logon (Remote Desktop Services).

I have uploaded the following script to the script gallery on TechNet:

http://gallery.technet.microsoft.com/Detect-Authentication-09b0a749

This script gathers the current session of the logged on user to identify the correct sub key in the LOGONUI\SessionData branch.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\SessionData

On a Windows 8 Client:

If the user has logged on using the default Smart Card Authentication Provider the output should show:

If the user has logged on using the default UserName/Password Authentication Provider the output should show:

On Windows Server 2008 R2

If the user has logged on using the default Smart Card Authentication Provider the output should show:

If the user has logged on using the default UserName/Password Authentication Provider the output should show:

Much of the solutions mentioned in this article focus on the use of native Windows credential providers or other Microsoft Services. If 3^rd party products are included within the Smart Card implementation mileage may vary.

So to summarize:

Preferred Method:

Centralized Storage of Security Logon Events from all Domain Controllers

Leveraging Authentication Mechanism Assurance

Alternative Solutions:

If gathering from Windows 8 and Windows Server 2012

UserTile Registry Query

If Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2

SessionData Registry Query

Hope This Helps

Keith “Authentication Mecha What??” Brewer