Many enterprise organizations I have worked with has Hybrid Identity infrastructure in place and external partner accounts are managed at on-premises Active Directory, just like old days. Naturally, when organizations are using cloud services more and more there is a growing trend where organizations manages partner accounts only in cloud which is another option to manage partner accounts.

Organizations whose apps are currently at on-premises and are planning to move/migrate applications to the cloud might wonder what to do with partner accounts, how to grant access to the applications for partners when apps are moved to the cloud?

There are different ways to solve the problem with partner accounts and in general  options are:

  • Grant B2B users in Azure AD access to cloud and on-premises applications
  • Grant locally managed partner accounts access to cloud resources and on-premises resources

From guidance below you can find instructions how to achieve situation where partner account is managed at on-premises and is using same identity to sign-in to on-premises and AAD resources. Such a scenario can be achieved with custom rules on AAD Connect.

What is needed to for this scenario, in a nutshell:

Identify unique attribute for UserType. First thing to is to decide which attribute will be unique during for external collaborators? Two common approach (docs.microsoft.com):

  • Identify an unused on-premises Active Directory attribute (for example, extensionAttribute1) to use as the source attribute.
  • Alternatively, derive the value for UserType attribute from other properties. For example,  synchronize all users as Guest if their on-premises Active Directory UserPrincipalName attribute ends with the domain @partners.company.com.

Configure Azure AD Connect to sync users to the cloud

  • When unique attribute is identified,  Azure AD Connect is configured to sync these users to the cloud as Azure AD B2B users (that is, users with UserType = Guest). From an authorization point of view, these users are indistinguishable from B2B users created through the Azure AD B2B collaboration invitation process.

In my test environment I’m using the latter one which contains following tasks (all users with @partners.feta.fi UserPrincipalName will be synced to AAD):

  • Disable the sync scheduler and verify there is no synchronization in progress
  • Add the source attribute to the on-premises AD Connector schema
  • Add the UserType to the Azure AD Connector schema
  • Create an inbound synchronization rule to flow the attribute value from on-premises Active Directory
  • Create an outbound synchronization rule to flow the attribute value to Azure AD
  • Run a full synchronization cycle
  • Enable the sync scheduler
  1. Disable the sync scheduler
  • Set-ADSyncScheduler -SyncCycleEnable $false

2. Add the source attribute to the on-premises AD Connector schema

By default all attributes are not in AAD Connect schema. If attribute you have chosen is missing from scope it needs to be added to sync scope. In my scenario it’s already in scope (UserPrincipalName)

 

3. Add UserType to the Azure AD Connector schema

UserType is not enabled by default for synchronization because there isn’t corresponding attribute in on-premises Active Directory. It needs to be manually enabled and AAD Connect version needs to be 1.1.524.0 and later to support it.

 

4. Create an inbound synchronization rule

Created rule with following parameters

Connected System: feta.fi

Name: In from AD – User UserType

Connected System Object Type: User

Metaverse Object Type: person

Link Type: Join

Precedence: 50 (1–99 is reserved for custom sync rules. Do not pick a value that is used by another synchronization rule, if you do in saving phase you are receiving and error).

6

Scoping filter: adminDescription – NOTSTARTSWITH – User_

 

Transformation: Expression – userType – IIF(IsPresent([userPrincipalName]),IIF(CBool(InStr(LCase([userPrincipalName]),”@partners.feta.fi”)=0),”Member”,”Guest”),Error(“UserPrincipalName is not present to determine UserType”))

 

5. Create an outbound synchronization to Azure AD

Created rule with following parameters:

Name: In from AD – User UserType

Connected System: fetanet.onmicrosoft.com – AAD (Azure AD Connector)

Connected System Object Type: User

Metaverse Object Type: person

Link Type: Join

Precedence: 51

10.PNG

 

Scoping filter:

  • sourceObjectType – EQUAL – User
  • cloudMastered – NOTEQUAL – True

Transformations:

  • Direct – userType – userType – Update

 

6. Run a full import, full synchronization and export cycles

When rule has been configured Full Import needs to be run to both connectors

  • On-premise AD – feta.fi
  • Azure AD connector – fetanet.onmicrosoft.com – AAD

After full imports are ran verify synchronization rule changes from connector space for an existing user object. Most convenient way to do this is preview tool from AAD Connect where I can see that UserType has been populated to this user. How to preview changes

Verify and run Full synchronizations

When changes at individual object has been verified

  • Run Full synchronization to on-premises AD connector
  • Verify pending exports from Azure AD connector using search connector space mechanism with Add, modify and Delete values (picture below).
  • If everything looks good, changes are expected and we are ready to go

Run export to Azure AD Connector

  • When finished verify that your accounts are visible as Guest on the cloud

7. Re-enable the sync schedule

Remember to enable sync Schedule after changes has been verified with command:  Set-ADSyncScheduler -SyncCycleEnabled $true

 

Conclusion

If your organization is managing partner accounts at on-premises and you want those partners to have ability to use same credentials to access cloud resources it can be achieved with syncing partners as Azure AD B2B users (UserType=Guest). Keep in mind that Member and Guest user types doesn’t have permission difference. As Microsoft states:

“The UserType has no relation to how the user signs in, the directory role of the user, and so on. This property simply indicates the user’s relationship to the host organization and allows the organization to enforce policies that depend on this property”.

Guest users can be easily identified from Azure AD and this information can be used together with Conditional Access policies to require certain conditions from Guest users when they are accessing to cloud application, for example MFA.