Forum Discussion
Retrieve Active Directory Organization Units with Microsoft Graph APi
Is the desire to simply see what OUs are being synced or do you need to specifically call them via an api? If you just need to see what OUs are synced you can do that from the the Entra/Azure AD Connect sync service that is responsible for synchronizing all of your Active Directory accounts to Entra/Azure/M365. You can do so either through the synchronization service where Entra/Azure AD Connect is installed (https://supertekboy.com/2017/12/31/change-organizational-units-synced-office-365/) or through the actual Entra/Azure AD Connect config.
You can also determine the OU from which a specific user is being synced from by looking at their "On-premises distinguished name" in the user properties in Entra ID
Just to re-iterate, Active Directory organisational unit objects are not synchronised to Azure Active Directory - not by AAD Connect or Cloud Sync.
This negates the first paragraph from the original question entirely. It's not a question of API access: the data simply doesn't exist.
What you have on a per service basis is:
| Service | Construct | Creation method | Synchronised? |
| Active Directory | Organisational unit | Manual | No |
| Azure Active Directory (Entra ID) | Administrative unit | Manual | No |
| Azure AD Domain Services (Entra Domain Services) | Organisational unit | Manual | No |
All three are entirely unrelated to each other.
The second paragraph from the original question is an entirely separate topic relating to objects created within the Azure AD DS tenant (i.e. not synchronised from Azure AD or indirectly from on-premise), where there's nothing to discuss, since that very same documentation makes it clear that anything created within the Azure AD DS service is localised and not synchronised back into Azure AD.
More information - including a picture showing the unidirectional synchronisation relationship from on-premise, to Azure AD, and then from Azure AD to Azure AD DS can be found below, but it's a very clear-cut scenario:
The actual benefit of organisational units in Azure AD DS is not aimed at users synchronised from Azure AD (and by extension, Active Directory) since they can only live within the AADC Users organisational unit contained within Azure AD DS. Rather, it benefits those objects created exclusively within the Azure AD DS service, which as explained above, do not live in Azure AD - or anywhere else.
You can automate against Azure AD DS using the existing ActiveDirectory PowerShell module, as you have to remember that Azure AD DS is a lightweight replacement for Active Directory, where the explicit intent is to allow on-premise environments to migrate to a cloud offering (thereby being able to fully decommission any remaining on-premise infrastructure) where "legacy" (yet critical, IMHO, based on the current wider application landscape) functionality - such as LDAP, NTLM, Kerberos, etc. - is still required.
That implicitly means you can leverage existing Active Directory tools (such as the ActiveDirectory PowerShell module, ADUC, GPMC, LDP, etc.)
onPremisesDistinguishedName does indeed exist within Azure AD - if you've kept your AAD Connect installation up-to-date, that is (it's one of the more "recent" additions). However, it occupies a space between "useless" and "wildly inefficient" given it cannot be used as a query filter. That means you cannot simply pull a list of objects the are housed below a specific organisational unit.
Speaking to the last paragraph - which is yet another distinct topic, last I knew, there is no Graph API for integrating with Azure AD DS (i.e. for managing the Azure AD DS-local objects), though, I'm happy to be proven wrong given how quickly things change.
Cheers,
Lain