Effortless sync for Azure AD B2B users within AD Connect

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;

  1. Disable synchronisation – You should complete this before carrying out any work on AD connect
  2. Designate and populate an attribute which will identify your partner accounts. “ExtensionAttributes” within AD are a prime target here.
  3. Using the AD Connect Sync manager, ensure that you are importing your selected attribute.
  4. Using the AD Connect Sync Manager, enable “userType” within the Azure AD schema
Add source attribute to Azure AD Connector schema
Enabling UserType within the AAD 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"))

Our outbound transformation rule

And just like that, we have Azure AD Accounts, automatically marked as Guest Users!

Balon Greyjoy 
Barristan Selmy 
Benjen Stark 
Beric Dondarr.,. 
Bran Stark 
Brienne Of Tar... 
Brynden Tully 
BaIon.Greyjoy@lab.westall.co 
Barristan.selmy@lab.westall.co 
Benjen.stark@lab.westall.co 
Beric.Dondarrion@lab.westall.co 
Bran.Stark@lab.westall.co 
Brienneof.Tarth@lab.westall.co 
Brynden.Tully@lab.westall.co 
Guest 
Guest 
Member 
Guest 
Member 
Guest 
Guest

B2B and Member accounts copied from AD

9 Comments

  1. William S. says:

    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

    Like

  2. jameswestall says:

    Thanks William!

    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.

    Like

  3. Michael says:

    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 ?
    Thanks
    Michael

    Like

    1. jameswestall says:

      Hey Mate,

      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.

      Like

  4. David L. says:

    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!

    Like

    1. jameswestall says:

      Thanks David!

      You should be able to an OR statement to the expression language.

      Like

  5. Joshua Bines says:

    (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?
    https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-topologies#multiple-azure-ad-tenants

    Like

  6. Aengus says:

    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 🙂

    Like

  7. George D. says:

    in your example the guest account is still under the tenant domain, what happens in a real life example where the guest account needs to be the partner domain?

    Like

Leave a Comment