Ask Premier Field Engineering (PFE) Platforms

FAQ on ADFS - Part 1

Hello everyone, Jasmin here again and this time I am writing about Active Directory Federation Server (ADFS). Lately, I have been
getting several questions from most of my customers and some of my peers around ADFS deployment, planning, setup,
implementation etc. While addressing these questions, I realized that I was answering similar type of queries especially when it was a
first time ADFS deployment effort. I have therefore created a list of common Q/A around ADFS in hopes that it would benefit those
looking into federation for the first time.
What is ADFS?
ADFS helps you use single sign-on (SSO) to authenticate users to multiple web applications over the life of a single session. This is
accomplished by securely sharing digital identity and rights (Claims) across security and enterprise boundaries. Some of the ADFS
uses can be found here
What are the different versions of ADFS? Which one is the latest?
There are four versions of ADFS.
AD FS 1.0 - released with Windows Server 2003 R2 as part of the operating system and could be installed as a Windows
component.
AD FS 1.1 - released with Windows Server 2008 and was carried into Windows Server 2008 R2. In both editions, AD FS was
installed from the Server Manager as a role. There were minimal changes from AD FS 1.0 to AD FS 1.1.
AD FS 2.0 was released after Windows Server 2008 R2. It was released to the web and is free to download. It requires at
least Windows Server 2008 SP2 to install. Two versions (x86 and x64) are available for Windows Server 2008, while only the
x64 version is available for Windows Server 2008 R2.
ADFS 2.1 was released to Windows Server 2012 as part of the operating system and therefore, can be installed as a Role
from Server Manager.
One thing to note is that, AD FS 1.x is limited in its standards support which includes WS-Federation Passive Requestor Profile
(browser) and SAML 1.0 TOKENS while AD FS 2.0 extends standards support for WS-Federation. It supports WS-Federation PRP, WS-
Federation Active Requestor Profile, SAML 1.1/2.0 TOKENS, SAML 2.0 Operational Modes, IdP Lite/SP Lite/eGov 1.5
What is the benefit of installing ADFS on Windows Server 2012 versus on Windows Server
2008 R2?
In Windows Server 2012, ADFS 2.1 is released as part of the operating system and is installed from the Server Manager as a role.
Server Manager provides configuration wizard pages that perform validation checks and automatically install all the services that AD
FS depends on. Whereas, in Windows Server 2008 SP2 or Windows Server 2008 R2, ADFS 2.0 must be installed from the web. You
will also need to install the update rollup 3 for Windows Server 2008 and 2008 R2 which is located here. Furthermore, With Windows
Server 2012, the AD FS server role now includes new cmdlets that you can use to perform PowerShell-based deployment within your
federated identity installations and environments. Detailed cmdlets information can be found here. Lastly, with Windows Server
2012, AD FS can be integrated with Dynamic Access Control scenarios allowing AD FS to consume AD DS claims that are included in
Kerberos tickets as a result of domain authentication. More information on claims can be found here
Which AD FS configuration database store should I choose, Windows Internal Database
(WID) or SQL?
The AD FS configuration database stores all the configuration data. It contains information that a Federation Service requires to
identify partners, certificates, attribute stores, claims, etc. You can store this configuration data in either a Microsoft SQL Server 2005
or newer database or the Windows Internal Database (WID) feature that is included with Windows Server 2008,
Windows Server 2008 R2 and Windows Server 2012. Following is a short description of
WID Advantages WID Disadvantages
Very easy to setup and implement Supports five federation servers in a farm
Load balancing and fault tolerance is
possible if setup as a farm.
SAML artifact resolution and SAML/WS-
Federation token replay detection feature is not
available
Supports multiple Federation Servers in
a farm (limits to 5 federation server in a
farm)
It is not supported if there is more than 100 claim
trust providers trust or more than 100 relying party
trusts.

More info: In a farm with WID as the database, the first server in the farm act as the primary server and
host a read/write copy of the database. Secondary servers then replicate inbound the configuration data
into their read-only database. They are fully functional federation members and can service the clients
just like the Primary server. They are just unable to write any configuration changes to the WID which
does not take place every day.

SQL Advantages SQL Disadvantages
Supports multiple federation servers (not subject to
the limitation of WID)
Additional setup complexities. Require
PowerShell to install it
Load balancing and fault tolerance
SQL cluster introduces another potential
point of failure
Easily Scalable SQL server must be performing well to
service requests
SAML artifact resolution and SAML/WS-
Federation token replay detection supported

