[Date Prev][Date Next]
Re: OpenLDAP with ppolicy and SSSD configuration question.
Viviano, Brad wrote:
I don't see your point.
I'm not debating a user providing a password or
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
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
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
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
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/