I'm working with a Windows Server 2012 R2 domain controller which is being used primarily as a file server. The clients on this network are mostly not domain users, but instead use domain user accounts to authenticate a network drive mapping to the file server shares.

These domain user accounts, in turn, provide different levels of NTFS access permissions for different folders in the file server's shares. To do this, NTFS access permission are set at the domain user group level, and domain users are transiently added to or removed from these groups as is required.

What I'm noticing is that, when a user is added to a group which grants them additional access privileges (or indeed when they are removed from a group and so lose access privileges), these privilege changes do not come into effect until after a client computer (observed on Windows 7 Professional) has been restarted (and so, presumably, the cached access token for the corresponding mapped drive has been refreshed.)

As an administrator it would be useful to force a refresh of these access tokens as soon as a user has been added to or removed from a group, such that their new access privileges come into effect immediately, without having to restart their computer.

Is this possible to enforce? And if so, how?

  • 1
    Changes in group membership really has nothing to do with NTFS. This is all about Kerberos. – Zoredache Sep 30 '15 at 17:25

The straightforward answer is no. There is no definitive way that I know of to update the Kerberos access token without logoff/logon or reboot. The SID of the new group needs to be added to the token and is only done at those events.

You could try using klist purge as many articles on the web will suggest, but my efforts to attempt this did not work.


klist purge does indeed work for the vast majority of stuff, especially rights changes to shared folders. You need to be careful with this. Since this is session specific doing it from another user's account - even on the same system - will not work. You would want to run this under the logged on user's context. I would personally use this only when sitting at someone's desk (assuming this is for helpdesk situations) so it is easy to test.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.