NTFS Security Issue on Windows 2012 for members of the Administrators Group
I've been migrating some large file servers from a customer's environment into a service provider's cloud. Instead of just transferring the VMs (which would literally take weeks in some cases), we've provisioned new VMs and are replicating the data. Then, during an outage window, we do a differential copy, shut down the old server and give the old server's name to the new server. This also has the benefit of allowing us to get all of those older file servers up on Windows 2012 R2, so it's a win-win. Well, mostly.
One of these file servers has some very strict NTFS permissions due to the presence of sensitive data. In this case, the only permissions on the folder were a Full Control for the Domain Admins and a Full Control for the group who owns the data (we'll call them the Finance Department). We used good old Robocopy (taking advantage of the new /MT switch to multithread it for added performance!) to copy the data and all permissions from the old server that was originally hosting the data.
After the copy finished, I took a look at the destination server and found an unpleasant surprise; I couldn't browse the replicated data. My account is a domain admin, yet I did not have read permissions on the Finance Department's folder. I found that I could browse the folder just fine from an elevated command prompt, but whenever I tried to examine it through the GUI I received a permissions error.
Some research and experimentation has led me to believe that it's an issue that stems from UAC, but it's not as simple as dragging that slider bar down to the bottom to turn UAC off. It appears to me that user accounts do not effectively belong to the Domain Administrators (or the local Administrators) groups on a Windows system until they request UAC elevation. Even after that request is made, they only belong to those groups for the application that has requested elevation. Since my Explorer shell was not elevated, I was unable to browse those folders despite being a Domain Admin. In my elevated command prompt, I was able to browse the folders just fine.
Earlier, I mentioned that just dragging the UAC slider down to the bottom did not resolve this issue. I believe that that setting automatically approves elevation requests; in this instance, no request was being generated and so I did not have a way to enforce my group membership. I found a helpful TechNet article that pointed me at the right solution. By changing the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA value to 0 (and restarting the system), I forced the system to basically load an Administrator's shell with elevation. Upon doing so, I was able to access the folder and validate that my file synchronization was behaving as expected (and ensure that other Domain Admins would be able to access the folder in the expected way moving forward).
One of these file servers has some very strict NTFS permissions due to the presence of sensitive data. In this case, the only permissions on the folder were a Full Control for the Domain Admins and a Full Control for the group who owns the data (we'll call them the Finance Department). We used good old Robocopy (taking advantage of the new /MT switch to multithread it for added performance!) to copy the data and all permissions from the old server that was originally hosting the data.
After the copy finished, I took a look at the destination server and found an unpleasant surprise; I couldn't browse the replicated data. My account is a domain admin, yet I did not have read permissions on the Finance Department's folder. I found that I could browse the folder just fine from an elevated command prompt, but whenever I tried to examine it through the GUI I received a permissions error.
Some research and experimentation has led me to believe that it's an issue that stems from UAC, but it's not as simple as dragging that slider bar down to the bottom to turn UAC off. It appears to me that user accounts do not effectively belong to the Domain Administrators (or the local Administrators) groups on a Windows system until they request UAC elevation. Even after that request is made, they only belong to those groups for the application that has requested elevation. Since my Explorer shell was not elevated, I was unable to browse those folders despite being a Domain Admin. In my elevated command prompt, I was able to browse the folders just fine.
Earlier, I mentioned that just dragging the UAC slider down to the bottom did not resolve this issue. I believe that that setting automatically approves elevation requests; in this instance, no request was being generated and so I did not have a way to enforce my group membership. I found a helpful TechNet article that pointed me at the right solution. By changing the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA value to 0 (and restarting the system), I forced the system to basically load an Administrator's shell with elevation. Upon doing so, I was able to access the folder and validate that my file synchronization was behaving as expected (and ensure that other Domain Admins would be able to access the folder in the expected way moving forward).
Comments
Post a Comment
Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,