Explain “You do not have permission” error as a Domain Admin

I recently had a customer express frustration they could no longer manage file permissions on their Windows Server with a newly created domain admin account. They would receive a “You do not have permission to access” error when trying to open folders in Windows Explorer when they were confirmed to have full permissions to those folders.

I’ve run into this problem before but admittedly never fully understood why. I do now though and wanted to share my learnings for the benefit of others.
Here’s the scenario:

• Use COMPANY\administrator account to perform NTFS file share permission changes by first RDPing directly into SERVER1, opening the folder in question using its UNC path and modify the NTFS permissions. This works as expected
  
• COMPANY\administrator is a member of Domain Admins which in turn is a member of the local administrators group on all servers
  
• COMPANY\administrator account is then permanently disabled and a replacement account called COMPANY\newadmin is created. This account is assigned to the Domain Admins group and thus should have permissions identical to that of COMPANY\administrator
  
• RDP into SERVER1 as COMPANY\newadmin and try to open the same folder using the same path that previously worked as COMPANY\administrator and receive this error:
  

• Next try to open the folder directly in Windows Explorer (rather than the UNC share) and get this message:

• Pressing continue grants access to the folder but it does so by granting the logged in user “Full Control” to the ACL of every individual file and folder selected. This can take a long time and doesn’t make intuitive sense as to why it’s even necessary as COMPANY\newadmin is already a member of groups that have access to this folder
  

• Using the “Effective Access” verification tool in Windows confirms the permissions granted to COMPANY\newadmin on the folders tells us that it’s supposed to have “full control” and yet that is not the behavior we see
  
• As you might guess, the root cause is ultimately User Account Control or UAC but it’s a little more nuanced than I would have expected. UAC removes the admin tokens from the non-elevated session of COMPANY\newadmin at login which means when Explorer.exe is started, it runs in a non-elevated session.
  
• This ends up being a problem as documented by Microsoft here:
  

https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/dont-have-permission-access-folder

“This behavior is by design. But because the typical pattern with UAC elevation is to run an instance of the elevated program with administrative rights, users may expect that by selecting Continue, which will generate an elevated instance of Windows Explorer, and not make permanent changes to file system permissions. However, this expectation isn’t possible, as Windows Explorer’s design doesn’t support the running of multiple process instances in different security contexts in an interactive user session.”

That’s the issue. Explorer is running non-elevated and because of the long history of Windows Explorer and because its codebase long predates User Account Control as a concept, it doesn’t support being able to switch from a standard to an elevated session. Microsoft created the workaround we are familiar with whereby explorer launches a different process that then updates the ACLs of each individual file but that’s a kludgy workaround at best.

This behavior can be confirmed by accessing the same folder using any other tool such as PowerShell. In the example below I’m logged in as COMPANY\newadmin and am trying to open a folder. On the left I try to do so through Windows Explorer and I’m denied. On the right in the exact same session I do so in an elevated PowerShell session and it works fine:

• If we check Task Manager, we can see that explorer.exe is in fact running without elevated rights by design when UAC is enabled.
  Due to how explorer.exe is architected, a second elevated instance cannot be started in the same user session:

This is great but still leaves an unanswered question. Why was the customer able to modify these exact same permissions with the COMPANY\administator account on the same server? I would think that account should be subject to the same security but clearly wasn’t. I speculated that a previous administrator in years past may have created some kind of exception for the account. It took some digging but I believe I found that setting:

Under Computer Configuration –> Windows Settings –> Security Settings –> Local Policies –> Security Options:

You can see above that “User Account Control Admin Approval Mode for the Built-In Administrator” account is set to disabled which always runs everything, including explorer as elevated.

Now that we understand that UAC is causing this issue, how can we workaround it?

Microsoft recommends the best practice of encouraging administrators to perform all of their server administration remotely as opposed to logging directly into individual servers directly via RDP. I think this is why this issue has never been fully addressed as if administrators followed this best practice, they would never encounter this issue. This means that even though you get an access denied issue when accessing the shares locally on the server, file access works fine when accessed remotely through UNC.

This brings us to the workaround which is remarkably simple:

1. Connect to SERVER1 remotely from a different server using the COMPANY\newadmin credentials and browse to the desired file share
2. Modify your permissions from there as desired. You will no longer receive the security prompts as described above