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].  

001
002
003
004
005
006
007
008
009
010
011
012
013
014
015
016
$domain = "dc=contoso,dc=com";
$ouAdmin = "ou=Adfs Administration";
$ouServiceAccounts = "ou=Service Accounts";

$ldapConnection = [ADSI] "LDAP://$domain";

$newAdminOu = $ldapConnection.Create("OrganizationalUnit", $ouAdmin);
$newAdminOu.SetInfo();

Set-ADOrganizationalUnit "$ouAdmin,$domain" -ProtectedFromAccidentalDeletion $True;

$ouAdminPath = [ADSI]($newAdminOu.path)
$newAccountOu = $ouAdminPath.Create("OrganizationalUnit", $ouServiceAccounts);
$newAccountOu.SetInfo();

Set-ADOrganizationalUnit "$ouServiceAccounts,$ouAdmin,$domain" -ProtectedFromAccidentalDeletion $True;

 

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.

001
002
003
004
005
006
$dnsRoot = (Get-ADDomain).dnsroot
$pwd = read-host "Enter strong password" -AsSecureString
$upn = "SVC-ADFS" + "@" + $dnsRoot
New-ADUser –Name "SVC-ADFS" –SamAccountName SVC-ADFS –DisplayName SVC-ADFS -Description "Service account for ADFS farm" -userprincipalname $upn `
-Path "OU=Service Accounts,OU=ADFS Administration,DC=contoso,DC=com" –Enabled $true –ChangePasswordAtLogon $False -PasswordNeverExpires $true `
-AccountPassword $pwd

 
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. 

001
setspn -S host/contososerver.contoso.com contoso\svc-adfs

 

Step 7: Ok so now, let's add AD FS, which now is a role in Windows Server 2012.
 

001
Install-WindowsFeature AD-Federation-Services

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.

001
New-SelfSignedCertificate -DnsName fs.contoso.com -CertStoreLocation Cert:\LocalMachine\My

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.

001
002
003
004
005
#Run this if https for the default web site has not been enabled already             
New-WebBinding -Name "Default Web Site" -IP "*" -Port 443 -Protocol https

#Associate the cert with the SSL port 443 of the default web site
get-item cert:\LocalMachine\MY\[The cert thumbprint from previous step] | new-item 0.0.0.0!443


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.

001
002
003
004
005
$serviceAccountCredentials = Get-Credential
Install-AdfsFarm -CertificateThumbprint [The certificate thumbnail from the previous step] `
  -FederationServiceName fs.contoso.com `
  -ServiceAccountCredential $serviceAccountCredentials `
  -SQLConnectionString "Data Source=.;Integrated Security=True"

 

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