This post is as much for me as anyone else (because I’ve done and forgotten how to do this three times thus I am writing it down). If you want to stand up a new Active Directory Federation Services (AD FS) 2.0 federation server as the first server in a farm using a SQL backend this is what you need to do.
Note. When setting up labs I generally configure “farms” of one server. For me this is more representative of what I’ll encounter in the real world. Even if you’re not planning on scaling out at the moment it is probably at least worth testing a configuration that will likely be deployed in production at least once before you try for real in pre-production.
This post dives directly into the configuration. I’m therefore assuming the following:
- You’ve built either a full installation of Windows Server 2008 x64 Service Pack 2 or Windows Server 2008 R2 Service Pack 1.
- You’ve joined the machine to your AD DS domain.
- You’ve installed AD FS 2.0.
- You’ve enrolled a Web Server certificate and created a HTTPS binding for the Default Web Site.
- You’ve created a service account for AD FS 2.0 and created the necessary HOST Service Principal Name (SPN).
Information on how to perform the latter three bullets can be found by following the links on this TechNet checklist:
AD FS must be installed first. The configuration is then achieved using FSCONFIG.EXE.
SQL Server
The FSCONFIG.EXE installation/configuration tool will create the SQL database if the context it is running under is able to do so, i.e. you have the necessary permissions in the SQL server you tell the tool to use. However if you don’t have the necessary permissions to do this then you can generate the necessary TSQL and provide .SQL scripts to the SQL Server administrators.
To generate the SQL scripts you run FSCONFIG with the following command line parameters:
fsconfig GenerateSQLScripts /ServiceAccount CORP\svcadfs /ScriptDestinationFolder d:\deploy\adfs\adfsSqlScripts Configuring the AD FS server with an account that has permission to create the SQL database
A clean installation, without the need for SQL DBA scripts, is achieved using FSCONFIG with the CREATESQLFARM command as follows.
PS C:\Program Files\Active Directory Federation Services 2.0> .\FsConfig.exe createsqlfarm /serviceaccountCORP\svcadfs /sqlconnectionstring "database=adfscfg;server=sql\idmdbs;integrated security=sspi" /autocertrolloverenabledEnter a password for CORP\svcadfs:********Creating a new federation server farm...Stopping the AD FS 2.0 Windows Service...PassedConfiguring the AD FS configuration database...PassedCreating an Active Directory container for sharing signing and decryption certificates...PassedConfiguring certificates, service settings, and endpoints...PassedDeploying the browser sign-in Web site to the /adfs/ls virtual directory under the Default Web Site in IIS...PassedStarting the AD FS 2.0 Windows Service...PassedCreating default claim set...PassedCreating default claim acceptance rules on the Active Directory claims provider trustPassedConfiguration is complete.
Here’s the screenshot:
Configuring the AD FS server with an account that does not have permission to create the SQL database
If the database exists, i.e. a SQL DBA pre-created it and you want to start over, as opposed to join, you use the CLEANCONFIG switch in conjunction with the CREATESQLFARM, as follows.
C:\Program Files\Active Directory Federation Services 2.0>fsconfig createsqlfarm/serviceaccount corp\svcadfs /sqlconnectionstring "database=adfsconfiguration;server=adfs\idmsys;integrated security=sspi"/autocertrolloverenabled /cleanconfigEnter a password for corp\svcadfs:********Creating a new federation server farm...Stopping the AD FS 2.0 Windows Service...PassedConfiguring the AD FS configuration database...PassedCreating an Active Directory container for sharing signing and decryption certificates...PassedConfiguring certificates, service settings, and endpoints...PassedDeploying the browser sign-in Web site to the /adfs/ls virtual directory under the Default Web Sitein IIS...PassedStarting the AD FS 2.0 Windows Service...PassedCreating default claim set...PassedCreating default claim acceptance rules on the Active Directory claims provider trustPassedConfiguration is complete.
Here’s the screenshot:
Joining an additional node to the farm
Once the farm is created you join additional nodes to the farm using the following syntax where the thumbprint is that of the service certificate configured within the farm.
C:\Program Files\Active Directory Federation Services 2.0>fsconfig joinsqlfarm /serviceaccount corp\svcadfs /sqlconnectionstring "database=adfsconfiguration;server=adfs\idmsys;integrated security=sspi" /certthumbprint "91 f4 55 10 e9 04 18 ea 16 af 0b eb a5 13 ce f1 36 64 6c 69" Enter a password for corp\svcadfs:********
A discussion on the certificate requirement and options is probably a good subject for a future blog post.
Wrap-up
I used automatic certificate rollover above because I’m lazy. I installed the service, setup the farm and then changed the signing and decrypting certificates using the UI. This is a little backward for anywhere other than a lab. In a real environment the certificates will be installed and you’ll utilise the following command instead:
C:\Program Files\Active Directory Federation Services 2.0>fsconfig createsqlfarm /serviceaccount corp\svcadfs /sqlconnectionstring "database=adfsconfiguration;server=adfs\idmsys;integrated security=sspi" /signingcertthumbprint "91 f4 55 10 e9 04 18 ea 16 af 0b eb a5 13 ce f1 36 64 6c 69" /decryptcertthumbprint "91 f4 55 10 e9 04 18 ea 16 af 0b eb a5 13 ce f1 36 64 6c 69" Enter a password for corp\svcadfs:********
If I were to use any kind of real excuse for this I would say it was so that I could post both variants of the command: that that generates the self-signed certificate and that that specifically references an existing, proper certificate.
