Refresh membership in AD security groups without reboot or logoff

If you are adding a computer(s) or user(s) to a security group in Active Directory (AD), there will be no immediate effect, the permissions only take effect after a user has logged on again or the computer has been rebooted.

To avoid this you can renew the Kerberos tickets for the device

Purging Kerberos tickets

You can bypass the reboot by renewing the Kerberos ticket for the computer with klist.exe. If you run the following:

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

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

Subsequently, by executing

gpupdate /force

you will get new tickets if you run the following command:

klist.exe -li 0x3e7

Comparing the output with the earlier use of this command, you will see that the timestamps of the Kerberos tickets have changed.

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.

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.exe 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.

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.