Using ADFS with Windows Azure Pack

Today me and my colleague Martin, http://martinhannemann.com, decided to test out different ADFS scenarios together with Windows Azure Pack (WAP).

As you might know, out of the box WAP uses a ASP.NET provider for the tenant site. It is also possible to use ADFS for this though, and that’s what we we interested in. We had different scenarios to test out:

Login via service provider AD – that is, user accounts are stored and managed by the service provider
Login via customer AD by either:
1. Listing all available providers, for most this is not a good option as everyone can see the customers
2. Or by forwarding users to the ADFS serving their AD, by looking at their UPN
Last we have another scenario where we’re using Azure AD, but I’ll have to cover that in another post

I assume you have WAP and ADFS installed. After this we will configure the following settings:

IIS bindings and certificates
Change URLs for WAP sites in the WAP database
Configure ADFS

First we change the IIS bindings to something more intuitive than the default settings. We do this by opening IIS manager, selecting the site and clicking “Bindings”:

In this example we’re editing the AdminSite and pointing it to admin.solvoittest.com, using HTTPS on port 443 and a certificate issued by a public CA. Restart the site after configuring it for your needs. Note that the admin site typically is NOT public but only for internal use.

After this, we’ll have to update the database with the new settings, this is done with PowerShell:

First create a SQL connection string containing SQL server name, SQL instance, maybe even a port, and username and password with access to the WAP database Microsoft.MgmtSvc.Store:

[powershell]$connectionstring = ‘Server=SQLServerWAP,1435;Initial Catalog=Microsoft.MgmtSvc.Store;Integrated Security=SSPI;User ID=wapsql;Password=password'[/powershell]

We then update the URL and port with the new settings:

[powershell]Set-MgmtSvcFqdn -Namespace "AdminSite" -FullyQualifiedDomainName "admin.solvoittest.com" -Port 443 -Server "SQLServer"[/powershell]

Then we’ll have to update WAP to use ADFS for authentication. This is done by pointing it to the ADFS server FQDN + /FederationMetadata/2007-06/FederationMetadata.xml, in this example: https://fs.solvoittest.com/FederationMetadata/2007-06/FederationMetadata.xml

[powershell]Set-MgmtSvcRelyingPartySettings -Target AdminSite -MetadataEndpoint ‘https://fs.solvoittest.com/FederationMetadata/2007-06/FederationMetadata.xml’ -ConnectionString $ConnectionString[/powershell]

After this we’ll have to configure ADFS to trust WAP. Start out by opening the ADFS console, expand Trust Relationships, right click Relying Party Trusts and choose to add a new one. Here you’ll click next, and then add the metadata address of your WAP site, in this case: https://admin.solvoittest.com/federationmetadata/2007-06/federationmetadata.xml

After this, click Next, give the trust a name and finish with default settings.
Now the Add Transform Claim rule Wizard should open, if not, right click the new trust and choose to edit claim rules. Here we’ll use Send LDAP Attributes as Claims template:

And on the next page give the rule a name. Then choose Active Directory as your Attribute store, User-Principal-Name as the attribute and UPN as outgoing claim type:

After this we’ll add a similar rule for groups, using Token-Groups – Qualified by Domain Name attribute:

Then we’ll add 2 Pass Through Rules for UPN and Groups:

The last ADFS configuration is to enable JWT tokens. This is easily done with PowerShell:

[powershell]Set-AdfsRelyingPartyTrust -TargetIdentifier ‘http://azureservices/AdminSite’ -EnableJWT $true[/powershell]

Now you will be able to login via ADFS! The steps for configuring Tenant site is similar to those above. Just remember to address the TenantSite instead of AdminSite.

So, what about the scenario in 2.1, where we add multiple organizations? Here we’ll have to tell our own ADFS to trust the external ADFS. This way the requests will be forwarded to the tenant organization for them to authenticate. How do we do it?

Start on your side by opening the ADFS console, expand Trust Relationships, right click Claims Provider Trusts and choose to add a new one. Here we’ll point to the tenant ADFS metadata file:

And finish the wizard with default settings after you’ve named the Provider.

Next up, add the same 4 rules as we did above. This time add them by right clicking your new Provider and selecting Edit Claim Rules:

Finally, to allow the portal to use several ADFS setups, run the following command:

[powershell]Set-AdfsRelyingPartyTrust -TargetName "WAP Tenant Portal" -ClaimsProviderName @("Tenant1, Tenant2, Tenant3")[/powershell]

Next up, ask the tenant to add your ADFS in the same way, by pointing them to your ADFS, for example: https://fs.solvoittest.com/FederationMetadata/2007-06/FederationMetadata.xml

Remember that the tenant will have to enable JWT tokens:

[powershell]Set-ADFSRelyingPartyTrust -TargetIdentifier https://fs.solvoittest.com/adfs/services/trust -EnableJWT $true[/powershell]

That’s it, now your customers can login using their own ADFS!

This method will however list ADFS providers for ALL tenants. If you’re a service provider you probably don’t want to disclose your customers, so what can we do to prevent this?
I searched for this but couldn’t really find anything. Luckily the WAP guru Marc van Eijk could help with this. The way to do it is by adding the tenant Organizational Account Suffix to the provider. We can do this easily using PowerShell:

[powershell]Set-AdfsClaimsProviderTrust -TargetName Tenant1 -OrganizationalAccountSuffix @("tenant1a.com";"tenant1b.com")[/powershell]

In this example Tenant1 has 2 suffixes they would like to use when logging in: tenant1a.com and tenant1b.com

Now, when entering the tenant portal, you can write your own email (notice the URL, and name of the site):