Udostępnij za pośrednictwem

Gain insight into your AD FS traffic through “Azure Active Directory Connect Health”

  • Artykuł

Hello folks, my name is Gerardo Perez Ocampo, I'm a Senior Software Developer in the Customer Experience Engineering team at Microsoft.

On this post I will describe in a nutshell the "Usage analytics" capability of the new Microsoft Azure AD premium feature "Azure Active Directory Connect Health" and how it can be used to gain insight into the traffic of your on-premises identity infrastructure.


Current AD FS Auditing story

AD FS auditing is a very useful tool for AD FS administrators to monitor closely the AD FS traffic.

Unfortunately, the value of this auditing tool is often times not fully exploited by organizations due to the large amount of data that it generates and due to the fact that this data requires a deep understanding of AD FS concepts and must be parsed in order to discern each AD FS transaction and its corresponding outcome.

For example; the image below shows the event log entries generated by the AD FS auditing on a Windows Server 2012 R2 Federation Server.

The highlighted events correspond to a single WS-Trust Authentication request.

An AD FS request is processed by multiple subcomponents within the STS. These could be: receiving the HTTP request, decoding the headers, authorizing the caller, issuing the corresponding set of claims etc. Each of these subcomponents generate distinct audit events therefore, there is no single audit event that summarizes all the request's attributes.

In this particular case:

  • Event 403 specifies the client IP
  • Event 410 specifies the ADFS endpoint
  • Event 431 specifies the key type
  • Event 500 specifies the Issued identity
  • Event 501 specifies the caller identity (among other things).

In order for an AD FS administrator to determine all the attributes of a "logical login transaction" (this AD FS WS-Trust request), these audits must be associated to each other through the "Correlation ID" and "Activity ID" fields included on each event log entry. As you can imagine, this process can be tedious, error prone and time consuming.

 

"Usage Analytics" feature of "Azure Active Directory Connect Health"

When the "Azure Active Directory Connect Health" agent is installed on any supported AD FS STS (we support ADFS 2.0 on Windows Server 2008R2 as well as ADFS in Windows Server 2012 and 2012R2), the agent takes on the burden of parsing and understanding the contents of the AD FS Audit logs away from the administrator and uses the power of the "Azure AD Connect Health" cloud service to analyze and present the traffic of your AD FS infrastructure in a user friendly format.

Here is how it works:

As explained above, multiple AD FS Audits are created on the AD FS STS through the lifecycle of an AD FS transaction. Whenever an audit is created, the "Azure Active Directory Connect Health" agent dissects its contents and uses its "Activity ID" and "Instance ID" to create a "Logical AD FS Audit". As audit events come by, this logical audit will be updated to ultimately contain all the relevant information of each AD FS request such as Relying Party, Server Name, Authentication Method etc. (for security purposes, the agent does not include PII on the "logical audit").


 

At regular intervals, the "Azure Active Directory Connect Health" agent will take all the "Logical AD FS Audits" it has constructed so far and upload them to the "Azure Active directory Connect Health" service.

Every 15 minutes, the cloud service will aggregate the data that has been uploaded by all "Azure Active Directory Connect Health" agents installed on all the AD FS servers across the AD FS farm and update the "Usage Analytics" views to offer "Insights" into the identity traffic such as "Top application visits", "Total Requests by server", "Average unique users by Relying Party" (amongst others):

 

 

 

At the moment, the service offers two pivots to look at your data: "Total number of Requests" or "Unique User Count", each one of which has a different set of "Groupings":

 

 

I hope you will find this new Azure Active Directory Premium feature a valuable addition to your identity control plane.

Please try it out, as always, we'd love to hear any feedback or suggestions you may have.

For additional documentation, including step by step installation, please go to https://msdn.microsoft.com/en-us/library/azure/dn906722.aspx

Regards

Comments

  • Anonymous
    April 14, 2015
    This is awesome, but it would be even better to see the user activity too. So having a field to search by upn and see which RP Trusts the user accessed and which claims were presented. Thanks for your great work!
  • Anonymous
    May 28, 2015
    User activity would be helpful in determining why a user is having issues. I agree with JJ!
  • Anonymous
    November 16, 2015
    Do the AD FS servers need to have a trust with AD FS of Azure AD to be able to use this functionality? We have two on-premise domains, each one has an AD FS farm, but only one of these farms are used for Offifce 365. The other farm is not connected to Azure AD in any way. Can we still install the the "Azure Active Directory Connect Health" agent on these and use Azure AD Connect Health to do usage monitoring?