If you have a very richly filled local Active Directory, you might want to use portions of that data in your Microsoft tenant services, such as SharePoint. This data needs to be synced to Azure AD, obviously. However, looking at the data in various parts of the sync process, a number of variables are involved you may or may not be aware of. Let’s look at them one by one:
Local Active Directory
- AD attribute schema; the AD attribute schema plays, and has played a very important role in Active Directory throughout the years. Every AD DS edition (OS-based) has a specific schema version that holds and presents data at certain ways. While most critical fields in AD remain unchanged throughout schema updates, there are definate changes that need to be converted (through an AD schema update process) in order to retain or convert data in order to preserve access. Microsoft may rename a field name, or change its displayname in such a schema update. Nothing bad happens as long as your schema is updated nicely, but in any other way data might be lost. In the picture below you can see how Microsoft changed the LDAPDisplayname for the ‘country-code’ field and how it’s reflected in Powershell. While the AD schema clearly reads ‘Country-Code’, its displayname is actually ‘countryCode’. If you would query for ‘Country-Code’, it will not return the field data. In the picture below you can see this schema differentiation in effect:
So if you’re querying for user data using powershell and not get the result you’re after? Try looking into the AD Schema. This may seem like a small detail, but image building a custom sync process to Azure AD, knowing this little detail might save you a lot of time and hassle!
Since the AD schema is read-only and
you cannot alter it yourself, you can alter it yourself by putting the Schema in ‘updating mode’, but you shouldn’t do this is it is not supported to alter the schema manually! That being said, there isn’t much you can do here that will affect data being synced to Azure AD.
Keep in mind though, updating an AD schema may affect the way data is stored in AD, resulting in (minor) changes in data presentation in Azure AD.
Azure AD Connect
- Attribute mapping schemas; in Azure AD Connect all source data is stored in a central database, called the metaverse. The data that is imported is determined by the attribute selection in Azure AD Connect. Upon installing Azure AD Connect you’re given the option to determine what to sync, however, unless you’ve planned the deployment REALLY well, you’re unlikely to know in advance what attributes need to be synced in the long run. You can use the MIISClient.exe (a.k.a. Azure AD Connect Sync Tool) to configure this afterwards. You do this by opening the tool and navigating to the ‘Connectors’-tab, select the local Active Directory connector and clicking ‘Select Attributes’:
The default set of synced attributes is sufficient for most deployments, but if you want to extend this data, here’s the place to do it. As you can see, the AD Connect development team (formerly FIM / MIM) has had a very humanely perspective when using the term ‘person’, rather than ‘user’. To extend a persons attributes (person does feel a bit awkward to be honest.. ) you should be aware of the ‘show all’-checkbox. While opening the person attributes for selection, you will get a short list, showing all common attributes. However, if for some reason you want to include the field ‘carLicense’ you will need to click the ‘show all’-button to show all available user attributes and add whichever you need. Be aware that this lists a good portion of the AD schema for person, group and device, which aren’t grouped whatsoever, so a ‘bootFile’ (see picture above) does not have any relation to a person, but is used to point a booting device to a PXE server. To determine what fields in AD relate to a person, you can use adsiedit and connect to the Schema Naming Context. Then open the list of attributes, let it iterate through everything. You can’t tell for sure when it’s done, but it will start at A and end at, well you know.. Z and since we’re interested in USERS (this is AD, not AD Connect, get it?), just let it sit until all attributes are listed. Now you will see a distinction between two class types:
The attributeSchema is used to describe and define a specific attribute. What needs to be defined? Well, like the example above, a displayname might be different than the actual atttribute name, but also the syntax for the attribute. Some fields are text-based, others are numerical (or: integer) and others contain encoded values. But also: does the field only show if you enable AD Users and Computers to run in ‘Advanced Mode’, which in nature, shows more attributes than the default view.
The ClassSchema is used to group the attributeSchemas. You can open the CN=User classSchema and at the bottom-right, click the Filter button and deselect ‘Show only attributes that have values’. Now you’ll see all attributes that relate to users (or persons in AD Connect).
You can also check the default set of attributes here by navigating to the Microsoft Azure AD Connect attribute wiki: Azure AD Connect sync: Attributes synchronized to Azure Active Directory
Keep in mind that some attributes may be deprated, but still available in the AD Schema. Microsoft may not ever fill the attributes with actual data. So don’t go crazy and sync everything.
Cloud service data presentation
- Views; Once you’ve customized your attribute sync selection, there’s only one thing to do: start an on-demand sync! But wait, data does not show up, let’s sync again! Still nothing? Let’s do an initial sync and see if my custom fields show up. Still nothing huh? Wait, let’s do a Get-MSOLUser through PowerShell just to be sure. Let me guess, nothing huh? Let me explain why what’s happening:
There are a few ways of checking data that is in Azure AD, the first and most commonly used is the Azure (and Office) web portal. Here you can see the most common data that’s within Azure AD, such as displayname, a phone number and an e-mail address. However, as you can imagine, it’s undoable for Microsoft to present all user data in these portals. So, they’ve made a selection. If you sync additional user data to Azure AD, the way this is presented through the web interface isn’t changed, obviously, and therefore the custom data isn’t shown. You can of course differentiate between portal.office.com and older manage.windowsazure.com, both show user data and do vary slightly in shown data, but custom data will never show up here.
The next way to get user attribute data is to use PowerShell, the “Windows Azure Active Directory-module for Windows PowerShell“ to be precise. There you can go ahead and get some more data out of the user attributes. Actually, this shows far more data than the web interface, and depending on the enabled services for the particular user, even service-specific data might be shown:
Please note the | FL * portion, which shows far more data than leaving it out. So here you have yet another example of data presentation; you have to run some PowerShell cmdlets with particular parameters to get more data than their default outputs. But if you scroll back up a bit to the previous image, you see that the the attribute ‘carLicense’ isn’t returned in this query either, eventhough it’s a synced attribute.
So what’s happening here? Well, basically the same as in the web interface, but a little niftier than the web interface. PowerShell may return a bigger data set than the web interface, but don’t be mislead;
Even the PowerShell MSOL-cmdlets are built to return a limited set of attributes. This is intentionally and therefore by-design. Even if you select all attributes in Azure AD Connect, you won’t see all attributes using Get-MSOLUser in Powershell, let alone any custom attributes you might sync.
So, does this mean we can’t ever view our ‘non-default attribute sync set’? No, we just need a way to actually query Azure AD and enumerate all available fields for users. It may seem challenging, but trust me, the answer is really simple: Use Exchange Online PowerShell!
Even if you don’t use Exchange Online to host anything, you can still connect to your Azure AD using the Exchange Online PowerShell module.
You only need an elevated PowerShell session, so go ahead and open one up and follow the instructions as shown on the Microsoft article entitled “Connect to Exchange Online using remote PowerShell“. Next, you need to know a little bit about what’s happening; upon importing the remote PSSession on your local PowerShell console, you create a temporary copy of the Exchange PowerShell cmdlets you can use against your tenant. Obviously, if you’re not hosting any Exchange Online mailboxes, the number of useable cmdlets is limited, but you can still use the ‘Get-User’-cmdlet to query Azure AD through the Exchange Online API.
If you came till this part, you may see that data is available through the Exchange Online control panel as well… *hint hint*
The same goes for SharePoint. The take away here is that every cloud service discloses certain data to the end-user, this is a subset of all data in Azure AD. If you don’t see the data at first, it doesn’t mean the data isn’t there.
So there you have it, though Azure AD is a pretty straight-forward concept, it poses barriers you may not be aware of. Keep these in mind, especially when working with custom apps.
/ Office 365 Man out