The Red Hat Magazine included an excellent tip about how to lock out a user, if it fails to supply a valid password for a pre-defined number of login attempts. This is implemented by making use of the The PAM module pam_tally. This practice serves as a barrier for those, either human or bots, who would try to guess a user’s password. But, is this method always pain-free for the sysadmin?

I guess not. In environments with numerous user accounts, the system administrator, by implementing such a password-guessing prevention barrier, should be ready to deal with those legitimate user account owners who accidentally mistype their passwords more than a couple of times in a row. In these cases, manual unlocking would be required, unless the unlock_time=n parameter is used in the implementation. This would unlock the account n seconds after the initial account lock-out. But, I guess these incidents cannot happen that often.

What seems that could be a real problem are those evil users who, as soon as they discover this implementation, will try to block out other users by continuously trying to login with other usernames, without knowing the passwords. So, in this case, the implementation above could very easily turn the otherwise probably harmless users into potential troublemakers. I know it would be easy to trace who was the one who caused the trouble, but even after that, a significant amount of time would have been wasted.

On the other hand, this lock-out policy is rather beneficial and generally results in increased security for the system by protecting it primarily from external possible threats.

Another thing I should mention is the fact that this policy does not affect the superuser. It requires to explicitely set the even_deny_root_account parameter to also affect root. This is generally good.

IIRC, in a Windows system such an implementation does affect local administrators by default. This means that if the administrator account is locked out, noone can unlock any accounts, until the specified amount of time has passed. A tip for these occasions in a Windows environment or if you have used the even_deny_root_account option under Linux would be to keep a separate administrator account with a username, which would not catch one’s attention, so it could be used to unlock the regular sysadmin.

So, finally I assume that if or how this policy should be implemented would require a bit of thinking first. It is absolutely beneficial, but it could also cause some trouble.

Lock out a user after N failed login attempts by George Notaras is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Copyright © 2007 - Some Rights Reserved