Special Case: Dedicated SQL Server

By default, a Windows internal database (WID, formerly SQL Express) is created on the first server of a federation server farm. Whether you use Server Manager for the setup or automate the process with PowerShell, this database resides on the first, primary ADFS server and is only writable on this server. All other ADFS servers in your farm regularly receive copies of this database. The role of the primary ADFS server can be transferred to another federation server if the primary server is not available for a long time.

This behavior changes when a separate SQL Server is used for storage. Incidentally, use of this server does not need to be restricted to the federation services; it is also useful as a SQL Server shared by multiple applications. In the PowerShell examples above, a WID was automatically created by SQL options in the cmdlet. To use a separate SQL Server instead of a WID, you need to create unique databases on the SQL Server. However, you encounter a chicken and egg problem when you try to do this: The ADFS PowerShell module provides a cmdlet that creates the SQL statements, which, in turn, create the databases. But, the cmdlets are only located on a Federation Server, and these are not installed yet, because you don't have a database.

Note that the Active DFS PowerShell module is part of the ADFS feature. It is thus sufficient to add the ADFS feature to a future network server in advance. This is easy, requiring no certificates or other configuration, by using the Install-WindowsFeature cmdlet, as seen in Figure 3. An overview of the modules on a server is provided by the Get-Module-ListAvailable command. With the ADFS module now installed, you can generate the databases with the command:

Export-AdfsDeploymentSQLScript -DestinationFolder "C:\SQLScript" \
  -ServiceAccountName "kbcorp\adfssrv"

Now, specify the service account of the Federation Service so that the permissions are set in the databases for this purpose and so that a login account is created on the SQL Server. The result is the CreateDB.sql and SetPermissions.sql files. The file names describe the respective roles of the scripts. In SQL Server Management Studio, you can run them directly, but you must be a member of the sysadmin role.

Because of permissions granted in the databases, all federation servers within the farm are required to use the same service account. Once the databases are created, you need to use the cmdlets again to create a farm and add another node to the farm. The parameter that you now need to use for the SQL configuration is -SQLConnectionString; it essentially points to the SQL Server. The previous example would look like Listing 3.

Install-AdfsFarm -CertificateThumbprint $cert.ThumbPrint
  -FederationServiceDisplayName "KBCorp Federation" -FederationServiceName "sts.kbcorp.de"
  -OverwriteConfiguration:$true -ServiceAccountCredential $ADFSSrvCredentials
  -SQLConnectionString:"Data Source="SQL1.kbcorp.de";
  Initial Catalog=ADFSConfiguration;Integrated Security=True;Min Pool Size=20"

The -SQLConnectionString parameter is used here for a new farm node in the same way it is used for a new farm.

Integrating External Partners

Once your farm is running, you have an infrastructure that allows your users to authenticate against other IT environments based on SAML (Security Assertions Markup Language) tokens. However, there is much to do to make sure this works (i.e., you need to set up trust relationships with partners). A distinction is made here depending on whether your users need access to another network or whether you are allowing users on other network to access your resources.

The PowerShell engine for ADFS [5] offers everything you need to automate these steps. Office 365 certainly plays a special role in terms of trusts. Here, the user cannot use built-in tools on Windows Server 2012 R2 or the federation services and additionally requires the Microsoft Online Services Sign-In Wizard [6] and the Azure Active Directory module for PowerShell [7] on an ADFS management server. A three-part series by Microsoft describes step by step the task of setting up the federation services along with Office 365 [8].

Microsoft's identity tool portfolio is changing quite dynamically right now; it is thus prone to frequent updates and new features. The posting mentioned above is about a year old and based on ADFS 3.0. The overhead of building a lab environment might therefore be very much worthwhile. Additionally, this promotes an understanding of the necessary elements.

Automating Diagnostics

Microsoft support offers a PowerShell library that provides a useful supplement to the cmdlets included in ADFS. Although this library isn't an official Microsoft product and the manufacturer thus does not offer support or a warranty, the website with the download [9] refers to the moderated Microsoft Script Center for issues relating to the library. Apart from that, the cmdlets are not critical, because they only parse the federated landscape for diagnostics and testing purposes and do not support far-reaching configurations as of this writing.

Copy the downloaded library to a directory of your choice, and import it into PowerShell with the

Import-Module c:\Downloads\ADFSDiagnostics.psm1

command. To a certain extent, the cmdlets can be used for small-scale monitoring. The

Get-command -Module ADFSDiagnostics

command digs up all the cmdlets from the module, and you can use Test-ADFSServerHealth cmdlet for automated small-scale federated server monitoring.

In combination with the Task Scheduler, you can either set up scheduled tasks on each of the federation servers or create a task centrally on a workstation to check out what your federation servers are doing with PowerShell remoting (Figure 4). The cmdlet that gives you information on the status of the environment is:

Test-AdfsServerHealth | where {$_.Result -eq "Fail"}

Figure 4: The farm check can be automated in the Task Scheduler.

The command only returns rows that contain an error. Pour this into a .ps1 file that first imports the Diagnostics module and then executes the command. If you pipe the output of the cmdlet to an output file on a central file share to which all administrators have access using OutFile <Path\File>.txt, and you have an easy way to learn about the environment. This is only intended as a suggestion and to demonstrate the many possibilities.