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 than not, this is simply “Create an AD Account” and call it a day. But what about Azure AD? It’s important for organisations to enable trusted parties here, without paying for it.

Using native “cloud only” B2B accounts lets organisations onboard contractors seamlessly. Scenarios do exist where you may 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 challenges 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. The end result being on-premise AD accounts, synchronised to Azure AD as guest users.

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]),"")=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 a simpler configuration;

  1. You still complete Steps 1 and 4 from above.
  2. Ensure that your users are properly organised into OU’s. For this example, I’m using a “Standard” and “Partner” OU structure.

3. Finally, 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 

B2B and Member accounts copied from AD

[mailpoet_form id="1"]

Other Recent Blogs

Microsoft Teams IP Phones and Intune Enrollment

Microsoft Teams provides a growing portfolio of devices that can be used as desk and conference room phones. These IP phones run on Android 8.x or 9.x and are required to be enrolled in Intune. By default, these devices are enrolled as personal devices, which is not ideal as users should not be able to enrol their own personal Android devices.

Read More »

Level 9, 360 Collins Street, 
Melbourne VIC 3000

Level 2, 24 Campbell St,
Sydney NSW 2000

200 Adelaide St,
Brisbane QLD 4000

191 St Georges Terrace
Perth WA 6000

Level 10, 41 Shortland Street

Part of

Arinco trades as Arinco (VIC) Pty Ltd and Arinco (NSW) Pty Ltd. © 2023 All Rights Reserved Arinco™ | Privacy Policy | Sustainability and Our Community
Arinco acknowledges the Traditional Owners of the land on which our offices are situated, and pay our respects to their Elders past, present and emerging.

Get started on the right path to cloud success today. Our Crew are standing by to answer your questions and get you up and running.