- Install Windows Terminal without the Store (on Windows Server) - Thu, Jul 7 2022
- LAPS in Windows 11: Password encryption and DSRM account management - Wed, Jun 29 2022
- Install subsystem for Linux 2 (WSL2) on Windows Server - Wed, Jun 22 2022
If you make a server a member of an AD group, for example, to include it in the security filtering of a GPO or to grant it permissions to request a certificate, it simply may not be possible to restart it immediately afterwards. However, a reboot is usually necessary to update computer membership in AD groups.
Purging Kerberos tickets ^
You can bypass the reboot by renewing the Kerberos ticket for the computer with klist.exe. If you run
klist.exe sessions | findstr /i %COMPUTERNAME%
on a command prompt, you will see that the so-called low part of the local computer's LogonID always has the value 0x3e7, while 0x3e4 belongs to the network service. The corresponding cached Kerberos tickets can be displayed with
klist.exe -li 0x3e7
The low part of the local computers LogonID always has the value 0x3e7
After adding the computer account to a new security group in AD, you can remove them using the purge parameter:
klist.exe -li 0x3e7 purge
Invoking klist.exe li 0x3e7 purge deletes the tickets for the computer account
Subsequently, by executing
gpupdate /force
you will get new tickets. If you run
klist.exe -li 0x3e7
again and compare the output with the earlier use of this command, you will see that the timestamps of the Kerberos tickets have changed.
Using
gpresult /r /scope computer
you can display the groups in which the local computer is a member. However, this command usually does not reflect changes after the ticket was renewed, regardless of whether the account was added to or removed from a group.
However, if you use an AD group for GPO security filtering, then the change has an immediate effect here and is also visible in the output of gpresult. The same applies to the permissions on other resources.
Server2022Preview has been added to the HR group which is not eligible for the WinRM GPO. gpresult does not show the HR group but the effect on filtering.
Updating memberships for users ^
While servers often cannot be restarted just to update membership in AD groups, it is usually not a major problem for users to log off and on again to gain access to certain resources by changing group memberships.
However, if you want to avoid a logoff, klist.exe can help here as well. In this case, after the user account has been added to a new group, execute
klist purge
on a command line without elevated privileges. The program prints the LogonID of the current user and confirms that the Kerberos tickets for this user have been deleted. To get new ones, you can start another instance of cmd.exe using runas.
After the klist purge a new instance of cmd.exe shows the membership of the user in the group HR
If you run
whoami /groups
there, then the change in the group memberships should already be noticeable. Accordingly, the user should also be able to access a network share, for example via the FQDN of the server, which he was denied before he was added to the new AD group.
Subscribe to 4sysops newsletter!
It is obvious that the described solution works only for services that support Kerberos. With NTLM authentication, there is no way around rebooting or logging out.
In your screenshot it shows the gpo being denied for the computer object, not a group. Therefore a simple gpupdate would pick up that change anyway.
Well, I just came across a case where doing the klist purge doesn’t seem to update the groups, when displaying the groups with whoami /groups.
I also tried doing a gpupdate, and that didn’t update the groups. That was when I was trying to add a group to a user to give it access. But now, when I remove it, the access is denied immediately, but the groups listing still lists the groups, even after the klist purge.
Worked perfectly. Thanks for the posting. Always hated having to reboot when adding a computer to a Security group. Many times, you simply cannot restart a server to pick it up.