If the Primary Server in the farm is down, what happens?
Another server in the farm can be configured as the primary server. Below is the PowerShell command to run on the secondary
server which you want to make primary:
Add-PsSnapin Microsoft.Adfs.PowerShell
Set-AdfsSyncProperties -Role PrimaryComputer
Once the primary federation server is set run the following PowerShell commands on the other secondary federation servers to sync
them with the new Primary ServersCommand to run on the other farm member servers:
Add-PsSnapin Microsoft.Adfs.Powershell
Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName {FQDN of the Primary Federation
Server}
Is it possible to move from WID to SQL at some point in the future?
Yes it is supported to move from WID to SQL. Detailed steps are documented here

Is SAML artifact resolution and SAML/WS-Federation token replay detection feature
required by most Relying Parties?
From my experience most Relying Parties do not require this feature. However, there are some that do. So it would be wise to check
on that before deciding the database configuration store. If that is a requirement, the SQL must be selected.

What is the difference between a single ADFS server versus a farm? Which one is better?
ADFS can be setup as a
Standalone federation server.
Farm Federation Server using WID
Farm Federation Server using SQL
Farm federation server is definitely a better option than a standalone federation server for the obvious reasons scalability and
redundancy. Standalone federation server only support a single server and only store configuration information on a Windows
Internal Database (WID). Of course It is easy to setup and its best for lab environment but lacks scalability and redundancy.
Moreover, you cannot add more than one server to the Standalone federation server. However, with a farm federation server, you
can start a farm with one single ADFS server and add more ADFS servers to the farm at that time or sometime in the future. I often
get this question, can a farm federation server using WID function with one server? And the answer is YES! But remember you cannot
benefit from load balancing and redundancy since there is only one server in the farm. For more information on Federation Server
using WID or SQL please refer to the question of which database to choose.
Which type of certificates does AD FS require?
Basically you need three types of certificates.
Service communication certificate
o AD FS uses this certificate to enable HTTPS which is a requirement for traffic to and from the federation server
and federation server proxies ( to secure communication) So it is basically a SSL certificate which needs to be
installed on the IIS for each federation server and federation server proxy
Token signing certificate
o AD FS uses this certificate to digitally sign outgoing AD FS tokens. This is not used to secure data but in fact it is
used to ensure the integrity of the security tokens as they pass between the federation servers and application
server via the client computer.
Token decrypting certificate
o AD FS 2.0 and above has the ability to encrypt the contents of the AD FS tokens. This is in addition to having
these tokens signed by the server's token signing certificate.
Where can I obtain the required certificates from?
There are several options and each have their pros and cons.
Server communication certificate
o This certificate must be trusted by the client computers so it is recommended that in a production environment
this certificate is obtained from a public CA. Other alternative is to use your enterprise CA (PKI) to issues this cert
however, you will need to ensure that this certificate is trusted by all client computers. You may have to use
Group Policy to manually push down this certificate. Bear in mind that if the client machines are not joined to
the domain, they may not be able to trust your internal certificate which could result in bad user experience
such as receiving security ALERT prompts when they try to access the federated resources. In your test
environment, you can easily use a self-signed certificate if you wish as security is usually not of a concern in a
lab environment.

Token Signing Certificate
o This certificate can be issued via enterprise CA, public CA or by creating a self-signed certificate. The way it is
installed depends on how you create the AD FS farm. It is required that all federation servers in the farm use the
same token signing certificate. Hence you can install this certificate from the CA on a federation server and
export the cert along with the private key to other federation servers in the farm and save the cost involved in
obtaining a certificate from the public CA. However, the option that I personally favor is to allow what AD FS 2.x
does by default i.e. it creates a self-signed certificates for signing tokens. I like this option because the
maintenance is very low. It has a validity of one year after which it must be renewed however, AD FS provides
the capability for automatic renewal (Automatic Certificate Rollover) for self-signed certificates before expiry and
if the relying party trust is configured for automatic federation metadata, the relying party will automatically
sync the new public key.

Token Decrypting Certificate
o Similar to Token Signing Certificate AD FS 2.x by default will use another self-signed certificate for the Token
decrypting/encrypting certificate and as stated above, it also provides the capability for Automatic Certificate
Rollover.
How can I check if my ADFS server is operating successfully?
Check for Event ID 100 under Applications and Service Logs | AD FS | Admin. This event verifies that the federation server was able to
successfully communicate with the federation service.


