At our last Windows Management User Group Netherlands meeting, we had the honor to have Sami Laiho, one of the world’s leading professionals in the Windows OS and Security flying over to the Netherlands and present for our user group. In his presentation titled: “Securing Windows in 2020 and forward”, Sami made us aware that by implementing some simple Applocker policies on our Modern Workplace and by making sure that the user working on the device has no admin rights, we can seriously improve our security. In his presentation Sami referred to a quote from Mikko Hyppönen (Chief Research Officer at F-Secure): “Make your security better than your neighbours”.
In this blogpost I will share my experience with implementing Applocker policy within my own tenant, and how I started to use these principles myself which eventually led by removing my account from the local administrator group.
Disclaimer: This blogpost provides a very simplistic way of enabling Applocker policies, in the real world there are some caveats which must be addressed when implementing Applocker. I will address those caveats later in this post as well.
If you start Windows 10 business editions for the first time in the Out of the Box (OOB) experience, you can choose to join the device to Azure Active Directory. If you do this, by default the account performing the join will be added to the local administrator group. If you don’t want your users to become a local administrator on the device, you need to leverage Windows Autopilot where you can define this behavior (whether or not the user gets added to the local administrator group) in a deployment profile.
Due to this default setup provided by Microsoft it’s quite normal nowadays that there are some modern workplace implementation where the users are a local administrator on their device. In my opinion and based on my experience, this is a risk which must be mitigated. This mitigation can be done in several ways, where each solutions has it’s pro’s and con’s. For example you can decide to implement Microsoft Defender Advanced Threat Protection (MDATP) or a 3rd party solution providing services based on a “assume breach” approach on all your devices where the users are local admin, so that you have a way to detect and respond to a breach in a short period.
Another option is to revoke the administrator rights of your users, and implement some basic Applocker policies to prevent unwanted software from executing on your users devices.
First let’s see how we can setup Applocker
The best way to setup your initial Applocker policies is by implementing the policies in a local group policy on a “standard” machine within your environment. With standard I mean a machine containing the default configuration when it comes to settings and applications installed.
You can open the Local Computer Policy by executing gpedit.msc and browse to Computer Configuration -> Windows Settings -> Security Settings -> Application Control Policies, where you will find the Applocker node.
One of the recommendations mentioned by Sami, is to add a code signing policy rule to the default Executable rules. This will allow user to run signed applications (portable apps for instance) which they downloaded from the Internet for example.
As an example we want to deny the start of the built-in Paint 3D application
With the default rulesets implemented, and your customizations added you can verify it’s behavior
The first thing you need to do is configure enforcement behaviour for the Applocker policies, we will start with auditing the behaviour of the implemented rules.
Once the Enforcement settings are configured, we need to start the “Application Identity” service. This service is set to “Manual” by default. Make sure that it’s set to Automatic and started
Now that we have a good feeling based on the Audit events, we can enforce the Applocker rules on our test system.
Once you have a good working Applocker configuration you can export that configuration into a .XML file which we need later on when creating our Configuration Profile in Intune.
You can export the configured Applocker policy by rightclicking on the Applocker node, and by choosing export. Provide a name and location for the XML file and click Save.
From that point forward you can open your XML file in your favorite XML editor
By using a Configuration Profile in Microsoft Intune we can deploy our exported Applocker policy to our Intune managed Modern workplaces.
The first thing we need to do in order to use the CSP is to modify the XML and split it into several parts. I suggest doing it like this and to store these XMLs near your documentation for future reference.
Split the XML by copying the parts between and for each section (AppX, Exe, MSI and Script). We will use the content of the XML files later when creating our Configuration profiles
We can create a Configuration Profile for Packaged Apps (AppX) by going to the Microsoft Endpoint Manager admin Center -> Devices -> Configuration Profiles. Click on “+ Create Profile” to create a new Configuration Profile
Provide the following details:
Name: Profile – W10 – Applocker – AppX (in my demo)
Description: Windows 10 – Applocker Policy – AppX
Platform: Windows 10 and later
Profile type: Custom
You can click on Add at the OMA-URI settings and provide the following details
Name: Applocker – AppX
Description: AppX configuration for Applocker
OMA-URI: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/I2401/StoreApps/Policy
Data Type: String
Note: Notice the I2401 part in the OMA-URI, make this a unique string for your environment. You can choose this for yourself.
Copy the contents of your XML file and make sure it gets displayed without any error.
Now create other Configurationprofiles for Exe, MSI and Script – make sure that you use the OMA-URI strings which correspond to the rules you want to configure.
Exe: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/I2401/EXE/Policy
MSI: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/I2401/MSI/Policy
Script: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/I2401/Script/Policy
Once the Configuration profiles are created, assign them to either your users of machines
Note: As mentioned in the comments, this is not necessary, the Application Identity Service will automatically start, see below for more information.
In order for the Applocker policies to work, we need to make sure that the Application Identity service is configured for automatic start and is running.
In order to accomplish this, we will create a simple PowerShell script which we will deploy to our clients. The script will set the Application Identity service startup type to automatic, and afterwards start the service.
set-service Appidsvc -Startuptype automatic
Once the configuration profiles and the PowerShell script are applied to your Modern workplace device you can see the following:
Let’s say that besides blocking the usage of Paint 3D as described above, you also want to disable the use of the built-in Mail app.
Just create a new XML with the configuration you want to apply, and make sure that you define a new unique OMA-URI string, in my case: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/I2402/StoreApps/Policy. If you don’t make the string unique you will have a policy conflict.
When you apply this policy, it will become active and also block the built-in Mail app from being executed.
Update August 2020: Based on a comment I received from Jon Abbott, we noticed a change in behaviour on how this scenario is processed. This has to do with the fact that Microsoft changed how Intune policies are processed, see the following article by Olivier Kieselbach for more context on that: Changed Intune Policy Processing Behavior on Windows 10
Due to this change in behaviour you now have to include the default rule set you created at all times, the concept of adding applications after that will still be valid though (as verified in my environment)
If you want to verify whether the AppLocker settings are active on the system to which you deployed the Configuration Profile you will notice that the AppLocker node in the Local Group Policy Editor is empty. This is because the CSP is not configured as a local policy. It would be really nice to have a similar way (visual) to check for the CSP settings.
When using the Get-ApplockerPolicy commandlet you don’t get any information either. This is due to the fact this commandlet also relies on policies being set and doesn’t see the CSP configuration. Something MS must fix IMHO.
One of the disadvantages of the current internet is that “old” information doesn’t get removed. When I started reseaching for this article I became quite confused when reading about Software Restriction Policies (SRP), Applocker, Device Guard and Windows Defender Application Control (WDAC). Here is what I found out:
It all started with Software Restriction Policies which Microsoft introduced with Windows XP. SRP was hard to implement and therefore Microsoft released a version 2 of the Software Restriction Policies with Windows 7 and renamed the feature to AppLocker. Software Restriction Policies have similarities but also work slidably different. For a detailed comparison of Software Restriction Policies versus Applocker check out this article: “Determine your application control objectives“. It’s even possible to combine Software Restriction Policies with Applocker as detailed in this article: “Use Software Restriction Policies and AppLocker policies“
When Windows 10 was released Microsoft introduced Device Guard which could use Virtualization Based Security (VBS) allowing for better protection. Device Guard was later (when Windows 1903 was released) rebranded to Windows Defender Application Protection (WDAC). WDAC allows you to generate and configure policies using PowerShell and deploy them via Intune for example, but GPO’s is also supported. One of the neat additions for WDAC is that you can use reputation of the app as determined by Microsoft’s Intelligent Security Graph in order to allow or deny apps to run.
Also here you can decide to use AppLocker and WDAC in combination, see “Choose when to use WDAC or AppLocker” for more information. If you want more in detail information, I want to suggest that you read the following article: Application whitelisting: Software Restriction Policies vs. AppLocker vs. Windows Defender Application Control, by Wolfgang Sommergut on 4Sysops.
Device Guard (which is confusing since it should be called WDAC), is part of the MDM Security Baseline for May 2019 and provides the following configured options by default. So if you have the Security Baseline configured and deployed you are already using it.
There are many known ways to circumvent AppLocker policies, especially if you only use the default rules created using the wizard.
Aaron Margosis has written a solution based on PowerShell scripts which can further restrict the AppLocker policies, his solution called Aaronlocker is widely used IT departments configuring AppLocker in Enterprise environments.
From the documentation: AaronLocker is designed to make the creation and maintenance of robust, strict, AppLocker-based whitelisting rules as easy and practical as possible. The entire solution involves a small number of PowerShell scripts. You can easily customize rules for your specific requirements with simple text-file edits. AaronLocker includes scripts that document AppLocker policies and capture event data into Excel workbooks that facilitate analysis and policy maintenance
My advice would be that once you have a clear understanding of what Applocker can do in your environment you further restrict the Applocker policies, where both the Aaronlocker but also the Ultimate Applocker Bypass List can come in handy. Keep in mind though that you must also monitor for changes and implement those in your environment.
Implementing the described AppLocker policies in your environment can be a first step in order to make your security slightly better than you neighbor. It allows you to get to know AppLocker and provides some security improvements in your environment. Once you get a grip on these security measures you might want to consider to further implement other Applocker polices and configure WDAC.
We will have to do better though, if we want to further strengthen our security step by step..
Based on some feedback via comments I received some information which is valuable to this article as well.
Will this run on Window 10 Pro and will I be able to enforce my Applocker settings?
Anwer is yes, I’ve tested my Intune managed device on the Windows 10 Pro version and I have the ability to block applications
Oliver Kieselbach pointed me to the fact that configuring the Microsoft Identity Service for autostart is not really necessary since Windows will automatically start the service if needed. As you can see in the screenshot on a non-configured device the service is started and running.
Rudy Ooms made me aware that there is a more handy way to check whether the policies have been downloaded to the client
Aaronlocker, by Aaron Margosis
Hi Kenneth, nice post and walk through. What I have seen during several AppLocker implementations with Intune is that you actually don’t have to re-configure the “Application Identity service”, it is started as soon as the policy gets applied and there was never an issue leaving it on Manual (triggered start). I implemented it in fairly large environment with >15k devices without any script usage and later issues or security issues. best,
Oliver
Hi Oliver, Great addition – Thanks. I just followed the documentation and it stated that I needed to enable the service, never even tested without setting the service using a script in the first place. 🙂 /Kenneth
Bennie says:HI Kenneth, I noticed you didn’t include the /Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/I2401/DLL/Policy in your tutorial. I added the DLL to mine as we use this heavily with our current AppLocker. I am not able to execute one drive or teams and event logs show nothing. Oddly if I turn on SRP logging I can see that the DLL’s under c:\windows\system32 are being blocked for OneDrive and other applications. Any ideas on why this would be occurring? SRP is disabled on my machine. I also tried setting the DLL section to audit only as a test with no luck. Thank you for doing this article this is one of the only ones I found that explains this the proper way. Thanks
Bennie
Hi Bennie, Thanks for visiting my blog and providing a comment. I didn’t include the DLL part since I consider this an “advanced” scenario, and my goal was to provide a simple solution which makes “your security slightly better than your neighbour (keep it simple)”. For your scenario I would suggest to use the AaronLocker solution (https://github.com/microsoft/AaronLocker/tree/master/AaronLocker) and see which rules it creates and apply those to your environment. Also make sure that you really are sure that you need the DLL rules, since MS makes the following remarks: “If you use DLL rules, a DLL allow rule has to be created for each DLL that is used by all of the allowed apps” and “When DLL rules are used, AppLocker must check each DLL that an app loads. Therefore, users may experience a reduction in performance if DLL rules are used.” – For me personally, this seems like a nightmare to manage. Hope this helps, also curious to know if you found a solution in the end. /Kenneth
Scavok says:Does this actually work for blocking MSIs on Win 10 Pro? Using Aaronlocker, or a simple admin-only allowed rule for MSIs, nothing is blocked and 0 events in the event viewer. Works fine for EXE’s and Appx’s. Been pounding my head on this for a week, and can only assume there’s some compatibility issue that’s impossible to troubleshoot due to lack of tools, or it’s not actually supported in the CSP.
Kenneth says:Hi Scavok, Thanks for visiting my blog – So, to make sure that the Applocker policies are recieved from Intune, could you check whether you have the c:\windows\system32\AppLocker\MDM folder available. If so please check whether you can click through and find an MSI folder in the folder structure containing a file called Policy? If so, you have received the policy from MDM. That should somehow reflect in a .policy file in your c:\windows\system32\AppLocker folder, while not readable, if you open the file with notepad, you might make some sense of which .policy file is for .msi usage If this is the working as expected, I assume you have an unsigned .MSI file which you use to test right? if not please do so, run it as a “normal user” since the default rule allows all .msi’s for admins and see if you get some logging. Sorry for not having an answer right away, but hopefully we can work this out together somehow. Regards, Kenneth
scavok says:Hi Kenneth, Thank you for the reply. I am receiving the policy – I can view the Policy files for the configuration buried in that folder and they are deploying correctly. When I open the Policy file with notepad, it’s readable as the same xml file that I uploaded. I just tested it again with the policy enabled, and it did work with blocking MSIs successfully with a classic error popup saying “The system administrator has set policies to prevent this installation”. However, it is still not logging under Applications and Services Logs/Microsoft/Windows/AppLocker/MSI and Script. After digging around, I found it is being logged under Windows Logs/Application like it’s using SRP rather than AppLocker for MSI files. Doing further research on SRPs, it appears they do not have an Audit mode, so I assume there’s no way to effectively use AuditOnly policies with MSIs? Same thing with Scripts. They are effectively being blocked, but I can’t find an event log anywhere that it’s being done. Is this the same way your setup behaves?
Kenneth says:Hi Scavok, Sorry if I ask obvious questions, but if you look into the policy file, what is the enforcementmode setting for Script and MSI? Is it set to “NotConfigured” ? or “Enforced ? So I did some follow up checking, on a device where I initially configured my Applocker policy (so no configuration via Intune/CSP) I have logging for MSI and Script in the eventlog. On a device where the Applocker policy is configured via CSP I don’t have logging in the Event Viewer either. Did check if logging was enabled, which is.. so it seems that if you deploy the AppLocker policy via CSP, you don’t have MSI and Script logging.. Application logging is working as expected though.. Very strange issue.. perhaps it’s worth to create a support call on this? From the documentation I also found an interesting statement: “AppLocker is unable to control processes running under the system account on any operating system.” (see: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview) – to my knowledge .MSI files when running are running under the local system account, which might explain why you don’t see something blocked on that part. To be honest, my blogpost was initially on some simple AppLocker policies which you can implement to make your security better than your neighbour, this is a more advanced scenario.. Learning a lot here though 🙂
Andrew Kovacs says:It is set to Enabled, and it is working now, it’s just the logging and auditing that doesn’t seem to be supported. On paper it looked pretty straightforward, but yeah nothing can ever be too easy 🙂 I really appreciate the confirmation that I wasn’t going crazy, and of course the original instructions! I will open a support ticket and let you know what they say. My initial thought is that it is almost certainly an intentional design decision, and the CSP, which also includes CodeIntegrity (WDAC), is a frankenstein on the endpoint of using SRP, AppLocker, and maybe WDAC capabilities to implement the application controls. That seems to me to make the global body of hardening knowledge on any one of these kind of pointless, e.g. how applicable is the Ultimate AppLocker ByPass List and Aaronlocker’s hardening efforts to this combined implementation?
Dan Padgett says:Hi Mate, I wanted to deploy my policy in Audit mode to a number of machines. The resulting policies in C:\windows\system32\AppLocker\MDM\…..\Native\EXE show the following “” yet the applications i have chosen to block actually block and are not listed as ‘would have been blocked’ in the eventvwr, which is what i see when developing these policies locally on a reference machine. Is audit mode supported by the CSP?
Jon Abbott says:Adding extra Applocker rules is easy: Are you sure? I’ve tried adding application specific rules via separate Intune profiles and they do not get merged into one rule-set. AppLocker appears to use the last rule-set it sees. In your example above that could break windows as it doesn’t contain the default rules. I’m not aware of any Microsoft documentation that covers how to use merged rule-sets with Intune. I’d go so far to say that the Intune/CSP implementation do not appear to be as feature rich as the GPO implementation as you also can’t use Azure AD groups to assign rules in a monolithic config.
Kenneth says:Hi Jon, Thanks for your comment.. let me re-verify my setup.. i’ll hope to get back to you soon. Regards, Kenneth
Kenneth says:Jon, I did some testing and indeed found some changed behaviour on this subject. This most probably has to do with the changes in Intune Policy processing (described by Olivier Kieselbach here). What I found out, is that you must now include the Default rule sets at all times, while you can still have differences in the policy. In my environment I tested this with AppX rules based on the blogpost. Situation I found with the settings in my (original) blogpost applied: I couldn’t start any AppX applications anymore, not even the store Testing: After removing the “extra” Configuration Profile which blocked the Built-in mail app, I noticed it started working again. I then modified the “extra” Configuration Profile to also include the default rule set (Allows members of the Everyone group to run packaged apps that are signed) and the concept started working again. I even added an extra Configuration Profile blocking another AppX application (Camera) to verify and as long as I include the default rule set, the concept of adding extra applications keeps working. Thanks for pointing me to this changed behaviour, I will update my blogpost to make sure that this is reflected. Regards, Kenneth
Jon Abbott says: Thanks for testing and confirming the behaviour I’m seeing. Dan Padgett says:A couple of comments. 1. Might be worth removing the step in this post relating to starting the appid service as it is not needed. 2. instead of creating separate rule sets for additional policies, why not just change the already defined policy. E.g. if you deploy the default set of appx rules and want to now block an app, why not just update the existing XML? 3. I run the above config with a baseline for all users, with an exception group on the deployment (user group) for those users who i need a more restrictive policy. I can switch users between groups and the policies apply without issue. Occasionally i do see “AppID policy conversion failed. Status Access is denied..” but then it seems to fix itself immediately
Kenneth says:Hi Dan, Thanks for your comments, highly appreciated. 1. Good idea, I’ve updated the article to reflect that (even though I mentioned it later already)
2. That is also an option, I just wanted to prove that you can different settings applied, and that you can mix and match within your organization
3. I really like the concept of applying a baseline to all users and work with exceptions, using that for more and more solutions in my daily work. Authorizing users via group membership so that the receive basic security settings is not the way to go, security must be default Regards, Kenneth
Regards point 2. AppLocker doesn’t support AzureAD groups, only local groups, so it’s currently not possible to have rules in a monolithic policy that apply to groups of Azure users. AppLocker also doesn’t support merged rules via Intune profile. Currently there is no way to implement per-app/per-user rules other than to duplicate the whole policy and assign the Intune profiles to user groups.
Kenneth says:Hi Jon, Again, merged rules should work as long as you include the Default rule set (see my earlier comment), I’ve successfully tested this in my environment. I do agree with Dan though that if you have many different use cases in your environment this is hard to maintain and manage. Indeed, it would be nice to have support within the XML files for including Azure AD groups, so that you can built one XML and make distinct on Azure AD group within. /Kenneth
Dan Padgett says:For point 3 i am referring to having two separate policies. Baseline – assigned to the all users group – all users get this by default, this policy has an exclusion for an ‘enhanced security group’ of users. Baseline+Extra – assigned to the ‘enhanced security group’ of users. This works for me as I only have two use cases to cover, however this method would not be useful in a large org with a lot of different use cases (that is when support for AAD groups would be welcomed)
Philip Harrison says:FWIW my experience applying more than one AppLocker policy of the same type (for example two EXE policies) to a single device with InTune is that it does not work as properly. I am using the default rules (allow all admins to run EXEs etc) and then some publisher allow rules for various other applications I want users to be able to run. I have the default rules included in both XML files, but one file might allow GoToMeeting while the other allows Putty. When you apply both these policies to a single device the default rules work as expected, but neither Putty nor GoToMeeting are allowed. Put them all in a single XML file and everything behaves as expected. I wonder is the experience you observed because you’re using blacklists? Either way, multiple policies to a single device does not currently work properly.
Kenneth says:Haven’t test this with .EXE indeed, my tests where with .APPX policies where it works.. If time permits I will do the same for .EXE and see if I can reproduce your scenario. Thanks for reaching out Philip. Regards, Kenneth
Finn W says:This is great thanks for the detailed step-by-step.
Apologies if I missed it, but how would you remove the policy if you then decided to allow an app.
1. Allow it for one specific user
2. Allow it now for everyone.
Hi Kenneth, Thank you for your nice work and time creating this post. Currently our users are bothered by the pop-up, your administrator have blocked this application. We would like that the pop-up doesn’t show up for them, any advise on how to do so ?
I’m not interested in transforming the pop-up or allowing the app, I want to keep the app blocked but I don’t want the user to see it. Kind regards,
Etienne
Hello Kenneth,
Thank you for you very instructive post, making me deal with applocker and intune easily.
But as it works like a charm for EXE files, impossible to make it work for scripts… it has absolutely no effect on it.
I read on other sites that applocker + intune + scripts is bloated, have you or someone here any experience on that ?
many thanks again
Hi Guillaume, Thanks for your comment – To be honest, I have no in-depth experience with scripts in combination with MEM/Intune Applocker policies. Regards,
Kenneth
Has anyone tried to put Azure AD Group SIDs into the Applocker XML policy, and does it work? I can get Applocker to recognize rules that have SIDs from local Windows groups like the Administrators group, but if I add a SID for an Azure AD group to an AppLocker rule, the AppLocker CSP doesn’t seem to honor it. For example, I might want a group in Azure AD to be allowed run all exe’s or appx’s as an override, but not be in the local Administrators group. Doing the same via Group Policy and an AD group is quite easy.
Matt says:Have you had any luck with this? I’m seeing same thing. Trying to use Azure AD Group SID for my “All Students” group to restrict K12 students on computer lab machines. Policy downloads to System32\AppLocker\MDM and everything, but no restrictions happening. No work arounds coming to mind either
Shifty says:Anyone know if there is a way yet to apply additional policies directly to Azure AD users and/or Groups yet? Spent the last hour searching and pretty much just found the same people on this thread asking around other websites, with no real answers. We’re hoping to implement AppLocker in the coming months, but have a very complex and large org which will require a lot of unique policies for groups of users. Ideally I don’t want to have to create a “master” baseline policy, clone that, apply custom policies to it and apply to each group of users, meaning any time we update the baseline I now have to update dozens or hundreds of other policies.
Valen says:Probably a bit late but others might see this. I haven’t tested it but you can assign AD users to local groups. I use it to give techs local admin access to devices while keeping MFA and such.
Perhaps you can leverage that and create local security groups to mirror your AD groups, you wouldn’t need to assign users to them on the local machines or anything just create the groups locally. Assign the Azure group to the local group and let it go.
Presumably some kind of moderately fancy powershell could be used to automate the sync of local groups to azure groups?
It’s a crappy AF workaround to be sure but still. WDAC can’t do user based controls at all yet.
I’m trying to implement WDAC and want to define Intune as a managed installer. For that Microsoft states that I have to define this in AppLocker xml. Since I have to create separate rules for EXE, MSI, Script etc. do I have to define the managed installer in every separate AppLocker policy or only in the EXE policy?
Valen says:WDAC is a seperate beast to applocker, except in this part.
After much searching I found how to create the XML then the command you need to run to get windows to use it.
Be aware that this tattoos itself into windows. Once you have set a trusted installer policy there is no way to remove it other than formatting that I have found and I tried for days to do it. The advice is to install a blank policy which *kinda* works but it’s still there and running and when you remove the policy it just means almost everything fails the policy check. I used a spreadsheet to generate this file that I deployed as a powershell script as you need to manually run the applocker merge. Being lazy I didn’t feel like making a win32app to ship the XML and the ps1 separately =================== Remove-Item “$env:TEMP\applocker_trusted_installer.xml” -ErrorAction Ignore Add-Content “$env:TEMP\applocker_trusted_installer.xml” “”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ”
Add-Content “$env:TEMP\applocker_trusted_installer.xml” ” ” Set-AppLockerPolicy -XmlPolicy “$env:TEMP\applocker_trusted_installer.xml” -Merge -ErrorAction SilentlyContinue
appidtel.exe start [-mionly]
Remove-Item “$env:TEMP\applocker_trusted_installer.xml” -ErrorAction Ignore
This is the script I use to separate the different XML sections. Makes it quicker to update and less error prone. $TypeList = “Exe”, “Msi”, “Script”, “Dll”, “Appx”
$CurDir = $PSScriptRoot
# Path to xml file
$Path = $CurDir + “\AppLocker.xml”
foreach ($t in $TypeList) # load xml file each time, since we are changing it
$xml = New-Object -TypeName XML
$xml.Load($Path)
foreach ($r in $TypeList) #Remove node if not $t
if($r -ne $t) #xpath query for section to be removed
$xpath = “/AppLockerPolicy/RuleCollection[@Type='” + $r + “‘]”
$item = Select-XML -Xml $xml -XPath $xpath
$null = $item.Node.ParentNode.RemoveChild($item.node)
>
> #Save result
$NewPath = $CurDir + “\AppLocker – ” + $t + “.xml”
$xml.Save($NewPath)
$xml = $null
>
I get errors with that script You cannot call a method on a null-valued expression.
At line:16 char:1
+ $null = $item.Node.ParentNode.RemoveChild($item.node)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvokeMethodOnNull
Based on current security guidance we attempted to use AppLocker to provide additional security to our clients (part of the Essentials 8 Level 4 standards), but it was an impossible task. Just enabling it on Windows 11 build 22621.2861 renders the Start Menu unusable (you can click the Start Button but it does not load). I also find that the new Outlook and Teams can install into %localappdata%\Microsoft\WindowsApps. There is no way to allow these to run that I can find. Even if I add the full path to the folder containing olk.exe it is still blocked. If you did get this running and roll it out successfully, with all the changes that occur over time it is 100% likely that something will break and cause major issues at some stage in the future, making it an unusable product in my opinion. And if you relax things to make it work then you may as well not be using it.
Kenneth says:Hi Simon, Sorry for my late reply I don’t recognize the behavior that your are describing, and my setup is currently running on thousands of devices already. I’ve chosen this setup for a reason, because it will allow all signed applications, and therefore has minimal impact if you are running normal applications. It becomes challenging if you have to support “badly configured” applications though, f.e. applications which are not signed, or install in non-standard applications. But this is more incidental than a daily issue in my working environments. /Kenneth
This site uses Akismet to reduce spam. Learn how your comment data is processed.
