Another day – another bug #bugmaster (although a very small one)
If you use Azure AD Connect and manually upgrading to v1.1.649.0 and have a Generic LDAP MA in your configuration, after the upgrade you will get a “no-start-ma” error on Delta / Full Import or an “extension-dll-exception” on an export or when syncs start automatically after the upgrade.
Fix: Easy one – open the MA and click through each config page to refresh the MA manually.
Microsoft has acknowledged the bug and will fix it in the next release.
I am surprised as there aren’t that many MA extensions in AADConnect so how this was missed in their internal testing..
I’ve been playing recently on try to figure out how I can extend the Azure AD Schema for my tenant.
In my endeavor, I have come across (till now) two way to do it:
Using AADConnect and selecting directory extension to create the attribute in AzureAD in the form of “extension_{AppClientId}_{attributeName}“. This method works only if I have the custom attribute already in my on prem AD.
Using Graph API to create it directly in Azure AD
Will expand on point 2 in this post. In our scenario, we have some custom attributes which are stored in AD LDS. For security and other reasons we didn’t want those attributes to be in our AD.
Goal
Create custom attributes in Azure AD when they are not available to be done via AADConnect Interface
Solution
Whenever AADConnect is installed for your tenant, it creates an app called “Tenant Schema Extension App”. You can find it in Azure Portal AAD Blade.
As you would see that it has some custom attributes I have created. The “name” tag has the attribute name with is “extension_{AppClientId}_{attributeName}“.
To create a new attribute change the GET to POST and put in the following code to create a new attribute called “newAttribute”
GraphAPI: newAttribute
1
2
3
4
5
6
7
8
{
"name":"newAttribute",
"dataType":"String",
"targetObjects":[
"User"
]
}
Press GO and it will create the new attribute for you
There you go. newAttribute is created and your schema has been extended in Azure AD. You can simply delete that by changing the type to DELETE and putting the URL
https://graph.windows.net/myorganization/applications/<ObjectID of App>/extensionProperties/<ObjectID of attribute>
Limitations
Now here is the bummer. For my scenario I thought when I do then and “Refresh Schema” in AADConnect for AzureAD MA, it will be visible and then I can create custom rules and flows from AD LDS (via Generic LDAP MA). BUT you still can’t see it (tested as of v1.1.524.0) . Microsoft says that this is as per design at the moment. They are thinking of future enhancements or even integrating AD LDS as an option in GUI.
Moreover, if you had directory extension done even by using the GUI (using custom attributes from AD), and you do a refresh schema – it looses those as well saying
The Attribute ‘extension_<GUID>_customAttribute’ could not be located in the schema.
I call this a bug rather than design.
Well, in the end, I couldn’t get to reach my end goal (provisioning values from AD LDS to AzureAD via custom schema) but atleast got there half way and understood how to create custom Attributes in Azure AD via Graph API.
There is more cool stuff you can do with graphAPI and for the people who are hardcore programmers.. not me atm.. Hit up the links below..
We have loads of objects in our AD / Azure AD.. we believe doing regular Full Imports and Full Syncs for all the MA’s is a good way to make sure Sync engine is healthy.
Had recently visited #MSAUIGNITE 2017 in Gold Coast, Australia and SME’s there suggested Full Sync is not needed in environments unless there has been a connector change.. But I disagree and consider ADConnect as Microsoft Identity Manager (MIM / FIM) and by experience we have seen a good healthy sync engine we should do FI / FS for maintenance.
After doing some initial sync timings, found our FI from Azure took 9 hrs and FS took about 2 hrs. Likewise from AD FI took 1 hr and FS took 2 hrs.
Decided we wanted to schedule each FI and FS to make sure sync engine is all caught up out of business hours.
Assumptions
The MA is called “AzureAD”
Run Profile Name is called “Full Import”
Do the following on our ADConnect Sync Box
Create a powershell script with the following code and save it as “AzureFI.ps1” at a location say D:\SyncScript
Create a task scheduler and run as the same user which runs the sync engine.
Schedule it once a week / month as per your requirement. As per your initial tests, you can schedule it out of business hours say 10pm and by morning it is finished.
