Federated Identities to Windows Azure Pack through AD FS – Part 3 of 3

Artikel
12/18/2013

In few of the previous posts, Anders Ravnholt discussed Installation & Configuration of WAP and Reconfiguration with FQDNs, ports and Trusted Certificates in detail. In this series, I will discuss how to configure AD FS and enable it to provide Identities to your WAP installation.

Scenario

Contoso Inc. is a Service Provider that hosts a private cloud stack and offers Compute resources to their customers. Contoso wants to install a Windows Azure Pack stack and

Provide administrative access to users from its own Active Directory
Provide self-service access to the Tenant Portal to users from Fabrikam Corp, one of its customers.

We will run through this scenario in 3 parts:

In the first part of this blog series, we discussed how Contoso can set up an AD FS Farm in their Corp domain pcloud.contoso.corp.

In the second part, we discussed how Contoso can set up trust between the AD FS instance and the WAP Admin Portal and provides its users, access to the Management Portal.

In this third part, we will discuss how Contoso can enable Fabrikam's users to access the Tenant portal by establishing trust between Fabrikam's AD FS and Contoso's AD FS and Contoso's AD FS and the WAP Tenant Portal.

Personas

Rob is a Fabric Administrator who is responsible for maintaining the infrastructure. Rob was tasked with installing the Windows Azure Pack Stack for Contoso Inc.

Mary is the Domain administrator for pcloud.contoso.corp domain in Contoso's Active Directory. Mary has necessary permissions to configure the AD FS linked to the domain.

George is the domain administrator of Fabrikam.corp domain. He has the necessary credentials to federate Fabrikam's AD FS with Contoso's AD FS.

Assumptions and Scope

In this post, the following are the assumptions about the environment:

Windows Azure Pack is already set up in the pcloud.contoso.corp domain
AD FS is enabled and configured for the pcloud.contoso.corp domain
AD FS is enabled and configured for the Fabrikam.corp domain
All the components in the environment have been configured with certificates from a Trusted CA
Both Contoso and Fabrikam have setup the necessary DNS routing to talk to each other

We also assume the following about you, the reader:

