After you have installed ADFS 2.0 on your server you will need to configure it for use (For information on installing ADFS 2.0 see Installing Active Directory Federation Services (ADFS) 2.0) . Using the configuration wizard is great but it will configure the server to use the Windows Internal Database (WID) as it’s configuration database. WID will work great in many environments as it is scalable, redundant and will let you add up to 5 ADFS servers in the farm but there are a few advantages to using SQL . If you decide to use a SQL server you will be able to use its high availability and backup features. Using SQL will also give you the added benefit of SAML artifact resolution and SAML/WS-Federation token replay detection. For more information on the SAML artifact resolution and SAML/WS-Federation, please go to Microsoft’s Technet Library and read about it. When using SQL for your configuration database, you must configure ADFS from the command line using fsconfig due to the fact that installing using the configuration wizard through the GUI doesn’t offer the option to use SQL. The configuration example I will be giving in this blog is meant to be used in a lab scenario since I will be using self-signed certs. I will be using a cert that I generate using selfssl for the Service Communication cert which is the cert that you bind to the default website in IIS as described later. The Token Signing and Token Decrypting being used will be self signed certs which are generated when running the ADFS configuration with the /AutoCertRolloverEnabled switch.
Preparing to run the ADFS Configuration
For the setup you will need to create a Domain User for the ADFS service (This will be your ADFS service account). You will also need to run the command logged on to the ADFS server with an account (Not the ADFS Service Account) that has the correct access to wite to Active Directory and the account will also need proper rights to SQL for creating the Databases. I just used a Domain Admin account and granted that account DB Creator and Security Admin in SQL.
Also, for the configuration to succeed, you will need to create a self signed cert as mentioned earlier. It seems when creating a self signed cert in IIS 7.5, it will only let you create a cert that uses the server name itself for the subject. For this reason, I used SelfSSL which is part of the IIS 6 resource kit because it gives you the freedom to create a subject name of your choice. The subject name of the Service Communication Certificate MUST match the name of the Federation Service Name. To create a self signed cert, download Selfssl to the ADFS server and open a command prompt as administrator. Change to the directory which contains the the Selfssl executable and type the following command replacing “adfs.pipe2text.com” with your own federation service name:
selfssl.exe /T /N:cn=adfs.pipe2text.com /V:365
Note: You may receive an error about being unable to open the metabase when running this command. You can safely ignore this error.
Using the /T will make sure the cert is place in the “Trusted Root Certificate Authorities” in addition to the “Personal” certificates on the local machine. Since this is a self signed cert and not issued by a trusted 3rd party CA like Verisign, it will need to be placed in “Trusted Root Certificate Authorities” for any machine that will be accessing the service using this certificate or there will be certificate errors. The “/V:365″ switch will make the cert valid for 365 days. You can increase this if you desire.
Now that you have your self sign cert created, you will need to bind it the default website in ISS following these steps:
1. Open the IIS Manager and right click the “Default Website” and select “Edit Bindings”.
2. Under “Type” choose “https” and under “SSL Certificate” choose the cert that was created using SelfSSL and click “OK”.
3. You will now see “https” and “443” in the list of site bindings. Click “Close”.
Now its time to configure the ADFS server. As mentioned earlier, since we are using SQL for the configuration database we will need to run the configuration from the command line. To do this you will need to use the fsconfig utility. To use the fsconfig utility, open a command prompt as administrator and switch to the “Active Directory Federation Services 2.0″ folder under the “Program Files” directory where fsconfig.exe is located. where fsconfig.exe is located. Type the following command replacing the information with information that is specific to your environment.
FSConfig.exe CreateSQLFarm /ServiceAccount pipe2text\adfslabuser /ServiceAccountPassword Password /SQLConnectionString “database=AdfsConfiguration;server=sqlservername\instance;integrated security=SSPI” /CleanConfig /FederationServiceName adfs.pipe2text.com /AutoCertRolloverEnabled
You will see the following output if everything ran ok.
A few notes about the above command.
The /ServiceAccount specifies the ADFS Service account (an account you created in your domain as mentioned earlier) to be configured to run the ADFS Service.
/ServiceAccountPassword is the password of the service account. If you don’t specify this switch it will prompt you for the password before it proceeds.
/SQLConnection is the name of the configuration database (It must always be “AdfsConfiguration”) and server is the name of the SQL server and instance name.
/Cleanconfig will clear out an existing ADFS configuration Database if one already exist.
/AutoCertRolloverEnabled enable the automatic rollover feature for signing and decrypting certificates. When this is enabled, self signed certs are used for the Token signing and decrypting certificates and they are renewed automatically. There are other switches that can be used to specify 3rd party certs for the token and decrypting certs but for this scenario I simply enabled the automatic rollover feature.
For detailed information on the using fsconfig to configure your ADFS server using different options and configurations you can simply type “fsconfig /help”.
Having a look around after the configuration was run
If you open the ADFS 2.0 management console you can look and see your Service Communication, Token Signing and Decrypting Certificates have been configured under “Service\Certificates”. Under “rust Relationships” you will see that Active Directory has been configured as a “Claims Provider Trust” and as an “Attribute Store”. Additionally, if you if you open the Services Console (service.msc) you will notice that the “AD FS 2.0 Windows Service” is configured to use the ADFS Service account. You can also open the IIS console and have a look under the default website to see that everything has been configured.
Now, if you look look in “Active Directory Users and Computers” (must be in “Advanced Feature View”) you will see the certificate sharing container was created under “Program Data\Microsoft\ADFS”.
On your SQL server you will notice that the ADFS Configuration and Artifact Resolution databases have been created.
Create an A Record in DNS for your Federation Service Name
You will need to create an A record on your DNS server for client’s browsers to be able to resolve the Federation Service Name. It MUST be an A record and NOT an alias (CNAME). If you use an alias you may run into things such as the browser prompting for credentials when hitting the ADFS server. In my case I added an A record for “adfs.pipe2text.com” with the IP address of my ADFS server. Just a note: If I had multiple ADFS servers in the farm I would have them behind a load balancer and then I would point the A record for the Federation Service Name to the Virtual IP Address on the load balancer.
Verifying your ADFS Server is Operational
To verify the ADFS server is now operational you can hit the following URL using your Federation Service name:
For Example using my federation service name it would be as follows:
If the server is working properly you will see an XML document displayed with the service description document.
Note: Since you are using self signed certs for the service communications cert, you will get a certificate error when connecting to the site since the cert is not trusted. You can just click continue to site. To avoid getting this error, you can export the certificate from your ADFS Server and import it to the “Trusted Root Certificate Authorities” of your client machine or just deal with the error.
Another step in verifying your ADFS server is by looking in the Event Viewer on the ADFS Server under “Applications and Service Logs\AD FS 2.0\Admin”. In the Admin log you should see event ID 100.
Now that your ADFS Server is setup you can add a relying party but I will save that for another blog. I will also be adding a blog on how to add additional ADFS Servers to the farm. I hope this was helpful. If you have any questions, comments or feedback please feel free to post them.