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