I've completed some testing to help identify methods of updating the group membership for a computer account without having to restart the computer. The results show that while it is possible to update the token used to authenticate external resource access, a group policy refresh does not use the updated group membership for policy processing.
Testing was completed with:
- Windows XP SP2 workstation joined to a Windows 2000 domain, using Kerberos authentication.
- A share on the DC, with access granted to Group1, but denied to Group2, making it very easy to determine whether group membership is being considered for Group2
Test steps:
- Add the computer account to the Group1, allowing access to the test share
- Start a command prompt as system (with psexec /s /i /d cmd.exe)
- Verify access to the test share on the DC from the computer context
- Add the computer account to Group2, denying access to the data in the share mount point
- Verify access to the test share on the DC from the computer context still works as the computer has not received an updated token
- Use 'klist purge' to purge all tickets
- Run 'nltest /dclist:%domain%' (causing a request for a Kerberos TGT)
- Run 'klist tgt' to verify that a new TGT has been received
- Verify access to the test share on the DC from the computer context is now denied.
This demonstrates that it is possible to force an update to the Kerberos tickets containing the Privilege Attribute Certificate details of computer domain account group membership, and subsequently access file based resources with the updated token. The following information is related:
- Using the steps above updates Kerberos tickets and ensures that remote resource access is performed with a refreshed token, however, this does not help when processing Group Policy (as can be seen by 'gpresult /z /scope computer'). Running gpresult, which lists the accounts a computer is a member of, does not include the groups added to the domain computer account (this appears to be due to cached information stored during the initial computer startup sequence). Destroying 'NT Authority\System' and 'NT Authority\Network Service' tokens associated with all processes (with 'Process Explorer'), combined with restarting the WMI service causes the wmiprvse binary to reload (required for gpresult), but the re-created tokens do not contain the updated domain SIDs
- The security principal representing the LocalSystem context (S-1-5-18) is a local identity only. The concept of using computer accounts as members of domain security groups makes use of the domain computer account (similar to drawing a parallel between same-named local user accounts and domain user accounts).
- When examining local tokens, a computer is a member of only three groups - a hidden member of administrators, and a member of two well-known groups (Everyone and 'Authenticated Users'). When accessing remote resources with the system account, the access token passed to the remote machine contains the SIDs of groups the computer's domain account is a member of
- The user context when clearing the Kerberos cache is important; For example, if the 'klist purge' command is executed under the interactive context instead of the system context, the TGT for the computer account (ComputerName$) is not renewed.
References:
Wayne's World of IT (WWoIT), Copyright 2008 Wayne Martin.
4 comments:
You said: "Using the steps above updates Kerberos tickets and ensures that remote resource access is performed with a refreshed token, however, this does not help when processing Group Policy"
I presume by that you mean neither GPRESULT nor GPUPDATE benefit from the updated ticket, without a restart. But is the updated ticket cached, so that the computer will benefit from it, on the next restart?
I ask this because we have VPN clients that need to get computer GPO changes driven by group membership, but they cannot get these because the VPN connection isn't established until after user logon. These computers never start connected to AD, so they never get updated group membership information.
I'm trying to figure out a way to update the computer group membership after logon, while connected to AD via VPN. If I can do that, I can tell the users to restart after the manual update.
Any suggestions? Thanks in advance for your time and help.
Hi Olphar,
I'm not sure that I can offer much, but I would go through the scenario you are talking about and run the following commands at the various stages to list the groups the computer account is a member of:
- psexec /s tokensz /dump_groups
- gpresult /z
The first will run the tokensz command in the context of the localsystem account on the local computer. The second will allow you to see the computer group membership from a group policy perspective - not necessarily the same thing as what's in the token.
The results might help identify if you can force an update, and will prove whether the domain computer account group information is cached across reboots.
There may well be a solution for this sort of VPN connectivity for computer-based GPOs (I haven't had the need to investigate).
Good luck,
Wayne.
Tokensz is a Microsoft utility, available from:
http://www.microsoft.com/downloads/details.aspx?familyid=4A303FA5-CF20-43FB-9483-0F0B0DAE265C&displaylang=en
In my scenario, I wanted to enable a policy for a few test servers, so they would join te appropriate WSUS group (client site targeting). I made these servers member of te security group that has the read/apply permission for that policy, but the policy was disabled until I performed the steps described in your article here. I did a gpupdate /force on the test servers and, voila! they neatly joined the WSUS group.
Sometime few educational blogs become very helpful while getting relevant and new information related to your targeted area. As I found this blog and appreciate the information delivered to my database. Office professional 2019 product key
Post a Comment