All administrators know that after a computer or a user is added to an Active Directory group the computer has to be reboot (if the computer account has been added to the domain group) or a user has to be logged off and on again to update group membership or apply assigned policies. It is necessary because the membership in AD groups is updated when a Kerberos ticket is created, which happens during the system boot and user login.
In come cases, the system reboot or user logoff is impossible for production reasons. At the same time you need to use the rights, access or apply new policies right now. There is an opportunity to update the membership of an account in Active Directory groups without computer restart or user relogin.
You can get the list of groups the current user is a member of in the command prompt using the following command:
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.
Kerberos tickets can be reset without the restart of a computer using klist.exe . Klist is included in OS Windows since Windows 7. For XP and Windows Server 2003 it is installed as a part of Windows Server 2003 Resource Kit Tools.
To reset the whole cache of Kerberos tickets on a computer (a local system) and update the computer membership in AD groups, run the following command in the command prompt with the administrator privileges:
klist -lh 0 -li 0x3e7 purge
After running the command and updating the policies, all policies assigned to the AD group using Security Filtering will be applied to the computer.
As for the user. Suppose that the user domain account has been added to the Active Directory group to access a file share. Obviously, without re-login a user won’t be able to access it.
Reset all Kerberos tickets of the user with this command:
klist purge
To see the updated list of groups, run a new command prompt window using runas for a new process to be created with a new security token.
For example, the AD group has been assigned to a user to access a network share. Try to access it using its FQDN name (e. g., \\lon-fs1.woshub.loc\Install) and make sure that the TGT ticket has been updated:
klist tgt
The network share to be accessed using the AD group will open without user re-login (!!! You must use the FQDN name).
4 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.