After you add a computer or a user account to an Active Directory security group, the new access permissions or the new GPOs are not applied immediately. To update the group membership and apply the assigned permissions or Group Policies, you need to restart the computer or perform a logoff and logon (for the user). This is because AD group memberships are only updated when the Kerberos ticket is issued, which happens when the system boots or when a user is authenticated at logon.
If you cannot immediately restart the computer or log off the user, you can update the account’s AD group membership by using the klist.exe tool. This utility allows you to reset and renew a computer’s or user’s Kerberos tickets.
You can list the domain security groups that the current user is a member of with the command:
whoami /groups
or GPResult:
gpresult /r /scope user
The list of groups the user is a member of is displayed in the “The user is a part of the following security groups” section.
Update Computer Group Membership and Kerberos Ticket Without Reboot
You can list the security groups that this computer is a member of with the command
gpresult /r /scope computer
The computer is a part of the following security groups
You can list cached Kerberos tickets received by the computer, as well as the date they were received and the time of the next renewal.
klist.exe -li 0x3e7
Now add the computer to the AD security group (using the ADUC snap-in or with PowerShell: Add-AdGroupMember -Identity grAVExclusionPC -Members wks-mns21$ )
To clear the computer’s Kerberos ticket cache and update the computer’s AD group membership, run the command (for Windows 7 and Windows Server 2008R2)
klist -lh 0 -li 0x3e7 purge
Or for Windows 11/10/8 and Windows Server 2022/2019/2016:
klist –li 0x3e7 purge
Deleting all tickets: Ticket(s) purged!
Update the Group Policy settings using the gpupdate /force command. All Group Policies assigned to the AD group through Security Filtering will then be applied to the computer without a reboot.
You can use the command to check when a computer has received new Kerberos tickets:
klist -li 0x3e7 tgt
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 can get an error: “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 will need to run the command line on behalf of NT AUTHORITY\SYSTEM and purge your computer Kerberos ticket cache in that console:
psexec -s -i -d cmd.exe –run cmd on behalf of Local System using the psexec.exe tool
klist purge – reset computer ticket
gpupdate /force – update GPO
This method of updating computer group membership is the only working option for updating GPO settings on clients connecting to your network via VPN, where the user logs in using cached domain credentials.
Reload User Groups Membership without Logging Off
Another command is used to update the assigned Active Directory security groups in the user session. For example, you have added a user to a security group that grants access to a shared folder. The user won’t be able to access this network folder without logging off and on again.
You must reset a user’s Kerberos ticket cache if you want to update the list of assigned security groups for that user. Open an unprivileged command prompt in a user session (do not run cmd in administrator mode). Run the command:
klist purge
Current LogonId is 0:0x5e3d69 Deleting all tickets: Ticket(s) purged!
In order to see the updated list of groups, you will need to open a new command prompt using runas (so that the new process will be created with the new security token).
List the user’s groups:
whoami /groups
Get-WmiObject Win32_LogonSession | Where-Object {$_.AuthenticationPackage -ne 'NTLM'} | ForEach-Object {klist.exe purge -li ([Convert]::ToString($_.LogonId, 16))}
For the user to be able to connect to the shared network folder, you must restart the File Explorer shell with a new token. (with a new security group)
- Open the command prompt;
- End the current user’s File Explorer process:
taskkill /f /im explorer.exe - Start a new Explorer process using your account credentials. You can use the
%USERDOMAIN%\%USERNAME%environment variables or specify the domain and user name manually. For example:runas /user:woshub\jsmith explorer.exe - Enter your account password;
- File Explorer will then restart with a new access token and you will be able to access the network folder with the permissions of the new security group.
In the previous method, you must explicitly specify the password of the user in order to refresh the security groups in Windows File Explorer. If this isn’t possible, you can try a workaround.
Suppose a user was added to an AD group to access a file server shared folder. Try to access it by its short name (NETBIOS) or FQDN((!!! this is important). For example, \\lon-fs1.woshub.loc\Install. But not by IP address.
At this point, a new Kerberos ticket will be issued to the user. You can check if your TGT ticket has been updated:
klist tgt
(see Cached TGT Start Time value)
A shared folder that has been granted access through the AD security group should open without the user logging off.
Run the whoami /groups command to ensure that the user has received a new TGT with an updated list of security groups without re-login.
Once again, we would like to remind you that this method of updating security group membership will only work for services that support Kerberos. For services with NTLM authentication, a computer reboot or user logoff is required to update the token.
