As we apparently are in the age of DevOps, where automation of repetitive administrative tasks seem to be in the vogue, I would like to join in with a series of posts about how to streamline the deployment and administration of AD FS on Windows Server 2012.
My twist to the story is that I would like to deploy an AD FS farm in a test/lab environment with the AD FS configuration stored in a SQL Server database. Initially the one and only AD FS instance will serve as an IdP STS to enable internal Web SSO, and so only be used for authentication of internal users accessing internal applications (see part two).
I will make use of Powershell 3.0 to write scripts that I might be able to reuse in other environments later.
Luckily for me, I already have a fresh install of Windows Server 2012 on a VM and the machine has been promoted to be the domain controller on a fictional domain called Contoso.com. On top of that I have installed an instance of SQL Server 2012.
In this post the focus will be on setting the scene for later adventures with AD FS. So be prepared for some initial AD FS deployment stuff, presented in a step-by-step manner.
First a disclaimer: This lab worked on my machine (VM) and is here for conceptual illustration only. It is not intended to be used in a production environment. Also, it might just not work on your machine! For the full disclaimer, see my blog’s About page.
Step 1: Log on to the server with appropriate administration rights.
Step 2: Start the Powershell ISE 3.0 tool, run as Administrator .
Step 3: Adjust the execution policy for Powershell 3.0, if needed.
Step 4: Create some order in the AD: This script creates two OUs right under Contoso [Adfs Administration –>Service Accounts].
Step 5: Create the service account for the AD FS farm. When running this script, it will ask you to come up with a password for the service account called SVC-ADFS. Don’t worry about the account’s rights for now. It will automatically be assigned when installing the ADFS farm.
Step 6: Configure the Service Principal Name, SPN, for AD FS service account. The following one-liner does just this, after verifying no duplicates already exist.
Step 7: Ok so now, let’s add AD FS, which now is a role in Windows Server 2012.
That’s all there is to that. It will automatically add the web server role with IIS 8, for you.
Step 8: Create a self-signed SSL cert. Among the improved set of PowerShell commandlets that are being shipped with Windows Server 2012 we find one called New-SelfSignedCertificate. Its purpose is to create self-signed certificates for testing purposes. Note that Life is made simplier now that we are able to set the common name right. Let’s make use of it.
Make note of the thumbprint that was written out to the host, because we will need it in the upcoming steps.
Step 9: Associate the self-signed cert with port 443 for Default Web Site.
Step 10: Finally, we are ready to create the farm and its first federation server node. When asked credentials, supply the credentials for CONTOSO\SVC-ADFS.
You should now be able to see
- Two newly created databases in SQL Server: AdfsArtifactStore and AdfsConfiguration
- The service account CONTOSO\SVC-ADFS has been assigned approriate SQL Server rights
- A new web app under default web site: adfs/ls
- A new Windows service: AD FS Windows Service which runs under the account CONTOSO\SVC-ADFS.
That’s it for this time folks. I’ll be back with more posts on AD FS on Windows Server 2012. Until then: Happy New Year!
–> Part 2