One ADFS to serve them all (Part II)!

Rewriting URL's for ADFS with SSO support.

As stated in my previous post "One ADFS to serve them all! (part I)" I'd supply you with a method that's necessary for rewriting you're ADFS host federation service name and still be able to keep SSO working with a custom vanity host name for your federation service name.

I'm going to assume you read my previous post to get acquainted with the basic requirements and other aspects of working with Microsoft Application Request and Routing module. If you're not acquainted with the subject matter were about to walk-through I'd recommend you read my first post which will walk you through a very the basic installation, and tell you a bit about the workings which i will skip in this post.

One new component I am going to introduce is the web application proxy feature that's introduced in Windows Server 2012 R2. This feature was introduced to replace ADFS reverse proxy functionality and Microsoft's UAG (Unified Access Gateway) server. This article won't tell you how to get WAP up and running with ADFS and your SharePoint sites. There are dozens of posts telling you how to get that up and running.

But know i am assuming you put this behind your ARR configuration for routing your original URL's internally.

So assuming your have a basic understanding of the subject matter i am going to walk you through configuring a custom sign in URL for ADFS which uses the brand name "example.nl".

We will also use "Example.nl" for our SharePoint web applications which are hosted on a SharePoint 2010 and 2013 farm. (This should also work with SharePoint 2007 WIF(Windows Identity Foundation), but i haven't had a chance to test that yet.., i tested with 2010 and 2013)

Lab Requirements.

Windows 2012 R2 server for WAP (Configured for ADFS and your existing web applications)
Windows 2012 R2 server for ARR (you can use other windows / IIS versions for ARR)
Windows ADFS 2.0 / 3.x server
SharePoint 2010 Web application (Claimbased)
SharePoint 2013 Web application (Claimbased)

WAF (Web application firewall, I used Sophos UTM)

Limitations.

In older products like TMG and its successor UAG there was the possibility to use "pre-authentication" The goal of this technology was to let the reverse proxy handle your credentials and deal with double hop issues and other security security sensitive issues. ARR in this case does have the reverse proxy capabilities but doesn't have a working replacement for the pre-authentication part.

So we needed to introduce a second component to make this happen for us in a secure way that we can use without introducing new issues, Which would be WAP. (Web Application Proxy) this feature was introduced with Windows 2012 R2. In this post as mentioned before, all traffic from ARR will be routed through WAP for both ADFS and the SharePoint web applications.

One issue I saw when using SSO is that the SSO token is set in the session that connects to the ADFS server itself. So in a scenario like the previous post "One ADFS to server them all (part I)" you connected to www.example.nl this would also be the place where the SSO token would have been set. This is due to the session in which ADFS is being handled. In my previous blog post Part I it was within the same session as the web application. (All traffic including ADFS was being handled from www.example.nl)

Now lets say you wanted to redirect the customer to a different site where the same token could have been reused. The user would hit a hyperlink to the other website and go through the authentication process. The SSO token wouldn't be found in that session due to it being in the session of the previously opened website and not in your newly opened site. So how to solve this? Read on!

Goal

Our goal is going to be to create two IIS sites, one for our SharePoint sites which we will call www.example.nl and one that will use the custom vanity host name called Login.example.nl. All binding we will add to www.example.nl bindings list in IIS will redirect to login.example.nl which is our custom vanity host name for ADFS which users connect to.

Step by step configuration.

Step1:

Again lets create two sites in IIS Manager for this example lab. The first site we will call "www.example.nl" and the second site will be called "login.example.nl" (this will be our custom login for ADFS)

Make sure you've got the bindings correctly set up with SSL end to end for ADFS and for you're SharePoint sites!

(Part II) Figure A - Sites in IIS

Now we need to do our first task and that's adding a server variable to the site www.example.nl. Open up the URL Rewrite module and in the action menu select "View Server Variables...." this will open up a new window. In this window select "Add" and type the following: CURRENT_DOMAIN. And your done. Just hit OK.

(Part II) Figure N -Server variables

Step2:

We will start configuring "www.example.nl" so lets open up the URL rewrite module on this site and add a "Rule" and select the reverse proxy rule. You can choose a name you like for this rule. In our case we will not rewrite the host name for this rule so just remove the flag for offloading and type the host name of your SharePoint site. (www.example.nl)

So the first thing we will do in the "Match URL" section is to fill in the following, [Requested URL: Matches the Pattern], [Using: Regular Expressions] and for the [pattern: (.*)]

(Part II) Figure B - Match URL

For the second part we are going to add the conditions.

Condition1: [Input: {CACHED_URL}], [Type: Matches the Pattern] and [Pattern: ^(https?)://]
Condition2: [Input: {HTTP_HOST}], [Type: Matches the Pattern] and [Pattern: ^(?:.+\.)?([a-zA-Z0-9\-]{0,61}[a-zA-Z0-9]\.[a-zA-Z]{2,6})$]

(Part II) Figure C - Conditions

third we will add a server variables. The server variable will be used for storing the host name. This is necessary to be able to redirect back to the correct web application that you're user connected to before getting redirected to ADFS. So lets "Add" a server variable. [Name: CURRENT_DOMAIN], [Value: {C:1}] and [Replace: True].

(Part II) Figure D - Server Variables

Last but not least we must establish which action we want to take with this rule. In our case it's simple we want to use the standard server variable {HTTP_HOST}. The [Action type: Rewrite], [Action Properties: https://{HTTP_HOST}/{R:1}] and we want to flag the boxes for Append Query String and Stop Processing of Subsequent Rules. Save the rule and were done with the incoming rule for our sites.

(Part II) Figure E - Action

Step3:

We will now add another rule only this time it will be an outbound rule for www.example.nl. The goal of this rule will be to act correctly on the response location. So lets add a rule to the collection of outgoing rules (which should be blank at this moment) and select blank rule. You can give the rule any name you like again, but remember make sure you give the name a meaning that will help you recognize its goal and its place within the order of things.

First thing to do is to add a precondition. In our case we are going to create a new one. So select <Create new precondition....> in the drop down box of the precondition section. This should open the "Edit Precondition" window. Give the precondition a name that makes sense to you and set the following: [Name: Something you decided], [Using: Regular Expressions], [Logical Grouping: Match All] and then hit the Add button. The first will be the [Condition Input:{RESPONSE_STATUS}], [Check if input string:Matches the Pattern] and [Pattern:3\d\d].

(Part II) Figure F - Action

Second we will set the Match part of the outbound rule we are currently editing. So lets start by setting [Matching Scope: Server Variable], [Variable name: RESPONSE_LOCATION], [Variable value: Matches the Pattern], [Using: Regular Expressions], [Pattern: adfs\/(?:fs|ls|oauth2|portal|proxy|services).*|FederationMetadata\/.*] and make sure the ignore case is flagged.

(Part II) Figure G - Match

Third will be the action part. The Conditions will be left as it is. So moving on to actions the actions part the following will be set, [Action Type: Rewrite], Action properties [Value:https://login.{CURRENT_DOMAIN}/{R:0}], make sure "Replace server variable" is flagged and stop processing of the subsequent rules is not flagged! The goal of this rule is to redirect you to your custom login url for ADFS within the same domain namespace that your SharePoint site is in. (Example.nl) and lets save the rule.

(Part II) Figure H - Action

Step4: We will be adding a second and final rule to the outbound list of rules. This rule will be pretty much the same as the previous rule with the main difference being correcting the host name in the body. This will make everything look and work flawlessly. (Else you might see a host name reference of the original ADFS "Federation Service Name"). So lets add that rule! And Remember be smart about your naming convention!

So we just added another blank rule. For the precondition select the previously created precondition which was called "IsRedirect" in my case if you take a look at my name in Figure F.
For the match part we will be doing things a little different. So lets set things up shall we. [Matching scope: Response], [Match the content within: A], [Custom tags:], [Content: Matches the Pattern], [Using: Regular Expressions] and [Pattern: adfs\/(?:fs|ls|oauth2|portal|proxy|services).*|FederationMetadata\/.*]. Make sure "Ignore Case" is flagged!

(Part II) Figure I - Match

So we will be skipping conditions as we won't be using them. (Same as in the previous rule) And lets move on to the final part of this rule, action.[Action Type: Rewrite], Action properties [Value:https://login.{CURRENT_DOMAIN}/{R:0}]. Save the rule.

(Part II) Figure J - Actions

Going on with "Login.example.nl"

This will be the finishing touch of this post. Now lets create the final necessary rule for the vanity ADFS URL. As mentioned in the sub topic this will be happening in IIS -> Sites -> login.example.nl. Lets open up the URL Rewrite module.

Lets add a new "Reverse Proxy" rule and make sure the flag for offloading is gone. Give the rule a fitting name and lets take a look at the "Match URL" part of the rule. It should say the following, [Requested URL: Matches the Pattern], [Using: Regular Expressions] and for the [pattern: (.*)]

(Part II) Figure K - Match URL

The second act will be to validate the condition. It should say, [Logical grouping: Match All], [Input: {CACHE_URL}], [Type: Matches the Pattern] and [Pattern: ^(https?)://]

(Part II) Figure L -Conditions

Last but not least the action. Here we make sure it point to the REAL host name of the ADFS that you're trying to reach. (This should point to the real name your WAP server expects for the ADFS. Yes, funnel your traffic through the WAP server for your ADFS and SharePoint traffic. Because we use WAP to fill in the preauthentication part that ARR doesn't have.)And save the rule.

(Part II) Figure M - Action

Result

Now that we've setup the configuration we should be able to open up www.example.nl and get redirected to login.example.nl and back again. As long as the domain name is example.nl you can keep adding sub domain bindings like www2.example.nl or aminuts.example.nl and it will work. All traffic will be redirected to login.example.nl and back.

If you want to add a different domain name then you will have to do the same trick all over again for sites and ADFS. This depends on the first part of the rule which state login.{Current_domain} if it fits no problem there. But lets say your users want to be able to open signin.{current_domain} you will have to create a new site with its own set of rules for this new domain. (Or you can get really creative with rules which might results in a maddening configuration which is hard to maintain)

So i hope you like my post and it helped you out somehow.

Again regards and thanks to my colleague Bart Danse for testing and validating my setup. And thinking about how to get the rules mean and lean.

Zoeken in deze blog

IT issues and solutions