Active Directory Federation Services (AD FS) with Azure Pack Tips, Tricks & Troubleshooting
We have been getting a lot of interesting questions from customers and partners who have implemented AD FS as an identity system for Azure Pack and bringing us some very interesting scenarios. This blog post is an outcome of our engagement with those folks. I will be discussing a few of the lesser-known features/ tips & tricks that you can leverage with AD FS to provide customized solutions for your WAP instance. A big thank you to MVP Marc Van Eijk for his contributions to this blog 
I will keep updating this post as and when I find newer and more interesting tips which will help you better understand AD FS and its interaction with WAP. Please let me know in the comments section if you use/know of a neat trick with AD FS in the context of WAP.
Also, here is a good reference for Customizing AD FS sign-in pages https://technet.microsoft.com/en-us/library/dn280950.aspx. Few of the tips mentioned in this blog is taken from this reference.
Set specific Identity Providers to a Relying Party
This is a scenario when you have multiple Claims provider systems to AD FS ie. when you have federated your AD FS with many other Identity systems, and you want to permit only a subset of Identity Providers to show up to your users.
For instance, in my environment I have 3 Claims providers as seen in the AD FS Console:
Let’s say that I would like to enable only the asp.net claims provider and the Microsoft Corporation for my WAP Tenant portal. I can run the handy Powershell cmdlet below:
Set-AdfsRelyingPartyTrust -TargetIdentifier https://azureservices/TenantSite -ClaimsProviderNames @("Microsoft Corporation","asp.net")
This will ensure that only the Microsoft Corporation and asp.net Claims Providers will show up when I visit my tenant portal.
Email suffixes for Claims Providers
Each Identity (Claims) Provider can contain users with one or more email suffixes. AD FS provides the capability for administrators to list the suffixes, for example, @us.contoso.com, @eu.contoso.com, that is supported by a claims provider and enable it for suffix-based discovery. This is typically needed when a service provider does not want their customers to know who their other customers are. Based on the suffix provided the client browser will redirect to the appropriate STS.
As in our example above, let’s say that I know that @microsoft.com and @exchange.microsoft.com are the email suffixes for my Microsoft Corporation Claims Provider. In that case, I would run a powershell script like the one below
Set-AdfsClaimsProviderTrust –TargetName “Microsoft Corporation” -OrganizationalAccountSuffix @("microsoft.com";"exchange.microsoft.com")
Doing this would change my landing page to a single option that says “Other Organization” and when I click on that I will be shown a textbox where I can enter my email address
Now when I click on Next, AD FS will automatically detect that the Microsoft.com email address needs to go to the Microsoft STS and will send me over to Microsoft directly.
Enable Forms-based Authentication every time
When Active Directory is enabled and the user’s device is in a domain the windows Authentication prompt comes up every time. If the application is accessed from anywhere outside the domain, the AD FS login page shows up. A few customers wanted the AD FS login page to be shown every time the WAP Tenant portal is visited and wanted to turn off the Windows Authentication/ windows popup for authentication.
You can set this up in the AD FS Console by going to Authentication policies and editing global authentication policy and changing it to forms authentication and unchecking windows authentication. This will ensure that the login form shows up even if the user is within the domain.
Managing AD Groups to access WAP
Here is an excellent article on creating a Rule to Permit or Deny Users Based on an Incoming Claim https://technet.microsoft.com/en-us/library/ee913594.aspx. If you have followed my earlier blog post about providing AD Groups access to WAP, then select the claim type to be ‘Group’ and specify the group name. Select if you would like to Permit or Deny the above mentioned group and click ‘Finish’. This will restrict access to your WAP installation as a whole only to the Group that you’ve mentioned.
Validate ADFS logon
One of the basic principles of ADFS is that the end user is redirected to STS logon page if he connects to the Azure Pack tenant site unauthenticated. When you are in a troubleshooting scenario, where connecting to the Azure Pack tenant site URL will just timeout, it is not always clear if the issue is related to the tenant site or ADFS. When the tenant site is working correctly and ADFS is not, you are redirected to AD FS, but the timeout will still be displayed with the URL of the tenant site in the browser. To verify if ADFS is functioning properly you can authenticate to ADFS directly by using the following URL https://<fqdn.ofyour.sts>/adfs/ls/IdpInitiatedSignon.aspx. When you can logon to ADFS successfully, the issue is probably related to Windows Azure Pack. If not, you should be looking at ADFS first.
Adding Groups as Co-Administrators
Azure Pack accepts User Principal Name (UPN) claims and Group claims. A tenant requires a UPN claim to logon to the portal. When a tenant subscribes to a plan the UPN is made owner of the subscription. A UPN is required as owner for a subscription. The Group claim is optional and can be used to specify Co-Admins for an existing subscription. A common design is to designate an owner of the subscription that is responsible (for example a department head) and add a group claim as co-admins for the subscription (for example a group containing all the departments users). Azure Pack will not accept a space in the Group when configuring Co-Admins for a subscription.
Group claim with Domain DNS name and NetBIOS mismatch
If you are unable to access the Azure Pack portal after configuring access for a group that the user is member of, you might have a mismatch with the value specified in the cmdlet and the actual Group claim that is issued by ADFS.
For example; when microsoft.com is the DNS domain name and MSFT is the NetBIOS domain name. The two group claim types will both reference the DNS domain name.
· Token-Groups – Qualified by Long Domain Name > The claim will be in the format DnsDomainName\Groupname (microsoft.com\group)
· Token-Groups – Qualified by Domain Name > The claim will be in the format FirstDnsDomainName\Groupname (microsoft\group)
Neither claim type will result in a format with the NetBIOS domain name. If your desired group claim is referencing the NetBIOS domain name you could create a transform rule that changes the DNS Domain Name in the NetBIOS domain name.
Verify the content of an incoming claim
If you want to look at the content of an incoming claim, for configuring the correct values in Windows Azure Pack it is possible to use a PowerShell cmdlet to request a base64 encoded token. The token will contain the issued claims.
To request a token from the ADFS server you need to use a function. This TechNet article contains the function Get-AdfsToken https://technet.microsoft.com/en-us/library/dn554315.aspx
Remember to fill in the values at the bottom of the function before running it. The result of this script is a base64 encoded token.
You can use any online base64 decoder to paste the string and decode it.
It is also possible to create a more user friendly website that displays the claims in a website. The Windows Identity Foundation SDK contains a sample claimapp that will display the incoming claims in a browser.
The procedure for setting up the website can be found here https://technet.microsoft.com/en-us/library/dn280939.aspx#BKMK_5.
And if you’re a PowerShell wiz, then you can use the following script to decode the token and display its contents. The script is at https://gallery.technet.microsoft.com/JWT-Token-Decode-637cf001
Automatically redirected to an STS after authenticating once
By default, AD FS sets a cookie on the client end to track the user’s selection for authentication methods. When users log on to ADFS for the first time using form based authentication, they are presented with the Home Realm Discovery page and can select a identity provider. Based on the selection the user makes, a cookie is created on the client machine to remember the selection. The next time the user logs on to ADFS he is automatically redirected to the STS specified in the cookie. This is a user friendly method for authenticating to ADFS, but can be inconvenient when you are configuring the environment.
You can disable the creation of the cookie by running the following AD FS Windows PowerShell cmdlet on the ADFS server:
Set-ADFSWebConfig -HRDCookieEnabled $false
The user will now be presented with the ADFS logon page every time.
As I mentioned at the beginning, I will keep updating this post as and when I find newer and more interesting tips which will help you better understand AD FS and its interaction with WAP. Please let me know in the comments section if you use/know of a neat trick with AD FS in the context of WAP.