Is there a checklist that I can follow to setup ADFS in my environment?
ADFS 2. 0 http://technet.microsoft.com/en-us/library/dd807086(v=ws.10).aspx
I also found a checklist specifically for Windows Server 2012 which is located at http://technet.microsoft.com/en-
us/library/dd807086.aspx
More useful resources:
AD FS 2.0 Step-by-Step and How to Guides: http://technet.microsoft.com/en-us/library/adfs2-step-by-step-
guides(WS.10).aspx
AD FS 2.0 Content Map: http://social.technet.microsoft.com/wiki/contents/articles/2735.ad-fs-2-0-content-map.aspx
That's it for now. As I get more questions, I will create part 2 of the ADFS FAQ.
Jasmin Amirali
How to Build Your ADFS Lab on Server 2012
Part 1
Hey yall Mark and Tom here with a series we think you guys will dig. I feel like half of our blog posts are building a lab of some kind. We love our labs in PFE. Thats
how most of us learn. Set up a lab, play around with the technology, and get it configured. Its fun for everyone! Right?! We are starting to get more and more
customer requests around people just starting out with ADFS. We thought wed get everyone starting by walking you through how to setup your very own ADFS
Lab.
Initial Setup
First you have to have an AD Forest set up. If you dont have that check out a blog post by Doug
Gabbard.http://blogs.technet.com/b/askpfeplat/archive/2013/01/30/no-excuses-you-need-a-lab-for-active-directory-2012.aspx
We are going to assume you have the following setup before you dive in.
Active Directory Forest
ADFS Server running Windows Server 2012
o Domain Joined
o Valid network configuration
Creating a Service Account
ADFS runs on a service account. This will need to be created ahead of time before doing the install.
Some warnings about this service account:
#1: Dont mess around with or set the Service Principal Names (SPN) on any accounts related to ADFS. The ADFS configuration wizard will automatically
configure the correct Service Principal Names (SPN) on this service account so dont worry about this configuring the SPN.
#2: Ensure that the physical computer name of any of the ADFS servers in the farm dont match the ADFS service name. If you plan to call your ADFS
service name sts.markmorow.com, ensure that none of the servers in the farm have this same actual computer name. If you do this, you immediately have a
duplicate SPN scenario, which will prevent Kerberos authentication to this ADFS farm. Here is more information on duplicate SPNs:
http://blogs.technet.com/b/askpfeplat/archive/2012/03/29/the-411-on-the-kdc-11-events.aspx
For my environment test environment I created an account called ADFS_SVC and my server is called ADFS01Corp.
Getting Certificates
As Jasmin talked about at http://blogs.technet.com/b/askpfeplat/archive/2013/07/22/faq-on-adfs-part-1.aspx we need three certificates on ADFS. But really, we
only need to have 1 setup to do the install. We need a Server Communications (SSL) certificate. We got three choices.
1.) You could use an publically signed external cert. Since this is TEST you may not want to pay for one.
2.) You can generate a self-signed cert. This has a great walkthrough on doing that. http://www.sslshopper.com/article-how-to-create-a-self-signed-certificate-in-
iis-7.html
3.) You can request a certificate from your internal PKI. You do have an internal PKI set up
right???http://social.technet.microsoft.com/wiki/contents/articles/4797.ad-cs-and-pki-step-by-steps-labs-walkthroughs-howto-and-examples.aspx
I picked #3. I had spent a few hours before and setup a PKI infrastructure in my lab. The walkthroughs are very easy to follow. Dont be scared.

First we need to request a certificate. We do that by going to the MMC snap-in, adding certificates for the Computer Account, Local Computer, right click Personal,
go to All Tasks, Request New Certificate.

We are going to select our Active Directory Enrollment Policy and click Next

If you dont see Web Server make sure your Web Server template is published and you have rights to it. As we can see here we need some additional configuration
information. Click on the blue text.

Our certificate name is going to be STS.yourdomain.com. Obviously configure this to fit your needs. Click ok and finish the cert process.
Installing ADFS
Ok now that we got all our pre-reqs in order lets do the actually install of ADFS.

Youll want to start by going to Server Manager and adding the ADFS role. Click Next

It will add any other additional roles and features it needs. Click Add Features and next through these new features until you hit the ADFS Role services.

