none
Windows Server 2008 R2 and UAC and "you don't currently have permission to access this folder."

    Question

  • Running Windows 2008 R2 server.  I would like to continue leveraging the UAC feature.  I have these two UAC settings deployed via a GPO:

    1.  User Account Control: Behavior of the elevation prompt or administrators in Admin Approval Mode = Prompt for consent on the secure desktop.

    2.  User Account Control:  Run all administrators in Admin Approval Mode = Enalbed

    With UAC enabled, when I click on certain folders on the c:\ drive (for example, PerfLogs) i get the message "you don't currently have permission to access this folder.  Click Continue to permanently get access to this folder."  When I click Continue it gives my account explicit permissions to that folder.  This is not the desired outcome.  I am a Domain Admin and a member of the Administrators local group.  The Administrators group has the permissions to the c:\perflogs folder.

    I don't want to circumvent UAC behavior or set a less desirable settings to bypass UAC as some other solutions have provided.  I thought that this was improved in Windows Server 2008 R2 where we can maintain UAC but still get to these folders without having the explicit permissions set.

    I also want to avoid having to change ownership.  Can this be accomplished in W2K8 R2?  If so, please be detailed in the solution.

    thank you,

    Raffi

    Wednesday, September 22, 2010 4:10 PM

Answers

  • There are several workarounds for this issue, but unfortunately none of them *really* solve the problem:

    0) Allow Windows to add your permissions explicitly:  Goes without saying, but I am listing here for completeness.  You could create/find a script to clean up these explicit permissions...  Not pretty, but neither is the extra SACLs everywhere.

    1) Admin Command Prompt:  You can launch the command prompt as elevated and reach the folder/files.  You can make Shell DLL calls if you need to see GUIs.  Here is an example: http://support.microsoft.com/kb/2462308

    2) Launch App as Elevated, then open the file.  For example, run Notepad as elevated, then File Open, browse to the Perflogs folder and open the CSV file.  NOTE: This is also a workaround to opening GUI windows that you otherwise depend on Explorer to get to. In the File-Open window, just right-click on the folder and perform whatever operations you need.

    3) Remote Administration -  If you connect from your desktop to the administrative share on the server using your DA / Admin credentials, then you will not receive any prompt and credentials will not be explicitly added.  (This is because no split-token is created; the server is not running a user shell - your desktop is.)

    4) Modify your Folder Permissions.  The final option is to enable directory traversal for the folders that you want your administrators to browse to with the split-user token. 

    Discussion

    Actions such as Delete will work correctly as Microsoft is able to perform them as elevated automatically without using the Explorer process.  You can identify them by the Blue Shield icon that is next to the context menu option or in the lower left corner of the icon in the start menu.  This explains Chris' experience.  Note: Explorer.exe will not launch elevated if UAC is enabled.  You can try, but it launches under the user context and does not alert the user to this fact.

    This is an issue that will Microsoft will continue to wrestle with as it tries to apply sudo type *NIX security within the existing Windows shell framework.  Unless Microsoft can detach explorer.exe from the console shell, I expect that Microsoft may implement #4 on their own in forthcoming OS's.  (or rewrite the shell).  Until then, try to do most of your work remotely if possible.

    You can read more about UAC and Windows Explorer limitations here: http://support.microsoft.com/kb/2273047

       EDIT: The KB article appears down, but a copy is available here: http://consumersupport.lenovo.com/ph/en/Guides/OS_guide_show_1261110914140580.html

    -B

    Edit: turn links into hyperlinks
    • Proposed as answer by Tony Britton Friday, May 06, 2011 7:37 PM
    • Unproposed as answer by Tony Britton Friday, May 06, 2011 8:23 PM
    • Marked as answer by Colorjet3 Monday, May 09, 2011 1:51 PM
    Friday, May 06, 2011 7:31 PM
  • Hi,

    The behavior occurs because Users does not have read access to the PerfLogs folder. With UAC, the explorer.exe is launched by the standard user token of the administrator account.

    For more information about UAC, please refer to the following articles:

    http://technet.microsoft.com/en-us/library/cc709691(WS.10).aspx

    http://technet.microsoft.com/en-us/library/dd835548(WS.10).aspx


    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Monday, September 27, 2010 3:25 AM
    Moderator

