AD FS identity integration on Azure Stack – filling in the gaps

4 Sep

One of the clients I’ve been engaged with use AD FS as the identity provider for their Azure Stack integrated system. All well and good, as setting that up using the instructions provided here is *fairly* straightforward:

Here’s a high level of the tasks that need to be performed:

On Azure Stack (by the operator via Privileged Endpoint PowerShell session):

  1. Setup Graph integration (configure to point to on-premises AD Domain, so user / group searches can be performed, used by IAM/RBAC)
  2. Setup AD FS integration (Create federation data metafile and use automation to configure claims provider trust with on-premises AD FS)
  3. Set Service Admin Owner to user in the on-premises AD Domain

On customer AD FS server by an admin with correct permissions:

  1. Configure claims provider trust (either by helper script provided in Azure Stack tools, or manually)
  2. If performing manually:
    1. Enable Windows forms-based authentication
    2. Add the relying party trust
    3. Configure AD FS properties to ignore token ring bindings (If using IE / Edge browsers and AD FS is running on WS 2016)
    4. Set AD FS Relying party trust with Token lifetime of 1440
  3. If performing by helper script:
    1. From Azure Stack tools directory, navigate to \DatacenterIntegration\Identity and run setupadfs.ps1

The only gotcha with the instructions that I encountered was that the certificate chain for AD FS was different than was provisioned for Azure Stack endpoints, so I tried to follow the instructions for this scenario provided in the link above, but they didn’t work.

It turns out that there was a problem with me running the provided PowerShell code:

[XML]$Metadata = Invoke-WebRequest -URI https://<YourADFSFQDN>/federationmetadata/2007-06/federationmetadata.xml -UseBasicParsing

$Metadata.outerxml|out-file c:\metadata.xml

$federationMetadataFileContent = get-content c:\metadata.cml


Enter-PSSession -ComputerName <IP Address of ERCS> -ConfigurationName PrivilegedEndpoint -Credential $creds

Register-CustomAdfs -CustomAdfsName Contoso -CustomADFSFederationMetadataFileContent $using:federationMetadataFileContent

OK, so first off there is a typo: $federationMetadataFileContent = get-content c:\metadata.cml

It should be $federationMetadataFileContent = get-content c:\metadata.xml

Easy enough to spot – that wasn’t the issue. The problem was passing the $using:federationMetadataFileContent into the PEP PS Session; it didn’t like it. Now, luckily for me, I came across the issue very recently in a client workshop with passing objects into PEP sessions. Karsten Bott was also at the same workshop and he found a fix, using the old-fashioned way of passing in parameters as an Argument list.

Here’s the modified code that worked for me:

[XML]$Metadata = Invoke-WebRequest -URI https://<MyADFSFQDN>/federationmetadata/2007-06/federationmetadata.xml -UseBasicParsing
$Metadata.outerxml|out-file c:\metadata.xml


$federationMetadataFileContent = get-content C:\metadata.xml
$AzsPSSession = New-PSSession -ComputerName <PEP IP Address> -Credential $creds -ConfigurationName PrivilegedEndpoint -name AzsPEP
Invoke-Command -Session $AzsPSSession {Register-CustomAdfs -CustomAdfsName <A custom name of your choosing> -CustomADFSFederationMetadataFileContent $args[0]} -ArgumentList $federationMetadataFileContent
remove-PSSession -Name AzsPEP

Thanks to Karsten! A useful tip 😊

Setting up Graph integration

So, onto my next finding. Graph is very easy to setup, so there’s not much to go wrong.

From the PEP, run:

Register-DirectoryService -CustomADGlobalCatalog <your AD FQDN>

Just a short note on how to verify if you’ve set it up correctly. It only really becomes apparent if it’s correctly configured when you try to modify RBAC for resources within a subscription. If you attempt to search for a user or group and you get a blank result window before even typing anything into the select search box, you’ve got a problem.

Below is an example of a mis-configured Graph endpoint:

…and here’s one that is correctly configured:

The things to check for are that the correct FQDN to the AD domain are provided and the user / password combination is correct. Graph just needs a ‘normal’ user account wit no special permissions. Make sure the password for the user is set to not expire!

You can re-run the command from the PEP without having to run Reset-DatacenterIntegationConfiguration. Only run this when AD FS integration is broken.

If you want to use AD Groups via Graph for RBAC control, keep in mind that they need to be Universal, otherwise they will not appear.

Hopefully this information will help some of you out.

In my next blog post, I’ll fill in the gaps on creating AD FS SPN’s for use by automation / Azure CLI on Azure Stack.

Danny McDermott

Danny is a Cloud Architect within the Azure Cloud Enablement Team, based in the UK.

Twitter LinkedIn