After you next your way a few default screens youll come up to this screen. Well come back later to an ADFS Proxy, but for now just leave the Federation Service
checked. Hit next a few more times than Finish. Let the install finish.

You should see a yellow exclamation point at the top right to let you know there is additional configuration requirements. Click Run the AD FS Management snap-
in

Youll then get the ADFS Snap in to finish configuring. Click ADFS Federation Server Configuration Wizard

Since this is our first ADFS Server we are going to select Create New Federation Service and hit next.

Well be creating a server farm of one. Click next.

ADFS should automatically pick up the Server Certificate. Well click next.

Input the service account we created earlier and click Next. The install should start.

All done. We are now setup using the WID database. If you wanted to use a SQL database you would have to do the install from the command line. Check back for
Part 2 on how to configure a relaying party and a web app to view claims.

How to Build Your ADFS Lab on Server 2012, Part2: Web SSO
Mark and Tom here again, continuing our series on ADFS. In this post, we'll show you how to use some
sample-code to configure a web application for Web Single Sign-On (Web SSO) with ADFS.
What's Web SSO?
While Federated Web Single Sign-on (henceforth, SSO) is when two organizations create a federation
trust between each other for the purpose of sharing applications while still using their own credentials,
most of our customers are setting up ADFS for using Web SSO.
Web SSO is when a claims-aware web application, either on-premise or off-premise, is configured to
enable users to login to the application using their existing Active Directory credentials. Great examples
of these are ServiceNow for your helpdesk, Dynamics CRM Online for CRM, or an Office 365 SharePoint
site for collaboration. In a typical Web SSO transaction, the end-user will navigate directly to the web
application and the web application will determine that the user is not authorized and redirect them to
their ADFS server. There, they authenticate using integrated Windows authentication or by typing in
their credentials. Finally, they get redirected back to the application with a SAML token. The application
will then verify the SAML token and the web application will then load.
The key to remember here is that the claims-aware application never communicates with the ADFS
server directly. The client's browser handles the responsibility of authenticating against the ADFS server
and then the browser receives the SAML token, which it submits to the application. This is the reason
that Web SSO is described as a passive request; the browser isn't truly SSO-aware but is still capable
of BROKERING the transaction.
Having a sample claims-aware website that you can install, that also shows the claims that are being
sent, can immensely help in understanding Web SSO, how to configure the ADFS components, and how
to troubleshoot the claims that are being sent. Once you have this solid foundation, onboarding more
Web SSO applications for your users should be much easier.
What Do I Need for Web SSO?
The requirements are pretty simple. You need:
An ADFS Server. More than one, load balanced and using a SQL backend for prod. But, since this
is all about building a lab, one is just fine. For the purposes of this series, it should be on
Windows Server 2012 or 2012 R2.
An attribute store. This will be Active Directory, SQL Server, or an LDAP provider. Since 99.9% of
you (completely scientific statistic) will likely use Active Directory Domain Services, we'll talk
about that. We also won't talk about deploying AD, since you're probably already done with
that.
A claims-aware web application that has been configured to point to your security token service.
This should be on its own IIS server. We'll point out some sample code, share a sample test
application (Disclaimer: We aren't developers), and use Message Analyzer to highlight the
authentication flow.
Let's get to it!
The Lab
The forest we'll be using is called corp.milt0r.com. The ADFS service URL is https://sts.milt0r.com.
Finally, the test application will live on an IIS server at https://adfstest.corp.milt0r.com. In checklist
form, you'll need:
A working Domain Controller
A working ADFS member server. All of our examples refer to ADFS 2.1 on Server 2012, but
should apply to 2.0 on 2008 R2 as well, with the exception of the script. (See our previous
article to get ADFS setup)
A working IIS member server, running Windows Server 2012 or Windows Server 2012 R2
A client machine that is joined to your lab domain.
The URL of your web application
*Optional* An SSL certificate for your web application from a trusted CA
The Web Application
We started by grabbing some sample code from MSDN. You can find that code here. Then we were
shown some much nicer looking code (Thanks Dave) and used that instead. Since our primary focus in
this post is configuring web SSO from an infrastructure standpoint, we aren't going to cover the code
itself. To make it even easier, we included a PowerShell script that will set it all up for you. Both are
attached at the bottom of this post. Make sure to read the disclaimer
Setup Script
The setup script is going to do the following:
Create a self-signed certificate
Configure IIS (app pool, new site, HTTPS binding)
Modify the application's web.config file and federation metadata document to contain your STS
URL and application URL.
The script requires Windows Server 2012 or 2012 R2. It will not work on Windows Server 2008 R2.
Before running it, you'll need to collect some information. Those items are:
The fully qualified domain name of your test app. (ex: MyTestApp.corp.contoso.com)
The name of your ADFS server
You will need to manually perform the following:
Register an A record in your DNS zone for the test application
Ensure the PowerShell execution policy on your IIS server is set to remotesigned, and you've
run Unblock-File on the script, or set the policy to unrestricted.
Once you've got that, copy the ZIP file contents up to the IIS server. Unzip the script to a folder, and
move the entire deploy folder from the zip file to a location on the system drive. Now, run the script.
The parameters are pretty straightforward:

The parameters are as follows:
SourcePath: This should be the path to the web site code we've provided. In the example, we
had copied the site data from the zip file to c:\temp\deploy.
SiteName: This will be the name of the test site in IIS, as well as the application pool
SitePhysicalPath: The location on disk where the template site will be copied. We used
C:\sites\adfstest.
ADFSServer: The hostname/FQDN of your ADFS server (not the friendly name, but actual
hostname).
AppFQDN: The full qualified domain name of your test application. This will be set as a binding
on the site in IIS.
The script will install everything you need, including the necessary features and roles.
Creating the Relying Party Trust
A term you should be very familiar within ADFS is "Relying Party." But what's a relying party? Who's
relying on what? The RP can be a couple of things, so simply saying "Relying Party" is vague. Relying
Party can refer to:
Relying Party Application
o This is the application or service that relies on the claims for authentication.
Relying Party Trust
o The relying party trust is the connection between the relying party application and our
ADFS infrastructure. It's what we configure in ADFS to make the whole thing work.
We've already got our relying party application configured, thanks to the script and files above. Next,
we'll need to setup the relying party trust between the application and the ADFS server. To setup the
trust, you'll need the following information:
Path to the relying party application's federation metadata document.
Or, the UNC path to the federation metadata document. This will be under the test application's
site path.
Open up the ADFS Management console and right-click on "Relying Party Trusts" then "Add Relying
Party Trust."

Click start in the first screen. On the "Welcome" step is where we'll specify the location for the
federation metadata document. Here, you should be able to enter the URL to the metadata document.
If the certificate you used in the app isn't trusted by the ADFS server, and you use the Import data about
the relying party published online or on a local network option, it will fail. So, if you used our handy
script above, you can either 1) trust the self-signed SSL cert on the ADFS server or 2) Use the 2
nd
option
Import data about the relying party from a file.

