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.

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

Comfortable: Connect Health

If you have an Azure Active Directory P1 Premium License, you should take a look at Azure Active Directory Connect Health. This monitoring solution is available for three Microsoft technologies: Domain Services (ADDS), Network Services (ADFS), and Azure Active Directory Connect (Sync). Each technology has its own agent, which you first need to download. It is only Azure Active Directory Connect that integrates the Health Agent.

The agent information converges in the Azure portal. The fastest way to reach the Azure Active Directory Connect Health Dashboard is from https://aka.ms/aadconnecthealth or directly from the Azure Active Directory Dashboard (Figure 2). The dashboard is organized in order of the three technologies and shows the health state of your monitored servers and services. In the dashboard, you will want to focus on the Quick Start area, which comes with useful documentation, including a video with information for getting started. The agents are also available for download there.

If you choose the Active Directory Federation Services area and then a federation service (sts.kbcorp.de in this case), you have three basic options:

1. Select the service name (sts.kbcorp.de) in the overview and be taken to the list of servers, which includes both ADFS and WAP servers. From there, you can view details of the systems, such as the version of the federation services, the "Behavior Level" introduced with ADFS 2016, which, like the functional level of Active Directory, becomes important for migrations with regard to the available ADFS features.

2. Select the Operations | Alerts area in the dashboard, which takes you to the farm details. The option of viewing incidents that have already been remedied is very useful. The ability to define the displayed time period and define who to notify by email in case of problems round off the possibilities.

3. Select the Monitoring area, where you can display the most important aspects of the ADFS farm in a diagram. Much like the Windows Server Performance Monitor, various metrics are available here. The number of Token Requests per second, for example, is probably an important indicator of capacity utilization, but the Extranet Account Lockouts are also an interesting indicator for detecting attacks on the farm from the Internet.

Free Monitoring Alternatives

Administrators who don't use SCOM to monitor their IT landscape and don't have an Azure Active Directory premium subscription have a variety of options they can use to see whether the ADFS landscape is still healthy. These methods can also make sense as a supplement to other monitoring systems or for test environments whose servers are not integrated into SCOM. Keep in mind that an ADFS server farm does not come with a large number of nodes, as is usually the case with a typical server farm, because of the architecture and because two ADFS servers in one farm are sufficient for an environment in which tokens are issued for several thousand users. The important issues for sizing can be found in an overview from Microsoft [5].

The number of servers to be monitored is therefore manageable, which makes it easier to integrate them into monitoring with Windows Server on-board resources. Server Manager is a quick and simple tool. You can add all existing ADFS servers there to the dashboard of your admin workstation and see centrally whether important services are running. Access and filtering of the event log by the severity of messages is also possible from a central location. The presentation of performance data and the results of the Best Practices Analyzer [6] round off the monitoring options in Server Manager at this point.

PowerShell Redux

Administrators who like to use PowerShell to monitor server services can use cmdlets to check ADFS and the WAP server. If you add the Active Directory Composite Services role (or Remote Access for the WAP server), the PowerShell modules are installed for that service. If you already have PowerShell-based monitoring that provides information about your server landscape on a regular basis (e.g., through the Schedule service), you will find a pool of cmdlets that can be integrated there.

View these cmdlets in the PowerShell ISE. If you select the module on the right side, all the cmdlets it contains are displayed on the left. Figure 3 shows an example with the WebApplicationProxy module, including the associated help. If you prefer to work at the PowerShell prompt, you'll find that the

Get-Command -Module adfs

command returns a list of the 170 cmdlets in ADFS 2016, some of which are useful for monitoring or just to see what's going on. For example, the Get-ADFSCertificate cmdlet displays ADFS certificate details. The expiration date on which the certificates lose their validity is important.

If you still have not found what you need for monitoring at the command line with the standard PowerShell modules, you should take a look at the free AD FS Diagnostics Module [7] toolbox, which goes one step further in terms of diagnostics and tests the ADFS landscape for inconsistencies. The disadvantage of this module is that, according to the website, it was only tested up to Windows Server 2012, which corresponds to ADFS Version 2.1. In Microsoft speak,"not tested" does not mean that it does not work, but only that there is no warranty and certainly no support. In any case, there were no errors in the tests for this post. The cmdlets don't perform any critical tasks, they just perform tests and read information. If you decide to rely on this module, you will still want to take a close look to ensure that the results of your individual ADFS setup are determined correctly.

Good news for subscribers to Azure Active Directory Premium 1: If you installed the Azure AD Connect Health Agent, the above-mentioned AD FS Diagnostics Module will also be installed on the server with the agent. According to comments in the PowerShell source code, this is tested for ADFS 2016. To use its cmdlets, you need to import the module with the command:

> Import-module C:\Program Files\Azure Ad Connect Health Adfs Agent\Diagnostics\ADFSDiagnostics.psm1

One of the most important cmdlets is Test-AdfsServerHealth, which runs a hodgepodge of tests examining, among other things, certificates and Active Directory to discover duplicate SPNs, as mentioned earlier.

If you give the cmdlet some additional parameters (e.g., Test-AdfsServerHealth | ft Name,Result), the output becomes more attractive. The command

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

only returns the results of the tests whose results failed. You can run the command at regular intervals using the scheduler service and redirect the test results to a file located on a central admin workstation. This gives you a complete mini-monitoring environment – for free. If the file is empty, everything is running smoothly. If errors are listed, something is wrong. The scope can be extended arbitrarily, and email can be sent to the admin team.

Trace Logging

For troubleshooting purposes, and perhaps because you are prompted to do so by Microsoft support, you can set up tracing (or trace logging, if you prefer), which is a kind of debug mode. Open the Microsoft.IdentityServer.Servicehost.exe.config file under C:\Windows\ADFS. When you get there, you will find further information on how to set up the SwitchValue for debugging. What you are not told, although it is indispensable, is that you need to enable the View | Show Analytical and Debug Protocols option in the Event Viewer, which exposes the AD FS Tracing node with the debug log (Figure 4); right-click the Debug log and choose the Enable Log option in the context menu. It does not make sense to run tracing permanently because it affects server performance and is really only designed for troubleshooting purposes.

ADFS 2016 still has an audit level that can be customized with PowerShell and is set to Basic by default, which is fine in most cases. If you are interested in further information, such as client IP addresses or other details provided by users when they log on, you can increase the audit level with the

Set-AdfsProperties -AuditLevel verbose

command. You can find out which audit level is currently set with the Get-ADFSProperties command.

Conclusions

Active Directory Federation services are particularly critical and important to the end user, so it makes sense to use the options discussed in this article to create a mix for monitoring. Why not use SCOM or Azure Active Directory Connect and PowerShell and Scheduler to monitor a couple of systems in the background? Dispatching email with PowerShell from an admin workstation to the team, triggered by the results of a cmdlet procedure, is no longer rocket science, and this double safety net will help you feel really secure as the employee responsible for your enterprise's federated services.