Everything says Applocker is supposed to work: Why doesn’t it

applockergroup-policywindows 7

I've setup a basic group policy consisting of the default Applocker rules. Per Microsoft's technet article on the subject, any files not explicitly allowed to run by the policy are supposed to be blocked from running. After deploying this policy and verifying it was being applied to the correct user using gpresult, I was still able to download and run an exe from the internet, an exe that was saved to the user profile's temp folder. It was at that point I did more googling, and saw that the App Identity service had to be running, and it wasn't: So, like any good admin, I started it, set it to automatic, and rebooted just in case. The policy still didn't work after restarting. Below is a screenshot of the current policy.

enter image description here

I added the deny rules explicitly because the default rules weren't working. I correctly applied the policy to the machine and verified that the rules are enforced (it says so in the screenshot). I used the Test-AppLockerPolicy cmdlet to verify that the rule is should be blocking the EXEs and MSIs from running, but it doesn't. Open to most suggestions, no matter how ludicrous they may sound.

Update

Forgot to add that I checked the event log for AppLocker during this whole fiasco, and it was blank. Not a single entry the entire time.

Best Answer

If your path block was not defined correctly then that would explain you situation.

For example if you were to use the %userprofile% environment variable. There are only a subset of the environment variables available through GPO/AppLocker and that's not one of them.

I have had success with the following path rule:

%osdrive%\users\*

Related Solutions

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

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:

Disable UAC (I've never tested this, not sure if it will work -- in our environment, we leave UAC on)
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.
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).

Security – how to disable run via search on Windows 10

I know it has been a long time since you posted this question, but thought I would let you know how we have dealt with this problem as it may still help you or somebody else.

We have disabled the search function using AppLocker and then placed shortcuts to commonly used applications (E.g. Office) on the desktop. We have also deployed a Start Menu layout which contains tiles for all of the common applications so Word, Excel etc all have a tile on the Start Menu. I know you didn't want to completely disable the search function, but maybe the Start Menu layout and desktop could be an acceptable compromise?

To configure AppLocker to block the search function I created the following rule:

Note: For those who have never used AppLocker, it can be found here COMPUTER Configuration\Policies\Windows Settings\Security Settings\Application Control Policies\AppLocker

Under Packaged app Rules I created a policy with the following settings. I chose to Allow all packages by default and create exceptions for anything I wanted to disable. You could just configure a Deny rule for the Cortana package instead.

Action: Allow
User: Everyone
Publisher: *
Package name: *
Package version: 0.0.0.0 And above

Exceptions:

Publisher: CN=Microsoft Windows, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Package name: Microsoft.Windows.Cortana
Package version: * And above

I then created another rule which allowed all packages with no exceptions and applied it to a security group which contains myself and my colleges (E.g. DOMAIN\IT Support) to stop it from preventing us access to everything my first rule blocks. (NOTE: I found that using the Administrators group didn't work well for this as you would need to elevate your account/run as administrator to use anything which was blocked. Using another group such as 'IT Support Staff' works much better).

To deploy the Star Menu layout I enabled the following policy:

USER Configuration\Policies\Administrative Templates\Start Menu and Taskbar\Start Layout File

I stored the layout file in an accessible share and pointed the policy at that. Here is an example of the layout file:

<LayoutModificationTemplate Version="1" xmlns="http://schemas.microsoft.com/Start/2014/LayoutModification">
  <LayoutOptions StartTileGroupCellWidth="6" />
  <DefaultLayoutOverride>
    <StartLayoutCollection>
      <defaultlayout:StartLayout GroupCellWidth="6" xmlns:defaultlayout="http://schemas.microsoft.com/Start/2014/FullDefaultLayout">
        <start:Group Name="Internet" xmlns:start="http://schemas.microsoft.com/Start/2014/StartLayout">
          <start:DesktopApplicationTile Size="2x2" Column="0" Row="0" DesktopApplicationID="Microsoft.Windows.Computer" />
          <start:DesktopApplicationTile Size="2x2" Column="2" Row="0" DesktopApplicationLinkPath="%ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Internet Explorer.lnk" />
          <start:DesktopApplicationTile Size="2x2" Column="4" Row="0" DesktopApplicationID="Chrome" />
          <start:DesktopApplicationTile Size="2x2" Column="0" Row="2" DesktopApplicationID="N:\" />
        </start:Group>
        <start:Group Name="Office" xmlns:start="http://schemas.microsoft.com/Start/2014/StartLayout">
          <start:DesktopApplicationTile Size="2x2" Column="0" Row="2" DesktopApplicationID="{6D809377-6AF0-444B-8957-A3773F02200E}\Microsoft Office\Office16\MSACCESS.EXE" />
          <start:DesktopApplicationTile Size="2x2" Column="4" Row="2" DesktopApplicationID="{6D809377-6AF0-444B-8957-A3773F02200E}\Microsoft Office\Office16\ONENOTE.EXE" />
          <start:DesktopApplicationTile Size="2x2" Column="2" Row="0" DesktopApplicationID="{6D809377-6AF0-444B-8957-A3773F02200E}\Microsoft Office\Office16\EXCEL.EXE" />
          <start:DesktopApplicationTile Size="2x2" Column="0" Row="0" DesktopApplicationID="{6D809377-6AF0-444B-8957-A3773F02200E}\Microsoft Office\Office16\WINWORD.EXE" />
          <start:DesktopApplicationTile Size="2x2" Column="4" Row="0" DesktopApplicationID="{6D809377-6AF0-444B-8957-A3773F02200E}\Microsoft Office\Office16\POWERPNT.EXE" />
          <start:DesktopApplicationTile Size="2x2" Column="2" Row="2" DesktopApplicationID="{6D809377-6AF0-444B-8957-A3773F02200E}\Microsoft Office\Office16\MSPUB.EXE" />
          <start:Tile Size="2x2" Column="0" Row="4" AppUserModelID="Microsoft.Office.Sway_8wekyb3d8bbwe!Microsoft.Sway" />
          <start:DesktopApplicationTile Size="2x2" Column="2" Row="4" DesktopApplicationID="{7C5A40EF-A0FB-4BFC-874A-C0F2E0B9FA8E}\Adobe\Acrobat 9.0\Acrobat\Acrobat.exe" />
        </start:Group>
      </defaultlayout:StartLayout>
    </StartLayoutCollection>
  </DefaultLayoutOverride>
</LayoutModificationTemplate>

You can create your own Start Menu layout file by exporting the layout from your own Start Menu. This can be done using this powershell command:

Export-StartLayout –path <path><file name>.xml

More info here: Customize and export Start layout (docs.microsoft.com)

Hope this helps somebody.

Best Answer

Related Solutions

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

Security – how to disable run via search on Windows 10

Related Topic