01-31-2020 06:47 AM
01-31-2020 06:47 AM
One of the AATP prerequisites is the SAM-R GPO.
The link above describes how the gpo should be configured.
However, the documentation is ambiguous on multiple aspects.
A note posted on this page
tells you that if you are configuring this GPO, you might break OAB (if you are running Exchange 2013/2016 in your environment).
There are some fixes proposed:
- unlink the gpo (that is required for AATP) and probably loose LMP
- configure the gpo to filter out domain controllers, and allow also exchange server groups.
- hardest one: implement policy in audit mode, identify the apps using AuthZ and then add the required accounts in the allowed list.
If you have other applications using AuthZ, those might stop working...
With the GPO enabled I can confirm it breaks building OAB in my lab.
I can also confirm that creating a GPO from a w2016 machine, and applying it to w2012 machines, the settings are there (checked with remote registry from a W2016 machine)
I can also confirm that not implementing the GPO, I still see some lateral movement paths built (at lease in the reports), but not for all the objects...
In the use case where you have windows 2012, 2012 r2, 2016, exchange 2016, and windows 10 clients in the environment, what is Microsoft's AATP product team recommendation to have LMP available without breaking anything?
02-02-2020 12:46 AM
Logically, solutions other the Azure ATP might require that GPO, hence, your LOB apps might break if another app enables it so we suggest that you identity and add all required accounts into that policy to avoid "breaking" things. This does take some effort but the lateral movement paths feature is a very important feature for Azure ATP (and about to get even bigger, stay tuned!)
Hope this helps
02-02-2020 11:44 AM
@mcliviu have you ever looked at the baseline security policies for Windows?
It specifies the following should be set for Windows clients and member servers
|Network access: Restrict clients allowed to make remote calls to SAM|
Domain Controllers are listed as blank. Which I think is required to allow a DC to work correctly.
I thought by default the remote SAM was open to Anon access? Or is that when the domain has gone through upgrades from early versions? So if it's not open, I would have thought you already had a GPO in place that was locking it down? If you're locking it down via GPO you should be able to add the AATP account to that GPO.
02-02-2020 11:45 PM
My understanding is that on the older versions of OS, everyone has read only access.
However, on the newer versions, and the OS patched in the list below, this GPO is required to allow SAM-R.
Windows 10, version 1607 and later
Windows 10, version 1511 with KB 4103198 installed
Windows 10, version 1507 with KB 4012606 installed
Windows 8.1 with KB 4102219 installed
Windows 7 with KB 4012218 installed
Windows Server 2016
Windows Server 2012 R2 withKB 4012219 installed
Windows Server 2012 with KB 4012220 installed
Windows Server 2008 R2 with KB 4012218 installed
Now, MS recommends to enable the GPO in audit mode first to identify the apps that might require access, in order to avoid breaking things...
The issue in my case, is that unlinking the GPO, still doesn't fix OAB, and I think there can be other issues as well.
I was expecting the AATP documentation to be very clear and specific, unfortunately, it's not the case...
In the prod env, SAM-R is built for some accounts, but not for others, therefore the guideline of enabling AATP SAM-R is a bit inconsistent...
02-03-2020 12:20 AM
Keep in mind that unlinking the GPO does not remove it's associated registry setting defined in https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network... and you have to remove it yourself using group policy preferences or other means (script?).
In regards to the documentation around that requirement, we will take your feedback under advisement.
02-03-2020 12:48 AM
In the documentation it says the fix is to unlink the GPO.
When the GPO is unlinked, the default settings should apply.
Clear the RestrictRemoteSAM registry entry or remove the policy.
The documentation states "or", not "and"
If that is applied to thousands of computers, manually removal it's not an option....