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
WSAdminGroup1
with member
admin1
- Workstation
ws1
:
WSAdminGroup1
is a member ofBUILTIN\Administrators
user1
is a member ofBUILTIN\Users
- when
user1
encounters a UAC prompt,admin1
can authorize the elevationChanges:
- Add domain group
WSAdminGroup2
with member
admin2
- Add
WSAdminGroup2
toBUILTIN\Administrators
Result:
- when
user1
encounters a UAC prompt,admin2
cannot 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?