Tuesday, January 28, 2014

Cloud Authentication Primer: Basic Active Directory Federation Services Setup

Cloud computing. Cool stuff eh? Just pay your (not quite) local provider and all your problems are a thing of the past.

How are we going to authenticate/authorize our users? I dunno, but sign the contract now and you get a special price for a limited time!

Fortunately you're in luck. Microsoft released Active Directory Federation Services (ADFS) all the way back with 2003 r2 and released the much appreciated version 2.0 a bit after the release of 2008 r2 (install-able as an upgrade). Version 3.0 has just shipped with 2012 r2, and each release has brought many welcome new features.

Put (probably too) simply, ADFS allows you to extend your Active Directory space to other platforms, including Azure, Amazon EC2,  and other cloud services including those supporting SAML. By doing so, you can grant your already set up internal users access to new services located elsewhere. ADFS is also required for some Microsoft products including the new Web Application Proxy, which I'll be covering later. This isn't the only way to accomplish AD auth to other parties (AD Replica; IDaaS), but it's a great place to start.

The main components of ADFS are as follows:

  • Federation Service: This service on one to many servers facilitates the core functionality; sending/receiving authentication requests to/from third parties. 
  • Federation Service Proxy: Sits in a perimeter network (DMZ) and sends requests to Federation Service servers on the interior of your network on behalf of clients outside the interior. 
Highly simplified view of ADFS In Use; I'm guessing Bob is cool with that. 

With that primer set, let's walk through a basic install/test of a single instance of Active Directory Federation Services 3.0 on Windows 2012 r2. I will not be covering the proxy or services integration at this time.

Requirements


Other than domain admin rights as listed, you'll also need:
  • An Active Directory domain you would like to extend
  • 2012 r2 media and licensing taken care of. 
  • Domain Admin privileges; minor AD updates will be necessary and you'll need a new service account.
  • The ability to create new trusted certificates from either an internal or external source. (Need a new PKI setup? See my article here.)
  • At least one VM/Physical machine; One for the ADFS server and another as a shared database infrastructure if you desire. More on those options below. 
  • Desired server on the internal network and domain joined with access to Active Directory servers. 
  • Access to add records to DNS. (May not be required but I recommend it) 
  • (If applicable) Ability to create a new DB in a shared infrastructure. Note this is only a requirement if you do not intend to use the Windows Internal Database. 

Sizing


ADFS, like Active Directory and most related services, is not very demanding from a hardware perspective. A modestly sized VM is generally a good solution in most cases and scaling usually is realized horizontally, dictated by geographic concerns. You can use either the built in Windows Internal Database for ADFS or place the database on a shared infrastructure if desired. I will be using a shared DB infrastructure for this example. For more information on sizing, see this link. 

Step 1: Install ADFS Binaries

  1. Log on to the machine you would like to set up as an ADFS server with your administrative logon. 
  2. If not launched already, launch Server Manager and click Manage-> Add Roles and Features
  3. Click Next on the Before you begin page. 
  4. Select Role-based or feature-based installation and click Next.


  5. Select the appropriate server and click Next.


  6. Select the Active Directory Federation Services role and click Next. (Note that despite serving up some services via HTTPS IIS is not needed)


  7. No additional features will be needed; click Next.
  8. Read the ADFS notes and then click Next to proceed.


  9. Click Install to execute. When completed, do not configure ADFS yet.


Step 2 : Acquire Certificates 


For ADFS to function correctly you'll need at least one certificate. The certificates needed are for service communications and Token-signing. For the purpose of this tutorial I will not be replacing the auto-generated Token-signing certificate because the install will work fine without doing so. For a large scale, production installation, however, I highly recommend installing a custom Token-signing certificate after installation. For more information on how to do so, see this TechNet link.

As for the service communications certificate, this must be created to proceed. This can be either an internal PKI or third party cert so long as all clients intending to use ADFS trust the certificate. Obviously if you're working with a large third party (say salesforce.com) you'll need another third party's certificate (digicert for example). If you're working across your enterprise only, you can use your PKI but you will need to ensure all devices (mobile included for workplace join) trust your CA and your CRL needs to be accessible externally (see Publish Root CA CRL & CRT to Web) For the purposes of this example I'll be using the company PKI so expect specifics of certificate application to differ accordingly.

