Retrieve Active Directory Organization Units with Microsoft Graph APi

Copper Contributor

How can I retrieve the Active Directory organization units(OU) that have been synced to Azure using ADDS(Active Directory Domain Services)?


According to: User accounts, groups, service accounts and computer objects that you create under custom OUs will not be available in your Azure AD tenant. In other words, these objects will not show up using the Azure AD Graph API or in the Azure AD UI. These objects will only be available in your Azure AD Domain Services managed domain  


So, is this just a "not possible" using Graph Api? Or is there another way? Is it possible using a different Microsoft api other than Graph?

5 Replies



Hi, Kantu.


Active Directory is the on-premise directory service that has been around for ~ 25 years.


Azure Active Directory - now re-branded by the marketing whizzes as Entra ID - is the cloud directory service.


Organisational units are not synchronised from Active Directory to Azure Active Directory - it's not possible.


The organisational units you create manually within Azure AD DS are not related in any way to those that exist in Active Directory.






To retrieve Active Directory Organization Units (OUs) using Microsoft Graph API, you can use the Microsoft Graph API's beta version. Note that using beta features means they are subject to change and not recommended for production use. Ensure that you have the necessary permissions and follow the authentication process for your application.

Here's a general outline of the steps:

  1. Register Your Application:

    • Go to the Azure Portal.
    • Navigate to Azure Active Directory > App registrations.
    • Register a new application and note down the Application (client) ID and Directory (tenant) ID.
  2. Assign Permissions:

    • In the Azure portal, navigate to your registered application, and go to the "API permissions" section.
    • Add the required permissions. For reading OUs, you may need to add the "Directory.Read.All" permission.
  3. Acquire an Access Token:

    • Use the OAuth 2.0 authorization code flow or another suitable authentication flow to acquire an access token for your application.
  4. Make a Request to Microsoft Graph API:

    • Use the acquired access token to make a request to the Microsoft Graph API.



Maybe we can step back a bit, any reason behind syncing OU to AAD? This is not necessary by AAD management compared to AD


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


ServiceConstructCreation methodSynchronised?
Active DirectoryOrganisational unitManualNo
Azure Active Directory (Entra ID)Administrative unitManualNo
Azure AD Domain Services (Entra Domain Services)Organisational unitManualNo


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.