Object management in a hybrid environment

When an organization is migrating various parts of its IT-landscape to Microsoft 365, administrators need to plan the management of directory objects. Unexpected challenges may appear regarding Object management in a hybrid environment.

Azure AD Connect

When you setup and configure Azure AD Connect, you enable the synchronization of objects to Entra ID. This enables your organization to use the same Active Directory objects in Azure and Microsoft 365.

Below table shows in which directory the object is created. And which directory must be used to manage and govern the object.

Active DirectoryEntra ID
Object is created in Active Directory and is not synchronized to Entra IDX Object is not present in Entra ID
Object is created in Active Directory and synchronized via Azure AD Connect to Entra IDX Object is present in Entra ID and can be used by Microsoft 365
Object is created in Entra IDObject is not present in Active Directory X
Objects are created with the same name in Active Directory and Entra ID without synchronization via Azure AD ConnectXX
Group and Computer object is created in Entra ID and synchronized via Azure AD Connect to Active DirectoryGroup and Computer object is present in Active DirectoryX

Source of authority

The on-premises version of the object is the source of authority. Meaning that every change applied to the on-premises object will be synchronized to the corresponding Entra ID object. This is a one-way sync and therefor you can’t edit (most) object attributes in Entra ID for synchronized objects.

The directory where the object is created determines the directory that must be used to manage the object.

If object is created with the same name in AD and Entra ID, they are in fact two separate objects. When Azure AD connect tries to synchronize the object in Active Directory to Entra ID it will result in an error. Therefor objects, groups included, that are recreated in Azure AD must be manged and governed in both directories and treated as individual objects.

Objects that are created directly in Microsoft 365 are cloud-only objects and are, by default, not synchronized back to the on-premises Active Directory. Azure AD Connect, however, has capabilities to synchronize computer objects and group objects back to Active Directory. This feature comes with some caveats.

Group Writeback

Group writeback allows you to write cloud groups back to your on-premises Active Directory by using Azure Active Directory Connect.

There are two versions of group writeback. The original version is in general availability and is limited to writing back Microsoft 365 groups to on-premises Active Directory as distribution groups.

The new, expanded version of group writeback is in public preview. It enables the following capabilities:

  • You can write back Microsoft 365 groups as distribution groups, security groups, or mail-enabled security groups.
  • You can write back Entra ID security groups as security groups.
  • All groups are written back with a group scope of Universal.
  • You can write back groups that have assigned and dynamic memberships.
  • You can configure directory settings to control whether newly created Microsoft 365 groups are written back by default.
  • Group nesting in Entra ID will be written back if both groups exist in Active Directory.
  • Written-back groups nested as members of on-premises Active Directory synchronised groups will be synchronised to Entra ID as nested.
  • Devices that are members of writeback-enabled groups in Entra ID will be written back as members of Active Directory. Entra ID-registered and Entra ID-joined devices require device writeback to be enabled for group membership to be written back.
  • You can configure the common name in an Active Directory group’s distinguished name to include the group’s display name when it’s written back.
  • You can use the Azure portal, Graph Explorer, and PowerShell to configure which Entra ID groups are written back.

More information can be found here: Azure AD Connect: Group writeback – Microsoft Entra | Microsoft Learn

Group objects

Each service or resource on-premises and within Azure / Microsoft 365 leverage groups to fulfil a particular purpose to a set of users that have a common denominator. This could be e.g., granting the same set of permissions to a resource so users are able to logon to an application, file share, printer, or server, or to be able to send an email to a set of users who are a member of the same distribution group.

Group object in AD

Active Directory knows two types of groups:

  • Distribution groups – Used to create email distribution lists.
  • Security groups – Used to assign permissions to shared resources.

Both group types can be synchronized to Entra ID.

Note: When you have a hybrid Exchange environment in place the synchronization of mail enabled security groups and distribution groups is recommended to ensure that these lists can be used by your online users.

E.g., if you recreate distribution groups in Exchange Online, Exchange won’t know the existence of these groups because Azure AD Connect doesn’t synchronize the object back to Active Directory. And if they share the same primary smtp address, depending on your mail flow settings, e-mail from on-premises users will only be send to the members of the on-premises distribution group, e-mail from an online user will be send to the members present in the online version of the distribution group and external e-mail to this group will end up being send to the on-premises members if the smtp MX record refers to your on-premises Exchange servers or to the online members if the MX record refers to Exchange Online Protection.

Group object in Entra ID

Entra ID also knows two types of groups:

  • Security groups – Used to manage access to shared resources.
  • Microsoft 365 groups – Provides collaboration opportunities by giving group members access to a shared mailbox, calendar, files, SharePoint sites, and more.

Device Writeback

Device Writeback is used in the following scenarios:

  • Enable Windows Hello for Business using hybrid certificate trust deployment.
  • Enable Conditional Access based on devices to ADFS (2012 R2 or higher) protected applications (relying party trusts).

Both scenarios are intended to increase security regarding access management.

So, there you have it, a detailed overview about object management in a hybrid environment. How do you manage your users, groups, and devices in your hybrid environment and which challenges do you have?


Posted

in

by

Tags:

Comments

Leave a Reply