Recently I have been working on a few identity projects where Azure AD B2B users have been a focus point. The majority of organisations have always had a solution or process for onboarding contractors and partners. More often then not, this is simply “Create an AD Account” and call it a day. But what about Azure AD? How do organisations enable trusted parties, without paying for it?
Using native “cloud only” B2B accounts lets organisations onboard contractors seamlessly, but what about scenarios where you want to control password policy? Or grant access to on-premise integrated solutions? In these scenarios, retaining the on-premise process can be a hard requirement. Most importantly, we need to solve all these questions without changes to existing business process
Thankfully, Microsoft has developed support for UserTypes within AD Connect. Using this functionality, administrators can configure inbound and outbound synchronisation within AD Connect, with the end result being on-premise AD mastered, guest accounts within Azure AD.
The Microsoft Process
Enabling this synchronisation according to the Microsoft documentation is a pretty straight-forward task;
- Disable synchronisation – You should complete this before carrying out any work on AD connect
- Designate and populate an attribute which will identify your partner accounts. “ExtensionAttributes” within AD are a prime target here.
- Using the AD Connect Sync manager, ensure that you are importing your selected attribute.
- Using the AD Connect Sync Manager, enable “userType” within the Azure AD schema
5. Create an import rule within the AD Connect rules editor, targeting your designated attribute. Use an expression rule like so to ensure the correct value is applied.
IIF(IsPresent([userPrincipalName]),IIF(CBool(InStr(LCase([userPrincipalName]),"@partners.fabrikam123.org")=0),"Member","Guest"),Error("UserPrincipalName is not present to determine UserType"))
6. Create an export rule moving your new attribute from the metaverse through to Azure AD
7. Enable synchronisation and validate your results.
A Better Way to mark B2B accounts
While the above method will most definitely work, it has a couple of drawbacks. Firstly, it relies on data entry. If the designated attribute is not set correctly, your users will not update. If you haven’t already got this data, you also need to apply it. More work. Secondly, this process can be achieved through a single sync rule and basic directory management. Less locations for our configuration to break.
To apply this simpler configuration, you still complete Steps 1 and 4 from above. Next, you ensure that your users are properly organised into OU’s. For this example, I’m using a “Standard” and “Partner” OU structure.
Finally, you create a single rule outbound from the AD Connect metaverse to Azure AD. As with most outbound rules, ensure you have an appropriate scope. In the below example we want all users, who are NOT mastered by Azure AD.
The critical part of your rule is the transformations. Because DistinguishedName (CN + OU) is imported to AD Connect by default, our rule can quickly filter on the OU which holds our users.
IIF(IsPresent([distinguishedName]),IIF(CBool(InStr(LCase([distinguishedName]),"ou=users - partners,dc=ad,dc=westall,dc=co")=0),"Member","Guest"),Error("distinguishedName is not present to determine UserType"))
And just like that, we have Azure AD Accounts, automatically marked as Guest Users!
Hello, Why do you need the extension attribute if the rule does not use it?
Also, why is member in front in your transform rule instead of just Guest? And do you need any join rules?
Thanks for a great article
I only mention the extension attribute to show the Microsoft way of doing things.
As for mentioning member first, my transform rule lets me ensure that memberType will be set to the right value when users exist outside of the appropriate OU.
Hello. Thanks for this nice article. I ‘ve tried to implement the effortless solution but unfortunately it doesn’t work. Rule applies to every user object and not only to my targeted OU. Any Idea ?
I would check the individual transformation rules that have been configured in the solution.
Just another note, was looking at someone elses config, potentially check for the OU being the correct case – It should be lower.
Excellent article! In using the OU method if I had 2 OUs that I wanted userType marked as guest, would I create a 2nd outbound flow rule or can you add the multiple OU options in the Expression statement? I’m looking for the cleanest/simplest way to do this. Thank you very much in advance!
You should be able to an OR statement to the expression language.
(Public preview) Each object multiple times in an Azure AD tenant
In theory we should be able to sync from the local forest and create them as guests for B2b account creation. Thoughts?
If we have OU filtering, and the partner OU is filtered out, will your rule still work, or is there a need to have the Partner OU included in the “inbound from on prem” connector … and if the OU must be included, then do we need to adjust other rules so the Partner users don’t sync as onmicrosoft.com accounts … hope that makes sense 🙂