All Windows admins know that after a computer or a user is added to an Active Directory security group, new permissions to access domain resources or new GPOs are not immediately applied. To update group membership and apply the assigned permissions or Group Policies, you need to restart the computer (if a computer account was added to the domain group) or perform a logoff and logon (for the user). This is because AD group memberships are updated when a Kerberos ticket is created, which occurs on system startup or when a user authenticates during login.
In come cases, the computer reboot or user logoff cannot be performed immediately for production reasons. At the same time you need to use the permissions, access or apply new Group Policies right now. In such cases, you can update the account membership in Active Directory groups without computer reboot or user re-login using the klist.exe tool.
You can get the list of groups the current user is a member of in the command prompt using the following commands:
whoami /groups
or GPResult
gpresult /r
The list of groups a user is a member of is displayed in the section The user is a part of the following security groups.
You can reset current Kerberos tickets without reboot using the klist.exe tool. Klist is a built-in system tool starting from Windows 7. For Windows XP/Windows Server 2003 klist is installed as a part of Windows Server 2003 Resource Kit Tools.
How to Refresh Kerberos Ticket and Update Computer Group Membership without Reboot?
To reset the entire cache of Kerberos tickets of a computer (local system) and update the computer’s membership in AD groups, you need to run the following command in the elevated command prompt:
klist -li 0:0x3e7 purge
After running the command and updating the policies (you can update the policies with the gpupdate /force command), all Group Policies assigned to the AD group through Security Filtering will be applied to the computer.
klist -li 0: 0x3e7 purge command, you get an error like: “Error calling API LsaCallAuthenticationPackage”:
Current LogonId is 0:0x3d2de2
Targeted LogonId is 0:0x3e7
*** You must run this tool while being elevated, and you must have TCB or be a local admin.***
klist failed with 0xc0000001/-1073741823: {Operation Failed}
The requested operation was unsuccessful.
In this case you can purge your computer Kerberos ticket on behalf of NT AUTHORITY\SYSTEM. The easiest way to do this is with the psexec tool:
psexec -s -i -d cmd.exe – run cmd on behalf of Local System
klist purge – computer ticket reset
gpupdate /force – update GPO
Klist: Purge User Kerberos Ticket without Logoff
Another command is used to update the assigned Active Directory security groups in user session. For example, a domain user account has been added to an Active Directory group to access a shared network folder. The user won’t be able to access this shared folder without logoff.
In order to refresh Kerberos tickets of the user use this command:
klist purge
Current LogonId is 0:0x5e3d69 Deleting all tickets: Ticket(s) purged!
To see the updated list of groups, you need to run a new command prompt using runas (so that a new process is created with a new security token).
Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
Suppose the AD group has been assigned to a user to access a shared folder. Try to access it using its FQDN name (!!! this is important, for example, \\lon-fs1.woshub.loc\Install). At this point, a new Kerberos ticket is issued to the user. You can check that the TGT ticket has been updated:
klist tgt
(see Cached TGT Start Time value)
The shared folder to which access was granted through the AD group should open without user logoff.
You can check that the user received a new TGT with updated security groups (without logging off) with the whoami /all command.
We remind you that this way of updating security group membership will work only for services that support Kerberos. For services with NTLM authentication, a computer reboot or user logoff is required to update the token.
9 comments
Nice Post…Interestingly enough you can also kill the explorer process….then create a new task with “runas /user:username@domain explorer”. Then you can use all your mappings as per usual.
On my domain only works this for a network drive:
@echo off
net use M: /d /y
gpupdate /force
net use M: \\10.11.12.233\Archivos /persistent:Yes
explorer.exe M:
The reason this works is because your connection of the mapped drive effectively creates a logon session on the remote fileserver. Then the memberships are re-evaluated by -that- server and it allows the connection, even if your local system hasn’t yet recognised the new membership.
Sure. Anyways not always works without reboot the computer. Sometimes (and I do not know why) it is necesary reboot the client computer for update the internal permissions on NAS folders.
For a service ID (instead of a user ID), does “klist purge” work refresh the AD group membership ? A service ID is used for running a Windows service and no logon/logoff is allowed.
Hello,
On a Windows Server 2016 in a Windows Server 2012 R2 Active Directory. Each command is use in an administrative shell
– The server is in the group “test computer group”
– gpresult /r –> Server is confirmed in the group
– In active directory, removes the server of the group
– Force AD resync and wait 5 min (to be sure resync is ok)
– gpresult /r –> Server is still in the group (normal)
– klist -li 0:0x3e7 purge –>
LogonId est 0:0x3bbed
Suppression de tous les tickets :
ticket(s) supprimé(s) !
– gpupdate /force –> Update without error
– gpresult /r –> Server is still in the group (huh ?)
– Reboot of the server
– gpresult /r –> Server is confirmed not in the group (Normal)
So, are there some configuration items to point why this procedure doesn’t work on my servers ?
This stopped working for me as well. I’m confident it was working a few months ago in a different AD environment. Strange.
This does not work for me. I can see the new group memberships via a new cmd prompt using runas and with whoami /groups, however until Explorer is restarted and using runas to start a new explorer process, the user is never seen to be a member of the new groups.
I’ve always known this to be expected behavior, users on VPN simply have no way to get an updated kerberos token pulling their new group memberships without the suggestions above. However I have just experienced something I cannot understand. I am finding that in my environment, if I add a user to a new AD group that binds permissions to a file share, the user is able to log off and back on, reconnect the VPN, and somehow it’s magically working without performing any of the steps above. Further when inspecting “whoami /groups”, the token for the new group IS NOT THERE! How on earth is this working this way? This conflicts with everything I know.