Month: September 2017

ADFS Monitoring with Azure, OMS, SCOM 2016

· 3 Comments ·

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.

Verdict

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.

Differences Between Active Directory and Azure Active Directory

· 1 Comment ·

Lately, a lot of people keep asking, “What’s the difference between Active Directory, and Azure Active Directory?” Well, in short, a lot! Here is my take on it, and my typical response to customers.

One thing to note is, Azure Active Directory (AAD) and traditional/on-premises Active Directory (AD) are similar yet two very different things. One thing to note is, Azure Active Directory (AAD) and traditional/on-premises Active Directory (AD) are similar yet two very different things.

When you’re focusing on traditional On-Premises AD, you have the ability:

  • Create Organizational Units (OUs),
  • Create Group Policy Objects (GPOs),
  • Authenticate with Kerberos,
  • Working with a single domain (machine joins),
  • Query and interact with Lightweight Directory Access Protocol (LDAP),
  • Domain trusts between multiple domains,
  • And so on…

With Azure AD (AAD), functions mentioned above do not exist. AAD is simply an identify solution, and essentially a federation hub for online services, ie. Office 365, Facebook, and other various 3rd party applications/websites, etc.

  • Users and groups can be created but in a flat structure, things like OUs and GPOs do not exist in AAD.
  • Since there is no domain trust with AAD, federated services are used to create a relationship. This can be achieved with ADFS, which allows On-Prem AD to communicate and authenticate with SSO (Single Sign On).
  • Also, you cannot query against AAD with LDAP, however you can use REST API’s that work HTTP and HTTPS.

Here is a great article, along with many others on the web, that help explain. https://blogs.technet.microsoft.com/chrisavis/2013/04/24/active-directory-differences-between-on-premise-and-in-the-cloud/