Microsoft Entra Suite Tech Accelerator
Aug 14 2024, 07:00 AM - 09:30 AM (PDT)
Microsoft Tech Community
SOLVED

Entra OU sync vs group filtering

Copper Contributor

Hello,

Currently, we are utilising Microsoft 365 Business Standard with a free Entra ID, but we also have a trial version of M365 Business Premium that I would like to test for a couple of users and computers running Microsoft Windows.

For testing purposes, I would like to synchronise those users and devices from on-premise Active Directory to the Entra ID using Entra Connect Sync. I am contemplating which option I should choose:


The users (and devices) I want to synchronize are located in a specific Organizational Unit (OU) in Active Directory, but the users also have accounts in Entra ID and mailboxes in Exchange Online.
I know that Entra Connect Sync is not destructive, but I am unsure whether to choose "Sync all domains and OUs" during installation and then use filtering to select the security group to which the test users (and devices) belong or would it be better to directly choose only the specific OU containing the users and skip filtering? In the future, I plan to synchronize all users.


An additional question: if I choose only one OU, will it not clear the others, existing Entra ID users who are not members of the on-premise OU?

9 Replies
best response confirmed by EricBBB (Copper Contributor)
Solution

@EricBBB 

 

Hi, Eric.

 

There's no categorically right or wrong answer here, but since you've mentioned "testing", I'd recommend using the group filtering option.

 

You mentioned that AAD Connect is not destructive, and to some extent that is true. But it has to be noted that if through normal Active Directory administration, you scope someone out of synchronisation, they do get soft-deleted by AAD Connect, and under default conditions, that means they will be permanently deleted 30 days after the soft delete.

 

Once you're ready to exit your test phase, you can readily re-run the configuration wizard (or PowerShell, if you're comfortable with the command line) to no longer use group filtering.

 

Just make sure you're matching of the on-premise identities to the existing Azure AD identities is solid, or you might face some interesting outcomes if they end up mismatching. This is where group filtering can pay off, since it's harder to "accidentally" scope too many people in or out of synchronisation, and high importance identities - such as executives - can remain confidently immune from such accidents while you're testing.

 

There's nothing complicated about selecting the organisational units. Just select the ones (a tick will be displayed in their checkbox) you wish to make eligible for synchronisation in the tree. Any that you do not select - or later deselect - will not feature in the synchronisation (where deselection post synchronisation leads back to what I mentioned above about falling out of scope, soft- and permanent deletion).

 

Cheers,

Lain

@LainRobertson What are your thoughts on gradually synchronizing users to Entra ID by adding one OU at a time, for example: Sales OU today, Finance tomorrow? When returning to Entra Connect Sync, will the previously selected OUs remain visible, or does the process starts again from the beginning?

@EricBBB 

 

Once you exit your testing phase, the approach you've outlined is as fine as any - again, there's no right or wrong here, just what's suitable to you and your organisation.

 

Organisational units don't disappear from the selection tree in the configuration wizard. You can check and uncheck them as you see fit, though as I mentioned before, if you start with an organisational unit selected, then de-select it later on, the objects (user, computer and group objects) will fall out of scope, causing those objects to be soft-deleted and then permanently deleted (as mentioned earlier). So, you want to carefully plan around de-selecting organisational units.

 

But adding additional organisational units (i.e. putting a tick next to them) has no such issues and is quite safe - so long as your AD-to-Azure AD matching is robust.

 

If you happen to de-select an organisational unit, so long as you re-select it within the soft-delete period (30 days by default), everything will match up again and the soft-deleted objects (technically, this is just the user objects as computer and group objects synchronised from on-premise do not go through the soft deletion phase) will become visible once again.

 

If you start off using group filtering while testing and then proceed to remove group filtering, then as long as the objects contained within the filtering group remain in scope (i.e. are positioned in an organisational unit that is included for synchronisation), then they will not change at all.

 

