With the introduction of Windows Vista came the first implementation of User Account Control (UAC) and with it, a file server NTFS permission issue which has been driving me nuts for years. If you are a Windows server admin you have probably seen this too but never thought twice.
When accessing a folder on a Windows file server, it prompts saying "You don't currently have permission to access this folder". Now I know this folder has the following permissions set on it:
If I click continue to this prompt, UAC will automatically add my user name with full control permissions to the folder and all sub folders and files which I'm attempting to access. With multiple administrators maintaining a file server this results in unwanted user name ACL's spread across folders and files throughout the file server making the permission structure a mess.
After many years and now with the release of Windows Server 2012 this issue is still occurring. It's about time we spend some time and work out what's going on.
Resolution
After leasing with some colleagues of mine in Microsoft who work on the file services team they told me three group policy settings are responsible for this behaviour which can be found under:
Computer Configuration --> Windows Settings --> Security Settings --> Local Policies --> Security Options
You don't have to create a group policy object to implement these changes unless you have multiple file servers you want to target. In this instance I simply utilised GPEDIT.MSC on the local file server and set these changes as a local policy.
Now when my administrators navigate the file server they are no longer prompted to add their account to NTFS permissions and in result making a mess of my NTFS permission structure.
When accessing a folder on a Windows file server, it prompts saying "You don't currently have permission to access this folder". Now I know this folder has the following permissions set on it:
- SYSTEM - Full Control
- Administrators - Full Control
- Users - Create Folder append data
If I click continue to this prompt, UAC will automatically add my user name with full control permissions to the folder and all sub folders and files which I'm attempting to access. With multiple administrators maintaining a file server this results in unwanted user name ACL's spread across folders and files throughout the file server making the permission structure a mess.
After many years and now with the release of Windows Server 2012 this issue is still occurring. It's about time we spend some time and work out what's going on.
Resolution
After leasing with some colleagues of mine in Microsoft who work on the file services team they told me three group policy settings are responsible for this behaviour which can be found under:
Computer Configuration --> Windows Settings --> Security Settings --> Local Policies --> Security Options
- User Account Control: Admin Approval Mode for the Built-in Administrator account
- User Account Control: Behaviour of the elevation prompt for administrators in Admin Approval Mode
- User Account Control: Run all administrators in Admin Approval Mode
- Disabled
- Elevate without prompting
- Disabled
Now when my administrators navigate the file server they are no longer prompted to add their account to NTFS permissions and in result making a mess of my NTFS permission structure.
Thanks you
ReplyDeleteThank you! This has been driving me nuts on our 2008+ servers. I finally decided I had enough and went looking for a fix!
ReplyDeleteThis article is useful, however, I am getting this issue and my local policy is already set to this configuration. I think my next bet is to completely disable UAC as I cannot really see the point of it when my file server is already so hardened. Down side is a reboot but I can deal with that!
ReplyDeleteThanks a lot!
ReplyDeleteThis solved our issue, thanks a lot!!
ReplyDeleteMerci beaucoup !
ReplyDeleteThis feature was annoying me since long time ago !
Great! Thank you!
ReplyDeleteThanks a lot
ReplyDeleteI have Windows Server 2012 R2 and I am getting this prompt on a folder in the root of E: I turned UAC off in Control Panel but I still get prompted. Are these registry changes different than turning UAC off in the Control Panel?
ReplyDeleteIs it necessary reboot the server ?
ReplyDeleteJust tested this in our environment. Steps needed
ReplyDelete1. create a gpo.
2. wait for some time (5 to 15 minutes)
3. run gpupdate /force
4. verify with rsop.msc that gpo is applied
5. test and get error message again
5. reboot server
6. after reboot, it works.
So reboot seems to be a mandatory.
works like a charm, thank you!
ReplyDeleteWorks perfectly. Thank you !
ReplyDeleteExcellent!
ReplyDeleteThank you! I was so frustrated with this!
ReplyDeleteThank you for this post, however for simply accessing folders alone without the security prompt that messes up security permissions on the folder, I found that I don't need to change the second item to Elevate without Prompting, which in my opinion is kind of a huge security hole you're opening as you're allowing any third party binary to run itself under your account potentially without you knowing.
ReplyDeleteOr you could just create a seperate group (which is not in the administrators group locally on the server) with the user you want to give access, and give that group full access to the folders(or drives) you want.
ReplyDeleteCreate a security group for Fileserver Administration is the best approach, it works without UAC changes.
DeleteI found granting principal Domain Users read permissions right to the share. Much simpler than disabling UAC or hacking the registry :)
ReplyDelete^ Enterprise file security is much more complicated than giving all domain users access to your share, or creating a local group and giving it full access. In a corporate environment you have security requirements that need to be consistent across several file servers and many many folders within those file servers. this article addresses an issue that causes inconsistencies in security permissions defined by admins.
ReplyDeleteWho said anything about granting domain users access to a share? Granting read permissions right does exactly that, it grants domain users the right to read folder ACL's.
ReplyDeleteDomain users will not have the rights to open folders & folders will remain hidden if ABE is enabled
^ I get what you're saying, but my issue for ending up here was like this: I am logged into this file server (win 2012) with a user account that is member of domain admins. I can manipulate permissions on a folder named "Share" for example. I take away all rights to the folder and give system, domain admins and the local administrators group on the file server full security permissions. Now with UAC enabled, if I try to browse into the folder I just set these on, I get a notification saying you need to provide administrator blah blah to access this folder, and when you hit continue, it gives explicit full permissions to my user (which is already a member of the domain admins group), without recognizing the membership and the changes are permanent. So if I do this and several other admins in the company do this every time they browse to one of these folders, soon looking at the security permissions of any of these folders will look like a mess. Are you saying allowing domain users to read the folder permissions fixes this? And if so, then why is it respecting that but not the domain admins membership with even full permissions?
DeleteFor clarification, we're talking security permissions not share permissions and seriously I'd love to leave UAC intact as it is intended to be and get around this "issue".
Thanks.
This comment has been removed by the author.
ReplyDeleteDude, I was so frustrated with this too. Makes no sense that my user account has to be added to the ACL when I'm already a member of a group that is assigned to the ACL. Your are awesome!
ReplyDeleteYes Yes Yes! Mwah! x
ReplyDeletehttps://wiki.ap3x.org/bin/view/Main/You+don%27t+currently+have+permission+to+access+this+folder+windows+2008,2012 - may wanna have a word, looks like you posted first!
ReplyDeleteOnce again, by chance , I found exactly what I was looking for . You're doing a good job. Thanks a lot ;)
ReplyDeleteThank you very much I 've solved a problem for several days.
ReplyDeleteGood, thanks !
ReplyDeleteAlso, as a workaround, you can run elevated explorer or a filemanager (right click c:\windows\explorer.exe -> run as administrator) to access these files
Factually you just removed UAC. If you go to UAC settings and turn it to "Never notify" you'll have same result.
ReplyDeleteNo, you don't get the same results. That's why this article was posted.
Deleteyes, you are right.
Deletethere are instances that you still get prompted for permission
anyway, "never notify" is not equivalent to "right elevation"
Great post
ReplyDeleteGreat job! So well documented that a link to this page is used for Government of Canada server builds ;-)
ReplyDeleteThank you so much! Following the indications depicted here I was able to resolve the following situation
ReplyDelete1. Two computers, no Active Directory Domain, one with Win 8.1 (name W81 for example), other with Server 2012 (name w12 for example)
2. Two local users on w12: [UserA] with PasswordA and [UserB] with PasswordB. Both belong to the [Administrators] local group.
3. Two local users on w81: [UserA] and [UserB] with se same PasswordA and PasswordB as the corresponding users of w12. Both belong to the [Administrators] local group.
4. I share a folder on w12:
a. Share name: Temp1$
b. Share permissions: [Everyone], Full Control
c. NTFS permissions: [Administrators], Full Control. No other Group has NTFS permissions here
5. Logged in on the W12 as [UserA], I try accessing the share using UNC \\w12\Temp1$ . I get an error saying I have no access. The share is found. Just no access.
6. Logged in on the W81 as [UserB], I try accessing the share using UNC \\w12\Temp1$ . I get the same error. RESTARING w12 DOESN'T HELP.
7. If I add [UserA] and [UserB] explicitly to the NTFS permissions, they now have access to the share using steps 5 and 6.
8. I used the settings for #1 and #3 recommendations:
#1, User Account Control: Admin Approval Mode for the Built-in Administrator account : Disabled.
#3, User Account Control: Run all administrators in Admin Approval Mode : Disabled.
And left #2 untouched:
#2, User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode : Prompt for consent for non-Windows binaries
9. Restarted the machine and the situation didn't happen again.
Thanks again
Based on my tests, disabling "User Account Control: Run all administrators in Admin Approval Mode" is virtually identical to disabling UAC. I now go into the control panel and the slider is at the very bottom. Windows notifies me of security risks and says UAC is off. Setup.exe no longer prompts. Might has well have disabled UAC through the control panel. I much prefer the solution of creating a new group with read access rights. If someone knows how this is different than disabling UAC from the control panel, do let me know.
ReplyDeletenow we are in windows 10 era,
ReplyDeletewe have another prompt from the system,
there are local storage places that an administrator user (not the built-in administrator) is not allowed to save things into via a software's "save" functionality, but moving or copying files into these places is okay.
of course, login as the built-in administrator will do.
any idea?
https://www.youtube.com/watch?v=3fpPUEoiKcM
Deleteis this the only workaround?
Why it doesn't work for me? :(((
ReplyDeleteThanks a lot !!
ReplyDeleteThank you, solved the problem!
ReplyDeleteThat's disabling UAC. That is not a solution to the prompt "problem".
ReplyDeleteWe set up UAC to be on for all users with credentials prompt for both Admin and Standard users.
We do _not_ have this problem accessing folders or folder shares with UAC enabled via GPO at any client site.
The primary reason for this "problem" is an incorrect method for disabling inheritance. One should COPY/CONVERT the existing permissions from the folder to be disinherited. Not REMOVE!
Once the COPY process completes, for large folder sets it can take time, REMOVE the DOMAIN\USERS (or SERVER\USERS) account and add the security groups necessary. Click APPLY and OK.
NOTE: If there are subfolders and files already in the foldermake sure to tick the "REPLACE all child object permission entries..."
The catch is if there are already customized permission sets on subfolders those too would be removed. So, use the replace with caution on existing folder sets.
The best method is to always disable inheritance using the above method _before_ copying data into the folder.
We've found that over the years ACL corruption, and thus the need to reset permissions on the entire folder set, is primarily caused by the improper disinheritance process run previously.
Or, in some cases the lack of patience by the admin/user that clicked the "Replace All Permissions on Children" option on a huge folder set and cancelled mid way through the process.
Hi Philip, I would be most interested to see an RSOP and GEPEDIT outpout of you environment. I've encoutered this issues only for the last few weeks on most of our 2008 an 2012 servers, but not all. Yet, gpo are the same. There are dozens of admins here so somebody must have changed something. Feels like the adminitrators local group doesn't work as it should. Do you believe is is normal to have individual accounts added with the continue button? Even adding the domain admins group to the folder is not something I'm inclined to, but somehow is the only workaround other than disabling UAC, which I refuse to do.
DeleteFixed my issue as well on the local file server that was a DC 2012 R2. The only catch here is that you have to reboot before it will actually work.
ReplyDeleteThank you very much! It works very well for me.
ReplyDeleteFile server : W2K12 R2
gmbk902@gmail.com
This comment has been removed by the author.
ReplyDeleteСпасибо огромное! Thank you so much!
ReplyDeleteNice Post. vehicle tracking system dealers in pune
ReplyDeleteGreat!
ReplyDeleteThis article has great reference value, thank you very much for sharing, I would like to reproduced your article, so that more people would see it.
ReplyDeleteIdentity Theft
Thank you so much!
ReplyDelete