How Does Lockout Gate Work
I am back! I haven't forgotten you all. I was just busying with RTM Update 1 which is now live on Microsoft Update.
In Forefront Identity Manager - Credential Management, Part 2, i talked about what Lockout Gate is capable of doing and in the Password Reset Deployment Guide, it mentions if you put the Lockout Gate as the first gate, there is the possibility of DoS attack and the mitigation is to put a QA gate in front of the Lockout Gate.
I have received a couple inquiries regarding that point and I realize the documentation never explains how Lockout Gate works and why the ordering/position of the Lockout Gate relative to other gates matters. This post is trying to address them.
How it works
Each gate can be interactive (requires user interaction) or non-interactive; and regardless of which type of gate it is, gates are executed in sequential order one after each other. Lockout Gate is an non-interactive gate and it does the followings:
- It checks if the user is temporarily locked out. If yes, the authentication will fail and the user would receive an error message. Notice if the user is permanently locked out, the request processor will kick the user out in earlier stages and will never hit the Lockout Gate.
- Increments the lockout counter for the specific user.
- Temporarily or permanently lockout the user if necessary based on the updated counter.
It also registers itself to the workflow's Completed event, when signaled, will unlock the user.
Why ordering matters
Consider if you have Lockout -> QA in the AuthN WF, a malicious user can initiate SSPR for EmployeeA and intentionally fail the QA gate to permanently lockout EmployeeA. By changing the AuthN WF to QA -> Lockout -> QA, the Lockout Gate will not be hit unless the malicious use passes the first QA Gate. Please note that in this case, the first QA Gate is not protected by the Lockout Gate and is subjected to brute force attack. That is the price you have to pay to prevent DoS using Lockout Gate. You should work with your security compliance team in your organization to decide what is right for your company.
Once a while, I get feedback saying "I have failed the QA Gate many many times but the lockout logic does not kick in".
Usually that is because the Lockout Gate is sequenced at the end of the AuthN WF. Now since you know how Lockout Gate works, it is obvious that by putting it at the end of the AuthN WF, the internal counter of the lockout gate will be incremented but reset back to zero immediately after that.
FAQ: Why would canceling out from the QA Gate increment the lockout count
While it is true that you never fail the QA Gate, the lockout count is not kept in the QA gate. Thus, when you see the QA Gate, the lockout count has already been incremented (and in fact, the user is temp/perm locked out already). So it is not failing or canceling the QA Gate (or any gate) that increments the count, it is the fact that executing the non-interactive Lockout Gate increments the count.