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/