B2B Users & INternal apps

By rzomerman | | No Comments | Azure

AAD B2B & AD KCD – AAD App Proxy

In a previous post I talked about using Azure AD App Proxy in combination with B2B accounts. This is to allow B2B invited guest users to be able to connect to internal applications using Kerberos, without them knowing their sAMAccountName or password. In that post, I described the AAD Configuration and how-to setup a user in AD to make this work.

It’s good to see that I was not the only one with this “problem” and that Microsoft actually now supports the creation of B2B accounts in AD based on an AAD source through the use of MIM – however, I wasn’t too sure on using MIM for this, certainly in smaller environments.

So, without further delay; a PowerShell script that does exactly the same, with (a lot) less resources and overhead.

There are 2 files, a PS1 and a function module PSM1. Make sure the psm1 file is in the same directory as the ps1.

The script inner-workings are pretty simple

  • Grab all B2B UPN’s from AAD
  • Grab all users in a specific OU in AD
  • Verify UPN’s
  • Create a list of users to be created in AD (newly added B2B guests)
  • Create a list of users to be deleted from AD (removed B2B guests in AAD)
  • Execute creation/deletion

Each “B2B” user in AD will receive its own unique sAMAccountName generated from a prefix (“G”) with a random number and a 40-character generated password. Note that both values do not have to be given to the actual end-user. These values will be required to create the user in AD but are never used by anyone. And to secure it even more, B2B users are required to provide a Smartcard to login (which they don’t have) – this eliminates any interactive login for these accounts.

To use the script there are 2 options. One is to run the script manually, but an automated version (and provisioning) option is available too.

Prepare the script and environment

Create a new OU in your AD. In my case I named it “External Users”. If you are going to run it in an automated way, grant permission to the computer (object) to create/delete user accounts in that OU.

Change the script options to set the full LDAP path to this OU, and if required change the “G” letter for the sAMAccountName prefix.

Very important note: when creating the B2B External Users OU in AD, make sure to NOT synchronize this OU using AADConnect. You can deselect the OU in the MIIS client, or by running AADConnect and configuring it to exclude the OU.

Manual run of the script

It’s probably best to run the script manually for the first few times just to see if all parameters and permissions are set correctly.

The script has multiple parameters that can be used, but in manual mode, you’d only need to determine if you want the script to ask for a login. By default, it doesn’t and assumes you are already logged in, but if not, run

AADADb2BSync.ps1 -Login $true

Make sure that the user executing the script has permissions on the specified OU to create/delete users.

If you are already logged in to Azure AD as (at least) Directory Reader, you don’t have to specify the -login parameter.

Automated Provisioning

To onboard the script for automated provisioning, open PowerShell in Administrative mode and run: 

AADADb2BSync.ps1 -Provision $true -Login $true

The onboarding will ask you to login to the AAD service. Please use a Global Admin Account in order for the script to create a new application and service principal to be used by the script in the automated version. Note that automated provisioning can be ran repeatedly. At every run, it will delete the existing application, scheduled tasks and authentication certificates prior to recreation.

The provisioning will execute the following tasks

  • Login to AAD (if -login $true)
  • Validate if an application with the name B2BSyncScript exists if so, delete it
  • Validate if certificates with subject CN=B2BSyncScript exists if so, delete it
  • Validate if a scheduled task with the name AADtoADB2BSync exists, is so, delete it
  • Generate a new self-signed certificate with subject CN=B2BSyncScript and the AAD tenant ID as Alternate DNS name
  • Generate a new random password for the PFX to be created
  • Export the certificate to the script folder with the newly generated password
  • Create a new Azure ADApplication with displayname B2BSyncScript
  • Create a new Azure AD Application Key Credential (using the created cert)
  • Create a new Service Principle for the created application
  • Grant the new Service Principle Read access to the AAD (Directory Readers)
  • Create a scheduled task to run the script:
    • Powershell -NoProfile -command & ‘$workingDirectory + \AADADB2BSync.ps1’ -ApplicationId <AppID>”
  • Requires a new login – for regular runtime and executing the first sync (can be cancelled).

As the scheduled task is ran under the system account, make sure that the computer object running the script has permissions to create/delete users from the OU specified in the script.

Once you know the application ID (shown in the provisioning output), you can now also run the script from a PowerShell prompt (on the computer that you can provision on)

.\AADADB2BSync.ps1 -ApplicationId c740da-blabla-blabla

LogFile

A logfile is created everytime the script is running. The logfile is stored in the same folder as the script and provides information on the actions taken. This includes detailed information on the created accounts and deleted accounts.

Final note

Given the sAMAccountName is generated on the fly and not synchronized back to AAD, Kerberos Constraint Delegation will only work for UPN’s. This means that the F5 tutorials in this blog will not function for these accounts (as those tutorials are based on sAMAccountName). A workaround will be provided for single domains (using UPN), but multi-forest/domain authentications will not work icw F5.

The Azure AD App Proxy by default uses the UPN and therefore will/should work.

Tagged , , , ,