Because of the AMA and Security Subsystem design that's described in the "Symptoms" section, users experience the following scenarios in which AMA can't reliably identify the type of interactive logon.
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:
Note 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.