Description of AMA usage in interactive logon scenarios in Windows

Problem Scenario 1 (logon/logoff)

Consider the following scenario:

• An administrator wants to enforce Smart Card (SC) Logon authentication when users access certain security-sensitive resources. To do this, the administrator deploys AMA according to the Authentication Mechanism Assurance for AD DS in Windows Server 2008 R2 Step-by-Step Guide for the issuance policy object identifier that's used in all the smart card certificates.
  
  Note In this article, we refer to this new mapped group as “the smart card universal security group."
  

• The "Interactive logon: Require smart card" policy isn't enabled on workstations. Therefore, users can log on by using other credentials, such as user name and password.

• Local and network resource access requires the smart card universal security group.

In this scenario, you expect that only user who signs on by using smart cards can access local and network resources. However, because the workstation allows optimized/cached logon, the cached verifier is used during logon to create the NT access token for the user’s desktop. Therefore, the security groups and claims from the previous logon are used instead of the current one.

Problem Scenario 2 (lock/unlock)

Consider the following scenario:

• An administrator wants to enforce Smart Card (SC) Logon authentication when users access certain security-sensitive resources. To do this, the administrator deploys AMA according to Authentication Mechanism Assurance for AD DS in Windows Server 2008 R2 Step-by-Step Guide for the issuance policy object identifier that's used in all the smart card certificates.

• The "Interactive logon: Require smart card" policy isn't enabled on workstations. Therefore, users can log on by using other credentials, such as user name and password.

• Local and network resource access requires the smart card universal security group.

In this scenario, you expect that only a user who signs on by using smart cards can access local and network resources. However, because the access token for the user’s desktop is created during the logon, it's not changed.

Logon/logoff

If Fast Logon optimization is active, the Local Security Subsystem (lsass) uses local cache to generate group membership in the logon token. By doing this, the communication with the domain controller (DC) isn't required. Therefore, logon time is reduced. This is highly desirable feature.

However, this situation causes the following problem: After SC Logon and SC Logoff, the locally cached AMA group is, incorrectly, still present in the user token after the user name/password interactive logon.

Notes

• This situation applies only to interactive logons.

• An AMA group is cached in the same manner and by using the same logic as other groups.

In this situation, if the user then tries to access network resources, cached group membership on the resource side isn't used, and the user’s logon session on the resource side won't contain an AMA group.

This problem can fixed by turning off Fast Logon Optimization (“Computer Configuration > Administrative Templates > System > Logon > Always wait for the network at computer startup and logon”).

Important This behavior is relevant only in the interactive logon scenario. Access to network resources will work as expected because there's no need for logon optimization. Therefore, cached group membership isn't used. The DC is contacted to create the new ticket by using the freshest AMA group membership information.

Lock/unlock

Consider the following scenario:

• A user logs on interactively by using the smart card and then opens AMA-protected network resources.
  
  Note AMA protected network resources can be accessed only users who have an AMA group in their access token.
  

• The user locks the computer without first closing the previously opened AMA-protected network resource.

• The user unlocks the computer by using the user name and password of the same user who previously logged on by using a smart card).
  

In this scenario, the user can still access the AMA-protected resources after the computer is unlocked. This behavior is by design. When the computer is unlocked, Windows does not re-create all the open sessions that had network resources. Windows also does not recheck group membership. This is because these actions would cause unacceptable performance penalties.

There's no out-of-box solution for this scenario. One solution would be to create a Credential Provider filter that filters out the user name/password provider after the SC logon and lock steps occur. To learn more about Credential Provider, see the following resources:

ICredentialProviderFilter interface

Windows Vista Credential Provider SamplesNote We can't confirm whether this approach has ever been successfully implemented.

More information about AMA

AMA can neither identify nor enforce the interactive logon type (smart card or user name/password). This behavior is by design.

AMA is intended for scenarios in which network resources demand a smart card. It's not intended to be used for local access.

Any attempt to fix this issue by introducing new features, such as the ability to use dynamic group membership or to handle AMA groups as a dynamic group, could cause significant problems. This is why NT tokens don’t support dynamic group memberships. If the system allowed groups to be trimmed in real, users might be prevented from interacting with their own desktop and applications. Therefore, group memberships are locked at the time that the session is created and are maintained throughout the session.

Cached logons are also problematic. If optimized logon is enabled, lsass first tries a local cache before it invokes a network round trip. If the user name and password are identical to what lsass saw for the previous logon (this is true for most logons), lsass creates a token that has the same group memberships that the user had previously. 

If optimized logon is turned off, a network roundtrip would be required. This would make sure that the group memberships work at logon as expected.

In a cached logon, lsass keeps one entry per user. This entry includes the user's previous group membership. This is protected by both the last password or smart card credential that lsass saw. Both unwrap the same token and credential key. If users were to try to log on by using a stale credential key, they would lose DPAPI data, EFS-protected content, and so on. Therefore, cached logons always produce the most recent local group memberships, regardless of the mechanism that's used to log on.