Strange/unexpected behavior with NTFS, AD groups, and Kerberos Tokens while on VPN.

Question

I have a question I need help to understand. I've been in IT for 20+ years. It has always been my understanding that when adding a user to a new Active Directory group, that group membership is not picked up until the user logs off the machine and logs back on.

This is required to refresh the user's kerberos ticket/security token so that access granted via use of this group can be allowed, for example to file servers.

As part of my administration, any time I add a user to a group, I instruct them to log off/back on, and everything works as expected.

Today I ran into something I can't explain. With the time of COVID and everyone working from home and over VPN, we've had numerous issues regarding the circumstances above, as our user's VPN connections occur AFTER logon, which means they can never pick up the new security token to reflect their new group memberships.

There are countless articles out on the web highlighting this issue and the workarounds people are doing to get around it, such as using tools like klist /purge or ending task on Explorer and restarting it using a cmdline runas /user:ad\account to launch a new instance of explorer with the updated security tokens/group memberships.

I've been utilizing those workaround myself for the longest time and stress this issue every time we have a project that requires new groups to be created, especially if it affects large user populations.

This concept was recently challenged as unnecessary by a colleague who noted they never faced this issue in their environment when adding users to new groups over their VPN.

After a lengthy debate about how that cannot be possible I opted to just test it, and somehow my colleague is right and I, for the life of me, do not understand how this is possible.

My test:

1. Try accessing a file share my account normally does not have access to - CONFIRMED denied, as expected
2. Add my account to the AD group tied to that file share.
3. On my office (on network machine), without logging on, attempt access to share. - CONFIRMED DENIED, as expected.
4. On my remote laptop at home connected to VPN, attempt access without logging off - CONFIRMED DENIED, as expected.
5. Check "whoami /groups", the new group is not listed - CONFIRMED
6. On laptop, logged off, logged back on, and reconnected VPN
7. Recheck 'whoami /groups' - CONFIRMED, still DO NOT HAVE new group as part of token
8. Retest access to share. - IT WORKS?! HOW?

How is this possible? My laptop is off the network when the log off/log on occurs so it has zero connectivity to my work network, thus cannot pull the new security token, yet some how the act of logging off and back on allows me to connect anyway, and all the while my security token DOES NOT LIST this new group I added myself to.

The fact that I don't fully understand this is driving me mad. LOL

Answer 1

Hi,
About the question, here is my understanding
1, When users log off, all the kerberos tickets will be cleared.
2, When you logon without the VPN disconnected, the group membership won't change since the domain controller can't be connected.
3, When you try to access the share again, the user needs to contact the DC to get the new access token.
Then the kerberos authentication will process to get the new ticket.
If possible, you can capture a network package when access the shares.

How do you think about?
Best Regards,

Answer 2

Hello @MatthewMcDonald-6506 ,

Although @Vadims Podāns normally provides very useful and insightful information, I don't think that the information about periodic updating of group membership in the process access token is correct. As usual, it is difficult to find clear evidence of something that is not the case (i.e. a clear statement that periodic updating does not occur) but, equally, I could not find any clear statement that it does occur.

It might be useful to consider the following three cases.

Access to a local resource: the access token contents at the time of token creation (e.g. login) determine the access.

Access to a network resource with Kerberos authentication: the information cached in the Kerberos ticket PAC (Privileged Attribute Certificate) will be used remotely to create an access token - this information (the whole Kerberos ticket) is renewed periodically (perhaps every 8 hours, by default).

Access to a network resource with NTLM authentication: the remote server will contact a DC to create an access token and receive up-to-date group membership.

Gary

Answer 3

Hello @MatthewMcDonald-6506,

Just like the command windows that you have examined with whoami/groups, Windows Explorer keeps its original token - it can't "see" the new group.

If there was a directory hierarchy on your local computer that you could previously not access and then you were added to a group that granted access, Windows Explorer would not be able to access the hierarchy until you somehow force a new token (with re-login, runas, etc.).

When the directory hierarchy on a remote computer, the local access token is not somehow serialized and sent over the network; instead a new token is created on the remote server. If NTLM is used for authentication, the new token will reflect the newest group membership (ignoring AD replication delays, etc.). If Kerberos is used and the Kerberos ticket contains a PAC then the PAC contents will be used to set the domain groups in the token; although the Kerberos ticket has been cached on your local computer, it was not used to update local tokens - the current groups in the token of Windows Explorer will not necessarily match the groups in the PAC of the Kerberos ticket.

Gary