Hey y’all Mark and Tom back again with part 4 in our most likely never ending ADFS series. It’s going to end up being as long as Game of Thrones when it’s 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. You’re 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. Let’s dig in.
You’ll 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. We’ll get to this in a bit.
From the process standpoint we can break this down into a few key steps.
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 you’ve been using our previous guides you’ll 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 3rd party cert on any of the other certs, you’ll 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.
You’ll want to confirm the “Yes, export the private key” check box is selected. If it’s greyed out and you are using an internal PKI it’s 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. Don’t 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.
Then go ahead and copy this over to your new ADFS 3.0 server. We’ll need this certificate in just a bit.
It’s time to back up our current ADFS server. You’ve 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 you’ll need when you are setting up your new ADFS server, the farm name and the service account it’s going to be using.
This shouldn’t be too much of a surprise but you’ll go to Server Manager and Add Roles and Features wizard. You’ll want to select Active Directory Federation Services as shown below.
Then click Next on the features install.
Click Next on the ADFS screen.
Once it’s done you’ll 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 doesn’t 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 aren’t 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 it’s 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 it’s time to put in the service account you are running ADFS under. This was also told to you during that PowerShell export. Once you’ve 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, let’s hit Next.
It will now do a pre-requisite check. If you get a pass, click Configure. If you didn’t, it’s time to troubleshoot. If you’ve been following along you should be ok.
This is what you should get when it’s completed. Looks good.
Ok so let’s 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.
At this point we have a nice, brand new, clean ADFS 3.0 instance. That’s great but we don’t 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 let’s run that sister script, Import-FederationConfiguration.ps1 –Path “Where you put the export folder”. It’s 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 let’s 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 it’s all working we can move on but note we haven’t affected our ADFS 2.1 at all. It’s still exactly the way it was before we started on this.
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, I’ll 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? Don’t 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 it’s all done you’ll 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), you’ll 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. You’ll also need to enter some credentials for the ADFS server so it can complete the configuration. Once you’re done hit Next.
We are almost done; it’s 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 we’d love to hear from you. Until next time.
Mark “was late to the Red Wedding” Morowczynski and Tom “knows nothing like Jon Snow” Moser