Error: “You don’t currently have permission to access this folder. Click Continue to get access to this folder.”
If you click continue the currently logged in user id will be granted security permissions to the folder. This is not a good idea and the folder permissions will get messy quick if very many domain admin accounts are accessing the folders on the server. So, what is really going on?
Here’s how to recreate the issue:
- Create a new account in Active Directory and add it to the Domain Admins security group.
- Create a Windows Server 2008 server and join it to the domain.
- By default the Domain Admins security group is added to the local Administrators group when the server is added to the domain.
- User Account Control (UAC) must be left enabled.
- Login to the server with the account created in step 1 (Not the default built-in Administrator account for the domain).
- Create a new folder on the hard drive.
- Edit the security permissions by removing inheritable permissions from the parent
object and adding the local Administrators group and SYSTEM giving them Full Control permission. - When trying to access the folder an error will display that says you do not have permission to access this folder.
- Click Cancel. If the Continue button is clicked the currently logged in user id will be granted security permissions to the folder, which will gain access to the folder, but will cause folder permissions to get messy.
- There is NOT an option to elevate privilege to gain access to the folder with the rights that were granted in step 7 which should be sufficient (i.e. full control).
This issue is the result of User Account Control (UAC). UAC is the feature in Windows Vista and Windows Server 2008 that is designed to apply the principle of least privilege.
If UAC is turned OFF this issue goes away. Also, if you login with the built-in Administrator account for the domain the issue also goes away.
After digging into UAC a little further, I found that by default UAC applies to all interactive users with the exception of the built-in administrator account. This is because the group policy Admin Approval mode is on for the built-in administrator account is disabled by default which means the built-in administrator account will logon in XP compatible mode and run all application by default with full administrator privilege with out a filtered access token. This would seem to explain why the built-in administrator is not affected by the issue created by having UAC turned ON.
Note: If the group policy Admin Approval mode is on for the built-in administrator account is enabled this issue also effects the built-in administrator account in the same way.
All other admin accounts are subject to UAC and the filtered access token. The group policy Behavior of the elevation prompt for administrators in Admin Approval Mode is set to Prompt for Consent by default. There is not a policy to disable Admin Approval mode for non-built-in administrator accounts.
Check out the Security Policy Settings and User Account Control blog post for more details.
At this point it looks like there are two choices to get around this issue:
1) Leave UAC turn ON and use the built-in Administrator account for the domain and let everyone share the same account which is a bad security practice or
2) Turn UAC OFF and use any user account that is a member of the domain administrators group. This might not be a bad idea since UAC is really a client feature anyway.
I would consider this issue a bug. Hopefully, Microsoft will come out with a fix that will allow UAC to be left enabled.
