ADFS (Active Directory Federation Services) has really taken flight since the inception of Office 365 and Azure Active Directory. Getting your on-premises environment configured with online identity services such as Azure, and having the SSO (Single Sign-On) abilities makes ADFS fundamental. Implementing ADFS is one thing, but what about monitoring your ADFS environment?
The following post is intended to illustrate the differences between ADFS monitoring by comparing the following monitoring tools: Azure AD Connect Health, OMS (Operations Management Suite) and SCOM 2016 (System Center Operations Manager).
SCOM (Operations Manager) 2016
First step is to deploy SCOM agents to your ADFS environment/servers along with the ADFS Management Pack install. Once that is complete, and discovery has run, we should start seeing data within the ADFS view(s).
Within the ADFS view, we can see some useful information such as Token requests. This data is represented in an hour fashion, and we can see the number of tokens being requested per hour over the given date range.
And good view is the Password Failed attempts. We can see how many bad password attempts were made over the various date range, but information such as which user, and when, could be useful.
This information is all good, however without doing some custom management pack work, it is impossible to get any additional data, ie. which users are requesting the token, which users are inputting bad passwords, and which users are connecting to which site/service offered by ADFS.
OMS (Operations Management Suite)
OMS does a nice job with dashboards, but unlike SCOM, we need to not only know which Event IDs we need to capture, we also need to build our dashboards out. This is not ideal, as it does require some custom work, and some investigation with regards to ADFS related Event IDs.
The query below, “EventID=4648 OR EventID4624 | measure count() by TargetAccount” shows us which target account/active directory user has requested the most ADFS tokens over the last 1 hour. Please note, this query is based on the OMS Log Analytics language version 1.
Since OMS does require a lot of ADFS knowledge, ie Event IDs, I decided not to proceed any further and build additional queries and dashboards.
Azure AD Connect Health
Lastly, Azure AD Connect is probably the most simple, and least technical configuration.
As a prerequisite, I enabled the all event types on the ADFS logs.
After running the AD Connect agent on the ADFS server(s). And launching the Azure Resource Manager portal, we get some dashboards. Right off the bat, we can see some excellent information. Let’s take a deeper look.
If we click on the total request widget, this shows us similar data as we see in SCOM 2016, with some exceptions. Not only can we see the number of tokens being requested. We also can see which ADFS server within the farm is distributing the tokens. Since this is a highly-available and load-balanced configuration, it is comforting to know ADFS is distributing tokens as it is designed.
Secondly, we can also see which services within ADFS are generating the most hits. This is great to see which sites are the most busy. This something that lacks in SCOM and OMS, and I was unable to generate even after some custom MP work.
If we go into the Bad Password Attempts widget, we can see not only the number of bad password attempts, but also see which user and at what time and their source IP the attempt was generated from — very cool!
Overall, AD Connect Health does an excellent job and provides rich data and expands on what SCOM already does.
After comparing SCOM 2016, OMS and Azure AD Connect Health, the clear winner is Azure AD Connect Health. Not only is the configuration straight forward, but provides more than enough information to monitor the ADFS environment. Azure AD Connect Health provides rich and very clear dashboards with almost no effect other than some log configuration on the ADFS server(s). The data is comparable to what SCOM presents, however much more richer and detailed. OMS and SCOM are still good tools, however does require some more technical knowledge and building the dashboards can be laboursome.