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…
For the internal AD, we have the following layout:
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
For directory synchronization, we have:
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:
- Name, description and memberships come over via dir sync
- Note the 'SOURCED FROM' value where 'Local Active Directory' means on-prem
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.
Next up, we see what those AD objects look like in our InTune Portal:
- 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.