If you had to use the 2
nd
option, it should look something like this:

Notice that we had to use the UNC path to the file, instead of the URL. If the federation metadata isn't
published or available, this is also a valid way to configure the relying party trust.
Click next. On the following screen, enter a descriptive name for the application, as well as any notes on
why this particular relying party trusts exists (process owner, app owner, related processes, etc).

Click Next. On the Choose Issuance Authorization Rules screen, make sure Permit all users to access the
relying party is selected. If you didn't want users to have access, you could deny all by default, then go
back and add "Allow" rules after. We'll cover that later.

On the Ready to Add Trust screen, review the settings and click Next. Finally,
click Close. Congratulations, you've configured the relying party trust! Now let's test!
Caveat: If your STS is in a domain that is NOT in the same domain as your machine, for example the STS
URL in this post issts.milt0r.com, but the client workstation is in corp.milt0r.com, you'll need to add
sts.milt0r.com to your intranet zone in IE to permit Windows Authentication. To do that, in IE go
to Internet Options -> Security tab -> Local Intranet -> Click the Sites button ->Advanced. There, add
your STS URL (ie, https://sts.milt0r.com) to the list. Click OK.
On your client machine, navigate to your application URL. You should see something like this:

You might end up with a certificate error if you didn't trust the certificate. But, if you see this screen,
you've successfully configured web single sign-on between your application and ADFS. The box that says
"Issued Identity" is where you'll see any configured claims. We'll cover that more in the next post in this
series.
Under the Hood
Now, let's take a look at what the authentication flow looks like in Message Analyzer.
First, we ran klist purge on the client machine, and opened an In-Private browser session, just to make
sure we didn't use any old cookies. Using Message Analyzer's web proxy and NDIS providers, we're able
to view the unencrypted traffic as captured on the client. Navigating to the application URL, the
conversation looks like the image below.
1) The browser connects to the web application. Since we're using passive claims, the web app provides
a 302 redirect to the browser, pointing it to the ADFS service (Frame 114)

