In this blog, I’ll go though the PKI portion of setting up Trey Research and Adatum. While you can do this a number of different ways – I always setup and use a Standalone CA instead of generating self-signed certificates.
In my opinion, setting up a new CA (or making an existing lab box a CA) is faster in the long run than using self signed certificates. Also, it offers a better user experience for testing. Self signed certificates should NEVER be used for production systems.
Often, people will start with self signed, then change to CA issued certs and then generate a huge mess in the ADFS snap-in and in the certificate stores. When you get into this mess, you will find yourself looking through the thumbprint of different certificates to find the right one. If you lab setup will eventually be turned into your production environment, then do yourself a favor and setup the certificates the right way from the start.
I’ll start with the initial lab setup and end this blog at the completion of the certificate portion of the setup. Then do a part 2 blog that completes the FS setup with a sample application (the blog application) and a couple claims.
I know Nick’s step by step get’s you to the same place, but I think the PKI differences along with the order of steps I take you through are worthy enough to blog about and will help people get a good test environment up and running in short order. Performing the steps in my order makes the setup more logical to me - guess that's why it's "my order"
One last note on this...I've worked with a number of customers who had trouble setting up the step by step and getting it to work. In almost all cases - the problem was that they deviated from the guide. Sometimes - not doing something as it says in the step-by-step guide (or changing it around) matters, sometimes not.
I will try to stop at certain checkpoints and explain what we have done and why we did it.
Here’s my method (using Virtual Machines):
1. Build a R2 Enterprise Virtual Machine and install IIS, ASP, .NET 2.0 Framework. Put the support tools and resource kit on it… BGINFO that puts the IP / Machine name info on your wallpaper is handy as well. Another suggestion would be to install TextPad or some other file editor that can look at .xml files and display debug log files better than notepad. Get that server just how you like it – then run sysprep on it and copy the .vhd file off to use as the base image for the rest of your setup.
2. Create two single dc forests - name them what you like, but as I've said in the past, my lab walkthoughs will always use Adatum and TreyResearch. You may choose to set things up with Account.com and Resource.com – whatever works for you. Here are full machine names for the machines we will be installing certificates – if you have different names – you can map them to mine for the rest of the guide.
a. Adfsaccount.adatum.com - Domain controller and Federation Server for Adatum.com (FS-A)
b. Adfsresource.treyresearch.net - Domain controller and Federation Server for Treyresearch.net (FS-R)
c. Adfsweb.treyresearch.net - Web server in the Treyresearch forest. (WS)
d. Adfsclient.adatum.com - XP client in Adatum - used to test the user experience
3. Install and join an XP client to the Adatum forest
4. Install (or add the service to an existing machine) a stand-alone certificate authority. You can name it something creative like "StandaloneCA" - doesn't really matter
5. Configure DNS forwarders so both all machines can resolve adatum.com and treyresearch.net machine names
6. Install SSL certificates on the default web site of the FS-A, FS-R, and WS
7. Install the Certificate Authority CA chain in the Trusted Root store of FS-A, FS-R, WS, and the XP client
8. Install a Token Signing certificate on the FS-A and FS-R in the local computer store of your FS/DC machines
Let's get started...
At this point, you should have the forests established, name resolution configured, and the domain controllers/federation servers and the Web Server should already have IIS/Framework 2.0 installed.
The first order of business is to install a SSL certificate on the default web site of all of the servers. I like to create a directory called c:\certs on each machine while setting things up. There will be certificate request files, certificate files, then export of certificates copied to other machines, etc. by the time we are all done.
It's easier/cleaner than tossing random cert files on your desktop or the root of the c: drive.
Start by adding an SSL certificate to the default web site of each machine. Launch the IIS Certificate wizard by going to Properties of Default Web Site - Directory Security tab - Server Certificate
When going through the IIS Certificate wizard – pay attention to the Common Name page. It defaults to just your computer name and we need to change this to the FQDN of the computer.
Change it to reflect the FQDN
When you have finished the wizard, save the request file in the c:\certs folder
Next step is to launch a browser from this machine and go to http://certicate-authority-name/certsrv to access the certificate services web page. Choose Request a Certificate, then Advanced Certificate Request
Choose “Submit a request by using a base-64…”
Next – paste the contents of the certreq.txt file you created when running though the Server Certificate Wizard in IIS.
Once completed, go to your CA machine and issue the pending request from the Certificate Authority snap-in tool
Back at server where you are installing the SSL certificate - from the main page on the certsrv website, you can choose “View the status of a pending certificate request”
Download the certnew.cer file and save it to your c:\certs folder as certnew-ssl.cer so you can keep track of what this certificate is for.
We are now ready to go back to IIS and install the certificate. If you go to properties - directory security tab - server certificate - you will get this dialog
Complete the wizard by selecting the certnew-ssl.cer file you obtained in the previous step.
Install the CA Certificate Chain
After installing a SSL certificate on the Default Web Site, the next step will be to install the CA certificate in the Trusted Root Store of the local machine.
From the main certsrv page, choose “Download a CA certificate, certificate chain, or CRL”
Select “Download CA certificate chain” towards the bottom and save the file to your c:\certs folder.
NOTE: If you choose “Install this CA certificate chain” link at the top of this page – it will install to the local users trusted root store which isn’t what we want – we need this in the local computer trusted root store.
Launch a MMC and add the certificates snap-in – choose local computer.
Right click certificates folder under Trusted Root – all tasks – import. Then browse to the chain file you downloaded in the previous step. After doing this, you should see your CA listed in this folder.
At this point, we have installed a SSL Server Authentication Certificate on the default web site and installed the CA chain in the local computer Trusted Root store. These steps should be repeated on the other Federation Server, the Web Server, and your XP client
Install the Token Signing Certificate
The next step will be installing a certificate to the local computer store which will be used for the ADFS Token Signing certificate. The token signing certificate can be any type (there is no EKU requirement for the TS certificate) and we don’t have to worry about the “issued to” name like we did with the SSL certificate.
From the main certsrv web page choose Request a certificate – advanced certificate request – create and submit a request to this CA
I change the type of certificate needed to Code Signing Certificate (but the type doesn't really matter). Select the checkbox to “store in the local computer store” to save a step later. Everything else can be left at the default.
Also – give this certificate a descriptive name in the friendly name field – we will want to differentiate this cert from our SSL cert at a glance.
Complete the request, then issue the pending request from the from the CA the same way we did for the SSL certificate, then take the browser back to “check the status of a pending request”
Now you can install this certificate to your local machine store by selecting “Install this certificate”
The FS-A and FS-R local computer computer store should look something like this
Remember – you will need 5 certificates in this setup example – 3 SSL certificates (adfsweb, adfsaccount, and adfsresource) and 2 token signing certificates (adfsaccount and adfsresource) installed in the local computer store. The Certificate CA Chain should be installed on every machine (client, FS, and WS) in the lab environment.
If you give some attention to detail on these steps - the rest of the setup will be much easier and you will get things working much faster at initial setup.
This completes the PKI portion and we are now ready to start the ADFS installation and configure the federation servers. I'll finish the part 2 blog that covers the remainder of the setup soon.
Hello! Very interesting. Thank you.
We are seeing quite a few support calls relating to certificate problems. Many of these are due to a
Thank you for this comprehensive explanation.
What about if we set up proxy servers?
Should we have 4 types of TS Certificates ?
- 1 for FS-A
- 1 for FS-AP
- 1 for FS-R
- 1 for FS-RP
Or only 2 types?
- 1 for FS-A and FS-AP
- 1 for FS-R and FS-RP
The ADFS Proxy component does not use a Token Signing Certificate. It uses a client authentication certificate. The client auth certificate is exported and placed on the trust policy of the Federation Server.
Can I have Web Server and Fed-R be same Virtual machine? Since I am a applicition Developer, I do not have the intimate knowlege of Setting on VM and DNS, activedirectory, "Configure DNS forwarders so both all machines can resolve adatum.com and treyresearch.net machine names" can you give it a sample?
I am getting the error below when trying to install the ADFS Windows components. I have run Windows updates, otherwise verified prereqs, fixed domain replications issues, double-checked certs. This machine is a DC at the forest root and also has Exchange and SQL Server on it. The error happens no matter what options I choose in the installer. This is the first ADFS component installed in this forest. Has anyone seen this error?
3352.3368> AdfsOcm-Error: Nov 03 08 22:07:56 RunExternalCommand failed for command line '"C:\WINDOWS\System32\msiexec.exe" /quiet /norestart /l*vx "C:\WINDOWS\adfsmsi.log" /i "C:\WINDOWS\adfs.msi" FRAMEWORKDIR="C:\WINDOWS\Microsoft.Net\Framework\v2.0.50727" ADDLOCAL=FS,WS,Common ADFSVDIR=adfs TARGETDIR="C:\ADFS" TRUSTPOLICYPATH="C:\ADFS\TrustPolicy.xml" THUMBPRINT=7CE0E7216E76178B6EB6298CF2F02C3272C98736 PATCH="C:\WINDOWS\adfs.msp"'
3352.3368> AdfsOcm-Error: Nov 03 08 22:07:56 ADFSOcmInstallUninstall failed with hr=0x80070654, hrFailure=0x0
To configure ADFS to work with SharePoint follow these instructions: Get your certificates ready ( http://blogs.technet.com/adfs/archive/2007/02/26/setting-up-an-adfs-lab-environment-part-1.aspx
Thanks for the excellent detail and example.
We're starting simple - one domain. The business requirement is to enable use of 'forms based' ADFS logon pages and have ADFS generate an NT Token for the user in the same domain, so the app runs under Windows security as the logged on user (like Basic Auth). All the examples seem to assume a much more complicated requirements scenario (2 domains etc). If it's not too much trouble, we'd appreciate a quick summary of just the steps and components required to use ADFS to allow multiple logon means within the same domain (ADFS forms logon triggering an NT Token for access to NT Token-based apps). Thanks!
Can the token signing cert be replaced after ADFS is fully installed? what do we need to take care of in this case?
Answer for joelrising:
I was experiencing the same error.
I found out this little tool `err.exe` which you can use for looking up error codes like 0x80070654
This results in:
# as an HRESULT: Severity: FAILURE (1), Facility: 0x7, Code 0x654
# for hex 0x654 / decimal 1620 :
# This installation package could not be opened. Contact the
# application vendor to verify that this is a valid Windows
# Installer package.
# 1 matches found for "0x80070654"
Therefore I concluded that the MSI file ADFS.msi I was using might be corrupt. I renamed c:\windows\adfs.msi to adfs.msi.BAK and ran the installation once more. The wizard prompted me for cd 2 of 'Windows Server 2003 r2', which contained a good version of adfs.msi.
Still haven't found out the reason why this file was corrupt.