jmchristy
asked on
Applocker ignoring user security groups
My Applocker policy appears to be behaving incorrectly, and I need to know if this is the type of behavior I should expect with the way the policy is setup.
Running Windows 2008 R2, all Windows 7 Ultimate clients. Application Identity service enabled and started, and we have successfully used AppLocker for nearly 2 years now. The Executable rules are being enforced, Windows Installer set to Audit only, and Script rules are not configured. I never edit my policy right from GPO, I export it to my local desktop and edit it from my local security policy editor and then export/import back into my GPO.
I have a screenshot of a basic AppLocker policy that is not applying correctly in my mind. With this policy (which I rebuilt as a test), I experience the following results when trying to open a .EXE from this location.
%OSDRIVE%\USERS\USERNAME\A PPDATA\LOC AL\CITRIX\ LAUNCHER\C ITRIXONLIN ELAUNCHER. EXE
My path rules that are named All Files simply have an * for the path. The AppLocker PC group contains every PC in the organization except Administrative computers, with Exceptions for C:\Program Files (x86)\* and C:\Windows\Temp\*
If I change my Allow rules from the security group Domain Admin, to just a username account then it allows the user to launch GoToMeeting. Even though they are a member of the Domain Admin group.
What is the "catch all" for an administrative group to be able to install .EXE's using AppLocker?
applocker-policy.JPG
Running Windows 2008 R2, all Windows 7 Ultimate clients. Application Identity service enabled and started, and we have successfully used AppLocker for nearly 2 years now. The Executable rules are being enforced, Windows Installer set to Audit only, and Script rules are not configured. I never edit my policy right from GPO, I export it to my local desktop and edit it from my local security policy editor and then export/import back into my GPO.
I have a screenshot of a basic AppLocker policy that is not applying correctly in my mind. With this policy (which I rebuilt as a test), I experience the following results when trying to open a .EXE from this location.
%OSDRIVE%\USERS\USERNAME\A
The user account which is a member of the Domain Admin security group gets blocked by the AppLocker policy when trying to launch GoToMeeting.
The user that is a member of the AppLocker Group, can run GoToMeeting.
The Administrator can launch GoToMeeting.
The user that is a member of the AppLocker Group, can run GoToMeeting.
The Administrator can launch GoToMeeting.
My path rules that are named All Files simply have an * for the path. The AppLocker PC group contains every PC in the organization except Administrative computers, with Exceptions for C:\Program Files (x86)\* and C:\Windows\Temp\*
If I change my Allow rules from the security group Domain Admin, to just a username account then it allows the user to launch GoToMeeting. Even though they are a member of the Domain Admin group.
What is the "catch all" for an administrative group to be able to install .EXE's using AppLocker?
applocker-policy.JPG
ASKER
I considered that...but I prove that incorrect by modifying the Allow rule for Domain Admins and substituting the a security group for a user account. If I logon with that user account, I can launch GoToMeeting.
That rule is simply a path rule for *, and the Deny rule is still in place....and it works.
That rule is simply a path rule for *, and the Deny rule is still in place....and it works.
It should be easy to solve or at least say if it's malfunctioning, if we had the rules and all memberships listed. Your picture does not show what exceptions the deny rule has, for example and I am not sure what account is in what group.
ASKER
The first 3 rules are the default Executable AppLocker rules, that give full access to all files on the local system to Administrators, Program Files, and Windows Folder.
I did say what my exceptions were for that Deny rule.
C:\Program Files (x86)\*
C:\Windows\Temp\*
The Applocker PC security group has all non-admin computer accounts in the domain.
The Applocker Group security group has all non-admin user accounts in the domain.
Domain Admins security group has all administrative user accounts (4 users)
I'm testing this with my user account, which is part of the Domain Admin group.
If I modify the bottom rule, that is supposed to be applied to Domain Admins to just my user account then I am able to run GoToMeeting. IF I leave it as applying to Domain Admins, I get the blocked by AppLocker message.
I tested this with another user account that is a member of the Domain Admin group, and the same thing happens. I've also tried a different security group, and it gets blocked as well.
It's just bizarre that if I change it to a user account, that same rule, it works for that user.
I did say what my exceptions were for that Deny rule.
C:\Program Files (x86)\*
C:\Windows\Temp\*
The Applocker PC security group has all non-admin computer accounts in the domain.
The Applocker Group security group has all non-admin user accounts in the domain.
Domain Admins security group has all administrative user accounts (4 users)
I'm testing this with my user account, which is part of the Domain Admin group.
If I modify the bottom rule, that is supposed to be applied to Domain Admins to just my user account then I am able to run GoToMeeting. IF I leave it as applying to Domain Admins, I get the blocked by AppLocker message.
I tested this with another user account that is a member of the Domain Admin group, and the same thing happens. I've also tried a different security group, and it gets blocked as well.
It's just bizarre that if I change it to a user account, that same rule, it works for that user.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The work around for this, was to change my rule from Domain Admins to another security group that I created. I believe I stated earlier that it did not work, but I chose an incorrect group when I was testing.
So if you look at my All files rule that is applied to Domain Admins, changing that from Domain Admins to another security group did the trick.
Thanks for the help.
So if you look at my All files rule that is applied to Domain Admins, changing that from Domain Admins to another security group did the trick.
Thanks for the help.
ASKER
Helped point me in the right direction to find a solution...
I think it was not only a direction-pointer. The domain admin group is also stripped off its token by UAC, so users have to elevate in order to use it (and so does applocker) - if I remember correctly.
ASKER
You are correct, I found a few other posts on social.technet.microsoft.c om that speak to that.
http://social.technet.microsoft.com/Forums/windows/en-US/34a10cfe-d21b-45fc-8756-b5614eebd287/applocker-default-executable-allow-rule-for-administrators-doesnt-work?forum=w7itprosecurity
It's funny though that I never ran across that following Microsoft's TechNet article years ago for implementing AppLocker, and I still don't find a reference to it.
If someone else comes across where Microsoft states oh by the way, don't use the Domain Admin group (or any other built in group for that matter) in your rules unless you enjoy right clicking everything and selecting Run As Administrator....please post it here!
http://social.technet.microsoft.com/Forums/windows/en-US/34a10cfe-d21b-45fc-8756-b5614eebd287/applocker-default-executable-allow-rule-for-administrators-doesnt-work?forum=w7itprosecurity
It's funny though that I never ran across that following Microsoft's TechNet article years ago for implementing AppLocker, and I still don't find a reference to it.
If someone else comes across where Microsoft states oh by the way, don't use the Domain Admin group (or any other built in group for that matter) in your rules unless you enjoy right clicking everything and selecting Run As Administrator....please post it here!
Could it be that you ignored that?