If you administer Windows systems, you are probably painfully aware of the big changes created by UAC (User Access Control). The UAC system is in place to prevent fully-privileged Administrative users from performing fully-privileged administrative tasks without first asking for “elevated” permissions.
To get around the barriers imposed by UAC, program installer packages are now becoming UAC-aware to request elevated privileges as part of the standard install process. These UAC-aware installers are usually distinguished by a small “shield” high-privilege logo on the installer icon. Other programs on the system can be run with “privilege elevation” by right-clicking and selecting “Run as administrator”.
Unfortunately, not all components of Windows support privilege elevation to bypass UAC. One of the most frustrating tools in this category is the standard graphical file manager, “Windows Explorer.” This can make it very difficult to manage file permissions on a Windows server from within Windows Explorer while UAC is enabled on the system.
Fortunately there is a good workaround for file permission problems with UAC and Windows Explorer. Let me first introduce the typical problem scenario:
- Your account belongs to the local “Administrators” or domain-wide “Domain Admins” groups. These groups are granted “full control” on most Windows folders by default.
- You are locking down a folder to permit access only by administrators and a specific group, for example: “MyProjectGroup”. Your admin account is not a member of this project group.
- You remove the default local “Users” or domain-wide “Domain Users” groups from the folder list and add “MyProjectGroup” with typical “modify” permissions, then you apply the changes.
- After the permission changes take effect, you try to browse into the folder with Windows Explorer and you receive the following error message: “You don’t currently have permission to access this folder.“
- At this point Windows offers a button with the “shield” high-privilege logo offering a weak solution “Click Continue to permanently get access to this folder.” If you use the button, your individual admin account will be added with permissions to the folder, but other administrators will still be blocked.
- If you connect to the folder remotely using a Windows file share (UNC path or mapped drive letter), you are granted privileges since the UAC folder privilege filtering does not apply to file share users … go figure! 😛
Why does this happen? Administrators and Domain Admins are clearly on the folder permissions list with full control, yet they are not allowed access to the folder. This is caused by UAC, which strips off the default Administrators, Domain Admins, and other default administrative groups from the folder permission list – effectively blocking Windows Explorer from using your standard administrative group privileges on folders.
Now for the workaround: You can grant full control privileges on the drive root or any folder to a new local or domain group that your administrative account belongs to. Since UAC does not strip groups other than the default admin groups, you will get folder permissions in Windows Explorer without directly adding your individual admin user. Here are some recommendations for this workaround:
- Create a domain group for these full-control folder permissions, something like “MyDomain\File-Managers” to indicate that the group will be used for file-system and file-share management. Add your administrative account as a member.
- Remember that group changes must replicate to each site with the directory. You can wait for replication to complete on schedule, or you can force replication between domain controllers with repadmin.
- Remember that group membership is determined when you login to a Windows system. Group membership must replicate to the correct site *before* you login or you will not be considered a member of the group. After the group has replicated, log out and log back in to make sure Windows knows about your new group membership.
This solution is based in part on a discussion from serverfault. Thanks to users “TheCleaner” and Greg Askew for their valuable comments.