Certificate enumeration
When a smart card is inserted, the following steps are followed in order:
(Note: Unless otherwise mentioned, all operations are performed silently (CRYPT_SILENT is passed to CryptAcquireContext)
1. The Cryptographic Services Provider for that smart card is queried from the Smart card Resource Manager database.
2. A qualified container name is constructed using the reader name and is passed to the CSP. The format for that name is as follows: \\.\<Reader name>\
3. CryptAcquireContext is called to retrieve a context to the default container. A failure here would cause the smart card be unusable for smart card logon
4. The name of the container is retrieved by requesting the PP_CONTAINER parameter using CryptGetProvParam
5. Using the context acquired in 3 the CSP is queried for the PP_USER_CERTSTORE parameter, which was added in Vista (See Section on new CAPI properties for more information). On success, a certificate store is returned and program flow skips to step 8.
6. If 5. Fails, then the default container context (from 3) is queried for the AT_KEYEXCHANGE key.
7. The certificate is then queried from the key context using KP_CERTIFICATE. The certificate is added to an in memory certificate store.
8. For each certificate in the certificate store (Either from 5 or 7), the following checks are performed. These are the same requirements as in Windows 2003 but they are performed before the user enters their PIN. Many of these can be overridden using group policy settings:
a. The certificate must be valid based on the computer system clock. (Not expired or valid in the future)
b. The certificate must not be in the AT_SIGNATURE part of a container
c. The certificate must have a valid UPN.
d. The certificate must have the Digital Signature Key Usage
e. The certificate must have the smart card logon EKU
Certificates which meet the above are displayed to the user display the certificates Common Name in large text along with the certificates UPN (or email address or subject depending on presence of the extensions).
9. A certificate is then chosen and the PIN is entered.
10. LogonUI.exe packages up the information and sends the information to lsass.exe to process the logon attempt. See the section below for its usage there.
11. If successful, logonUI.exe is torn down causing the context acquired in 3 to be released.
New session management in Windows Vista
In order for smart card applications to work properly under Vista, the correct handling of sessions must be observed. The first user account gets session 1, the second gets session 2. Temporary sessions (used when the user chooses disconnect instead of log off) are also assigned a session number. Sessions last for the length of the user logon. On a reconnect (such as over TS or in a Fast User Switching (FUS) scenarios), the temporary session will be destroyed.
A key distinction is that a disconnected logon session is treated identically to a disconnected remote session. Also sessions can transfer between local and remote without requiring a process restart.
Winscard enforcement of session separation
By default, the smart card readers on the local machine are only available to the current active console. This is handled by restricting access to the smart card resource manager and is enforced by the winscard layer. Consider the following example:
1. User A logs in and is assigned a session of 1.
2. User A launches Application XYZ which monitors for smart card removal.
3. User A then locks the computer and presses the FUS button so others can use the computer.
4. A new session (2) is created which launches logonUI.exe.
5. At this point all smart card contexts acquire in session 1 are invalid due to the session change. Any use of the contexts will result in an error. These contexts should be closed.
6. Application XYZ receives the error SCARD_E_SYSTEM_CANCELLED from their SCardGetStatusChange call. Performs any actions based on this return.
7. Application XYZ then calls SCardAccessStartedEvent () and waits for the smart card resource manager to “start up” again.
8. User A returns to the computer and logs on and is reconnected to session 1.
9. The next two operations occur at the same time
a. All contexts associated with session 2 are invalidated in the same way as those contexts for session 1 where in Number 5.
b. The event from 7 is signaled and Application XYZ can call SCardEstablishContext to communicate with the smart card.
10. User A calls "run as /smartcard" when he is returned to the desktop
Smart card logon in the LSA using Kerberos
The operations performed in smart card logon are very similar to the ones performed in previous versions of Windows. The primary exception is that previously the smart card operations were done via a call back into winlogon. Now with the improved session handling in the Smart Card Resource Manager, CSP contexts are used directly in the LSA.
All CSP calls are made impersonating the caller. This means initial logon will under the system context but operations such as runas /smartcard will be performed under the context of the current user.
The majority of trouble in getting authentications will occur due to the session behavior. Also, the LSA does not reacquire the Context instead relying on the CSP to handle the session change. In the above example, step 8 would have caused a context to be acquired by Kerberos under a session 2 impersonation token (under system context). In Step 10, that same context would be reused but under a different impersonation token (the user token). This could cause trouble with some CSP implementations.
(thanks to Dan Sledz for information)