Where can I get metric information about user logins for ADFS

  • Last Post 22 July 2014
BrianB posted this 16 July 2014

All:   My management would like me to record metric information from ADFS pertaining to the number of success / fail logins for ADFS, who is logging in using ADFS, Top users, etc.   I thought I could get that information from the SQL DB but it is not recorded in there. I found that if I enable Success/Fail logins on the ADFS Services node, I can get information in the security event log. Is that the only place I can obtain metric information for ADFS?       Brian Britt Senior Systems Analyst Vanderbilt University VUIT Identity Operations Team Office: (615) 322-4676 Lync: (615) 875-9858   Description: Description: MCSE(rgb)_406    Description: Description: MCSA(rgb)_440_454  Description: Description: Description: MCTS(rgb)_1078  

Order By: Standard | Newest | Votes
patrickg posted this 16 July 2014

Using ADFS under 2012R2 here and the only location is via the Security event log. With ADFS 2.1 and earlier there was some logging via modifying the web.config file

under the WSFederationPassive.Web directory. You could have a scheduled task using PowerShell querying against the security event log and dump the data into a SQL database.




Patrick Goggins

Senior Systems Administrator

University of Wisconsin - Green Bay





kool posted this 16 July 2014

There are PerfMon counters for getting raw numbers such as total logons and total failures. These can be read using the GUI or with code. I am using PowerShell like the following:


$reqs = Get-Counter -Counter "\AD FS 2.0\Token Requests" -ComputerName $computerNames -ev e2


These counters show the scale of activity but don’t give the level of detail you’d like. We are using ADFS 2.0 which enabled me to instrument the Home Realm Discovery page code-behind (we have multiple claims

trust providers, thus ADFS invokes the HRD page). I send that data to a SQL DB which allows me to see which RPs are getting requests and which ADFS servers are servicing those requests. We’ve had no requests for user-specific data thus I’ve not looked into

plumbing the event logs for that. I wonder if there might be PII privacy issues around user-based reports.


    Eric Kool-Brown, University of Washington - IT Identity and Access Management



joe posted this 17 July 2014

We do something a little crazy here but it has worked well for us so far. Essentially, we have custom attribute store that we invoke as part of the authorization rules processing in the "relying party" side of the claims processing pipeline. The attribute store is queried with standard parameters that we want to log (we use UPN, RP identififer, claims provider identifier and authorization result) and the attribute store actually logs the login event centrally. Right now it logs to SQL but we may change this to something else. 

It does not actually track login failures but gives us great high level tracking of which RPs are getting used by which users and which CPs. We had trouble figuring out how to stitch this data together from just event log output.

I doubt most orgs would consider something this involved to implement but I thought I'd throw it out there for consideration as well.


skradel posted this 22 July 2014

There was a similar discussion in late March titled "counting ADFS logins per RP" where I noted that event IDs 299 and 501 provide enough information about each user and the destination of the sign-in request.  However, Joe's approach with a custom attribute store might actually be easier to manage, so long as claims authorization rules don't play a major part...


joe posted this 22 July 2014

It is with some trepidation that I mention the approach we use as it is more complex than reading the audit logs but has been generally more useful to us too. One thing that is not mentioned in my post is that we've invested heavily in tooling to manage our claim rules in a standard way and have a framework for implementing authorization rules where this particular step fits neatly toward the bottom and is designed to work well in concert with the rest of the stack. We planned this out pretty carefully and got some great results at scale with it (>1500 RPs in production and counting). Most orgs probably don't have problems that look like this though and thus might not consider investments at this scale either.