Least-Privilege BUILTIN\Administrator Failure Configuring Application Control Policies with AppLocker

Question

I asked this question over at SuperUser to no avail a while ago, before realizing that serverfault may be a better option.

I'm configuring execution control on a computer running Windows 7 SP1 Ultimate with one hard drive with a single partition. With AppLocker comes the option to create "default rules". In the case of the Executable Rules group, those are as follows:

• Allow Everyone Path %PROGRAMFILES%*
• Allow Everyone Path %WINDIR%*
• Allow BUILTIN\Administrators Path *

(No exceptions.)

With all these in place, "everything works as expected". However, if the first two rules applied to "Everyone" are removed, things go awry.

Now, logging in using an account from the BUILTIN\Administrators security group is no longer possible. (If the account was previously already logged in, you may need to restart the computer to see this fail. Also, this does not apply to the BUILTIN\Administrator account, which still works). What happens when you try is this:

There is a delay, and when the desktop should be presented the screen turns blank. Then, nothing more. The computer does not become unresponsive, e.g. Ctrl + Alt + Delete still works.

(If I reconfigure AppLocker to explicitly allow BUILTIN\Administrators execution privileges for %WINDIR%*, or restore that rule for "Everyone" these accounts can log in again.)

According to MSDN:

The asterisk (*) wildcard character can be used within Path field. The asterisk (*) character used by itself represents any path. When combined with any string value, the rule is limited to the path of the file and all the files under that path. For example, %ProgramFiles%\Internet Explorer* indicates that all files and subfolders within the Internet Explorer folder will be affected by the rule.

This to me implies that the default rule for BUILTIN\Administrators should completely overlap the default rules created for "Everyone", rendering them redundant in the case of accounts belonging to the BUILTIN\Administrators group. As you can see, this appears not to be the case.

So, I have two questions on this:

1. Why is the default rule for BUILTIN\Administrators in itself not enough to get accounts belonging to this group working (i.e. what's wrong with it, and what is it that is failing because of it), and;
2. What is really the least-privilige configuration for a working administrative account (not BUILTIN\Administrator) with regard to AppLocker configuration?

Answer 1

As I understand it, your problem relates to how windows treats Administrative accounts.

Out-of-the-box, since around Windows Vista, administrative accounts do not actually have the administrative rights enabled on them straight away, and you need to elevate to administrator privileges using User Access Control, UAC (e.g. if you try and change a system setting, you get the UAC prompt asking if you know what you're doing). Until you do that, the user account basically only has the same level of permissions that a normal user would.

Consequentially, when you're logging in as a member of the Administrators group, your user account doesn't technically have the privileges of an administrator (since you haven't elevated using UAC) and therefore does not meet the requirements of your "Allow *" rule. Your Windows session then proceeds to implode because your user account doesn't have permission to run any of Windows system files needed during login.

I have a similar issue in one of my AppLocker environments, I don't lock down the Programs Files and Windows directories as much as you have (by deleting the default rules), but I do have a rule basically saying "Members of BUILTIN\Administrators, allow *". However, when you login as an administrator and try double-clicking a random executable outside Windows/Program Files, you get an AppLocker violation and it prevents you from running it. Instead, you have to right click it and go "Run As Administrator"; it's only at that point AppLocker will understand you're indeed a member of BUILTIN\Administrators.

Possible workarounds are to:

1. Disable UAC (I've never tested this, not sure if it will work -- in our environment, we leave UAC on)

2. Create a new Windows local group called "System Administrators" or something, and add individual windows user accounts into it of people who should be able to access it (but do not simply add BUILTIN\Administrators to it); then create an AppLocker rule saying members of the 'Systems Administrators' group is permitted to run anything.

3. Keep the default allow rules generated by Windows, but then add some 'Deny' rules which apply to end-users preventing them from accessing the specific files in the Windows and Program Files directories you're worried about. This is what we do in our environment (e.g. permit C:\Windows\*, but block access to cmd.exe, PowerShell.exe, regedit.exe, etc etc.) Keep in mind that a Deny rule always overrides an Allow rule.

If you haven't already, be sure to turn on AppLocker logging and look at the Windows Event Viewer as it should give information as to why a particular user has not been permitted to run something. Also check out the Test-AppLockerPolicy PowerShell command to simulate what's allowed and what's not for a particular user and executable (although, I'm not sure if it's available in Windows 7, you may need to upgrade your version of PowerShell).