As for the certificate name you should pick the eventual external name of the ADFS service. Should you configure an ADFS proxy in the future, Microsoft instructions mandate the use of the same certificate. For this reason plan accordingly. Other SANs are necessary as well; we'll cover that below:


  1. Apply for a certificate; if using internal Microsoft AD PKI the web server template will work fine. 
  2. Set the common name to your desired external connection URL. For this example I'll be using fs.companyname.com
  3. Add the following DNS SANs (subject alternative names)
    1. fs.companyname.com (Yes, it's in the CN but needed here again to work properly)
    2. internalservername.internaldomain.lan (Unless you plan on splitting DNS internally) 
    3. enterpriseregistration.companyname.com (This is needed should you ever want to utilize Workplace Join and won't hurt you even if you don't) 


  4. Ensure the private key is marked as exportable as you'll need this cert for an ADFS Proxy in the likely event that you need it.


  5. Acquire the certificate and ensure it is installed correctly in the personal store of the local computer. 

Step 3: Configure ADFS


With your cert in hand we're ready to config ADFS. Be prepared to create a new service account for this step. 
  1. On Server Manager on the ADFS server, click the flag and then select Configure the federation server on this server.


  2. On the Welcome screen, select Create the first federation server in a federation server farm and click Next.


  3. For Connect to AD DS ensure you have the appropriate user selected. If it's the current user you won't need to change anything. Click Next. 


  4. On Specify Service Properties select the SSL certificate you imported earlier or import it now if you have yet to do so. 
  5. Ensure the Federation Service Name matches the external URL reference associated with the SSL certificate name. 
  6. Set the Federation Service Display Name to what you would like your users to see when using the service explicitly, i.e. "My Awesome Company". Click Next.


  7. As for the Service Account, I recommend using a Group Managed Service Account if your domain supports it (Windows 2012). If not, fall back to a Managed Service Account or standard Service Account. As I'll be using a managed service account we'll need to do the following; if not, substitute your own account creation needs for the sub steps below. 
    1. To facilitate the GMSAccount Open a Powershell prompt as administrator and execute Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)


    2. Close Powershell and return to the Wizard
  8. Select the appropriate service account type and specify a name. If using a GMSAccount the Wizard can create it for you. Be sure you give it a name that suits your standards (I use GS_ where G=Group,S=Service, _=meaningful) and click Next. 


  9. Select if you would like to use the Windows Internal Database or a SQL install/instance on a different server. In my example I'm using a dedicated SQL server. Click Next.


  10. On the Review Options page you will be presented with the information you have just entered. Ensure it is correct and click the View Script button. This is the Powershell equivalent for this installation; save it for later reference and perhaps use for another member in the farm. Click Next.


  11. The Pre-Requisite checks will run. Provided it passes, click Configure. 


Step 4: Configure Networking

  1. Add a DNS record to your internal network to point the public URL you specified in the SSL certificate to the internal address of the ADFS server. 
  2. If testing workplace join internally, add the appropriate enterprise registration DNS entry as well. 
  3. If you proceed further with an ADFS Proxy you will need to add an external DNS record at that time. 

Step 5: Test and Troubleshoot


After installation you can perform a simple test by navigating to:

https://fs.(companyname).com/adfs/ls/idpinitiatedsignon

Where the fs.(companyname).com represents the URL specified in the DNS SAN/CN of the cert. This should present you with the following logon screen: 

All you need do is click the Sign In button and you will receive a login prompt. If entered correctly and all is working you should get the message You are signed in. when completed. 



If you have any additional problems I can offer the following: 

  • The most interesting event logs are stored in Event Viewer->Applications and Services Logs->AD FS->Admin. 
  • If the configuration fails with a cryptic error message, ensure you don't have anything taking up port 80 or port 443. If either is taken the config routine crashes. 
  • If you need to re-do the installation for any reason that is fine, but make sure you overwrite the database. The easiest way to do so is use the powershell script we mentioned above, but add the -OverwriteConfiguration True parameter. 

In Closing

Clearly this is just the beginning. The next logical step would be to setup an ADFS Proxy and then establish relationships with your SaaS providers. We'll have more on that in the future. To get started now, check these thoroughly vetted and highly appreciated links, now with 86% less sand.

Edit: Dan Salmon from the good folks at RBA Consulting sent over this excellent Microsoft link that lists many SSO ready SaaS offerings. A great place to start if you're looking...

ADFS

WindowServer: ADFS Overview
TechNet: Planning for Federation Server Capacity
TechNet Security Forum: ADFS SSL Certificates
ADFS Product Support Blog: SSL, Token Signing, and Client Authentication Certs
MSDN Social: ADFS Token Cert - 3rd Party Cert Required?
TechNet: Certificate Requirements for Federation Services
TechNet: Token Signing Certificates
TechNet: Federated Web SSO Example
TechNet: Installing the ADFS Web Agent component of ADFS
Jeffrey Schwartz: ADFS 2.0 Open Doors to the Cloud
Example in Action: ServiceNow ADFS/SAML config

ADFS Proxy


Azure + AD


Misc


Thanks for reading!

Posted by at
Labels: , , , , ,
Subscribe to: Post Comments (Atom)