How to Refresh AD Groups Membership without Reboot/Logoff?

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.

Note. The method described in this article will work only for network services that support Kerberos authentication. The services working only with NTLM authentication still require logoff + logon of a user or Windows restart.

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

Note. 0x3e7 is a special identifier that points to a session of the local computer (Local System).

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.

If the LSA access restriction policies is configured in your domain (for example, the Debug Program policy restricting the use of SeDebugPrivilege), or other security policies, in some cases when you run the 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).

On the RDS server you can reset Kerberos tickets for all user remote sessions at once using the following PowerShell one-liner:

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.