Managing Hybrid Identities Across Portals



AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at (hosted at Please bear with us while we are still under construction!

We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either as you do today, or at our new site Please feel free to update your bookmarks accordingly!

Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.

If you have never visited the TechCommunity site, it can be found at On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.

NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at!

As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!


Greetings! Hilde here once again to bend your ear about hybrid identity.

Just between you and me, I can be a bit of a slow learner. Some people can process new information and ideas at the speed of light, as electricity lights up the synapses in their brain. They are able to swing those new ideas and concepts around into their own thought processes very quickly. Often, I'm not one of those people. It can take me a few tries before I make it up the Warped Wall in the mental American Ninja Warrior.

So it was for me with Active Directory back when it came out and so it is with Azure AD.

I'm also a visual person – I tend to think about things in circles, lines and arrows. A good day is a clean whiteboard with a new set of markers; Visio is one of my favorite Microsoft products.

To help continue growing our understanding of hybrid identity, in this post, I'll provide a fairly high-level discussion of the various UIs that lay over AD (and AAD) objects.

We all know AD is a directory service and AAD is the same type of thing, but what does that even mean?

Directory services, such as AD and AAD, are collections of objects and their attributes – like a phone book that has both the White Pages with info about people, as well as the Yellow Pages, with info about other entities (groups, computers, etc).

I think it is safe to say, we all know what on-prem AD looks like in terms of the ADUC – a given domain's objects (users, computers, groups, etc), likely sprinkled among OUs:


However, when talking about a hybrid Active Directory, things can be a little different.

Let's start with the on-prem side of hybrid…


For the internal AD, we have the following layout: 

  • ROOT.LAB AD forest –
    • An "empty root" – ROOT.LAB
    • A single child domain – CHILD.ROOT.LAB
  • CORP.LAB AD forest – with no trust between the ROOT.LAB AD
    • Consider this as a different business unit or perhaps an acquisition


From an AD object stand-point, we have the following (from the two AD forests):

  • Note the different OU structures, users and groups




On-line, we have the following setup:

  • An Azure subscription
  • An Office 365 subscription
  • An InTune subscription

Directory Synchronization

For directory synchronization, we have:

  • A single server on-prem, running Azure AD Connect – the latest and greatest directory sync tool from us, sync'ing certain containers and object types from both AD forests.
    • I have only implemented directory sync with password hash sync into my Azure AD directory
    • I have not implemented ADFS or Web App Proxy


    • CHILD.ROOT.LAB domain sync details:




    • CORP.LAB domain sync details:





On-premises … in the Cloud

Now that we have the background, let's take a look at how the various on-prem AD objects are represented in our on-line services…


Azure Active Directory

Here is what those AD objects from the two forests we're sync'ing look like in Azure AD:



  • Display name in Azure AD = display name from on-prem AD
  • User Name in AAD = a constructed value of on-prem logon name and cloud values
  • Note the 'SOURCED FROM' values – 'Local Active Directory' means on-prem AD




  • Name, description and memberships come over via dir sync
  • Note the 'SOURCED FROM' value where 'Local Active Directory' means on-prem

Office 365

Next, here they are in O365:



  • Display name in O365 = display name from on-prem AD
  • User Name in AAD = a constructed value of on-prem logon name and cloud values
  • Note the 'Status' values – 'Synced with Active Directory' means on-prem and 'In cloud' means, well, in the cloud. Thanks, captain obvious.



  • Name and memberships come over via dir sync
  • Note the 'Status' value where 'Synced with Active Directory' means from on-prem
  • Note the details for the selected group in the far-right box


Microsoft InTune

Next up, we see what those AD objects look like in our InTune Portal:



  • Again, the display name in InTune = display name from on-prem AD
  • User Name in InTune = a constructed value of on-prem logon name and cloud values

    Note the 'Status' values – 'Synced with Active Directory' means sync'd with on-prem



  • Display names for Groups come over via dir sync…


  • Note the "Details" dialog for the selected group – it lists the description from the on-prem 'master' group and the UI reminds you that in this case, the group can only be managed via on-prem tools.



  • Note the "Members" dialog for the selected group – it lists the available members and the current members.
  • Again, here the UI reminds you that in this case, the group can only be managed via on-prem tools.



And now, through the magic of MS Paint, for you old-school AD admins, I present our multi-forest AD objects as represented in Azure AD directory – but in an ADUC-like pretend UI:

So what's the point of all of this? My intent here is to help folks grasp the idea that on the back-end, there are just "objects with attributes."

Through various portals (as well as PowerShell, APIs, etc), we are able to access/view/manage those objects and their attributes. The various UIs are just different "lenses" viewing the same back-end directory service objects/attributes (whether that back end is on-prem, on-line or both).

The more time I spend working with hybrid identity concepts, the more sense it all makes.

I hope it helps you, too.