Use of pam_tally With Multiple Authentication Services and Colliding Userids

Latest response

In our environment, we currently leverage both locally-managed userids (e.g., for root and for application service accounts like "oracle") and AD-managed userids (for our interactive users and sysadmin staff). We also use the pam_tally module for each PAM module authenticated through. We use pam_tally to enforce our security requirements to automatically lock accounts after three failures.

Over the years of running this way, we've discovered that pam_tally can become a pain-point if you have collisions between the two authentication name spaces. That is, if userid "jxsmith27" exists in both the "files" authentication-domain and the "winbind" authentication-domain and both entries passwords differ, even on a successful login, pam_tally will increment. This is mostly just inconvenient if no one fat-fingers (tally-counter ends up displaying a misleadingly-high failure count) but highly problematic if you enter the wrong password even once. Mostly, we've avoided this problem by eliminating authentication-domain collisions over the years.

Recently, we were asked to merge some of our operational capabilities with another group. That other group uses an OpenLDAP back-end for their user management. To accommodate that, we'd need to add an LDAP module to our PAM config - and an associated pam_tally reference. While there may not be collisions between the existing "files" and "winbind" name-spaces and the coming "LDAP" name-space, we currently don't have access to their LDAP to be able to know for sure. Short of telling all remotely-authenticated users "you'll need to use fully-qualified userids (e.g., either an NTLM-style or Kerberos-style userid for AD-authenticated users and, presumably, a DN for LDAP-authenticated users) to login to avoid spurious lockouts", is there any way to still leverage pam_tally in a way that it only increments once, even if a userid lookup succeeds multiple times but a password-match fails for all successful userid lookups? That is, if a userid exists in two name-spaces:

  • increment a total of one tally-count if the password-match fails for both name-spaces
  • don't increment the tally-count at all if a password-match succeeds against one (or both) name-spaces
Th
Log in to join the conversation

Responses

Arpit Tolani's picture Red Hat Expert 1083 points
8 April 2013 5:42 PM

First of all, I will suggest you to move to pam_tally2 from pam_tally.

Second from what I understand you are configuring RHEL as a AD client & authenticating users with AD credentials. Now you want to setup account lockout policy based of failed logins in RHEL system.

In regard of Network users, You should not lock Network users with pam_tally2, Consider a situation.

- You have a AD server with password & account policy configured which will block users after three invalid logins.
- You also setup client to lock user after 3 invalid logins.

Now a user test user has three invalid logins & user is locked in LDAP as well as local system. Administrator has to unlock user at two places. In regard of AD users, Account Policy should always be configured at AD server. The ideal solution is to configure account policy in AD server & configure pam_tally for only local users.

Let me know if you want to implement this, I will provide you steps.

Now coming back to the original problem, You should never never have one same user added in local user & network both. Can you tell us why have you configured like this, may be we can come up with a proper solution for your environment.

ss Community Member 70 points
17 September 2014 10:50 AM

Hi Arpit!

I see this post of yours is already one and a half years old, but I'm wondering if you can help me out with avoiding double locking accounts for AD users(once by AD policy and twice by pam_tally).

Thank you,
Alex.

David Powles's picture Red Hat 25369 points
22 September 2014 3:14 AM

Hi Alex. It might be helpful to start a new, separate discussion for your issue.

Th Guru 2987 points
8 April 2013 7:17 PM
  1. We are using pam_tally2. I just tend to shorthand it, at this point, since it's been years since we deprecated the use of the old pam_tally subsystem in our enterprise.
  2. Negative on your understanding. Lockouts are already set based on failed login attempts. Simply trying to come up with a better method of handling name-space collisions - as the collisions cause spurious tally-increments.
  3. Don't really have a choice on this. Our security auditors tell us what we have to do. Whether or not it duplicates things elsewhere (it does) and whether or not it makes any kind of sense to do (in this case, it doesn't) - we're still stuck doing as they direct.
  4. There's no adminstrator intervention required - auto-unlock happens at our security-mandated minimums. Both AD-based and local tally-counters are configured for this.
  5. Yes, I'm fully aware that one shouldn't have collisions. However, such things aren't always preventable - particularly not when merging previously separate components into a larger, enterprise-whole. When you're forced to integrate multiple name-spaces - including ones that you have no authority to proactively de-lint - you're kind of stuck with a sub-optimal situation. The best you can do is try to anticipate likely pain-points and to reduce the levels of pain that inevitably come about.
Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.