Refresh Active Directory group membership

With more and more people working from outside the office and the growth of online tooling like Office 365 and others, your windows endpoints may be spending long periods away and not connected to the corporate LAN. When a VPN is not required, employees will likely only set up a VPN when they need to access resources not exposed via the internet. This makes Active Directory group changes or GPO filters propagate extremely slow because these group memberships are updated when a Kerberos ticket is created. This occurs on system startup or when a user authenticates during login.

That does not work when the VPN is not running during a login outside the office. Even on a connected laptop in the office, the computer reboot can sometimes not be performed on a critical running system.

User and computer group memberships

The following command will show you which groups you, as a user, are a member of.

whoami /groups

This list is only refreshed when your Kerberos ticket expires, AND you make a new successful authentication request. An example of how to do the latter is by accessing a file share on the network, so a new security token is issued.

Computer membership can be shown using the following command.

gpresult /scope computer /r

Purging Kerberos tickets

By giving a purge command, the Kerberos tickets will expire and group memberships will be loaded from the domain. This, of course, requires a connection to a domain controller.

Purging computer tickets, to refresh the computer AD group membership:

klist -li 0x3e7 purge

Purging current user tickets, to refresh the user AD group membership:

klist purge

Purging all user tickets of users on the local system, to refresh the user AD group membership, requires powershell:

Get-WmiObject -ClassName Win32_LogonSession -Filter "AuthenticationPackage != 'NTLM'" | 
ForEach-Object {[Convert]::ToString($_.LogonId, 16)} |
ForEach-Object { klist.exe purge -li $_ }

Note that 0x3e7 is a special identifier that points to a session of the local computer (Local System). Without providing this option, the purge command defaults to the LUID of the user who is currently signed in.

Re-evaluating GPO security filters and WMI filtering

If the reason you are doing this is related to Group Policies, you need to refresh the GPOs and re-evaluate the filters on those GPOs. You can do this with the below command.

gpupdate /force

Group membership limitations for local access

The local security subsystem (LSASS) that is already running will not refresh the working copy of the group membership dynamically as long as the user is logged on. This is because the local session is using NTLM, and NTLM persists until logoff. Even locking and then unlocking the client does not end the existing sessions. A refresh requires a full user logoff/logon (or a system reboot).
In order words, if what you are doing is based on AD group memberships … after the refresh of everything, a new login is required to actually enable the new or changed settings.
This can be a security risk if you use group members to assign administrative privileges to a user. The user can still use these privileges long after removing the user from that respective AD group.

Other use cases for klist.exe

This klist command has more purposes. You can read all about it on the documentation page at Microsoft.