« Previous 1 2 3 Next »
Monitoring Active Directory Federation Services
Reducing the Drop Height
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.
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)