Description of AMA usage in interactive logon scenarios in Windows

Summary
This article discusses how to use Authentication Mechanism Assurance (AMA) in interactive logon scenarios.
Introduction
AMA adds an administrator-designated, universal group membership to a user's access token when the user's credentials are authenticated during logon by using a certificate-based logon method. This makes it possible for network resource administrators to control the access to resources, such as files, folders, and printers. This access is based on whether the user logs on by using a certificate-based logon method and the type of certificate that's used to log on.
In this article
This article focuses on two problem scenarios: logon/logoff and lock/unlock. The behavior of AMA in these scenarios is "by design" and can be summarized as follows:

  • AMA is intended to protect network resources.
  • AMA can neither identify nor enforce the interactive logon type (smart card or user name/password) for the user's local computer. This is because resources that are accessed after an interactive user logon can’t be reliably protected by using AMA.
Symptoms

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.

Scenario examples

Note In this article, group membership is retrieved for interactive logon sessions by using “whoami/groups.” This command retrieves the groups and claims from the desktop’s access token.

  • Example 1

    If the previous logon was performed by using a smart card, the access token for the desktop has the smart card universal security group that's provided by AMA. One of the following outcomes occurs:

    • The user logs on by using the smart card: The user can still access local security sensitive resources. The user tries to access network resources that require the smart card universal security group. These attempts succeed.
    • The user logs on by using user name and password: The user can still access local security sensitive resources. This outcome isn't expected. The user tries to access network resources that require the smart card universal security group. These attempts fail as expected.
  • Example 2

    If the previous logon was performed by using a password, the access token for the desktop does not have the smart card universal security group that's provided by AMA. One of the following outcomes occurs:

    • The user logs on by using a user name and password: The user can't access local security sensitive resources. The user tries to access network resources that require the smart card universal security group. These attempts fail.
    • The user logs on by using the smart card: The user can't access local security sensitive resources. The user tries to access network resources. These attempts succeed. This outcome isn't expected by customers. Therefore, it causes access control problems.

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.

Scenario examples

  • Example 1

    If the access token for the desktop has the smart card universal security group provided by AMA, one of the following outcomes occurs:

    • The user unlocks by using the smart card: The user can still access local security sensitive resources. The user tries to access network resources that require the smart card universal security group. These attempts succeed.
    • The user unlocks by using the user name and password: The user can still access local security sensitive resources. This outcome isn't expected. The user tries to access network resources that require the smart card universal security group. These attempts fail.
  • Example 2

    If the access token for the desktop does not have the smart card universal security group provided by AMA, one of the following outcomes occurs:

    • The user unlocks by using user name and password: The user can't access local security sensitive resources. The user tries to access network resources requiring the smart card universal security group. These attempts fail.
    • The user unlocks by using the smart card: The user can't access local security sensitive resources. This outcome isn't expected. The user tries to access network resources. These attempts succeed as expected.
More information
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.
Authentication Mechanism Assurance AMA Interactive Logon
Vlastnosti

ID článku: 3101129 - Poslední kontrola: 11/21/2015 02:06:00 - Revize: 1.0

Windows Server 2012 R2 Standard, Windows Server 2012 R2 Datacenter, Windows 8.1 Pro, Windows 8.1 Enterprise, Windows Server 2012 Standard, Windows Server 2012 Datacenter, Windows 8 Pro, Windows 8 Enterprise, Windows Server 2008 R2 Standard, Windows Server 2008 R2 Enterprise, Windows 7 Enterprise, Windows 7 Professional

  • kbinfo kbexpertiseadvanced kbsurveynew KB3101129
Váš názor