All replies

  • Colorjet,

    Where the GPO scope is applied determines if it affects Domain Admins, for instance if you set it at the domain level (Default Group Policy) then it would include those domain admin accounts. When you're Enabling Admin Approval Mode for an administrator account it requires even the local admin account to prompt for elevation. 

    So I think if you wanted Domain Admins to not fall under this policy you could setupt Security Filtering to exclude them from having the policy applied to their accounts & set your policy scopes accordingly.

    Wednesday, September 22, 2010 6:45 PM
  • Hello cschaar,

      The UAC settings, as I change them in the GPO, are applying correctly to any account(s) that can logon to a W2K8 R2 server with local admin rights.  I have no issues with Security Filtering either since it applies to "Autenticated Users". 

    My main problems, as stated above, is "With UAC enabled, when I click on certain folders on the c:\ drive (for example, PerfLogs) i get the message "you don't currently have permission to access this folder.  Click Continue to permanently get access to this folder."  When I click Continue it gives my account explicit permissions to that folder.  This is not the desired outcome.  I am a Domain Admin and a member of the Administrators local group.  The Administrators group has the permissions to the c:\perflogs folder."

     

     

    Friday, September 24, 2010 2:37 PM
  • "Security Filtering either since it applies to "Autenticated Users".

    I understand, but that would mean the policy is also applying to Domain Admins, & consequently it makes no difference if you're using a DA or local admin account as the GP would apply to them since they fall under the scope of the policy. So, one option to ensure said accounts aren't afflicted by this issue would be to change the scope of the policy so it doesn't apply to them.

    Review the settings in UAC: Run all admins in Admin Approval Mode (Run all users, including administrators, as standard users.) With it enabled, as you have, & the behavior of the UAC set to Prompt for consent on the secure desktop, this outcome is what you'll get, as it defined as the following:

    "Application starts with a full administrative access token and prompts for consent on the secure desktop".

    And I think this is the case b/c you're attempting to access %system root%.

    http://technet.microsoft.com/en-us/library/ee732416%28WS.10%29.aspx

    Friday, September 24, 2010 4:24 PM
  • Hi,

    The behavior occurs because Users does not have read access to the PerfLogs folder. With UAC, the explorer.exe is launched by the standard user token of the administrator account.

    For more information about UAC, please refer to the following articles:

    http://technet.microsoft.com/en-us/library/cc709691(WS.10).aspx

    http://technet.microsoft.com/en-us/library/dd835548(WS.10).aspx


    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Monday, September 27, 2010 3:25 AM
    Moderator
  • Thank you for explanation.  I will play a bit more with the UAC settings in the GPO to see if I can get the desired result.

     

    Tuesday, October 05, 2010 5:49 PM
  • Hey Colorjet3,

    Did you ever find a solution to this issue? Our 2008 R2 servers are getting messy directories permissions due to this UAC behaviour.

    Thanks.

    Thursday, November 25, 2010 5:00 AM
  • Hi TristoRR,

      No answer yet.  However, I am working directly with a Microsoft engineer and hope to have an answer soon.

     

    • Proposed as answer by Vaclav Dolezal Wednesday, November 07, 2012 2:02 PM
    Monday, March 07, 2011 4:58 PM
  • I read somewhere, maybe in one of the links above, that a Admin setup a Universal Security Group and applied it to all the folders so the pop up would stop.  I haven't tried that yet.

    Well that's fine but I was then thinking why not just add the Domain Admins group instead.  Well this didn't work.  Then I was wondering why there is even a local Administrators group because now UAC makes it completely useless.   So as a Domain Admin with UAC on, I can't even change permissions on files and folders without being explicitly added to the security permissions.  I even tried it as "run as administrator" and it wouldn't let me.

    Does something not sound right here or is it just me.

    Tuesday, March 29, 2011 9:23 PM
  • So, here is the explanation I have received from Microsoft:

    UAC team’s explanation for this is:

    This is by-design. With UAC on, the account being in the local admin group means that it has access to the Admin token, but does not run with it. To access a folder, the shell elevates to add the ACE, and then lets the non-elevated user access the folder. It does this because the Shell cannot run elevated (it can be forced to run elevated, but that is a very bad idea) and so this business of adding the ACE to the folder is a way of granting access to the user. It has been this way since Vista.

    Something still does not sound right here.  I am going to open a problem ticket with Microsoft and see if I can really get to the bottom of this.

    Stay tuned.....

    Wednesday, March 30, 2011 1:12 PM
  • Thanks for the update Colorjet3, this has been very helpful so far.

    We are probability going to run with it off for the time being, as it conflicts with our security policy on file and folder permissions. 

    So MS said  It does this because the Shell cannot run elevated (it can be forced to run elevated, but that is a very bad idea) but I don't see how that would be any different then how Server 2000 or 2003 ran for years. If it is different I would really like more information on that so I can better understand this new security model. 

    I guess I just don't see the benefit of this process.   It seems like it defeats the purpose of the Domain Admin & local administrators groups.  I hope they change this in the next server release.



    Wednesday, March 30, 2011 1:25 PM
  • Hi ChrisI88,

      In most cases I actually don't have an issue with the general approach to UAC.  It takes a bit to get used to it and once you understand it and find your workarounds it works well if "security" is a priority.

    However, this specific issue with the "explicit permissions" having to be granted when you are already part of another group that grants you those permissions just puzzle me.

    Based on discussions with Microsoft, this will not change, but will be improved.  I wonder how UAC works with windows core services?  I wonder how much of this UAC issue is due to having a GUI vs. non-GUI (windows core) and work like UNIX/Linux does with SU root?

     

    Wednesday, March 30, 2011 1:35 PM
  • I just had an interesting experience with this.  I was able to delete the same folder that I couldn't access that only had the local administrators with full control.

    I am a DA so of course I was a member of the local admins indirectly.  I just though it was funny that I could delete a folder that I couldn't access because of the UAC.

     

    • Proposed as answer by Tony Britton Friday, May 06, 2011 7:15 PM
    • Unproposed as answer by Tony Britton Friday, May 06, 2011 7:15 PM
    Wednesday, March 30, 2011 6:31 PM
  • There are several workarounds for this issue, but unfortunately none of them *really* solve the problem:

    0) Allow Windows to add your permissions explicitly:  Goes without saying, but I am listing here for completeness.  You could create/find a script to clean up these explicit permissions...  Not pretty, but neither is the extra SACLs everywhere.

    1) Admin Command Prompt:  You can launch the command prompt as elevated and reach the folder/files.  You can make Shell DLL calls if you need to see GUIs.  Here is an example: http://support.microsoft.com/kb/2462308

    2) Launch App as Elevated, then open the file.  For example, run Notepad as elevated, then File Open, browse to the Perflogs folder and open the CSV file.  NOTE: This is also a workaround to opening GUI windows that you otherwise depend on Explorer to get to. In the File-Open window, just right-click on the folder and perform whatever operations you need.

    3) Remote Administration -  If you connect from your desktop to the administrative share on the server using your DA / Admin credentials, then you will not receive any prompt and credentials will not be explicitly added.  (This is because no split-token is created; the server is not running a user shell - your desktop is.)

    4) Modify your Folder Permissions.  The final option is to enable directory traversal for the folders that you want your administrators to browse to with the split-user token. 

    Discussion

    Actions such as Delete will work correctly as Microsoft is able to perform them as elevated automatically without using the Explorer process.  You can identify them by the Blue Shield icon that is next to the context menu option or in the lower left corner of the icon in the start menu.  This explains Chris' experience.  Note: Explorer.exe will not launch elevated if UAC is enabled.  You can try, but it launches under the user context and does not alert the user to this fact.

    This is an issue that will Microsoft will continue to wrestle with as it tries to apply sudo type *NIX security within the existing Windows shell framework.  Unless Microsoft can detach explorer.exe from the console shell, I expect that Microsoft may implement #4 on their own in forthcoming OS's.  (or rewrite the shell).  Until then, try to do most of your work remotely if possible.

    You can read more about UAC and Windows Explorer limitations here: http://support.microsoft.com/kb/2273047

       EDIT: The KB article appears down, but a copy is available here: http://consumersupport.lenovo.com/ph/en/Guides/OS_guide_show_1261110914140580.html

    -B

    Edit: turn links into hyperlinks
    • Proposed as answer by Tony Britton Friday, May 06, 2011 7:37 PM
    • Unproposed as answer by Tony Britton Friday, May 06, 2011 8:23 PM
    • Marked as answer by Colorjet3 Monday, May 09, 2011 1:51 PM
    Friday, May 06, 2011 7:31 PM
  • I fixed this issue tonight! I was at my witts end. I had one 2008R2 server exhibiting the symptoms and one not.  I compared UAC settings, local security policy, registry settings. All matched. I logged in local to the bad server, deleted my domain admin profile via the computer, properties, advanced, user profiles (renaming the profile didn”t work). It was recreated when I logged back in with my domain admin account. I can”t remember if I changed the UAC slider, or if it just prompted me I had to reboot to take affect (I am pretty sure I didn”t touch the slider, but then again I didn”t think this would work, so didn”t write it down). I scheduled a reboot and just did it… holy smokes it is fixed! I can use my domain admin account on that server again. Why it was in a half snit I have no clue…Waiting for another admin to very theirs works too, but at least mine is fixed so far.

    Edited to add: it is fixed for the other admin as well.

    • Edited by tishward Wednesday, March 13, 2013 6:19 PM
    • Proposed as answer by tishward Wednesday, March 13, 2013 6:19 PM
    Wednesday, March 13, 2013 1:38 AM
  • Did you got solution for the above said issue..I am facing the same issue and things really getting worst..Request you to share if you have solution.


    Thursday, April 25, 2013 6:48 PM
  • I fixed this issue tonight! I was at my witts end. I had one 2008R2 server exhibiting the symptoms and one not.  I compared UAC settings, local security policy, registry settings. All matched. I logged in local to the bad server, deleted my domain admin profile via the computer, properties, advanced, user profiles (renaming the profile didn”t work). It was recreated when I logged back in with my domain admin account. I can”t remember if I changed the UAC slider, or if it just prompted me I had to reboot to take affect (I am pretty sure I didn”t touch the slider, but then again I didn”t think this would work, so didn”t write it down). I scheduled a reboot and just did it… holy smokes it is fixed! I can use my domain admin account on that server again. Why it was in a half snit I have no clue…Waiting for another admin to very theirs works too, but at least mine is fixed so far.

    Edited to add: it is fixed for the other admin as well.

    I just tried this and can confirm it does not work unfortunately. Even after deleting the User Profile in the manner described and a reboot, I still have the same issues as originally posted.
    Thursday, May 02, 2013 2:23 PM
  •  

    I finally got my issue resolved by myself last night...I spent hours in getting the solution and found it was simple and i was revolving around problem.. :)

    I have not applied any domain level policy. Only local policy but i noticed that it is important to restart the machine in order to see the change.
    User account Control : Admin Approval Mode for the built-in Administrator account--Enabled
    User account control :Behavior of the elevation prompt for administrators in admin approval mode : Prompt for credientials
    User account control:Detect application installations and prompt for elevation : Enabled
    User account control :Run all administrators in admin approval mode : Enabled.

    Sunday, May 12, 2013 5:56 AM
  • I know this is an old thread, but wanted to chime in for the benefit of others.

    I've found the easiest way to get around this issue whilst leaving UAC enabled for security is to enlist the use of other groups, outside that of the default Administrators group.

    The problem stems from using the local Administrators group to control access to the folders/files.  I have found that if you create another group and add yourself/your admin users, and also give it full permissions to the folder/file (leaving Administrators is up to you and won't affect anything), the access/functionality you expect will return.  For example, I created a local group called NTFSAdmins and added Domain Admins to it then applied that with full control at the parent folder and let the permissions inherit down.

    Note:  If you create a new group during your session, be sure to log out of the system and back in to pick up the login token for being a member of that group.  This bites many admins in the rear.

    I would not suggest nesting the local Administrators group into the newly created group as that may cause it to require the elevated token as well, though I have not tested this.

    I'm sure this will not solve all problems related to UAC and folder permissions, but when setting up specific shares, e.g. Home Folder shares, if you do this up front it will save headaches in the long run.


    Monday, June 24, 2013 9:46 PM
  • I know this is an old thread, but wanted to chime in for the benefit of others.

    I've found the easiest way to get around this issue whilst leaving UAC enabled for security is to enlist the use of other groups, outside that of the default Administrators group.

    The problem stems from using the local Administrators group to control access to the folders/files.  I have found that if you create another group and add yourself/your admin users, and also give it full permissions to the folder/file (leaving Administrators is up to you and won't affect anything), the access/functionality you expect will return.  For example, I created a local group called NTFSAdmins and added Domain Admins to it then applied that with full control at the parent folder and let the permissions inherit down.

    Note:  If you create a new group during your session, be sure to log out of the system and back in to pick up the login token for being a member of that group.  This bites many admins in the rear.

    I would not suggest nesting the local Administrators group into the newly created group as that may cause it to require the elevated token as well, though I have not tested this.

    I'm sure this will not solve all problems related to UAC and folder permissions, but when setting up specific shares, e.g. Home Folder shares, if you do this up front it will save headaches in the long run.


    Tested. This solution works
    Thursday, September 12, 2013 11:05 AM