You don’t often think about enterprise private clouds and high scale going together.  45K VMs running, 200K cores and 20K VMs created and deleted per day must surely be the domain of public cloud hosters?  In fact this is Microsoft’s internal private IaaS cloud (called Nebula) offering compute capacity for development and validation to Microsoft product engineering teams.   The challenge for the Nebula team is not just scale but also functional capability with many engineering teams bringing exacting needs for reliability, compute and networking.   With a long list of these items not being met with existing systems the Nebula team jumped onboard as the first internal partner for Microsoft’s Cloud Platform System (CPS).

Here’s a rundown of key features for Nebula service use of CPS:

Windows Azure Pack (WAP) Self-service portal experience

The Nebula service caters for both individual development engineers requiring small individual environments and test automation systems grabbing often hundreds of VMs at a time.  For the development engineers the Nebula team offers a self-service experience via the WAP portal.  The WAP portal shipping with CPS has been customized for the needs of Nebula users but is an example of how an enterprise IT department could tailor the experience.

The following show the home page view and creating a VM in the Nebula WAP portal.

Nebula WAP portal home page view




Creating a CPS VM in the Nebula WAP portal

Reliable, well monitored capacity

One of the things that Microsoft engineering groups really care about is reliability of their test runs.   For production services we all expect high availability and reliability, but for continuous engineering validation consistency and repeatability are also vital, and often without the luxury of resilient components in the mix.  Hence Nebula team has been striving to offer a high single VM instance SLA to internal partners.   CPS is ideal in this regard since it has built with redundancy and resiliency from the hardware design up through the storage, networking and management systems.   Nebula offers CPS as premium reliability in contrast to the standard reliability of our existing data center hardware.

Monitoring and troubleshooting abilities are also a key part of the equation for offering customer a comprehensive reliable service.  Historically the Nebula team has found in many cases an engineering test run is not hit with VM crashing but some aspect of the networking or storage environment which fails.  CPS offers a comprehensive view of what is going on with the stamp within Operations Manager.  A detailed description of the features used is contained in this blog post: http://blogs.technet.com/b/momteam/archive/2014/12/11/monitoring-the-cloud-fabric-in-the-cloud-platform-system-cps.aspx

Specialized workloads

A conventional workload for CPS is Sharepoint or SQL server, or getting more complex would be Microsoft Dynamics.  All of these offer a network endpoint to client applications to consume their services which can be connected to a corporate network or exposed to the internet in a secure manner.  Now consider testing a system which offers remote Operating System Deployment (OSD) capabilities using PXE boot including its own DHCP and DNS environment.  Not the sort of infra-structure you want connected to a corporate network if you value your laptop getting email on a Monday morning!   Thankfully CPS has a flexible solution to this problem using Software Defined Networking.  

Nebula solves this problem by offering isolated networking environments via windows virtual networking within CPS.  This allows the flexibility of having one v-net testing an OSD scenario in an isolated network accessed via a proxy server right with another v-net in the same CPS stamp offering a conventional corporate network accessible workload.  Previously Nebula had to dedicate specific hardwired data center kit for OSD scenarios which make poor use of capacity.

Another workload that Nebula is now offering via CPS is code integration.  This IO intensive operation for merging code trees is working well using the CPS shared storage and was not possible on Nebula conventional direct attached storage servers.

Service operations value

The Nebula team have to deal with challenges of increasing capacity need, balancing needs of Azure and private cloud use and meeting specialized feature needs for customers.  All this on top of day to day support for customers and dealing with data center issues.  In this environment the hit to the operations team for setup of new hardware and environments is considerable.  So this is where CPS really helps out.

Ready to connect, integrated support
When new hardware kit arrives in standard practice for Nebula operations team to spend time imaging the servers, and setting up management and fabric management systems.  When a CPS stamp is handed over to the Nebula Operations team all of this is done and all that’s needed is to hook up CPS interfaces to the Nebula VM request infra-structure and some account creation.  Since the System Center components are all running its easy to manage and monitor as the stamp is put through essential burn in testing.  Since the Azure operational insights data is also available to the CPS support team any problems in production usage can be seen by them in real time.  Since this is done in coordination with Dell this offers a faster and tighter loop for diagnosing issues.

Patching and upgrade

One bane of the Ops world is OS security updates for customer host servers.  Nebula have used Windows Server live migration for some time but with 4K servers in production running at 90% capacity it’s a fast game of Tetris to shift customer VMs around to complete patching in in a couple of days.  In short the administration burden is too great so patching and rebooting the servers remains the predictable path to ensure a secure private cloud.
Enter CPS with cluster aware updates and the operational effort is hugely reduced.  CPS takes care of moving VMs around and making continuous operation for customers a practical reality.

Well that’s a brief rundown of how Microsoft’s internal private cloud is gaining huge benefit from CPS adoption.  In a future post we’ll look in more detail about the operational aspects of using CPS.

