Even if the Extranet Lockout is enabled my accounts was locked out.

Another Hard to Find case.

This time I was involved in a root cause analysis on a customer site after a brute force attack vs some ADFS endpoints.

Let me give you an overview of the infrastructure.

ENVIRONMENT DESCRIPTION

The customer environment is very huge and complex, but I have simplified it in the following picture:

Has you can see we have two forests one is a logon forest (where the users are) and one is a resource forest, where we have the ADFS Servers that are running.

In this table you can find the server version of the environments

PROBLEM DESCRIPTION

The Customer unfortunately was recently exposed to a brute force attack, and even if they had configured the ADFS Extranet Lockout, multiple accounts was locked outs, (more important the BIG BOSS account IS LOCKED OUT!!!).

The Customer want to understand why this happens even if the Extranet Lockout is enabled.

TROUBLESHOOTING

To reproduce this problem, we have involved the security team of the Customer (a big thanks to them!) for generating a brute force attack against the ADFS Servers. (don't ask: which tools have you used? I can't tell you)

• Before starting the simulation of the brute force attack we have verified the Lockout configuration in the environment:

• On the ADFS Configuration:
  

• On the Active Directory:
  

• Then we have enabled the Audit logs for the ADFS Servers:

  ====================================================================================

  https://blogs.technet.microsoft.com/bulentozkir/2016/05/11/ho-can-you-enable-auditing-for-ad-fs/

  ====================================================================================

   

• By using a third-party tool, to simulate a brute force attack, we reproduced the problem, and one of the tests accounts was locked out due to many failed login attempts, and from the logs we were able to view the exact cause (please, read the logs from the bottom to the top):

   

1. The row indicated by the blue rectangle, indicating the event 516 on the ADFS server, show that the User01 is blocked by the soft Lockout on the ADFS Server.

    

2. The row indicated by the green rectangle, indicating the event 512 on the ADFS server, show an authentication for the User01 was permitted after the end of the ExtranetObservationWindow.

    

3. The rows indicated by the yellow rectangles, we can see the events 411 on the ADFS Servers, and the events 4771 on the DCs of the Fabrikam Forests, all these events, show us that in the same second 12:04:55, we have received 6 authentication requests for the User01 that have caused the account Lockout.

    

4. The last row indicated by the red rectangle, indicating the event 516 on the ADFS Server, show that the account User01 was locked out.
   

NOTE: has you can see in the yellow part, we have exactly 6 events 411 for the ADFS Servers, but we have 8 events 4771 on the DCs, and the question is………. WHY?

To understand why, you need to read "How the Domain Controllers Verify the Passwords":
==================================================================================================

==================================================================================================

In short: the authentication from the Contoso ADFS forest to the Fabrikam logon forest, sometime are directly done by the PDC, but sometime other DCs in the Fabrikam forest authenticate the User01, in this case the DC forward the Authentication to the PDC , because it is a badpwd logon attempt, this cause 1 more 4771 event.

Trick: count the number of 411 events on the ADFS infrastructure, for a specific user, if you want to verify that you received more authentication attempt than the "Account lockout threshold".

CONCLUSION

So, we have verified that, during a brute force attack, if you have a low difference between the "ExtranetLockoutThreshold" and the "Account lockout threshold" on the Domain Controllers, you can have some accounts that will go in Locked-out.

This is due to the time necessary from the DCs in the FABRIKAM forest to send back the info (badpwdcount) to the ADFS Servers in the CONTOSO forest, usually in milliseconds, but in those milliseconds, we can receive other authentication requests that will lock the accounts.

MITIGATION:

To mitigate this behavior, you can increase the "Account lockout threshold" on the DCs to a more bigger value.
For your enterprise a good value is 50, but it is also better to increase the "Account lockout duration" to 15 min or more.

Official reference:

Account lockout threshold
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/account-lockout-threshold

Account lockout duration
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/account-lockout-duration

FINAL SOLUTION:

If you want to say "BYE BYE" to the brute force attacks, you can implement Azure MFA (Multi Factor Authentication).
If your ADFS Farm is 2012R2 you can easily migrate to 2016 and then implement the MFA.

Official reference:

Moving from a Windows Server 2012 R2 AD FS farm to a Windows Server 2016 AD FS farm
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server

Configure AD FS 2016 and Azure MFA
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-and-azure-mfa