If we dig in to the frame details, we can pull out the entire redirect URL:

2) In the next frames, we can see the browser connect to the ADFS service and receives a 401 challenge.

3) Having purged our Kerberos tickets, we see the full AS/TGS exchange. In 262-275, we see the
authentication service requests and replies. In 284 and 288, we see the ticket granting service request
for our STS http/sts.milt0r.com. We've authenticated and received a Kerberos ticket.

4) We present the service ticket to the STS and are authorized. The ADFS service processes our request
and, assuming the relying party trust is in place, knows whether or not to issue any claims and what
those claims should be. The security token is packaged up and returned in the HTTP reply.

5) Finally, the browser provides the SAML token to the relying party application. Based on the contents
of the token, the user may or may not be authorized. In our test app, we get a reply back from the
server that contains all of the claims in our token.

Wrap-Up
We hope this post takes you one step further in the process of getting your ADFS lab built and
configured. At this point in the series, you've built an ADFS server, installed a test application on the IIS
server, and configured a relying party trust between the test application and the ADFS service. In the
next few posts in the series we'll cover federating between two organizations, claim rules, and more.
Stay tuned!

How to Build Your ADFS Lab on Server 2012
Part 3: ADFS Proxy
Mark Morowczynski [MSFT]
16 Mar 2014 11:00 PM
6
Hey yall Mark and Tom back after a small hiatus. We (well mostly Mark because this was his responsibility) got distracted by other
things like helping customers, the Olympics and Im tired Ill do it tomorrow, whats on Netflix streaming?. Hopefully so far
youve followed along and have an ADFS server built and have a sample Web SSO so you can start messing around or if your
manager asks, learning about ADFS. By now the security group has probably gotten wind of this experiment and come to you with
Hey man, these ADFS servers can make claims about anyone, they are just like a DC, no way were putting these in the DMZ.
Technically this person is correct. You will want to protect your ADFS servers the same way you protect a DC. If you wouldnt put a
DC in your DMZ (hint you probably shouldnt) then same goes for ADFS. However you can now sit back and tell your security group
Dont worry, we got an ADFS Proxy.
Installing the ADFS Proxy Role
When you see how simple this is you will be ashamed it took me this long to write this post. Youll have a machine that can be
domain joined or doesnt have to be as long as it can talk to the ADFS server on port 443. Since this is a test lab, I do have my ADFS
Proxy joined to the domain. Start by click Add Roles and Features in Server Manager.

Click on Active Directory Federation Services

Accept all the requirements by click Add Features.

Select Federation Services Proxy and hit next.

Youll then click finish let it install.
Configuring the SSL and DNS
The next thing you are going to need to do is put an SSL cert on your ADFSProxy. This SSL name should ALSO match the SSL cert on
your ADFS server. This shouldnt be too much of a shock when you think about what role its providing. For external users or
applications that are external, they are going to resolve the same ADFS service name, in my case sts.markmorow.com and it will
connect to the proxy instead of the internal ADFS server. Which brings us to DNS. Its up to the administrator to configure the
internal DNS servers to point at the internal ADFS server and the external DNS servers to point proxy.

This is the error message youll get if you thought you were slick and skipped that last paragraph about SSL and DNS.

Right click the default website, edit bindings, Add port 443 and select a certificate. For this lab you can use an internal cert as well
but in the real world you will want to use a public cert.

After the SSL and DNS has been configured we are now ready to run the ADFS Proxy Configuration wizard.

Its a pretty short wizard as you can see, click Next.

Youll add the federation server you want to connect to, remember your DNS configuration from before so you should be pointing
to the INTERNAL adfs server, for me that will be sts.markmorow.com. Youll then enter your domain credentials to establish the trust.

Click Next

Alright you are done. The proxy is configured. A good way to simulate the proxy in a lab environment is to change your host file to
resolve that name to the proxy instead of your internal adfs server. So after this post you should have a fully functional test lab that
includes an ADFS server, ADFS Proxy and sample claims app. Dont worry folks we are just getting started on this topic, if you have
specific ADFS things youd like to see covered or any comments let us know below.
Mark didnt even medal Morowczynski and Tom coach Moser

