Cannot Access Files/Folders After Adding User or Computer to Security Group in Active Directory

Published: Sep 28, 2023 12:30 PM

I'm sure you've ran into this before. As an IT professional, I've ran into countless times where you add a username or a computer to an Active Directory security group to either access files/folders or to add someone or some machine to a group under Security Filtering in group policy. You think everything is good and that things will just work, but it doesn't. You've double checked that you didn't fat finger the username or device and that the proper permissions look good on the back-end, but the user reports that they still can't access "the thing."

So what's an engineer dude to do?

This problem has recently shown itself in my enterprise environment and it's actually a problem that has been around for a while. It really started to show itself in 2020 during the pandemic when employees started working from home and using VPN to connect to corporate networks from the convenience of your couch or home office. Through research, what I've found is that the issue lies in the client device not knowing that it received a new group membership in Active Directory (AD). The reason this happens is because of our old friend Kerberos.

Kerberos is an authentication protocol developed in the late 1980's that issues tickets as a way of proving a user's identity. Your Kerberos tickets are issued from a Key Distribution Center (KDC), a server which holds a database of all principals and their encryption keys, the Authentication Server (AS), and the Ticket Granting Server (TGS). When you authenticate, you are issued a Ticket Granting Ticket (TGT) from the KDC. And within this TGT is where the magic happens, because it contains a Privilege Attribute Certificate (PAC) field which holds your AD group permissions (in a nutshell). Following so far?

So, when a user is logged into their computer and you add them to a new group in AD, that user's PAC data doesn't magically update right away. So what can we do?

First, let's verify that this is the problem. If you've added their account or machine to an AD group and you're sure everything looks good from the Active Directory side, on the client machine open a new Command Prompt as the affected user and run the command:

whoami /groups
          

This command will list any AD group memberships the user currently has from the PAC data. We should expect that the group we just added is missing from the list that is shown. If the group is not missing, then this article likely doesn't apply to your specific situation, but feel free to continue reading! If the group is in fact missing from the list, then we will need to get the PAC data to refresh itself to see that this user account does in fact have a new membership to a group in AD.

There are three methods to get this new AD group membership data within the PAC to refresh itself:

Method 1: Log off of the computer and log back on to force a TGT/PAC field refresh.

As long as you have line-of-sight to a DC when logging on to your machine, you should pull down the new TGT during the login process. Where this becomes tricky is when VPN is involved because you would need to authenticate to VPN prior to logging into Windows so that you have line-of-sight to a DC. Sometimes VPN doesn't connect right away and you may need to manually do this through the login screen prior to attempting to login depending on your VPN product and whether it supports machine-tunnel or some other pre-authentication method. If VPN isn't connected and you're remotely working, any login you attempt will use your cached credentials and subsequently would not refresh the TGT upon login.

Method 2: Wait for the TGT to automatically issue a new ticket (the default is every 7 days).

By default, the TGT will automatically pull a new ticket after 7 days. In the meantime, the current TGT will renew itself after 10 hours, but unfortunately this will simply be a renewal of the ticket we were already granted prior to permissions changing. You can see these results by running the "klist" command within a Command Prompt window:



The "Start Time" denotes when the current ticket's lifetime was started. The "End Time" tells you when the ticket's lifetime will expire and require a renewal which by default will automatically renew every 10 hours up until the "Renew Time." And the "Renew Time" will show you the time at which the renewal lifetime will expire, which means the ticket can no longer be renewed automatically and will require a new ticket to be issued from the KDC. In essense, by waiting it can take up to a maximum of 7 days for the new ticket to reach the target machine.

Method 3: Use the klist utility to purge any existing ticket, then re-authenticate to a Domain Controller (DC) so that a new TGT is issued (and subsequently new PAC data).

You can purge your own Kerberos tickets and then get them re-issued to your device/user. There are two different tickets you can purge, user tickets and computer tickets. If for instance you added a computer object into a security group in AD and wanted it so see new group memberships, you would need to purge the existing local machine ticket and force a new one to be issued from the KDC (this requires administrator rights). If you needed to purge a user Kerberos ticket, then you can easily do this via Command Prompt.

To re-issue a local system Kerberos ticket (with administrator rights):

1. Open Command Prompt as an Administrator and run the command:

          klist -li 0x3e7 purge
          

2. Then run a group policy update command to pull down a new local system TGT:

          gpupdate /force
          

3. Check if our new machine group membership is recognized by running the command:

          gpresult /SCOPE COMPUTER /R
          

To re-issue a user's Kerberos ticket (no administrator rights needed):

1. Open Command Prompt as the affected user and run the command:

          klist purge
          

2. Then check and see if the new group membership is recognized by typing:

          runas /user:DOMAIN\YOURUSERNAME cmd.exe
          
          (NOTE: Replace "YOURUSERNAME" with the affected domain username)
          

This should launch a new Command Prompt window. By invoking a process using the runas command (as ourself), we are calling a Kerberos authenticating command, that is, by calling runas we are forcing an authentication with the domain and subsequently by doing so this command will authenticate using Kerberos. Once it initiates, it sees we have no tickets anymore and the KDC issues us a new TGT.

3. Within this new Command Prompt window, type:

          whoami /groups
          

Did the group magically show up now? If so, it means that your Kerberos ticket was the issue. We aren't fully out of the woods yet though. Remember, the current session of your login is using the old ticket and the permissions that came with it. For instance, if the new group membership is giving you access to a file share, you still won't be able to access it if you try to map it. But why? Because the parent process of connecting to the drive is running under the context of explorer.exe which was originally spawned under your account when you first logged in under the old TGT permissions. So in essence, we could theoretically kill our current process of explorer.exe and do a runas.

4. Under the new Command Prompt window from step 3 above, type:

          taskkill /F /IM explorer.exe
          

5. Your explorer.exe (and the desktop and start menu) will disappear. Now type:

          start explorer.exe
          

This new explorer.exe process should now be running under the new TGT issued. Or if you want to avoid these last 2 steps, just restart the computer since we have a new TGT already - this way every process that starts from your username context moving forward will utilize the new Kerberos ticket.