Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to implement account lockout for Ubuntu systems using pam_tally. The login should be disabled for certain interval on 3 invalid login attempts. This should happen for both system and LDAP logins to the system.

(We have a working LDAP central authentication system where users from Ubuntu clients can authenticate)

How can we configure this ? I could see some articles on this for redhat but not ubuntu

share|improve this question
PAM is a standard system, you should find it similar across not just Linux but to Solaris and the BSD's. – Steve-o Aug 30 '11 at 6:05
It might be similar, but the PAM config files are all different – nitins Aug 30 '11 at 18:33

If you have pam_tally configured already, you just need to add it to your /etc/pam.d/common-auth directory. Failed logins from LDAP should appear--to PAM--as the same as failed logins against your local machine. So just make sure you get the ordering correct:

auth        required      /lib/security/$ISA/ onerr=fail no_magic_root
account     required      /lib/security/$ISA/ per_user deny=5 no_magic_root reset

(Adapt paths as necessary)


share|improve this answer
Thats for Redhat I think. No /etc/pam.d/system-auth file in ubuntu – nitins Aug 30 '11 at 12:25
Sorry, on Ubuntu its named "common-auth", but it serves the same function. – Andrew M. Aug 31 '11 at 1:15
Thanks Redmumba , but I have already tried something like this. May be my ordering is wrong. I dont understand PAM properly to order it correctly. Any reference for PAM ? – nitins Aug 31 '11 at 4:50

The above answer is incorrect for modern RHEL 5 and Ubuntu installations. It was true at one point, and I cannot identify when the change occurred, but it did occur before the OP on August 30, 2011 (given the CIS benchmark published in Aug 2011). deny= needs to be on an auth line, not an account line. Various sources on the Internet are outdated/incorrect on this point.

See the man pages for pam_tally:

... you will see that deny is an "auth" option, not an account option.

These are the correct settings: (in system-auth/system-auth-ac in RHEL and common-auth in Ubuntu)

#Actually locks out the user; put BEFORE auth line.
auth    required deny=5 onerr=fail unlock_time=900

(in system-auth/system-auth-ac in RHEL and common-account in Ubuntu)

#Resets the failed counter if the user finally gets in successfully. This is only needed to support programs that do not call pam_setcred(3) correctly (like sshd). Put BEFORE account line.
account required

Note that pam_tally2 has replaced pam_tally. Pam_tally still works, and if pam_tally alone is used the deny=5 still must be on the auth line and not the account line. Pam_tally2 is recommended in the current versions of the NSA and CIS RHEL hardening guides.

Some Internet sources suggest that you add the magic_root statement so that the root account won’t become locked if a user enters an incorrect sudo password. I have not found this to be true in testing. If a user enters an incorrect password for su, that may be true, but no one should be su’ing to root directly anyway, and if they are and enter the incorrect password, that seems OK to me that root would be locked. If you do have magic_root, some sources suggest that you also then need to add lines in /etc/pam.d/sshd; I have not tried that.

Pam_tally2 has the following improvements/changes:

  • GLOBAL: New “silent” and “no_log_info” options
  • AUTH: even_deny_root_account -> even_deny_root
  • AUTH: per_user deprecated
  • AUTH: New root_unlock_time and serialize option
  • ACCOUNT: no_reset deprecated
  • “faillog” no longer works; use pam_tally2 to list locked users or reset users.

The correct setting is present in the NSA RHEL Hardening guide and newest CIS Benchmark for RHEL 5. The NSA RHEL Hardening guides notes that the behavior of pam_tally has changed during the lifetime of RHEL, and that the new, corrected settings may not work on systems that are not up-to-date.

NOTE: In RHEL 6, the syntax is different. This is shown in the CIS Benchmarks for RHEL 6, but I have not tested those settings.


share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.