Proper care of your new ADFS server

Once implemented, ADFS becomes a vital part of your enterprise. Managing it and keeping it highly available is essential.

In the first part of this article, we looked at the process for setting up Active Directory Federation Services. But your work with ADFS doesn't stop after the setup is complete. ADFS is a critical part of your organization, so it's important to manage and keep it highly available. Let's take a look at some of the critical operations that come with having an ADFS server -- and at how to troubleshoot ADFS problems when they occur.

Updating ADFS server token-signing certificates

Active Directory Federation Services uses a token-signing certificate to digitally sign the token it crafts when the system makes an authentication request. This token is then sent back to the source of the request, which is referred to as the relying party. When an ADFS trust is created between two environments, the token-signing certificate is exchanged and ensures the remote partner environment can verify the validity of received tokens.

By default, ADFS uses a self-signed certificate. The general recommendation is to continue using self-signed certificates for the token-signing process. But a third-party certificate should protect communications that occur over the Secure Sockets Layer.

The default certificate comes with a validity period of one year. This means that after the initial exchange of the token-signing certificate, a new certificate must be configured before it expires. Additionally, the new certificate must be exchanged again with the remote partner organization.

Out of the box, ADFS is configured to automatically generate a new certificate when it's close to expiring. This behavior is controlled through the AutoCertificateRollover attribute of the ADFS server farm. To verify the current ADFS property settings, run the following command (Figure 1):

Get-ADFSProperties | Select AutoCertificateRollOver

ADFS properties commandFigure 1: ADFS properties command

If the remote organization supports dynamic updating for the federation metadata, you don't have to do anything. But Office 365 doesn't support this, so you'll need to manually update the certificate.

To manually update the federation metadata in Office 365, run the following commands from a computer with the ADFS server role installed:

Connect-MSOLService –Credential (Get-Credentials)

Update-MSOLFederatedDomain –DomainName <domainname>

You can execute similar commands from a non-ADFS server or script it using a canned script from Microsoft. If you still run ADFS on Windows Server 2008, you'll have to load the ADFS PowerShell snap-in prior to using ADFS cmdlets. Run the following command from the PowerShell instance:

Add-PsSnapin Microsoft.ADFS.PowerShell

Changing the primary federation server

The primary federation server is critical in a federation service farm that uses Windows Internal Database. The first server you install in the farm is automatically the primary federation server. All subsequent federation servers added to the farm will poll the primary federation server for configuration changes every five minutes by default. If it finds changes, they will replicate to a local instance of the configuration database.

Other servers remain operational if the primary federation server fails, but you won't be able to make changes to the ADFS configuration until the primary federation server is restored or another federation server is promoted as the primary server.

To promote a secondary federation server to primary, run the following commands from the secondary federation service you want to promote:

Add-PsSnapin Microsoft.Adfs.PowerShell

Set-AdfsSyncProperties -Role PrimaryComputer

After you set a new primary federation server, you need to configure the other secondary federation servers to sync with the new primary federation server. Use this command to run on the remaining farm member servers:

Add-PsSnapin Microsoft.Adfs.Powershell

Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName {FQDN of the Primary Federation Server}

Troubleshooting an ADFS server

Troubleshooting ADFS isn't one of the easiest things an administrator can do, mainly because there are a lot of moving parts involved.

First, look at how you can get more information out of your ADFS server farm. The application event log provides only limited information; there is no debug information available by default. So, when you start troubleshooting, make sure to enable the debug log for ADFS.

Open the Event Viewer, click the View menu and select Show Analytic and Debug Logs. This must be enabled to view the ADFS 2.0 Tracing log (Figure 2).

ADFS 2.0 Tracing logFigure 2: ADFS 2.0 Tracing log

Right-click the debug log under the ADFS 2.0 Tracing log and select Enable Log. Restart the ADFS 2.0 Windows Service (which is represented as adfssrv in the command prompt) either by right-clicking it in Services MMC or running the following commands at a command prompt:

net stop adfssrv
net start adfssrv

Once you enable debug logging, reproduce the error and see if there's anything useful in the debug event log. You may face another problem doing this, though. While ADFS is used in production, the event viewer can become cluttered. When you're troubleshooting a specific error, the events could clutter the view and make it more difficult to troubleshoot.

When filtering the ADFS event log, you want to capture all events related to a given transaction. You'll have to manually define a filter based on the ActivityID with these steps:

  1. Open Event Viewer.
  2. In the console tree, expand Applications and Services Logs, expand ADFS 2.0, and then click ADFS 2.0/Admin.
  3. On the Action menu, click Filter Current Log.
  4. Click the XML tab, and then select the Edit query manually check box.
  5. Click Yes when you are prompted to confirm manual editing of the query.
  6. Update the query to include the ActivityID attribute to set as the scope of the log filter (modify ActivityID with the exact value of ActivityID from your deployment), and then click OK. The query will look something like this:

    <QueryList>
      <Query Id="0" Path="AD FS 2.0 Eventing/Admin">      
        <Select Path=" AD FS 2.0/Admin ">*[System[Correlation[@ActivityID='{ 77269359-0b7d-45cb-9760-e3a4009883d9}']]]</Select>
      </Query>
    </QueryList>

Disable custom errors in an ADFS server

By default (and for security reasons), ADFS will not show exactly when the error occurred. But having more details about the error can be extremely helpful when troubleshooting. A regular error message is not very helpful at first and will be fairly generic (Figure 3):

Error messageFigure 3: Error message

Enabling custom error messages will give you more specific errors (Figure 4):

Custom error messageFigure 4: Custom error message

Add the following key to the web.config file to disable custom errors, which is typically located in C:\InetPub\Adfs\ls. The line should be added in the <system.web> configuration part.

<customErrors mode="Off" />

Don't forget to remove the key afterward so you don't give away the internals of your ADFS configuration.

About the author:
Michael Van Horenbeeck is a technology consultant, Microsoft Certified Trainer and Exchange MVP from Belgium, mainly working with Exchange Server, Office 365, Active Directory and a bit of Lync. He has been active in the industry for 12 years and is a frequent blogger, a member of the Belgian Unified Communications User Group Pro-Exchange and a regular contributor to The UC Architects
podcast.

This was first published in February 2014

Dig deeper on Microsoft Exchange Server and Active Directory

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

2 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchWindowsServer

SearchEnterpriseDesktop

SearchCloudComputing

SearchSQLServer

Close