Blog Post

Core Infrastructure and Security Blog
4 MIN READ

Managing Hybrid Identities Across Portals

MichaelHildebrand's avatar
Sep 20, 2018

First published on TechNet on Aug 31, 2015

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…

On-premises

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

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:

 

Users

  • 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

     

 

Groups

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

 

Users

  • 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.

     

Groups

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

 

Users

  • 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

     

Groups

  • 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.

     

MSP MMC

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.

Cheers!

Hilde

Updated Feb 20, 2020
Version 3.0
No CommentsBe the first to comment