It’s been over two years since my last foray into the murky waters of Active Directory Federation Services (ADFS) 2.0 and it came past due for a return to claims-based authentication and federation.
My previous journeys were somewhat chronicled here and here. This time around though, I’m going to be focusing on the latest and greatest – meaning Windows Server 2012 R2 (with update), which has been a far more pleasant journey thus far.
I literally started from scratch, because I rather like the environment to be clean before establishing a baseline configuration. From my earlier article:
so if you’re going to do this properly, get your certificates sorted out up front. My approach is to install and configure an Enterprise Certificate Authority and issue certificates from there. Then, it’s just a matter of trusting the root CA (signing) certificate in your environment, and your cert chain should be valid
I’m excited to say I took my own advise and started with the basics first. As you may recall from my earlier writing, my preferred scenario architecture is the segregation of external and internal entities by way of separate Active Directory forests.
As last time, I’m working predominantly with an initial set of four separate virtual servers, configured as follows:
Using an Enterprise CA, I trust the root CAs and then issue certificates as needed, and manage the DNS within each Active Directory forest. This time around I fully configured the CAs in both domains for web enrolment and device enrolment as well as updating group policy to include the Enrolment Policy locations.
I also added the Root CAs of each domain to the Trusted Root Certificate store in the opposite domain’s DC (where AD FS is located) so that the federation Uris would be valid when the trusts were established.
Believe it or not, this doesn’t take very long to set up. Configuring each domain at the same time (in parallel), I had most of the configuration working and tested in about an hour or so. Having done it many times before, I knew the correct order to install and configure which makes a huge difference.
Installing IIS on the CA server also means you can avoid having to install IIS on the domain controller server, which is a nice win in terms of resource minimisation.
Since we’re dealing with a few certificates here and there, it’s important to remember that clients/machines that do not trust the root CA signing certificate will experience warnings or other inconveniences – in other words, don’t do this in a Production environment unless it’s only used solely in-house, where you can deploy the CA signing certificate into the trusted root CA stores.
External AD FS installations should always be signed using a certificate from an external (public) CA like https://www.startssl.com which offers free class-1 certificates.
Certificate Path
My Desired Outcome
What I want to be in a position to do is to offer users a choice of realms:
For the sake of keeping things clear, I’ve labelled the relying parties to indicate which domain they live in, but you probably would label the DMZ as ‘External Users’.
What should happen, once a user has authenticated, is that their subsequent requests to claims-aware applications shouldn’t require any further authentication, and their identity should be available across both environments.
Generating Valid Certificates – The Low Effort Way
Another tip – the AD FS installation expects a certificate (plus private key) with the common name of the ADFS service you’re going to configure to be in the .pfx format.
if you want a fast way of generating a web server certificate and you have an Enterprise CA installed and configured within the domain, you can switch to IIS Manager and request a Domain Certificate when viewing the server features (under Server Certificates):
Here you can add the common name and friendly names
When you’ve entered the information, the wizard will go off and request a Web Server certificate based on the common name, and then will automatically store it in the Computer Account’s Certificate store. You can fire up MMC and add the Certificates snap in (FIle –> Add/Remove Snap In) making sure you select ‘Computer account’ along the way:
Once the certificate is located, you can simply export it including the private key. Just move the exported .pfx file to the ADFS host, and you’re ready to install with a valid certificate.
A word about ADFS installation
I’m not going to go into detail about how to set up AD FS 3.0 itself, the existing documentation on the Internet is quite accurate, and honestly, if you’ve established the environment correctly, it’s really not tricky to do. In Windows Server 2012 R2, ADFS 3.0 is a bona fide server role (in 2008/R2 the server role was ADFS 1.0/1.1, 2.0 was a separate download & install).
Sanity Checking the ADFS configuration
As mentioned in an earlier post, a quick browse to the following location: https://<your adfs location>/federationmetadata/2007-06/federationmetadata.xml should yield a metadata response:
Summary
This was just a brief intro to the environment I’ve configured, I’ll be going into more detail about how to live in a claims-aware environment in subsequent articles.
