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

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/