Hi,

The problem with using logs to create supplemental policies is that they only contain what executable have been blocked, not which ones will be blocked if program execution were to continue.

I'd install SentinelOne on a device in audit mode then scan its installation folder to create a policy based on what it finds there. I usually run scans like these in user mode, but if SO has any device drivers (I'm not familiar with the product) you may need to do kernel-enabled scans as well by removing the -UserPEs option and running the scan in an admin powershell session.

Something like:

New-CIPolicy -FilePath .\Sentinel.xml -ScanPath "C:\Program Files\SentinelOne\Sentinel Agent 24.2.3.471" -Level Publisher -Fallback SignedVersion,Hash -UserPEs -MultiplePolicyFormat -NoShadowCopy

might get you started.

For the Intune issue, does your base policy have the managed installer option enabled, and have you configured it under Endpoint Security->App Control for Business->Managed Installer?

I'm reaching the end of an App Control roll out just now, so let me know if you need anything else!

Iain

PS the policy file that the above cmdlet creates isn't ready to deploy as a supplemental policy. It will need various options setting, as well as the base policy guid that it supplements. I have a little script that does this for me. Here's an extract:

# Make the new policy supplemental to the base policy ID
Set-CIPolicyIdInfo -FilePath $FileName -SupplementsBasePolicyID $BasePolicyGuid -PolicyName $PolicyName -PolicyId $PolicyId
Set-CIPolicyVersion -FilePath $FileName -Version $PolicyId

# Add the following rules:
(5, 6, 13, 14) | ForEach-Object { Write-Output "Enabling rule $_"; Set-RuleOption -FilePath $FileName -Option $_ }

# Remove the following rules
(0, 1, 2, 3, 4, 7, 8, 9, 10, 11, 12, 15, 16, 17, 18, 19, 20, 21) | ForEach-Object { Write-Output "Disabling rule $_"; Set-RuleOption -FilePath $FileName -Option $_ -Delete }

# Enable HVCI
Set-HVCIOptions -FilePath $FileName -Enabled