[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: OpenLDAP with ppolicy and SSSD configuration question.

Unfortunately for me, I am in a situation where I have to trust PAM and not LDAP and don't have the luxury of binding for each user login.  I have to support SSH public keys or software we rely on doesn't work, commercial software I have no option but to use.  So yes, I trust PAM to know how to search LDAP based on my filters and ensure that I won't have 2 users with the same UID.  It's not perfect but its what I have.  So, I need a reliable way to lock an account that can handle both methods.  I am just trying to make the best of the situation and was looking for some help from the experts on the best way to handle that.

Again, I don't see the issue as sssd vs. OpenLDAP.  If I was using another package I'd be asking the same questions because my requirements don't change, I still need to support SSH keys and LDAP Binds.  Clearly there is some animosity between the OpenLDAP group and sssd group, on both sides as my experience here asking about sssd and on the sssd-devel list asking about OpenLDAP has shown me the last few days.  I don't really care about that.  I am just trying to make my setup work as best I can because its what my boss wants.  

Like usual, the end user is caught in the middle of the ongoing Open Source war of zealots who view their way as the only way and tend to forget the actual people who have to use the software they are developing, people who don't have the luxury of installing every package from tar.gz with their own custom compile time options in a nice test environment when users are all pretend and no ones account ever gets hacked.

As long as the accountLocked attribute is ACL'd correctly so that only key players can change it, it's no more or less insecure then any other piece of information in the directory.  You might as well argue that the rootDN should have a password no one knows because its possible that someone with the rootDN password could unlock a user's account by deleting pwdAccountLockedTime.  For all intents and purpose its a read only field that only gets changed when key events happen.

I appreciate yours and Michel's time in helping me solve my problem, I won't bother you further with my trivial user needs or issues.  Clearly you have more important things to do.

      -Brad Viviano

===================================================
Brad Viviano
High Performance Computing & Scientific Visualization
Lockheed Martin, Supporting the EPA
Research Triangle Park, NC
919-541-2696

HSCSS Task Order Lead - Ravi Nair
919-541-5467 - Nair.Ravi@epa.gov
High Performance Computing Subtask Lead - Durward Jones
919-541-5043 - Jones.Durward@epa.gov
Environmental Modeling and Visualization Lead - Heidi Paulsen
919-541-1834 - Paulsen.Heidi@epa.gov

________________________________________
From: Howard Chu <hyc@symas.com>
Sent: Wednesday, November 27, 2013 2:49 PM
To: Viviano, Brad; Michael Ströder; openldap-technical@openldap.org
Subject: Re: OpenLDAP with ppolicy and SSSD configuration question.

Viviano, Brad wrote:
> Howard,
> I don't see your point.

Clearly.

> I'm not debating a user providing a password or
> not.
I'm discussing how to inform the client that an account is locked. Slapd
already knows the account for DN=x is locked because the user provided an
invalid password too many times according the the policy and it set
pwdAccountLockedTime. The issue is, sssd, which is the standard for RHEL6 and
what I have to deal with doesn't understand that value. It wants a True/False,
not a timestamp. So what I'm asking about is, translating a timestamp to a
True/False.

slapd may indeed know that an entry DN=x has an accountLocked attribute set to
true, if you ask it. But *nobody* knows that DN=x corresponds to user y until
an LDAP Bind operation has been performed successfully for DN=x with a
credential that user y provides. Until you perform that verification step, you
cannot assert that any attribute in DN=x has any relevance to user y's login
attempt.

In your original post you talked about two scenarios:
   one, where a user logs in with a password, in which case an LDAP Bind is
performed and a ppolicy response control can be returned giving the account
lock status.
   two, where a user logs in with only an ssh public key.

In the first case, everything works and there's nothing to worry about.

The second case is what I've been explaining to you here.

If you are forced to rely on sssd then you are unfortunately being forced to
rely on an insecure system.

> I don't understand your second point. ANYONE can lock out a user with
ppolicy and that has nothing to so with sssd. I could do an ldapsearch and use
any users DN with an invalid password and lock them out if I hit the policy
settings that trigger the lock. Heck I could write a perl script that
requested every user with posixAccount objectClass and then proceed to bind
with invalid passwords to lock out the entire directory as a DoS.

Any such attempts would be obvious from syslog activity. What I was talking
about would be a simple LDAP Modify request that would never raise suspicion
or trip any alarms. But the obvious and more serious consequence is that the
Modify request could be used for the reverse - spoofing to re-enable a locked
account.

At any rate, as long as you insist on talking about how RHEL works I suggest
you contact RedHat for further support on this issue. It's their broken
software designs you're dealing with.

--
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/