Azure AD Connect Health - Top Users with failed username password logins for ADFS

  • Article

[Update 11/3/2016: Added more information on IP address]

Hello!

I recently blogged about Alerts in Azure AD Connect Health. Connect Health is more than just being a monitoring system for your identity components on-premises.

In addition to monitoring, one of our goals is to use the power of the cloud to provide deeper insights into your on-premises identity systems for operational as well as security insights. For ADFS, we provide these insights by analyzing audit logs that are streamed to the Connect Health service. Today, with Connect Health, we provide login trending on the following areas

  • Successful logins that can be pivoted by Application, Network Location, Type of Authentication or the server. This can be useful for capacity planning, understanding your load balancing or seeing the trends of how end users login. For example, one of our customers used this to find the optimal down time across their global data centers for maintenance operations. Another customer, used this to see adoption trends for applications.
  • Failed logins that can be pivoted by the failure type (e.g. disabled account, username/password failure). This is useful from a security standpoint to understand baselines and observe trends. Changes in trends are likely to need you to dig in further.
  • Unique user account logging in via ADFS that can be pivoted by applications.This really gives the perspective of adoption & ROI for running the authentication service as it provides info on how many unique users are logging in through ADFS for your applications.

You can read more about this in our documentation here.

Today, we are announcing a much asked feature from our customers by providing a new report to view the top 50 users that are failing username/password logins. Let’s dig in.

Top 50 Users with failed Username/Password logins

In real life, it is quite natural for users to fail their login using username/password occasionally. It typically happens to me for the following reasons.

  • I have a complex password that I fat finger quite often especially on mobile devices
  • I forgot my password and take a few guesses on what it is
  • I make a typo on my user ID

But you can also see failed logins occurring due to the following cases

  • A badly written app saves the password for a user account and keeps retrying continuously even after the password has expired. (we see this quite often for some of our testing apps internally within Microsoft IT environment). In this case, if you know the app and the user you’d want to contact them and investigate.
  •  A malicious user attempting to sign-in to a user’s account with a series of well-known passwords.

Azure AD Connect Health for ADFS now uses all the login data (audits) to highlight the top 50 users with failed username/password logins. Let’s examine experience.

The Azure Portal Experience

Within the service instance blade, you will now see a part under ‘Reports’ that is an entry point to the failed username/password report.

Within this part you have quick access to the following pieces of information

  • Total # of failed username/password logins in the last 30 days
  • Average # of users that failed with a bad username/password login on a daily basis. This piece of data gives you a baseline and if you see this jump up, definitely something that you should pay attention to and investigate.

Clicking on this part takes you to the main report blade which looks like the below. Obviously, I've obscured the user id's below for privacy reasons.

The part of the experience is a graph that shows 2 lines for the following:

  • The total # of failed logins due to a bad username/password on a per-day basis. This great to get a good baseline for your current usage. You will typically see this # decrease during weekends and increase during the week.
  • The total # of unique users that failed logins on a per-day basis. This is also great to establish a baseline.

Not very well know is that you can hover on a data point which shows the value (Y-axis) and the day (X-axis). You can also hover near a data point that shows you the value (Y-axis) for all the lines.

The next section provides a grid view of the top 50 users. It contains the following information as columns:

  • USER ID: This shows the user id that was used. Note that the value is what the user typed in and in some cases, you will also see the wrong user id being used.
  • FAILED ATTEMPTS: This shows the total # of failed attempts for that specific user id. The table is sorted with the most # of failed attempts bubbling to the top so that you can see the top hitters.
  • LAST FAILURE: This shows the timestamp when the last failure occurred. This gives you sense if the problem is still occurring or has been fixed.
  • LAST FAILURE IP:   [Updated on 11/3/16] This shows the last IP address where we saw the failed request originate from. This requires ADFS 2012R2 (with the latest patches) or higher. See picture below for this.

aadch_baduppwd_04

NOTE:

  • Failed logins due to disabled accounts or locked out accounts are not included in this. If you'd like a separate report for this and it is important to you, do let us know (info at the end of this post)

A typical workflow to use the reports would be:

  1. Establish a baseline of failed logins and the # of users that have failed logins due to bad username/password. Any time you are above your baseline, dig into the top offenders.
  2. For the top offenders, check to see how many failed attempts they have. In a 30-day period, you shouldn’t see anything over a value of 100 (or a value that is deemed to not be a security event in your org). If so, it is likely that there is a rogue app and you can track down the rogue app by reaching out to the user. Also, check if the user recently changed their password resulting in the rogue app constantly trying to login with the expired credentials. If you find that it is a rogue app due to an expired password, do let the vendor know as this pattern is essentially vector for an inadvertent DOS attack.
  3. If it is not a rogue app, there is potential for malicious activity. You can take additional precautions by
    1. Resetting the password for the user
    2. Enabling MFA at ADFS or in Azure AD with Azure MFA
  4. For those of you who use AD Account Lockout Policies or ADFS extranet soft account policy, this also provides you a baseline # to set within your organization.

Let me show you an example. Below is a sample report.

As you can see, you have one account that started peaking with bad username/password logins around 9/10 and this was fixed around 9/21 and accounted for over 650K failed requests in that period! This was a rogue app that kept hammering on ADFS with an expired password.

That concludes this post. As always, if you have thoughts/feedback/comments/suggestions, drop us a line at the AAD forums, or leave a comment in this blog or just tweet (@MrADFS). We had a few other features/capabilities in this area and we deprioritized it and are happy to revisit it with your feedback.

Thanks

//Sam (@MrADFS)