Reducing the Drop Height

The purpose of Active Directory Federation Services (ADFS) is to provide access to a different environment through a federation trust. Office 365 is a common scenario, but other target environments or applications are also common: SharePoint, Salesforce, or Google, for example. The important point is that both sides know each other, which is ensured when setting up the trust with certificates. In the home Active Directory, the ADFS server then ensures that a Security Assertion Markup Language (SAML) token is provided for users wanting to access the connected service; this token is used for access on the other side. In most cases, a WAP (Web Application Proxy) server comes into play in the perimeter network (DMZ); it knows the ADFS server in the neighboring Active Directory and controls access from the Internet.

For end users, this means they do not have to log in again by entering a password with their normal user ID when accessing the other service. The single sign-on scenario this creates is transparent and convenient for the user. In the background, however, a number of elements are responsible for the smooth process and present multiple sources of error that force the administrator to perform sophisticated monitoring at different levels. If the ADFS server no longer issues tokens, for whatever reason, all of a sudden, access is no longer possible. For Office 365, for example, this means that users cannot access their mailboxes with Outlook. Telephony will also fail if you use Skype for Business from the Office 365 portfolio.

Numerous Dependencies

ADFS has various dependencies. First is Active Directory, with the service account in whose context ADFS runs. It does not have far-reaching rights, but if it is blocked, nothing will work. It is also advisable to use a Group Managed Service Account for this purpose, which reduces such problems and also increases security. Active Directory also contains the Service Principal Name (SPN) for the ADFS service account, which is set up during installation and is no longer important for the admin. However, if a duplicate SPN appears, which is quite possible through misconfiguration, ADFS problems are assured.

An SQL server, which is required for storing configuration data, is another essential cog in the ADFS gearbox. You can either choose a Windows internal database (WID) running locally on the ADFS server or specify an existing SQL server during installation. If this causes problems during operation, authentication does not fail immediately, but the setup is modified. It is even impossible to restart the server without access to the database.

Certificates are particularly worthy of note; they form the core of ADFS and must be integrated into the monitoring system. Certificates are used continuously (e.g., to issue requested tokens), so if a certificate loses its validity because it has expired, ADFS functionality collapses like a house of cards. The above-mentioned Active Directory-related factors do not apply to the WAP server, because it is not a member of the Active Directory, but a single member of a workgroup. However, the SSL certificate on the WAP server, which establishes the trust between the ADFS and WAP servers, is also critical and needs to be monitored.

Monitoring via SCOM

If you already rely on the monitoring flagship System Center Operations Manager (SCOM), you can easily integrate ADFS servers there. The information that SCOM extracts from the collaborative services goes beyond plain vanilla problem monitoring. SCOM typically works in a reactive and proactive way. You always have everything in view, not just acute problems. With the help of performance monitoring and corresponding indicators (Server Performance Counters), you can perform trend analyses and identify bottlenecks at an early stage.

The different versions and history of ADFS are important in the context of SCOM. The management packs of older versions are not compatible with the management packs of other ADFS versions and must be integrated into SCOM for each ADFS release. If your ADFS server farm also contains Windows Server 2012 R2 computers, which corresponds to ADFS 3.0, you will need to integrate the Management Pack available separately. Do not try to initiate the download from the SCOM console. It makes more sense to download the Management Pack manually from the download page [1] and import it into SCOM. In addition to the Management Pack, you will also receive a Word document with valuable information about the setup and everything you need to know about SCOM monitoring of network services.

Targeted Parsing of Event Logs

The event log is still the place where all the information converges and all the server services file their messages. The setup of federation services has its own protocol that can be found under the Application and Service Logs node of the Event Viewer (Figure 1) and is where all irregularities are listed, along with information on the imminent expiration of certificates, even if still a few weeks in the future.

Figure 1: A separate event log provides information on the status of collaborative services.

Keep in mind that some information is also written to the security log, including, for example, incorrect password entries or the triggering of the Extranet Lockout policy, which prevents further input for external access after a certain number of failed logins has been exceeded. This design prevents a user's account from being locked in Active Directory. By the way, the Extranet Lockout policy, which allows you to monitor unauthorized access easily from the Internet, should be included in the planning of every ADFS farm [2].

To make sure that evaluating this plethora of information, no matter what the protocol, also benefits your monitoring setup, you will want to avoid having to click your way manually through several event logs in the GUI. The admin's PowerShell friend

> Get-WinEvent -FilterHashTable @{LogName='AD FS/Admin'; Level=2; StartTime=(Get-Date).AddDays(-7)} -ComputerName adfssrv1

shows you what went wrong on the adfssrv1 server last week. Especially worth mentioning here is the Level=2 parameter, which only lists errors. If you replace this with Level=2,3, the command also returns warnings. However, Get-WinEvent has far more to offer and can be very helpful if you plan to use PowerShell for monitoring. Microsoft describes the cmdlet in more detail online [3] and shows you, for example, how to iterate through a list of multiple servers with a one-liner.

Security monitoring is not enabled by default. A Microsoft article [4] describes in detail the policy settings required, and everything else you need. The article also documents how to enable the logging procedures, which I discuss below. If the settings were configured in line with the guidelines, you will in any case need to specify the logging scope in the ADFS server settings. These settings can be found in the properties of the ADFS service in the ADFS Management Console. Of course, it is also possible to use PowerShell:

> Set-ADFSProperties -LogLevel Verbose,Errors,Warnings,Information,failureaudits,successaudits