Microsoft Nebula Service team

The Enterprise Mobility Suite team has just launched a contest looking for the best tales from tech support – those things that end users do that (without you) would make your IT totally unsecure or insufficient.

Check out Brad Anderson’s post on the Enterprise Mobility Team blog for more details and to enter.

Multiple domain names and themes on a single Tenant portal

On to the First extensibility then! Before I go on further to explain how this is done, let’s re-iterate on the scenario we’re trying to tackle here.

Problem Statement

Contoso Hosting is a hosting company that has stood up a private cloud stack with Azure Pack. Contoso has two huge customers called Customer1 and Customer2 (innovative names… I know! but let’s call them these for simplicity ). Customer1 is a hosting company themselves who would like to offer the services provided by Contoso, to their own customers. Customer2 is an enterprise customer who would like to provide Contoso's services to their different departments.

Both of these customers would like Contoso to provide them their own personalized portals due to their business requirements. Customer1 would like to get the portal located at https://www.customer1.com and Customer2 at https://www.europe.customer2.com and would like the portals to be styled with their own respective themes.

Solution

One of the extensibilities that can be leveraged is the option that enables you to support multiple themes and domain names for a single Azure Pack Tenant Portal. This way, on the same tenant portal website, you can add additional IIS bindings, add multiple themes and set the WAP Portal and API layer to treat these as different entities and cater to each one differently. That’s the one-liner for this extensibility!

Why would you go in for this extensibility?

The merits of this extensibility are that

1. Infrastructure footprint is low. If you need more than three or more domains, the infrastructure cost for maintaining multiple tenant portals goes up steeply
2. You do not have to maintain different load balanced instances of the Tenant Portal. You can set up one portal in HA and scale that depending on your load
3. All the data lives within the context of one portal. You do not have to maintain multiple “different” portals
4. If your customers don’t have different scale requirements you could just have all of them on the same portal instance and scale that service uniformly.

Important Notes:

1. I am using Active Directory Federation Services (AD FS) as the Identity Provider for this extensibility.  You cannot use this extensibility with the ASP.NET Membership Provider. The main requirement for this in terms of Identity Providers is that the Identity Provider should be capable of supporting Multiple Relying Parties. My recommendation would be using AD FS. Also, I am assuming that your AD FS is already set up. If you haven’t set up AD FS, please follow the blog post at http://blogs.technet.com/b/privatecloud/archive/2013/12/02/federated-identities-to-windows-azure-pack-through-ad-fs-part-1-of-3.aspx for instructions on setting AD FS up.
   
2. I am also assuming that you as the reader know how to set up relying party trusts with AD FS. If not, please glance over my previous blog post here http://blogs.technet.com/b/privatecloud/archive/2013/11/27/federated-identities-to-windows-azure-pack-through-ad-fs-part-2-of-3.aspx.
   
3. I am not going over DNS changes required for this. It is assumed that the DNS is already set up and the domains are pointing to the Tenant Portal machine. Please ensure that you are able to access these domains before you begin this extensibility. This will save you a lot of troubleshooting later on.
   
4. This is a fairly advanced extensibility, so make sure you take snapshots after before and after Step 3 in case you need to go back.

This extensibility involves 4 steps:

1. Add additional bindings in IIS for the Tenant Portal website
2. Copy the different themes into Content folder of the Tenant Portal website
3. Modify the WAP Configuration Databases to accommodate for the new domain names
4. Setting up trust with your Identity Provider

1. Add IIS bindings to Tenant Portal

The first step is to add additional HTTPS bindings to your Tenant Portal website.

1. Open Internet Information Services Manager (IIS) on the computer that hosts your Windows Azure Pack tenant portal (MgmtSvc-TenantSite).
2. In the left pane tree-view, select MgmtSvc-TenantSite, select the Bindings action, select Add in the Site Bindings dialog and add the port, Host Name and SSL certificate information.
3. Ensure that you select ‘Require Server Name Indication’
4. Assign the appropriate SSL certificate to the host name.
   Note: These are recommended to be real certificates from a trusted CA. If you’re using Self-Signed Certificates, please make sure that the certs are in the Trusted Root Certification Authorities of all the machines you’re using.
5. Select OK to close the dialog.
6. Add as many bindings as there are host names that need configuring.
   

In our example, I am going to add two bindings called customer1.com and europe.customer2.com to my Tenant Portal

2. Add themes to Tenant Portal

The next step is to tell the Tenant Portal what theme to load when the Tenant Portal is accessed through each of the above domains. Create custom themes for each of your customers as appropriate and follow the steps below

1. Go to C:\inetpub\MgmtSvc-TenantSite\Content on your Tenant Portal Machine and create a folder called ‘ThirdPartyThemesByDomain’
2. Copy your themes inside that folder. Make sure to name the folders based on the domain name you would like them to be served for.

