This scenario emerged when changing the domain group membership that bestows membership in BUILTIN\Administrators. 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
WSAdminGroup1with member
admin1- Workstation
ws1:
WSAdminGroup1is a member ofBUILTIN\Administratorsuser1is a member ofBUILTIN\Users- when
user1encounters a UAC prompt,admin1can authorize the elevationChanges:
- Add domain group
WSAdminGroup2with member
admin2- Add
WSAdminGroup2toBUILTIN\AdministratorsResult:
- when
user1encounters a UAC prompt,admin2cannot authorize the elevation
So we have an administrator admin2 who should have membership in BUILTIN\Administrators 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:
- What really happened to administrator
admin2's access tokens as this scenario played out? - 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?
- 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?