M
Matthew McDonald (EWS)
EDIT - I have moved this question to the correct forum, as requested:
Strange/unexpected behavior with NTFS, AD groups, and Kerberos Tokens while on VPN. - Microsoft Q&A
------------------------------------------------------------------------------
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:
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.
I am completely confused and calling into question everything I know about IT. Please help!
Continue reading...
Strange/unexpected behavior with NTFS, AD groups, and Kerberos Tokens while on VPN. - Microsoft Q&A
------------------------------------------------------------------------------
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:
- Try accessing a file share my account normally does not have access to - CONFIRMED denied, as expected
- Add my account to the AD group tied to that file share.
- On my office (on network machine), without logging on, attempt access to share. - CONFIRMED DENIED, as expected.
- On my remote laptop at home connected to VPN, attempt access without logging off - CONFIRMED DENIED, as expected.
- Check "whoami /groups", the new group is not listed - CONFIRMED
- On laptop, logged off, logged back on, and reconnected VPN
- Recheck 'whoami /groups' - CONFIRMED, still DO NOT HAVE new group as part of token
- 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.
I am completely confused and calling into question everything I know about IT. Please help!
Continue reading...