In Our scenario, I am going to create two theme folders called customer1.com and europe.customer.com and copy them to the Third Party themes folder as below:

3. Modify WAP configuration Databases

Now would be a good time to take a snapshot of your Tenant Portal Machine. The next step involves making changes to the WAP Configuration Database.

This step involves composing a couple of JSON and modifying the Portal Config Store and API Config Store. What we’re doing here is

1. Telling the Portal that it needs to expose a different Realm and a different ReplyToEndpoint for each domain.
2. We are also telling the API layer to support these values while validating the user’s token.
3. Additionally, we are setting up the Portal and API to trust an identity system and telling the portal redirect the users here for authentication

To save you the trouble of modifying the database manually, I have automated this step in a PowerShell Script.

The script can be downloaded from https://gallery.technet.microsoft.com/Setting-up-Multiple-themes-1258f8f0 .

After downloading the script, open it up in PowerShell ISE and fill in the appropriate input data and execute the script.

In our scenario, I am filling the inputs as above. This needs to be understood clearly to understand this extensibility.

To  explain, given that I need a domain called customer1.com, I am telling the Tenant Portal to identify itself as http://azureservices/customer1 to its identity system and to the API layer and set the redirect Url to https://customer1.com so that the STS can redirect to this Url after authentication. Similarly, for the second domain Europe.customer2.com, I am telling the tenant portal to advertise itself as http://azureservices/customer2 and setting the replyTo address to https://europe.customer2.com.

Why do I need the tenant portal to have different Realms?

There are 2 reasons:

1. Since customer1 and customer 2 are at different URLs, your STS needs different identifiers to redirect the users to after authentication. Hence the STS will not allow you to register two Relying Parties with the same identifier.
   