Conversely, if you do not include the organisational unit(s) that contained the group members, then when you switch off group filtering, the members contained in organisational units not selected will fall out of scope and they will be soft-deleted from Azure (for users, that is; computers and groups will be permanently deleted).

 

Cheers,

Lain

Thank you, Lain, for sharing your knowledge!

Generally, I would test each scenario, but I was concerned that synchronizing just one test OU during the initial configuration might result in the loss of all my existing Entra users, leaving only those assigned the test OU :)

@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:

 

LainRobertson_0-1720655946821.png

 

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.

 

LainRobertson_1-1720656281820.png

 

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.

 

LainRobertson_2-1720656588111.png

 

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.

 

LainRobertson_3-1720656825121.png

 

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

@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

This explanation is comprehensive and exactly what I was seeking. Amazing, thank you Lain!
I have a thought I need to confirm. If I choose "Sync all domains and OUs" in Domain and OU filtering and then specify a particular security group containing my test users in the Filtering section, and subsequently, the on-premise AD's security group is deleted by mistake, the users within Entra would not be soft-deleted, correct? This is because they are still part of the enabled OU, according to the Venn diagram.

@EricBBB 

 

I'm actually not sure what happens in that situation, as really, that's an error condition, not a scope change.

 

If the filtering group has been deleted, I'd actually expect synchronisation to completely fail. This means the Venn diagram is irrelevant, and only becomes relevant again once the error has been resolved (by either restoring the group or changing the configuration in the AAD Connect wizard to point to a new group, or through choosing the "synchronise all users and devices" option).

 

In this scenario, nothing would be deleted from Azure AD, as no changes of any kind would be effected until the error has been resolved.

 

To mitigate the group deletion scenario, three quick options come to mind:

 

  1. Enable the "protect object from accidental deletion in Active Directory Users and Computers  -shown in Figure 1 below (under the hood, this results in a simple "deny" permission addition to the group);
  2. Explicitly add a "deny" permission to the group;
  3. Ensure the Active Directory Recycle Bin has been enabled (it's quite likely it's already enabled):
    1. Microsoft Entra Connect Sync: Enable AD recycle bin - Microsoft Entra ID | Microsoft Learn;
    2. Enable-ADOptionalFeature (ActiveDirectory) | Microsoft Learn;
    3. Restore-ADObject (ActiveDirectory) | Microsoft Learn.

 

You can mix and match these options - you don't have to choose just one.

 

LainRobertson_0-1720708134453.png

Figure 1: Protect object from accidental deletion.

 

Cheers,

Lain

1 best response

Accepted Solutions
best response confirmed by EricBBB (Copper Contributor)
Solution

@EricBBB 

 

Hi, Eric.

 

There's no categorically right or wrong answer here, but since you've mentioned "testing", I'd recommend using the group filtering option.

 

You mentioned that AAD Connect is not destructive, and to some extent that is true. But it has to be noted that if through normal Active Directory administration, you scope someone out of synchronisation, they do get soft-deleted by AAD Connect, and under default conditions, that means they will be permanently deleted 30 days after the soft delete.

 

Once you're ready to exit your test phase, you can readily re-run the configuration wizard (or PowerShell, if you're comfortable with the command line) to no longer use group filtering.

 

Just make sure you're matching of the on-premise identities to the existing Azure AD identities is solid, or you might face some interesting outcomes if they end up mismatching. This is where group filtering can pay off, since it's harder to "accidentally" scope too many people in or out of synchronisation, and high importance identities - such as executives - can remain confidently immune from such accidents while you're testing.

 

There's nothing complicated about selecting the organisational units. Just select the ones (a tick will be displayed in their checkbox) you wish to make eligible for synchronisation in the tree. Any that you do not select - or later deselect - will not feature in the synchronisation (where deselection post synchronisation leads back to what I mentioned above about falling out of scope, soft- and permanent deletion).

 

Cheers,

Lain

View solution in original post