Entra OU sync vs group filtering

EricBBB 

While explaining the repercussions of transitioning between in-scope and out-of-scope, I forgot to finish off with a statement about existing Azure AD users that are not matched to an on-premise account by AAD Connect.

The simple answer is that any existing Azure AD accounts that are not matched to an on-premise account will remain unchanged - they are not impacted by AAD Connect at all.

The only time you will have an impact is if AAD Connect joins an on-premise account to an Azure AD account at any stage.

Cheers,

Lain

EricBBB 

Hi, Eric.

Again, this comes back to the concept of "being in scope".

Let's hypothetically say you had planned a testing approach that looked like this:

1. Enable organisational unit "A" within AAD Connect for synchronisation to Azure AD;
2. Do some testing;
3. At a later date, disable organisational unit "A" within AAD Connect for synchronisation to Azure AD, while enabling organisational unit "B".

The problem with this hypothetical approach is that step 3 sees organisational unit "A" change from being in scope to being out of scope for synchronisation.

When an organisational unit falls out of scope, any objects beneath it that were joined between Active Directory and Azure Active Directory have that join broken, and breaking a join is what triggers the Azure AD partner object to be soft-deleted.

De-selecting an organisational unit does not allow any nested objects to remain active in Azure AD.

Similarly, if an in-scope child object residing beneath an in-scope Active Directory organisational unit is moved to a different organisational unit that is out of scope, that leads to the child object being taken out of scope, too.

The same principle of falling out of scope applies to group filtering (which also makes it an easy, low-impact way for testing the Azure deletion process prior to going live).

Using the following hypothetical process for group filtering - which is analogous to the one above for organisational units - will achieve the same Azure deletion process described prior:

1. User "A" is added to the AAD Connect filtering group;
2. Do some testing;
3. User "A" is removed from the AAD Connect filtering group.

Step 3 causes the previously in-scope user "A" to fall out of scope, leading to their Azure AD account being soft-deleted.

Furthermore, organisational unit scoping and group filtering are related.

When using group filtering, for an Active Directory object (user, computer, group) to be considered in-scope, the following must be satisfied:

1. The object resides beneath an enabled organisational unit; and
2. The object is a member of the AAD Connect filtering group.

As a Venn diagram, this looks like the following, where only the overlap bordered in red will be considered in-scope and eligible for synchronisation:

Users in enabled organisational units that are not in the filtering group, and group members not contained within an enabled organisational unit will not be considered in scope and will therefore not be synchronised.

This is important to remember in the context of soft deletion when making changes to either organisational units or the filtering group during testing.

Example

The following image shows the AAD Connect OU filtering screen, where you can see I'm only choosing two organisational units: Groups and Users.

This means only objects residing below either of these organisational units can be in-scope. If I add an object from the Computers organisational unit to the AAD Connect filtering group, it will not become in-scope as the Computers organisational unit is not enabled for synchronisation.

This next screen shows that I am using group filtering rather than allowing all objects from the selected organisational units to be considered in-scope.

Using group filtering is what allows for tight control during the testing phase, as additional users cannot accidentally slip in-scope through being moved in Active Directory into an enabled organisational unit (which is what would happen if the first option of Synchronise all users and devices was chosen).

In my case, I don't want everything from the Groups and Users organisational units to be in-scope, which is why I've used group filtering, as shown above. This allows me to have just a few deliberately-chosen users and groups from within those organisational units to synchronise to Azure AD.

After testing, you'd look to change this setting to use the first option, as shown below.

This now means that all objects contained below enabled organisational units (from the first screenshot) will be considered in-scope.

I have come across people who think this option includes everything contained in Active Directory, as if it somehow overrides the OU filtering screen. This is not what it means at all! It's just a by-product of the poor choice of words for the label.

Again, if you remember the Venn diagram from above, you'll remember that to be in scope, you must be within an enabled organisational unit, so this option simply means that everyone from within an enabled organisational unit will be in-scope.

Cheers,

Lain