Couple weeks ago I wrote about B2B scenario where organizations are managing partner accounts at on-premises, syncing them to Azure AD and grant permission to resources and published applications. Consider scenario other way around, what if your partner accounts are in the cloud and you want to grant access to applications located at on-premises? Doable, naturally!

Application scenarios available (shortened version from docs.microsoft.com):

  • On-premises SAML-based application
  • On-premises app using IWA and KCD applications

Access to on-premises SAML applications

This scenario can be achieved quite easily, what you need is Azure AD, B2B users invited to AAD and Application Proxy.

  1. Integrate SAML app to Azure AD by using non-gallery template, instructions found from here
  2. When integrated publish app via Application Proxy, instructions found from here

Access to on-premise IWA and KCD apps

When application is using IWA and KCD you need Azure AD Application Proxy for authentication and on-premise B2B user object, which is used for authorization.

  1. Publish application via Application Proxy
  2. When IWA is used with KCD on-premises AD requires user object to be in place at on-premises AD. This object is needed for Application Proxy to be able to  impersonate the user and get a Kerberos token to the app.

Options for creating partner users to on-premises directory are:

  • Microsoft Identity Manager (MIM) and MIM management agent for Microsoft Graph, guidance found from here
  • PowerShell scripting – reference script download

Architecture (docs.microsoft.com)

1

  1. A user from a partner organization (the Fabrikam tenant) is invited to the Contoso tenant.
  2. A guest user object is created in the Contoso tenant (for example, a user object with a UPN of guest_fabrikam.com#EXT#@contoso.onmicrosoft.com).
  3. The Fabrikam guest is imported from Contoso through MIM or through the B2B PowerShell script.
  4. A representation or “footprint” of the Fabrikam guest user object (Guest#EXT#) is created in the on-premises directory, Contoso.com, through MIM or through the B2B PowerShell script.
  5. The guest user accesses the on-premises application, app.contoso.com.
  6. The authentication request is authorized through Application Proxy, using Kerberos constrained delegation.
  7. Because the guest user object exists locally, the authentication is successful.

Configuration – What is needed?

  1. Register an application for B2B script to Azure AD tenant

2

2. Grant “Read directory data” permission to application and consent it to all users on behalf of the users

3

4

3. To prevent pulling all Azure AD users to on-premises, use target group which contains all partner users in Azure AD (Microsoft reference script is using group as target).

7.png

4. Create dedicated OU to store external partner accounts and create additional UPN suffix to on-premises AD, mine is “Partners-Cloud”

  • This OU cannot be in AAD Connect sync scope
  • Add Guest users UPN suffix to on-premises –  Set-ADForest -UPNSuffixes -Identity feta.fi @{Add=”fetanet.onmicrosoft.com”}

11

5. Create gMSA account, scheduled task and grant permissions to gMSA account to OU created for shadow accounts

  • Guidance for creating gMSA account, scheduled task for it and delegations found from here, select file named “1.1.830.0\Script and Readme to pull Azure AD B2B users on-prem.zip“
  • Package contains tools below
  1. Creating and installing gMSA account

8

2. Creating schedule task

9

3. DSACL command

10

Putting pieces together

When configuration is in place it’s time to run the script. Before running it the script needs slightly modifications, following variables need values:

  • $B2BGroupSid = this is the cloud group’s objectID
  • $ShadowAccountOU = OU where shadow accounts will be placed
  • $ShadowAccountArchive = OU where to move disabled accounts
  • $Createmissingshadowaccounts = $true
  • $disableorphanedshadowaccounts / $deleteorphanedshadowaccounts = Only one of the following can be true
  • $AppID = this is the application ID registered earlier to Azure AD
  • $AppSecret = application key created during registration
  • $tenantdomain = tenant name
  • $tenantId = tenant ID

After running the script my B2B users from the Azure AD are populated to on-premises AD to OU “Partners-Cloud” which I created earlier for this purpose.

I also created scheduled task which is running daily to be able to populate guest users automatically.

When’s B2B shadow user objects are created on-premises applications using IWA/KCD can be published (publishing part not covered in this post) to partners and achieve SSO experience. Application publishing part I’m not covering here.

121.png

 

Summary

If your organization is managing partner accounts in cloud and you want those partners to have ability to access on-premises resources it can be achieved as described earlier. To SAML based applications easily with Azure AD features and if application is using IWA/KCD creating shadow objects to on-premises Active Directory.