- Dec 23, 2014
- 8,591
Finally, I found out the source of the different results. In my tests (a few months ago) I used the SmartAppControl template included in Windows\Schemas... This template looked like a full base policy, but in fact, it is not. Recently I closely analyzed the Microsoft documentation and found out that this template should be merged with another policy file included in:
$env:windir+"\CCM\DeviceGuard\MergedPolicy_ISG.xml"
The above policy file comes from paid software, so I used one of the default templates included in WDAC Wizard.
The SmartAppControl template must be edited - the option "Enabled:Conditional Windows Lockdown Policy" should be removed as Microsoft suggests.
After making the binary .cip file I deployed it in the \Active directory. But, the system did not start properly due to blocking some drivers. For testing, I whitelisted all drivers and finally, this WDAC policy worked well.
Anyway, this policy alone does not work like SAC - it works as any WDAC policy on Windows 10. When SAC policies are renamed (inactive, but SAC is ON), some executables are blocked by ISG, but are not blocked by SAC (tested on another snapshot). When SAC policies are active then the SAC allowlist overrides the WDAC ISG (that is good). Also, I did not manage to deploy working supplemental policies for SAC.
Conclusion.
For now, I cannot see the possibility to make SAC more usable. It is possible to use custom WDAC policies alongside SAC, but this cannot be used to whitelist something. The custom policies can only add more restrictions.
Post edited.
Last edited:
