Filtering OUs/Users

[rob_wood_8894]

Hello,

I am a newbie in the world of MDI and on the project i've just joined the end client has a requirement to protect a group of sensitive users housed in an OU in a child domain.  There is a transitive trust relationship between the parent and child domain.

Is it possible to filter this group of users from data uploads to the cloud service.  So far my thoughts are not applying read permission to this OU for the Service Account running the sensor?

Thanks for any help!

Rob

[#2]

No, while you might be able to block MDI from syncing those users directly from AD,
you can't stop it from capturing it's traffic, the sensor might still see those samNames, Display names etc, only it won't be able to fully resolve them to the AD entity. this will heart detection, but won't keep those entities completely anonymized.
That is the reason for this? what is the exact risk they are trying to overcome ?
How does it makes sense to limit detection on some users? won't that make them a goldmine for adversaries ?

[#3]

Its related to a particular country that doesn't allow its data to be transferred out of the country

[#4]

There is no official support for such scoping.
Having said that, if indeed the DCs in this country are not communicating in the network level with entities outside the country, then blocking the entities in AD and not installing sensors on those DCs in this country will likely (never tested or verified) cloak them (and any adversary that will operate in this country) , but that's a big "IF" on the no outside communication.

[#5]

We will be running a POC so it will be useful to see what happens without a sensor being installed on that Child Domain. Clearly it would be reducing the effectiveness of the product if a whole DC was excluded from monitoring so the client would have to mitigate that risk!

[#6]

Hi Eli,
Having done some extensive testing for the client i can report on the following observations:
1. The sensor service account was explicitly denied read on the OU and all descendant objects. This had to be enabled before configuring the service account in the portal.
2. None of the user objects are visible in the portal after connecting the sensor to AD. They can't be found by searching for them.
3. Using queries in Advanced hunting returns no data.
4. If you move a user from the protected OU to an unprotected OU the user object appears in the portal when searching after the sensor syncs.
5. All the usual events appear in AD event logs as expected (risk mitigated)

So it would appear that you can prevent visibility of data in the portal front end, however, the big question is has the data actually been collected by the sensor and is sitting in the backend database in Azure?? Not a lot of detail on this in the documentation on MDI. Can you possibly enlighten me please. I need to enlighten the customer as to what likely happened to the data in the 'protected' OU.

[#7]

You have prevented the AD sync, which means that as log as we never had permissions to read the entity, we won't sync it and it won't be "copied" to azure.
having said that, if the blocked entity will create actual network activity to the DC running the sensor, we will still see the activity, and might still see and capture account details that are in this activity (for example samName, upnName, possibly Display name) , and while we won't be able to resolve them to an AD entity, we will still have them in azure and display them.

MDI was not designed in the first place for this approach, and probably will never be as it does not make any sense security wise.

[#8]

Hi Eli,
We appreciate that this is an unsupported activity and that it is nonsensical from a security perspective, however, these activities have been a necessary evil as we likely won't get approval to install sensors without this exclusion.
As far as activities are concerned, i used a non protected account to log on to a network device and this was reported in Advanced hunting queries. I did the same activity with a protected account and this wasn't reported in the same query. I assume Advanced Hunting runs its queries against Azure?

[#9 · Accepted solution]

It does, but it has some latency.
Jsut want to make sure you understand that even if you can "make it work" "good enough" now,
no one promises you that it will stay like that over time, as it it not designed which such approach in mind. a future code change might change things.
I still think that there could be cases where such data will be displayed even if not resolved properly.

[#10]

Thanks Eli, that helps a lot. I can use the points you make as caveats in the document we are submitting to the client