You are familiar with the installation of the Windows Azure Pack. For more information about Windows Azure Pack deployment, visit https://technet.microsoft.com/en-us/library/dn296432.aspx
You are familiar with some fundamentals of Claims based Authentication (Refer white paper at https://download.microsoft.com/download/6/F/7/6F7BB9DD-0D65-492F-9180-75A47A520F80/Claims-Based Authentication in WAP.docx )
You are familiar with setting up AD FS and the AD FS Console. For more information about AD FS visit https://technet.microsoft.com/en-us/library/hh831502.aspx
This post will describe, how to perform the scenario using the AD FS Console
This post will not talk about performing the scenarios using AD FS PowerShell

Overview of Scenario

Before I move on to explain how federation is established, I would like to give you an overview of the steps that need to be completed to get this working.

Add the WAP Tenant Portal as a Relying Party to Contoso's AD FS
This is done so that the AD FS knows that the Tenant Portal will be relying on it to provide authenticated Identities. This process has been explained in the second part of the blog series in the context of the Admin Portal.
Add Contoso's AD FS as Claims Provider to the WAP tenant Portal
This is done so that the Tenant Portal knows that AD FS is the entity that provides User Claims and that the users will have to authenticate against it. This process has been explained in the second part of the blog series in the context of the Admin Portal.

A similar relationship exists between Contoso's AD FS and Fabrikam's AD FS,

Add Contoso's AD FS as a Relying Party to Fabrikam's AD FS
This is done so that Fabrikam's AD FS knows that Contoso's AD FS will rely on it to authenticate users within its own realm
Add Fabrikam's AD FS as a Claims Provider to Contoso's AD FS
This is done to tell Contoso's ADFS that it can trust Fabrikam's AD FS and that it will be one of the trusted Claims Providers in the Federation Chain

All four of these steps have to be completed for the proper trusts to be established and enable users to login to the system.

Establish trust between Contoso's AD FS and WAP Tenant Portal

Adding a WAP Tenant Portal as a Relying Party to Contoso's AD FS

This process has already been explained in the second part of the blog series in the context of the Admin portal. We will go over it again here briefly.
Mary, Contoso's Domain Administrator, has to add the WAP Tenant Portal as a relying party with AD FS which tells AD FS that the Tenant Portal will be looking to get tokens from it. To do that Mary kicks off the "Add Relying party trust Wizard" from the AD FS Console

She enters the federation metadata information for the WAP Tenant Portal which is typically
<https://<<tenant portal url>>/federationmetadata/2007-06/federationmetadata.xml

Mary provides a friendly name for the Tenant Portal and proceeds with the rest of the wizard leaving default values.

Now Mary adds Claim Transformation Rules to the Tenant Portal, similar to the ones added to the Admin Portal (per the second part of this blog series).

Additionally, she ensures that the Tenant portal gets JWT Claims by using the Set-ADFSRelyingPartyTrust cmdlet. (Again, per the second part of this blog series)

    1: Set-AdfsRelyingPartyTrust -TargetIdentifier 'https://azureservices/TenantSite' -EnableJWT $true

Adding Contoso's AD FS as a Claims Provider to the Tenant Portal

Rob, who is the Fabric Administrator, logs on to the WAP box to complete the second half of this handshake. He runs the following script on the WAP Tenant Portal to let the Portal know it needs to Rely on AD FS for identities

    1: $fqdn = 'adfs.pcloud.contoso.corp'
    2: $dbServer = 'ContosoWAP'
    3: $dbPassword = 'pass@word1'
    4: $portalConfigStoreConnectionString = [string]::Format('Data Source={0};Initial Catalog=Microsoft.MgmtSvc.PortalConfigStore;User ID=sa;Password={1}', $dbServer, $dbPassword)
    5:  
    6: Set-MgmtSvcRelyingPartySettings -Target Tenant `
    7: -MetadataEndpoint https://$fqdn/FederationMetadata/2007-06/FederationMetadata.xml `
    8: -ConnectionString $portalConfigStoreConnectionString

Add Fabrikam's AD FS as Claims Provider to Contoso's AD FS

Mary, the Domain Administrator for the pcloud.contoso.corp domain opens the AD FS console and clicks "Add Claims Provider Trust" from the Actions pane on the right.
In the Select Data Source screen, she enters the address to the Federation Metadata information of Fabrikam's AD FS. It is typically https:// <adfs federation servicename>/federationmetadata/2007-06/federationmetadata.xml
Alternatively, the file can also be downloaded from the above location and imported into the wizard
The next step is to provide a friendly name for the Fabrikam AD FS. For easy identification, let's call it, well, Fabrikam AD FS
The remaining steps in the wizard deals with configuring Multifactor Authentication, Issuance Authorization rules etc which are not currently needed for this scenario and so she leaves them as is with the default values and completes the wizard. In the final step, Mary ensures that the "Open the Edit Claim Rules dialog.." checkbox is checked and clicks "Close"
In the "Add Transform Claim rule Wizard" , the Claim rule template should be selected as " "Send LDAP Attributes as Claims" and click Next

In the next step, Mary provides a Friendly rule name and selects the Attribute store as Active Directory and in the Mapping table, maps User-Principal-Name to UPN outgoing claim.

A similar process is repeated for adding Group Claims. Select Token-Groups – Qualified by Domain to map to Group outgoing claim
In some cases a UPN might already be available to AD FS. To handle these scenarios, there are two additional rules that need to be added to flow the UPN claims through as-is. In the "Add Transform Claim rule Wizard" select, "Pass Through or Filter an Incoming Claim"


in the next step, she provides a friendly name to the rule, and specifies the Incoming Claim Type as UPN and clicks Finish

Mary clicks on Yes in the AD FS Management Popup

A similar process is repeated for the Group Claim
Now that all four rules are added for this relying party, she finally clicks on Apply and is done with the Claim Transformation Rules
Once this is done Mary needs to ensure that when users are redirected to the ADFS from the WAP Tenant Portal, they should be taken directly to Fabrikam’s AD FS page for authentication. This is done by the following cmdlet
```
    1: Set-AdfsRelyingPartyTrust -TargetName "WAP Tenant Portal" -ClaimsProviderName @("Fabrikam AD FS")
```

Adding Contoso AD FS as a Relying Party to Fabrikam's AD FS

To complete the second part of the handshake, George, who is the Domain Administrator for Fabrikam should add Contoso's AD FS as a Relying Party. This is the same process as adding a Claims Provider and has pretty much the same set of steps:

Enters the location to the Federation metadata of Contoso's AD FS
Specifies a friendly name to the registered Relying Party
Clicks through the rest of the wizard by choosing appropriate values or the default ones depending on his preferences. On completing the wizard, he is shown the 'Add Transform Claim Rule Wizard'
In the "Add Transform Claim rule Wizard" , the Claim rule template should be selected as " "Send LDAP Attributes as Claims" and click Next
In the next step, he provides a Friendly rule name and selects the Attribute store as Active Directory and in the Mapping table, maps User-Principal-Name to UPN outgoing claim.
A similar process is repeated for adding Group Claims. Select Token-Groups – Qualified by Domain to map to Group outgoing claim
In some cases a UPN might already be available to AD FS. To handle these scenarios, there are two additional rules that need to be added to flow the UPN claims through as-is. In the "Add Transform Claim rule Wizard" select, "Pass Through or Filter an Incoming Claim"
In the next step, he provides a friendly name to the rule, and specifies the Incoming Claim Type as UPN and clicks Finish


A similar process is repeated for the Group Claim
Now that all four rules are added for this relying party, he finally clicks on Apply and is done with the Claim Transformation Rules
Once this is done, George needs to ensure that JWT tokens are issued to Contoso's AD FS. This is done by the following Powershell
```
    1: Set-ADFSRelyingPartyTrust -TargetIdentifier https://adfs.pcloud.contoso.corp/adfs/services/trust -EnableJWT $true 
```
That’s it! Now when users access the Tenant Portal, they will be redirected to Contoso AD FS which will then redirect them to Fabrikam AD FS. The Fabrikam AD FS will then authenticate the user
Once authenticated, users will be redirected all the way back to the WAP Tenant Portal to access their resources!

Comments

Anonymous
January 01, 2003
nice blog!!! can you please provide more information about this: Set-AdfsRelyingPartyTrust cmlet Set-AdfsRelyingPartyTrust -TargetName "WAP Tenant Portal" -ClaimsProviderName @("Fabrikam AD FS", "ABC.com", "bcd.com")
Anonymous
January 01, 2003
thanks for the detailed instructions. however, can we enable multiple tenant customers to log on through ADFS? just like windows azure. i noticed that you changed the claim provider directly to fabrikam adfs. what if, other companies, like abc.com, bcd.com to login through ADFS? how can we redirect them to their own adfs?
Anonymous
January 01, 2003
@Alternat: unfortunately no. As I mentioned in one of my previous comments, You need to manage your Active Directory infrastructure out of band. that is the secure model
Anonymous
January 01, 2003
The comment has been removed
Anonymous
January 01, 2003
You can add Multiple Claims Provider trusts to ADFS and then assign them all to the Tenant Portal using the Set-AdfsRelyingPartyTrust cmletSet-AdfsRelyingPartyTrust -TargetName "WAP Tenant Portal" -ClaimsProviderName @("Fabrikam AD FS", "ABC.com", "bcd.com")this way when a user gets redirected to the AD FS page they will be shown all these options
Anonymous
January 01, 2003
The comment has been removed
Anonymous
December 18, 2013
Pingback from Federated Identities to Windows Azure Pack through AD FS | MS Tech BLOG
Anonymous
December 19, 2013
Pingback from Thursday, December 19, 2013 on #WindowsAzure | Alexandre Brisebois
Anonymous
December 20, 2013
Pingback from Windows Azure Pack Blog Post Overview on Building Clouds & TechNet - Building Clouds Blog - Site Home - TechNet Blogs
Anonymous
December 20, 2013
Pingback from Windows Azure Pack Blog Post Overview on Building Clouds & TechNet - Building Clouds Blog - Site Home - TechNet Blogs
Anonymous
December 20, 2013
Pingback from Windows Azure Pack Blog Post Overview on Building Clouds & TechNet - Building Clouds Blog - Site Home - TechNet Blogs
Anonymous
December 26, 2013
Pingback from Federated Identities with Windows Azure Pack through AD FS | SME IT guy
Anonymous
January 02, 2014
Pingback from Windows Azure Pack – Admin & Tenant Portal AD Single Sign On einrichten ??? Daniel's Tech Blog
Anonymous
January 03, 2014
Pingback from Windows Azure Pack – Admin & Tenant Portal AD Single Sign On einrichten ??? Daniel's Tech Blog
Anonymous
January 03, 2014
Pingback from Windows Azure Pack – Admin & Tenant Portal AD Single Sign On einrichten ??? Daniel's Tech Blog
Anonymous
January 03, 2014
Pingback from Windows Azure Pack – Admin & Tenant Portal AD Single Sign On einrichten ??? Daniel's Tech Blog
Anonymous
January 06, 2014
Pingback from Windows Azure Pack ??? Admin & Tenant Portal AD Single Sign On einrichten
Anonymous
January 10, 2014
Pingback from Thursday, January 9, 2014 on #WindowsAzure | Alexandre Brisebois
Anonymous
March 25, 2014
Thanks Sriram...for your detailed blog. Great Work.
Anonymous
March 25, 2014
Thanks Sriram...for your detailed blog. Great Work.
Anonymous
May 08, 2014
原文链接： http://blogs.technet.com/b/privatecloud/archive/2013/12/06/windows-azure-pack-installing-amp-configuring
Anonymous
May 12, 2014
原文链接： http://blogs.technet.com/b/privatecloud/archive/2013/12/10/windows-azure-pack-reconfigure-portal
Anonymous
May 12, 2014
原文链接： http://blogs.technet.com/b/privatecloud/archive/2013/12/10/windows-azure-pack-reconfigure-portal
Anonymous
May 21, 2014
原文地址： http://blogs.technet.com/b/privatecloud/archive/2013/12/18/federated-identities-to-windows-azure
Anonymous
September 21, 2014
Depuis fin 2013, je suis tombé dans le monde de Windows Azure Pack. C'est un peu comme DirectAccess
Anonymous
October 08, 2014
Hi Shriram,

After integrating ADFS with WAP, when we create a tenant user in the Admin portal, that user is unable to login to the tenant portal. But an AD user can access the tenant portal without any issues. Please let me know if the set up is supposed to work in this fashion? Is there a way to sync the users created on the Admin portal to AD like Azure. However AD to Admin portal sync happens on first login to tenant site. Thanks!
Anonymous
November 06, 2014
Great stuff. At TechEd Europe last week you were telling me, that you are publishing a new blog post for the scenario "multiple claims provider" and AAD.
We do not want to publish the list of customers ;) So there should also be a solution similar to office365...

first asking for the ID and redirecting to the right Claims Provider...

looking Forward your post!
thx Stefan
Anonymous
December 03, 2014
I followed your step and it worked. but the thing, i lost the self serivce signup in WAP tenant portal and i have to create the users manually. is there a way i can add signup in ADFS portal?

Freigeben über