From time to time we get the question on how to find out if a user logged on to the Windows interactive session using his credentials (e.g. username / password) or by using a Smart Card.
Depending on your needs you can choose two ways to gather the data:
Centralized data collection
In some scenarios it makes sense to gather the logon data centralized in order to create statistics on Smart Card vs. credential usage or similar logon methods.
In this scenario, the Domain Controller Security Eventlog can provide the relevant data. The information on how a user was logged on is included in the logon events: Category “Account Logon” with “Pre-Authentication Type: PKINIT 14 to 17”. This data can be
collected using System Center Operations Manager Audit Collection Services (SCOM ACS)
or similar tools and a central report can be created and reviewed.
There is a caveat here: Kerberos
RFC 4120 states that the PKINIT events 14 to 17 just provide the information that PKINIT was used for logon:
PA-PK-AS-REQ_OLD 14 (pkinit)
PA-PK-AS-REP_OLD 15 (pkinit)
PA-PK-AS-REQ 16 (pkinit)
PA-PK-AS-REP 17 (pkinit)
But you can safely use this information from Domain Controller Security logs since we currently use these pre-authentication types just for Smart Card logon. See
 for further information.
The client-side approach
There might be other scenarios where you need the logon method information at the client-side.
Windows XP provided an environment variable in the user session when a Smart Card logon occurred. This environment variable called “SmartCard” is not present
anymore since Windows Vista / Windows Server 2008.
Instead, you can now gather the data on a client running on Windows Vista / Windows Server 2008 and above using the
Authentication Mechanism Assurance, which injects a special security group
into the user’s Access Token (in detail: the user's Kerberos TGT PAC). This security group can be used by applications by accessing user’s Access Token respectively the user's security group memberships.
There are some requirements
before you can start with "Authentication Mechanism Assurance":
“To complete all the steps in this guide, you must first complete all the steps in the AD FS in Windows Server 2008 R2 Step-by-Step Guide (http://go.microsoft.com/fwlink/?LinkId=133009).
However, it should be possible to complete the first three steps in this guide using a different, but compatible, configuration that meets the following minimum requirements:
(Quoted from http://technet.microsoft.com/en-us/library/dd378897%28v=ws.10%29.aspx#bkmk_Req)
From my point of view, at this time "Authentication Mechanism Assurance" is the best way to go if the data should be gathered on client-side.
If you do not meet the pre-requisites for
Authentication Mechanism Assurance yet, you can take the following approach (requires
Windows Vista/2008 and above at the client):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers lists all Credential Providers for a client:
You can access the Credential Providers information of the client's logged on users using the Session IDs. The sub-keys
of HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI provide the information which user logged on using which Credential Provider (SID and sAMAccountName removed in the screenshot):
As an alternative you can just use the "quick-and-dirty" approach and read the "UserTile" Information, which points to the click a user did when logging on to a machine interactive (SIDs removed in the screenshot):
A simple PowerShell sample script for Windows Vista/2008 and above that provides this basic UserTile information (running in the user’s logon session) could look like the following:
The different approaches discussed in this article should provide the basic information you need in order to track Smart Card usage at your clients.
Carsten Siemens edited Revision 8. Comment: fixed typo