2. Both customer1 and customer2 may have different Identity systems that they would like their user to login with. In this case, AD FS (or any STS) needs an unique identifier from the portal so that it can automatically redirect it to the right identity system. (In the 4th part of this series, I will discuss how this is done. If you’re really curious you can find this information under the “Set specific Identity Providers to a Relying Party” section in the  Active Directory Federation Services (AD FS) with Azure Pack Tips, Tricks & Troubleshooting blog post!

Provide the Federation Metadata of your Identity System to tell the Tenant Portal about your identity system and give the script a whirl. At the end of execution, it will open up a notepad file with the original Relying Party and Identity Provider values before the execution. Save this text file in case you need to go back to original settings.

To see if the script did its job right, you can visit https://<<domain>>/federationmetadata/2007-06/federationmetadata.xml and download the federation metadata file. You should get a different metadata file for each of the domains you’ve set up. In our scenario when I visit https://customer1.com/federationmetadata/2007-06/federationmetadata.xml, I get the following file. Note the entityId and was:Address fields

when I visit https://europe.customer2.com/federationmetadata/2007-06/federationmetadata.xml

In the interest of being thorough, I am providing an explanation below as to what the script does. It is good to understand this, but if you’re not interested in these details, you can skip to Step 4.

Portal Config Store Modifications:

1. The Tenant portal needs to issue a different realm based off the incoming domain name. to do that you go to the Tenant Portal’s Config store at Microsoft.MgmtSvc.PortalConfigStore and Add a key called Authentication.RelyingPartyByDomain and setting the Value to be in the following format.
   {“<<Domain1>>”:{“EncryptionCertificate”:null,”Realm”:”<<YourRealm1Here>>”,”ReplyTo”:”<<YourReplyToAddress1”>>”}, {“<<Domain2>>”:{“EncryptionCertificate”:null,”Realm”:”<<YourRealm2Here>>”,”ReplyTo”:”<<YourReplyToAddress2”>>”}}

For our scenario, the row will look like

Namespace	Name	Value	Created	Modified
TenantSite	Authentication. RelyingPartyByDomain	{"europe.customer2.com":{"Realm":"http://azureservices/customer2", "ReplyTo":"https://europe.customer2.com", "EncryptionCertificate":null}, "customer1.com":{"Realm":"http://azureservices/customer1", "ReplyTo":"https://customer1.com", "EncryptionCertificate":null}}	2015-01-15 13:49:07.0000000 +00:00	2015-01-15 13:49:07.0000000 +00:00

API Config Store Modifications:

The [Microsoft.MgmtSvc.Store].[Config].[Settings] table stores information required by the Service Management API. The [Authentication.RelyingParty.Primary] key under the [Namespace] ‘TenantAPI’ stores information about the portal and realms that is trusted by the API layer.
Similarly, the [Authentication.IdentityProvider.Primary] key under the [Namespace] ‘TenantAPI’ stores about the STS that sends the signed token. These keys are used by the Service Management API layer to verify the validity of the incoming claims and provide access to the user. The Service Management API can understand 2 additional keys which will not be present in the table by default and will have to be added to the table manually. These are:

Authentication.IdentityProvider.Primary.Multiple	This is an array that takes multiple JSON strings and is used to identify the different Relying Parties
Authentication.RelyingParty.Primary.Multiple	This is an array that takes multiple JSON strings and is used to identify the different Identity Providers

1. Edit the [Microsoft.MgmtSvc.Store].[Config].[Settings] table and add an additional row with Namespace TenantAPI and Name as Authentication.RelyingParty.Primary.Multiple. The value for this field should be if the format
   [{"EncryptionCertificate":null,"Realm":"<<YourRealm1Here>>","ReplyTo":"<<YourReplyToAddress1”>>"}, {"EncryptionCertificate":null,"Realm":"<<YourRealm2Here>>","ReplyTo":"<<YourReplyToAddress2”>>"}]
   
   Replace the values to match the value in the Portal Store as done above. You can add more array elements to the template above based on the number of Portals you have. In our scenario, My table will look like
   

   Namespace	Name	Value	Created	Modified
   TenantAPI	Authentication. RelyingParty. Primary.Multiple	[{"Realm":"http://azureservices/customer1", "ReplyTo":"https://customer1.com","EncryptionCertificate":null},{"Realm":"http://azureservices/customer2", "ReplyTo":"https://europe.customer2.com","EncryptionCertificate":null}]	2015-01-15 13:49:…	2015-01-15 13:49:…

    

2. The JSON string array representing the various Identity Providers needs to be composed. This is done by using the following template

   [{"Realm":"http://<<ADFSFQDN>>/adfs/services/trust","Endpoint":"https://<<ADFSFQDN>>/adfs/ls/","Certificates":["SigningCertificate"]},"Realm":"http://<<ADFSFQDN>>/adfs/services/trust","Endpoint":"https://<<ADFSFQDN>>/adfs/ls/","Certificates":["SigningCertificate"]}]
   
   My table looks like

   Namespace	Name	Value	Created	Modified
   TenantAPI	Authentication. IdentityProvider. Primary.Multiple	[{"Certificates":["MIIC3DCCAcSgAwIBAgIQJFolmpo+w<<truncated>>"], "Endpoint":"https://adfs.contoso.org/adfs/ls/", "Realm":"http://adfs.contoso.org/adfs/services/trust"}, {"Certificates":["MIIC3DCCAcSgAwIBAgIQJ<<truncated>>"], "Endpoint":"https://adfs.contoso.org/adfs/ls/", "Realm":"http://adfs.contoso.org/adfs/services/trust"}]	2015-01-15 13:49:…	2015-01-15 13:49:…

    

3. Delete the [Authentication.RelyingParty.Primary] and [Authentication.IdentityProvider.Primary] values under the [TenantAPI] Namespace in the [Microsoft.MgmtSvc.Store].[Config].[Settings] database table as a security measure to prevent conflicts
4. Perform ‘iisreset’ on the ‘MgmtSvc-TenantAPI’ machines for the changes to get picked up by the Service Management API

4. Setting up trust with the Identity Provider

The final step is to tell your Identity System about the tenant portal. Because we would like the Tenant Portal to work with two different domain names and two different realms, these would form two separate Relying Parties with AD FS.

Use this blog http://blogs.technet.com/b/privatecloud/archive/2013/12/17/federated-identities-to-windows-azure-pack-through-ad-fs-part-2-of-3.aspx to understand how to register Relying parties with AD FS. Follow the steps under the AD FS Configuration section replacing values as appropriate. We will set up two Relying Parties to support our scenario using the two federation metadata files mentioned above
https://europe.customer2.com/federationmetadata/2007-06/federationmetadata.xml
https://customer1.com/federationmetadata/2007-06/federationmetadata.xml

Please ensure you’ve followed all the steps in the ADFS configuration section of that blog as appropriate using the realm values in our current context and remember to Enable JWT tokens

Now when I visit https://europe.customer2.com, I get redirected to my AD FS sign in page and after a successful login, I am taken back to my Tenant portal with a “red” theme.

When I visit https://customer1.com , I am directed to the same AD FS again, and after successful login, I am taken back to my Tenant portal, with a “green” theme

Voila! You now have the same tenant portal giving you two different themes and is capable of supporting two different URLs!

If you’ve noticed, although we’ve set up two different domain names for the Tenant Portal, login still happens through the Contoso Active directory. In the fourth part of this blog, I will talk about how to point these to different identity providers. If you’re really curious you can find this information under the “Set specific Identity Providers to a Relying Party” section in the  Active Directory Federation Services (AD FS) with Azure Pack Tips, Tricks & Troubleshooting blog post!

In the next post, I will talk about how to set up Multiple tenant portals with Azure Pack!

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 http://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 http://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 http://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 http://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 http://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.