Cover Photo by Benjamin Sharpe on Unsplash
Introduction
In this post, I’m going to talk about a problem you may have come across before and been frustrated by many times, and how to overcome it.
Something that’s very powerful with Group Policy Objects (GPO) is the ability to use Security Filtering/Delegations to selectively apply (or indeed not apply) a GPO to a computer if the computer account is a member of an AD Security Group.
This can allow you to selectively apply an exception to security standards that are enforced via GPO to computers where you need a particular setting not to apply.
Another use case is where you are rolling out new security settings in a new GPO and you need the ability to selectively exclude computers from the settings in that policy if a problem is encountered that was caused by that GPO.
Ok so what’s the problem here?
If you make a computer a member of an AD group and then either wait for group policy to refresh (usually every 90-120 minutes) or by forcing a group policy update via the gpupdate /force command from an administrative shell, it will often not apply the GPO until the server is rebooted.
This is because the computer knows which groups it is a member of by way of its Kerberos ticket that it gets from AD Domain Controllers at logon and periodically when the ticket expires and is renewed.
Remember that the computer account that you add to the AD group is still just an AD user, just with different attributes than a normal user account. So when the computer is started up it will login to the domain it is joined to just as you do when you login to your domain joined desktop or laptop.
A reboot would renew the ticket from the domain controller and would included an updated group membership list and so that’s usually the approach people take.
However, for critical production servers this means downtime for the reboot and therefore an interruption to services.
This may either not be possible until a quiet period or may require change control first, which may delay the application of the GPO (or exclusion, depending upon how you have setup the security filtering for the group in the GPO).
So how can we get around this and get the server to recognise that its group membership has now changed, without having to reboot the server or do anything disruptive?
So how do I work around the reboot?
You can avoid the need to reboot by renewing the Kerberos ticket for the computer with the klist utility.
If you were to run klist sessions | findstr /i %COMPUTERNAME% at an administrative cmd prompt or klist sessions | Select-String $env:COMPUTERNAME from an administrative powershell session, you would see that there are two sessions returned for the computer account.
0x3e7 is the logon session.
0x3e4 is for the network service.
These are always the same on every Windows computer or server.
So, after you add the computer account to the group that is referenced in the GPO, enter the following from an administrative shell (Powershell, cmd prompt, Windows Terminal):
klist.exe -li 0x3e7 purge
This will return a response like below:
Current LogonId is 0:0xe43f6
Targeted LogonId is 0:0x3e7
Deleting all tickets:
Ticket(s) purged!
Now, if you run gpupdate /force from an administrative shell, it will recognise the computer group membership change and apply the GPOs you were expecting.
Example PowerShell session (truncated) below shows this being done on a server and the resultant output of both gpupdate and also gpresult which lists the Resultant Set of Policy (RSoP) on the machine:
After adding server to group CONTOSO\GPO_Exception_UserAccountControl and running gpupdate /force
gpresult /z
Microsoft (R) Windows (R) Operating System Group Policy Result tool v2.0
© 2016 Microsoft Corporation. All rights reserved.
Created on 1/18/2023 at 2:34:23 PM
RSOP data for CONTOSO\GAIA on TERRA : Logging Mode
-----------------------------------------------------------------------------------------------------
OS Configuration: Member Server
OS Version: 10.0.14393
Site Name: HQ
Roaming Profile: N/A
Local Profile: C:\Users\GAIA
Connected over a slow link?: No
COMPUTER SETTINGS
------------------------------------
CN=TERRA,OU=Servers,OU=Machines,DC=CONTOSO,DC=COM
Last time Group Policy was applied: 1/18/2023 at 2:33:56 PM
Group Policy was applied from: DC01.CONTOSO.COM
Group Policy slow link threshold: 500 kbps
Domain Name: CONTOSO
Domain Type: Windows 2008 or later
Applied Group Policy Objects
----------------------------------------------------------
POL_SRV_BASE
Default Domain Policy
Purge Kerberos ticket for computer account
klist.exe -li 0x3e7 purge
Current LogonId is 0:0xe43f6
Targeted LogonId is 0:0x3e7
Deleting all tickets:
Ticket(s) purged!
Run gpupdate /force again
gpupdate /force
Updating policy...
Computer Policy update has completed successfully.
User Policy update has completed successfully.
Check RSoP again
gpresult /z
Microsoft (R) Windows (R) Operating System Group Policy Result tool v2.0
© 2016 Microsoft Corporation. All rights reserved.
Created on 1/18/2023 at 2:34:23 PM
RSOP data for CONTOSO\GAIA on TERRA : Logging Mode
------------------------------------------------------------------------------------------------------
OS Configuration: Member Server
OS Version: 10.0.14393
Site Name: HQ
Roaming Profile: N/A
Local Profile: C:\Users\GAIA
Connected over a slow link?: No
COMPUTER SETTINGS
------------------------------------
CN=TERRA,OU=Servers,OU=Machines,DC=CONTOSO,DC=COM
Last time Group Policy was applied: 1/18/2023 at 2:33:56 PM
Group Policy was applied from: DCO1.CONTOSO.COM
Group Policy slow link threshold: 500 kbps
Domain Name: CONTOSO
Domain Type: Windows 2008 or later
Applied Group Policy Objects
----------------------------------------------------------
POL_Exception_UserAccountControl
POL_SRV_BASE
Default Domain Policy
And there you have it - we added a computer to a security group that applies a GPO, and didn’t have to reboot the computer to make it take effect.
Summary
In summary, if you have a GPO that is tied to an AD security group and you need it to be applied but don’t want to (or perhaps can’t) reboot the computer at that time, you can achieve this by purging the Kerberos ticket for the computer account without any downtime or disruption.
As ever, thanks for reading and feel free to leave comments down below!
If you like what I do and appreciate the time and effort and expense that goes into my content you can always 