How to Build Your ADFS Lab Part4:
Upgrading to Server 2012 R2
Mark Morowczynski [MSFT]
31 Mar 2014 12:00 AM
18
Hey yall Mark and Tom back again with part 4 in our most likely never ending ADFS series. Its going to end up being as long as Game of Thrones when its all said
and done, I can feel it. At this point you should have an ADFS server, an ADFS Proxy and a Web App all in your test environment. Now, you will notice that all of this
stuff was built on Windows Server 2012. You might even have wanted to ask us, Hey man, you guys picked Server 2012 instead building out your lab on that sweet
new ADFS 3.0 on Server 2012 R2. I followed along but built mine on Server 2012 R2. You guys must be crazy or something. Yea we are crazy alright, crazy like a
fox. Sometimes we have a plan, other times it looks like we have a plan. This one we actually did have a plan. We knew there are some folks out there already
running ADFS 2.0 on Server 2008 R2. We thought maybe they want to upgrade to the new hotness that is ADFS 3.0, so we planned an upgrade post for this series.
Youre welcome. If you are on ADFS 2.0 on Server 2008 R2 or ADFS 2.1 on Server 2012 you can follow along to get that lab up to the latest greatest. Lets dig in.
Pre-Reqs and High Level Process
Youll want two machines set up both Server 2012 R2, one that is domain joined which will be the ADFS server and one that is not. This will be the Web Application
Proxy (WAP) or what the ADFS Proxy has now become. Well get to this in a bit.
From the process standpoint we can break this down into a few key steps.
Export certificates from the current ADFS servers.
Export the configuration from the current ADFS servers.
Install ADFS 3.0 on the new server
Import the configuration on the ADFS 3.0 server
Install the Web Application Proxy (WAP) server
Test and make DNS changes to point to the new ADFS 3.0 infrastructure
Certificates on the ADFS Server
We first need to take a look at the different certificates we have. As we recall we have 3 certificates, the Service communication, the token-decrypting and the
token-signing cert.

If youve been using our previous guides youll most likely have something as above. A service communication certificate from your PKI and 2 self-signed certs. We
will now want to export out our Service communications cert. If you used a 3
rd
party cert on any of the other certs, youll want to export those as well. Our lab is
using self-signed.
To export the certificates open an MMC Console, Add Certificates, select Computer Account, Local Computer and Click Ok. It should look similar to this.

Next expand Personal, Certificates and right click the Certificate you want to export, pick All Tasks and select Export. Select next and should be at this screen.

Youll want to confirm the Yes, export the private key check box is selected. If its greyed out and you are using an internal PKI its possible you requested the
certificate without the option to allow the key to be exportable. This is why we have a test lab, people. Simply request a new cert, select the key to be exportable
and set this new certificate as the SSL binding on the site as well as the Server Communication certificate. Dont feel bad, the dates on my certs are different for the
exact same reason.
Now click Next, set a password on the certificate to export and click Next.

Select an output directory and click Next.

Then click Finish. You should get this message.

(Hooray!)
Then go ahead and copy this over to your new ADFS 3.0 server. Well need this certificate in just a bit.
Exporting the ADFS Server Configuration
Its time to back up our current ADFS server. Youve probably wonder how do I do that. Well there is a built in PowerShell script on the 2012 R2 media. Simply go to
\Support\ADFS and run the Export-FederationConfigration.ps1 Path Path to where you want it to go and the script will take care of the rest. It also gives you some
really important info youll need when you are setting up your new ADFS server, the farm name and the service account its going to be using.

ADFS 3.0 Install
This shouldnt be too much of a surprise but youll go to Server Manager and Add Roles and Features wizard. Youll want to select Active Directory Federation
Services as shown below.

Then click Next on the features install.

Click Next on the ADFS screen.


Once its done youll need to configure the service. Server manager should indicate you still need to do this as seen below.

At this point you would be inclined to say oh I have an existing farm, I want to join this to the existing one. Sorry, it doesnt work that way. What you will actually be
doing is standing up a new ADFS 3.0 farm. Select Create the first federation server in a federation server farm and hit next.

If you arent logged in with an account that has Domain Admin privileges you will need to enter an account and then hit next for it to connect.

