AkinsTech

If you’ve worked with Windows 7 or Server 2008R2 for any length of time, certainly you’ve run into situations where you find you don’t have permission to read, modify, or delete files and folders, even though you’re an Administrator.  With this article I hope to explain (in very basic terms) why this happens and more importantly, how you can provision things to ensure you always have permission, along with a simple script to set these permissions.

First of all, to see this in action, log into any system with an administrator account other than the built-in administrator.  Then browse to the C:\Users directory and try to open one of the folders other than your own.  You will see this…

Now the natural tendancy here is to just click “Continue”.  But really this is the LAST thing you want to do, especially on a server.  If you do that, you’re going to permanently modify the permissions of that folder and add the user name you are logged in with.  In a large environment with many click-happy administrators, this can get very messy with everybody’s names tattooed all over the folders’ ACLs..

I’m an administrator dammit, why dont I have permission?

When you are interactively browsing the file system of a Windows 7 or 2008 R2 machine, UAC (User Account Control)  checks to see exactly HOW it is that you have permission to a folder.  If the only way you have permission to a folder is via the built-in “Administrators” group, then it is going to block you and throw up that message.  So how do you get around it? 

Why don’t I just disable UAC?

You could.  But I recommend you don’t.  If you’ve ever used a Unix or Linux system you know that being “administrator” doesn’t necessarily mean you have permission to all files.  You have to be granted permision.  In fact being administrator AND having full access to files can be a very bad thing security wise. 

For years Windows users have enjoyed carte blanche when it comes to access to files.  This free-for-all access has led to the proliferation of malware, lazy programming practices, and a reputation as an “insecure” operating system. 

UAC, for all its pop-ups, delays, and annoyances is a step in the right direction.  Furthermore (and most importantly) leaving it on forces administrators, lazy developers, and systems engineers to architect solutions properly.  That is a good thing.

So then how do you get around it?

Stop working locally!

Notice above I said that UAC stops you when you’re working “interactively”.  That means accessing  files while logged into the system.  In the case of a workstation, obviously most of your work will be interactive, but not necessarily on a server.  In fact one of the easiest ways to avoid being pelted by UAC’s “You don’t have permission” notice, is to simply do your file management work remotely, via UNC.  So instead of logging into the server and operating on C:\ThisFolder, just simply access it from another machine as \\TheServer\C$\ThisFolder.  No UAC issues. 

Provision folders with a FileAdmin group

Remember from above the problem here is that you only have permission via the built-in Administrators group, which UAC is blocking.  So why not just create another group, give it full control, and put yourself (or perhaps your “Domain Admins” group in this group)?  That’s exactly what I recommend doing when you provision a file server. 

I like to create a local group (or a domain local group if you have Active Directory) called “F_FileAdmin”.  I then apply this group to all data areas on the server, giving it full control.  Then add your server admin team, file administrator team, and other appropriate people to this group.

Assume I have a server with a D: drive where I plan to store data.  I’m going to apply the F_FileAdmin group to the entire D: drive.  For this example I’ll use a local group on the server, but you could just as easily do a domain local group in AD.

First create the group.  Either run “Local Users and Groups” on that server, or from an elevated command prompt on that server, enter:

net localgroup "F_FileAdmin" /add

Now add yourself, other admins, Domain Admins, etc to this group.  You’ll need to log off and back on for the change to take effect.  Next you set the permissions.

If you try to set permisisons using the traditional GUI method, you may run into problems if you dont actually own some of the files.  Therefore we need to do this from an elevated command prompt using the icacls command.  Enter the following command:

icacls D:\ /grant "F_FileAdmin":(OI)(CI)F /T

This will add the “F_FileAdmin” group to the entire D: drive and propogate the permissions down to all subfolders and files, ensuring you have access. 

Automating it

Since I’m all about automation and standardization, let’s take the above icacls command and turn it into a reusable command you can run any time you need to provision a folder.

SetFileAdmin.bat
@echo off
icacls %1 /grant "F_FileAdmin":(OI)(CI)F /T

Stick this batch file in your scripts directory such that it is in your path.  Now on any server, from an elevated command prompt, you can provision a folder by simply typing:

setfileadmin d:\SharedData
setfileadmin e:\
setfileadmin "f:\Accounting Files"

Or even use it remotely like this…
setfileadmin \\MyServer\d$\GroupData

Note: UAC problems aside, this script also demonstrates a useful technique for provisioning folder permissions.  If you’re still doing it manually through the GUI, learn to use icacls.  In an upcoming article I’ll go more in-depth into how to use icacls to provision folder security.

As you can see, with a few simple modifications, you can get around the UAC permissions problems on Windows 7/Server 2008R2, and most importantly, do it without having to disable UAC and compromise security.

This entry was posted on Wednesday, February 10th, 2010 at 4:00 pm and is filed under Permissions, Windows. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.