In what ways can access token update be triggered for administrator accounts on workstations?

Posted on

In what ways can access token update be triggered for administrator accounts on workstations? – Managing your servers can streamline the performance of your team by allowing them to complete complex tasks faster. Plus, it can enable them to detect problems early on before they get out of hand and compromise your business. As a result, the risk of experiencing operational setbacks is drastically lower.

But the only way to make the most of your server management is to perform it correctly. And to help you do so, this article will share nine tips on improving your server management and fix some problem about windows, active-directory, access-control-list, groups, uac.

This scenario emerged when changing the domain group membership that bestows membership in BUILTINAdministrators. In particular, the group membership for the administrator did not update on the workstation until the administrator signed in to the desktop as a normal user would. This is the scenario that raised this question:

Starting setup:

  • Domain group WSAdminGroup1 with member
    • admin1
  • Workstation ws1:
    • WSAdminGroup1 is a member of BUILTINAdministrators
    • user1 is a member of BUILTINUsers
  • when user1 encounters a UAC prompt, admin1 can authorize the elevation

Changes:

  • Add domain group WSAdminGroup2 with member
    • admin2
  • Add WSAdminGroup2 to BUILTINAdministrators

Result:

  • when user1 encounters a UAC prompt, admin2 cannot authorize the elevation

So we have an administrator admin2 who should have membership in BUILTINAdministrators on workstation ws1 by way of their domain group membership in WSAdminGroup2 but is unable to authorize UAC elevations prompts on ws1.

No amount of waiting, rebooting, or signing out by user1 caused admin2 to gain administrator access on the workstation. It turned out that signing in to the workstation desktop as admin2 finally caused admin2 to gain administrator access.

This suggests that administrator admin2‘s access token was not updated on workstation ws1 until admin2 logged in to the desktop. But I haven’t yet found documentation that agrees with that conclusion.

In any case I’d like to get to the bottom of the following questions:

  1. What really happened to administrator admin2‘s access tokens as this scenario played out?
  2. For identities (like administrators) who do not regularly sign in to a workstation’s desktop, is there any other way to trigger issuance of a new access token that would reflect more up-to-date group membership?
  3. Do any of the ways of authorizing that don’t involve signing in to the desktop (like PowerShell remoting, or invoking “Run as administrator”) cause the issuance of a new access token to occur?

You could consider using the Protected Users capability of Windows (as discussed in this answer) to prevent caching of admin credentials at all. This helps mitigate lateral movement risks, too.

Leave a Reply

Your email address will not be published. Required fields are marked *