Now its time to get that certificate ready. Click the import button, browse to that certificate, put the password you set on it in and you should be good to go. Few
things to also notice. Here is where you are going to set the name of the federation farm name and it should match what you exported from the old farm. Also
note that we are setting up an SSL cert without any IIS. Let that sink in. Click Next.

Now its time to put in the service account you are running ADFS under. This was also told to you during that PowerShell export. Once youve got that in, hit Next.

Time to enter in what type of database we want to use. In the previous version our only choice was WID unless we wanted to do this whole install via PowerShell,
where you were able to configure SQL Server. Now you can do either through the GUI. Since this is a test lab we are going to stick with WID. Click Next.

One last stop if we need to make any changes. We can also see how this would be configured via PowerShell by hitting the View script button. All looks good, lets
hit Next.

It will now do a pre-requisite check. If you get a pass, click Configure. If you didnt, its time to troubleshoot. If youve been following along you should be ok.

This is what you should get when its completed. Looks good.

Ok so lets take a second and make sure ADFS 3.0 is working as expected before we move on. To do that on the ADFS 3.0 server, open IE and go
to https://localhost/adfs/ls/IdpInitiatedSignon.aspx.
If everything is working you should get a nice page like the following. You can ignore the cert error for now as well.

Import the ADFS Configuration
At this point we have a nice, brand new, clean ADFS 3.0 instance. Thats great but we dont want to really set up all those relying party trusts. Time to import that
previous export. Copy over that export folder to the ADFS 3.0 server. Much like a great magician, we show you that there is nothing in the Relying Party trusts other
than the defaults.

Now lets run that sister script, Import-FederationConfiguration.ps1 Path Where you put the export folder. Its located also in the 2012 R2 media under
\Support\ADFS\. You should get something like that screen below.

And now your Relying Party trusts should look something like.

Bam! All that came over magically. Our lab is pretty simple but to see more of what you can export and import check out this TechNet article. At this point lets take
a step back and think about what we have going on. Currently all our DNS is pointing to the ADFS 2.1 infrastructure. We can update our host file on our test client
to point at the new ADFS 3.0 infrastructure. Once we are convinced its all working we can move on but note we havent affected our ADFS 2.1 at all. Its still exactly
the way it was before we started on this.
Installing the Web Application Proxy (WAP)
The WAP has lots of great new features which are well beyond the scope of this post (told you the series will be long). Much like the ADFS proxy, we can domain
join this or leave it in a workgroup. For this test lab, Ill have mine domain joined. At this time we will want to export the certificate on the ADFS proxy and import it
on to this WAP server before we get started. You would do this the same way described above for the export and just double click the certificate and follow the
quick prompts to import it. Also much like the ADFS Proxy we will make sure DNS or using our host file points to the back end ADFS 3.0 server. Be careful if you are
using DNS and are pointing to the ADFS 2.1 server. You want the WAP to point to the ADFS 3.0 not the 2.1 ADFS server. Make sense? Dont worry you got this.
Startup Server Manager and click Add Roles and Features Wizard and click Remote Access.

Hit Next at the features page.

At the Remote Access screen hit Next.

Add any features it needs for the install.

Now select Web Application Proxy and hit Next and finish the confirmation dialog box.

Once its all done youll need to do some quick configuration on the WAP to hook it up with ADFS. This should look familiar.

Now, just like the ADFS Proxy (notice how I keep stressing that), youll need to enter in the ADFS service name. This should be the name that is on the certificate
you exported. We will want to make sure this name resolves to the ADFS 3.0 server as well. Youll also need to enter some credentials for the ADFS server so it can
complete the configuration. Once youre done hit Next.

We are almost done; its a pretty short configuration process, similar to the ADFS Proxy. Select that certificate you exported and hit Next.

Take a last look and hit Configure.

At this point you are all set up. You can once again update your host file to point to this new ADFS WAP. You should get a screen much like this.

Notice DNS really controls who is hitting what. So we are able to completely test our ADFS 3.0 using host files to confirm it is working as expected before we make
the big DNS changes to cut it over, big for a test lab, of courseJ. Update your DNS records to point to the correct ADFS servers and you should be all set. You just
completed your very first ADFS upgrade.
Let us know in the comments of these post are helpful and what types of ADFS stuff you want to learn more about. Tom and a few of us got some ideas but wed
love to hear from you. Until next time.
Mark was late to the Red Wedding Morowczynski and Tom knows nothing like Jon Snow Moser