Hello, I've searched the archives of this list, the web as best I can, and have this same question asked to the sssd-devel mailing list and can not seem to find an answer this my question. I have a RHEL 6.4 server with OpenLDAP 2.4.23-32.el6_4.1 and sssd 1.9.2-129.el6, both installed as standard RPM's from Redhat. I have ppolicy configured in slapd and on another RHEL6.4 system have sssd setup as a client. Everything works fine with password expires, grace periods, etc and sssd, if the user has to enter their password. But, if the user is using an SSH public key, setting the account as locked or the password is expired still allows them to log in. I can't seem to find a good solution that forces the user to change their password before they can login. The specifics are. sshd_config is configured to use PAM. My pam.d auth config is standard for RHEL6 which is:
auth required pam_env.so auth sufficient pam_fprintd.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so
I've confirmed that when a user logs in from ssh with both password and ssh keys, they are going through the PAM sss.so just fine, by turning up the debugging levels and watching the logs. I've read everything I can find on sssd and it appears that for all cases of LDAP, sssd wants a single true/false value along the lines of nsAccountLocked. I can't find anything in ppolicy that sets true/false for account locked like other LDAP implementations do, all ppolicy seems to provide is pwdAccountLockedTime.
While the issue seems more like a limitation on sssd's side, I thought I'd ask on this list to see if anyone has been able to come up with a solution or if there is something in ppolicy I am missing for a true/false on, is DN=X locked or not.
Thanks, -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
Viviano, Brad wrote:
Hello, I've searched the archives of this list, the web as best I can, and have this same question asked to the sssd-devel mailing list and can not seem to find an answer this my question. I have a RHEL 6.4 server with OpenLDAP 2.4.23-32.el6_4.1 and sssd 1.9.2-129.el6, both installed as standard RPM's from Redhat. I have ppolicy configured in slapd and on another RHEL6.4 system have sssd setup as a client. Everything works fine with password expires, grace periods, etc and sssd, if the user has to enter their password. But, if the user is using an SSH public key, setting the account as locked or the password is expired still allows them to log in. I can't seem to find a good solution that forces the user to change their password before they can login.
Why would you expect anything to validate their password if they are using an SSH public key? pam only gets the ppolicy info if it performs an LDAP Bind with the user's password.
Howard, I'm not expecting it to validate their password, I am expecting it to check if their account is locked for some reason. If their account is locked in LDAP, it shouldn't let them login under any circumstances. For technical reasons we need ssh public keys to operate (IBM GPFS), but I don't want the user to be able to circumvent LDAP authority. If I lock their account in LDAP they shouldn't be able to login to any system, and I shouldn't have to go to every one of my systems and disable their SSH keys manually.
The ideal case would be that ppolicy has an attribute that lists if the account is locked or not. This would also be useful when using pwdLockoutDuration. If I'm using pwdLockoutDuration and pwdAccountLockedTime is set, I don't really know if the account is locked because I then have to do the math and take the pwdAccountLockedTime and add the value of pwdLockoutDuration for the policy applied to that user and see if their account is in fact locked. If ppolicy just provided a true/false in addtion to the LockedTime, that would be much more useful.
Does anyone have a suggestions of a overlay that could create a derived attribute based on pwdAccountLockedTime so I could get a True/False value.
Thanks, -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: Monday, November 25, 2013 1:07 PM To: Viviano, Brad; openldap-technical@openldap.org Subject: Re: OpenLDAP with ppolicy and SSSD configuration question.
Viviano, Brad wrote:
Hello, I've searched the archives of this list, the web as best I can, and have this same question asked to the sssd-devel mailing list and can not seem to find an answer this my question. I have a RHEL 6.4 server with OpenLDAP 2.4.23-32.el6_4.1 and sssd 1.9.2-129.el6, both installed as standard RPM's from Redhat. I have ppolicy configured in slapd and on another RHEL6.4 system have sssd setup as a client. Everything works fine with password expires, grace periods, etc and sssd, if the user has to enter their password. But, if the user is using an SSH public key, setting the account as locked or the password is expired still allows them to log in. I can't seem to find a good solution that forces the user to change their password before they can login.
Why would you expect anything to validate their password if they are using an SSH public key? pam only gets the ppolicy info if it performs an LDAP Bind with the user's password.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Viviano, Brad wrote:
Howard, I'm not expecting it to validate their password, I am expecting it to check
if their account is locked for some reason. If their account is locked in LDAP, it shouldn't let them login under any circumstances. For technical reasons we need ssh public keys to operate (IBM GPFS), but I don't want the user to be able to circumvent LDAP authority. If I lock their account in LDAP they shouldn't be able to login to any system, and I shouldn't have to go to every one of my systems and disable their SSH keys manually.
You're missing the point. "ppolicy" is an abbreviation of *Password Policy* - if the user didn't supply a password, then the policy is irrelevant and cannot be applied.
pwdAccountLockedTime is set when a user has too many failed login attempts using their password. It is not a generic "account is disabled" flag. If you want that, you need to define your own attribute for the purpose because there is no generic *Account Policy* spec for LDAP. (This is in fact one of the outstanding objections to the last ppolicy draft, which prevented it from moving forward as a standard RFC.)
The ideal case would be that ppolicy has an attribute that lists if the
account is locked or not. This would also be useful when using pwdLockoutDuration. If I'm using pwdLockoutDuration and pwdAccountLockedTime is set, I don't really know if the account is locked because I then have to do the math and take the pwdAccountLockedTime and add the value of pwdLockoutDuration for the policy applied to that user and see if their account is in fact locked. If ppolicy just provided a true/false in addtion to the LockedTime, that would be much more useful.
Does anyone have a suggestions of a overlay that could create a derived
attribute based on pwdAccountLockedTime so I could get a True/False value.
Thanks, -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: Monday, November 25, 2013 1:07 PM To: Viviano, Brad; openldap-technical@openldap.org Subject: Re: OpenLDAP with ppolicy and SSSD configuration question.
Viviano, Brad wrote:
Hello, I've searched the archives of this list, the web as best I can, and have this same question asked to the sssd-devel mailing list and can not seem to find an answer this my question. I have a RHEL 6.4 server with OpenLDAP 2.4.23-32.el6_4.1 and sssd 1.9.2-129.el6, both installed as standard RPM's from Redhat. I have ppolicy configured in slapd and on another RHEL6.4 system have sssd setup as a client. Everything works fine with password expires, grace periods, etc and sssd, if the user has to enter their password. But, if the user is using an SSH public key, setting the account as locked or the password is expired still allows them to log in. I can't seem to find a good solution that forces the user to change their password before they can login.
Why would you expect anything to validate their password if they are using an SSH public key? pam only gets the ppolicy info if it performs an LDAP Bind with the user's password.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Howard, I understand what you are saying. It would of been nice if a generalized account locking method was included in the ppolicy or a similar overlay was available like other LDAP server implementations provide. But so be it. As others have suggested, I can spoof the same result, with some extra effort. I've added a schema extension called "accountLocked" which is a Boolean. If that is true, then sssd won't let the user login with either password or via SSH keys. Now, for the best way to implement that setting. I could write a perl script that queries every DN that has pwdAccountLockedTime and set the corresponding accountLocked to TRUE and run that from cron every 5 minutes, or something. But I thought I'd ask if someone could suggest a better way, something the slapd server could do already, with an overlay maybe, so I am not dependent on an external process to make this change.
Thanks, -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: Monday, November 25, 2013 1:38 PM To: Viviano, Brad; openldap-technical@openldap.org Subject: Re: OpenLDAP with ppolicy and SSSD configuration question.
Viviano, Brad wrote:
Howard, I'm not expecting it to validate their password, I am expecting it to check
if their account is locked for some reason. If their account is locked in LDAP, it shouldn't let them login under any circumstances. For technical reasons we need ssh public keys to operate (IBM GPFS), but I don't want the user to be able to circumvent LDAP authority. If I lock their account in LDAP they shouldn't be able to login to any system, and I shouldn't have to go to every one of my systems and disable their SSH keys manually.
You're missing the point. "ppolicy" is an abbreviation of *Password Policy* - if the user didn't supply a password, then the policy is irrelevant and cannot be applied.
pwdAccountLockedTime is set when a user has too many failed login attempts using their password. It is not a generic "account is disabled" flag. If you want that, you need to define your own attribute for the purpose because there is no generic *Account Policy* spec for LDAP. (This is in fact one of the outstanding objections to the last ppolicy draft, which prevented it from moving forward as a standard RFC.)
The ideal case would be that ppolicy has an attribute that lists if the
account is locked or not. This would also be useful when using pwdLockoutDuration. If I'm using pwdLockoutDuration and pwdAccountLockedTime is set, I don't really know if the account is locked because I then have to do the math and take the pwdAccountLockedTime and add the value of pwdLockoutDuration for the policy applied to that user and see if their account is in fact locked. If ppolicy just provided a true/false in addtion to the LockedTime, that would be much more useful.
Does anyone have a suggestions of a overlay that could create a derived
attribute based on pwdAccountLockedTime so I could get a True/False value.
Thanks, -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: Monday, November 25, 2013 1:07 PM To: Viviano, Brad; openldap-technical@openldap.org Subject: Re: OpenLDAP with ppolicy and SSSD configuration question.
Viviano, Brad wrote:
Hello, I've searched the archives of this list, the web as best I can, and have this same question asked to the sssd-devel mailing list and can not seem to find an answer this my question. I have a RHEL 6.4 server with OpenLDAP 2.4.23-32.el6_4.1 and sssd 1.9.2-129.el6, both installed as standard RPM's from Redhat. I have ppolicy configured in slapd and on another RHEL6.4 system have sssd setup as a client. Everything works fine with password expires, grace periods, etc and sssd, if the user has to enter their password. But, if the user is using an SSH public key, setting the account as locked or the password is expired still allows them to log in. I can't seem to find a good solution that forces the user to change their password before they can login.
Why would you expect anything to validate their password if they are using an SSH public key? pam only gets the ppolicy info if it performs an LDAP Bind with the user's password.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Viviano, Brad wrote:
I understand what you are saying. It would of been nice if a generalized account locking method was included in the ppolicy or a similar overlay was available like other LDAP server implementations provide.
It's very easy to lock accounts (or whatever entries) by ACLs.
Ciao, Michael.
Adjusting ACL's seems like overkill for this situation and I have to work within the bounds of what sssd offers. sssd doesn't have a native check for pwdAccountLockedTime when it does ppolicy based checking, the code just isn't there. sssd for LDAP auth does support a True/False check for account locked, which is how Redhat DS, 389ds and IPA do it, from what I've read. I've added a True/False as a schema extension, tested it and it works. If I manually set accountLocked to TRUE on a DN, the user can't login at all, it logs in the messages file the account it locked. Works perfect.
My question is, is there a better way to set that True/False attribute value based on pwdAccountLockedTime. What I am looking for is, if pwdAccountLockedTime is set for DN=x, then also set accountLocked=true for DN=x. Sure, I can do that with an external script, but is there a way to do it from within slapd.
Basically can I create a virtual attribute so when a user queries for accountLocked, it actually does a check for something else (pwdAccountLockedTime) and based on that value returns True or False. I'm thinking in terms of a stored procedure offered on many SQL servers.
Thanks, -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: Michael Ströder michael@stroeder.com Sent: Wednesday, November 27, 2013 9:35 AM To: Viviano, Brad; openldap-technical@openldap.org Subject: Re: OpenLDAP with ppolicy and SSSD configuration question.
Viviano, Brad wrote:
I understand what you are saying. It would of been nice if a generalized account locking method was included in the ppolicy or a similar overlay was available like other LDAP server implementations provide.
It's very easy to lock accounts (or whatever entries) by ACLs.
Ciao, Michael.
Viviano, Brad wrote:
Adjusting ACL's seems like overkill for this situation and I have to work
within the bounds of what sssd offers. sssd doesn't have a native check for pwdAccountLockedTime when it does ppolicy based checking, the code just isn't there. sssd for LDAP auth does support a True/False check for account locked, which is how Redhat DS, 389ds and IPA do it, from what I've read. I've added a True/False as a schema extension, tested it and it works. If I manually set accountLocked to TRUE on a DN, the user can't login at all, it logs in the messages file the account it locked. Works perfect.
You're still missing the point that if the user didn't provide a password for LDAP Bind, then LDAP authentication *didn't happen*. If SSSD is still doing an LDAP authorization check here, that's a *bug*, because without a successful authentication, it has no way to verify that the provided username matches any particular LDAP entry. Therefore it cannot assert that any particular LDAP attribute has any relevance to the current login attempt.
My question is, is there a better way to set that True/False attribute value
based on pwdAccountLockedTime. What I am looking for is, if pwdAccountLockedTime is set for DN=x, then also set accountLocked=true for DN=x. Sure, I can do that with an external script, but is there a way to do it from within slapd.
Of course you can write a slapd overlay to do this, but it would be a mistake because your security mechanism is broken. Anyone with permission to write to the directory could spoof their username attribute and lockout any user of their choice.
SSSD has a lot of issues. This is why we still recommend nssov.
Basically can I create a virtual attribute so when a user queries for
accountLocked, it actually does a check for something else (pwdAccountLockedTime) and based on that value returns True or False. I'm thinking in terms of a stored procedure offered on many SQL servers.
Thanks, -Brad Viviano
Howard, I don't see your point. 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.
As I said, there are any number of external methods I could do that would do it. I was hoping for an internal method, something that could translate it on the fly so if I request "accountLocked" for DN=x and pwdAccountLockedTime is not NULL then return accountLocked=TRUE otherwise return accountLocked=FALSE. If an existing overlay could be used to do that, I was interested in the specifics.
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.
-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 12:40 PM To: Viviano, Brad; Michael Ströder; openldap-technical@openldap.org Subject: Re: OpenLDAP with ppolicy and SSSD configuration question.
Viviano, Brad wrote:
Adjusting ACL's seems like overkill for this situation and I have to work
within the bounds of what sssd offers. sssd doesn't have a native check for pwdAccountLockedTime when it does ppolicy based checking, the code just isn't there. sssd for LDAP auth does support a True/False check for account locked, which is how Redhat DS, 389ds and IPA do it, from what I've read. I've added a True/False as a schema extension, tested it and it works. If I manually set accountLocked to TRUE on a DN, the user can't login at all, it logs in the messages file the account it locked. Works perfect.
You're still missing the point that if the user didn't provide a password for LDAP Bind, then LDAP authentication *didn't happen*. If SSSD is still doing an LDAP authorization check here, that's a *bug*, because without a successful authentication, it has no way to verify that the provided username matches any particular LDAP entry. Therefore it cannot assert that any particular LDAP attribute has any relevance to the current login attempt.
My question is, is there a better way to set that True/False attribute value
based on pwdAccountLockedTime. What I am looking for is, if pwdAccountLockedTime is set for DN=x, then also set accountLocked=true for DN=x. Sure, I can do that with an external script, but is there a way to do it from within slapd.
Of course you can write a slapd overlay to do this, but it would be a mistake because your security mechanism is broken. Anyone with permission to write to the directory could spoof their username attribute and lockout any user of their choice.
SSSD has a lot of issues. This is why we still recommend nssov.
Basically can I create a virtual attribute so when a user queries for
accountLocked, it actually does a check for something else (pwdAccountLockedTime) and based on that value returns True or False. I'm thinking in terms of a stored procedure offered on many SQL servers.
Thanks, -Brad Viviano
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
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.
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/
Viviano, Brad wrote:
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.
You're still not understanding. The only way *PAM* can get any useful information out of LDAP is by performing a Bind operation of its own. I never said anything about changing your user application software to perform a Bind.
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.
This is not sssd vs OpenLDAP. This is sssd vs secure programming practice. sssd is providing a PAM service that uses LDAP for authentication and authorization information. That's fine, that's the purpose of PAM, but you cannot do any authorization step without first performing authentication, and you can't do authentication to LDAP without performing a Bind.
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.
Nor does this have anything to do with open source programming practice. This is about how to design security software.
On Nov 27, 2013, at 9:23 PM, Viviano, Brad wrote:
So, I need a reliable way to lock an account that can handle both methods.
I haven't followed the thread closely, but if I understand you correctly: You want to disable/lock an account, without hiding it from ls etc?
As in, making sure the user can't authenticate?
If this is the case, do it the old standardized UNIX way: put an asterisk in front of the password.
Example: I'm using Kerberos V as 'password storage', hence my userPassword attribute looks like:
dn: uid=turbo,ou=People,o=FREQVIST,c=SE userPassword: {SASL}turbo@BAYOUR.COM
Simplest way to lock me out, would simply do a:
dn: uid=turbo,ou=People,o=FREQVIST,c=SE changetype: modify replace: userPassword userPassword: *{SASL}turbo@BAYOUR.COM
and send this to 'ldapmodify'...
This (should) work with any form of system you're using (pam, nss, sssd etc). It simply stops the authorization process, nothing else. -- Choose a job you love, and you will never have to work a day in your life.
Viviano, Brad wrote:
Adjusting ACL's seems like overkill for this situation and I have to work within the bounds of what sssd offers.
I'm doing this with sssd and it's definitely not overkill => there's no valid excuse to not learn about ACLs
And it does not only work for applications/clients which support a custom name-your-favourite-vendor-specific-lock-attribute-here. If done right ACLs simply make entries invisible for sssd or *every* application integrated with your LDAP server.
Ciao, Michael.
Michael, I can't foresee a time I would want a user to just disappear entirely from a system because their password is locked. I don't want locked users to be invisible, I want them to be locked so they can't login. I still want NSS to know the users exist so when someone does an 'ls -l' it doesn't just list numbers for them or if they need to query email or phone number, it's still available. There are a lots of reasons I can think why I need to lock an account to prevent a user from logging into a given system, none that I can think of where I would want to user to 100% disappear because their account is locked.
I understand how ACL's work and I don't see changing ACL's as a solution to this problem. My RHEL admin's won't take kindly to me just making users disappear on the their systems because their account is locked, they're funny that way. They'd rather a message showed in syslog that says user X is locked when the user tries to log in so they see it.
Thanks, -Brad
=================================================== 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: Michael Ströder michael@stroeder.com Sent: Wednesday, November 27, 2013 1:10 PM To: Viviano, Brad; openldap-technical@openldap.org Subject: Re: OpenLDAP with ppolicy and SSSD configuration question.
Viviano, Brad wrote:
Adjusting ACL's seems like overkill for this situation and I have to work within the bounds of what sssd offers.
I'm doing this with sssd and it's definitely not overkill => there's no valid excuse to not learn about ACLs
And it does not only work for applications/clients which support a custom name-your-favourite-vendor-specific-lock-attribute-here. If done right ACLs simply make entries invisible for sssd or *every* application integrated with your LDAP server.
Ciao, Michael.
Viviano, Brad wrote:
I can't foresee a time I would want a user to just disappear entirely from a system because their password is locked. I don't want locked users to be invisible, I want them to be locked so they can't login.
Gee, can't you read about ACLs *before* responding like that.
You don't have to make them invisible like I do. You can also just lock auth access to 'userPassword'.
I won't give a ACL lesson here though. You have to do your homework yourself.
Ciao, Michael.
On 27/11/2013 20:51, Michael Ströder wrote:
Viviano, Brad wrote:
I can't foresee a time I would want a user to just disappear entirely from a system because their password is locked. I don't want locked users to be invisible, I want them to be locked so they can't login.
Gee, can't you read about ACLs *before* responding like that.
You don't have to make them invisible like I do. You can also just lock auth access to 'userPassword'.
Changing access to userPassword, whether by ACL or by modifying the attribute value itself, doesn't have any effect when the user has a SSH key because LDAP is not involved in authentication.
There's no clean way to deal with this in my opinion. In the past I've modified accounts' shell attribute to prevent logins at the point they're determined to be disabled, and put back when the account is deemed unlocked.
Modifying the shell is useless for non-Unix systems though (web applications for example).
Now I use a custom 'lock' attribute on all accounts and use a LDAP filter at the client end. This is fine for our purposes but could be a problem for appliances that don't provide much in the way of LDAP configuration options.
Liam Gretton wrote:
On 27/11/2013 20:51, Michael Ströder wrote:
Viviano, Brad wrote:
I can't foresee a time I would want a user to just disappear entirely from a system because their password is locked. I don't want locked users to be invisible, I want them to be locked so they can't login.
Gee, can't you read about ACLs *before* responding like that.
You don't have to make them invisible like I do. You can also just lock auth access to 'userPassword'.
Changing access to userPassword, whether by ACL or by modifying the attribute value itself, doesn't have any effect when the user has a SSH key because LDAP is not involved in authentication.
Uuuhuuhh. You can even have two different ACLs for 'userPassword' and 'sshPublicKey' to solely make 'sshPublicKey' invisible. ;-)
You can then let your SSH key sync script remove the key from the system's authorized keys directory. Or any other appropriate solution.
There's no clean way to deal with this in my opinion. In the past I've modified accounts' shell attribute to prevent logins at the point they're determined to be disabled, and put back when the account is deemed unlocked.
Modifying the shell is useless for non-Unix systems though (web applications for example).
Yes, that's why mucking with 'loginShell' is not appropriate. Especially since you have to set it to the right old attribute value.
Now I use a custom 'lock' attribute on all accounts and use a LDAP filter at the client end. This is fine for our purposes but could be a problem for appliances that don't provide much in the way of LDAP configuration options.
But then you could simply use this filter in an ACLs. Read slapdaccess(5) before you claim that there's no clean way.
Ciao, Michael.
On 28/11/2013 08:53, Michael Ströder wrote:
Changing access to userPassword, whether by ACL or by modifying the attribute value itself, doesn't have any effect when the user has a SSH key because LDAP is not involved in authentication.
Uuuhuuhh. You can even have two different ACLs for 'userPassword' and 'sshPublicKey' to solely make 'sshPublicKey' invisible. ;-)
That assumes you have central management of SSH keys. We don't and it would be a huge job to do so.
Modifying the shell is useless for non-Unix systems though (web applications for example).
Yes, that's why mucking with 'loginShell' is not appropriate. Especially since you have to set it to the right old attribute value.
It's moot, but that particular problem is trivial to solve, you set it to '/bin/false /old/shell' to lock and restore it to '/old/shell' to unlock.
Now I use a custom 'lock' attribute on all accounts and use a LDAP filter at the client end. This is fine for our purposes but could be a problem for appliances that don't provide much in the way of LDAP configuration options.
But then you could simply use this filter in an ACLs. Read slapdaccess(5) before you claim that there's no clean way.
Sorry, I can't see how I can prevent non-LDAP authentication methods with a LDAP ACL and not make the user disappear from the system.
On Nov 28, 2013, at 9:30 AM, Liam Gretton wrote:
Now I use a custom 'lock' attribute on all accounts and use a LDAP filter at the client end. This is fine for our purposes but could be a problem for appliances that don't provide much in the way of LDAP configuration options.
I've used something similar to limit access on host level, but if I remember correctly, such a filter would hide the account from the system, not only lock it... ? -- Imagine you're an idiot and then imagine you're in the government. Oh, sorry. Now I'm repeating myself - Mark Twain
On 28/11/2013 08:56, Turbo Fredriksson wrote:
On Nov 28, 2013, at 9:30 AM, Liam Gretton wrote:
Now I use a custom 'lock' attribute on all accounts and use a LDAP filter at the client end. This is fine for our purposes but could be a problem for appliances that don't provide much in the way of LDAP configuration options.
I've used something similar to limit access on host level, but if I remember correctly, such a filter would hide the account from the system, not only lock it... ?
No, this is PAM configuration, not NSS.
You can use 'pam_filter' in the PAM LDAP module to filter on an attribute's value. For NSS there's a similar 'filter' option but as long as that's not changed the user won't disappear.
Viviano, Brad wrote:
I'm not expecting it to validate their password, I am expecting it to check if their account is locked for some reason. If their account is locked in LDAP, it shouldn't let them login under any circumstances. For technical reasons we need ssh public keys to operate (IBM GPFS), but I don't want the user to be able to circumvent LDAP authority. If I lock their account in LDAP they shouldn't be able to login to any system, and I shouldn't have to go to every one of my systems and disable their SSH keys manually.
So why don't you just write a script which removes SSH keys automatically?
The ideal case would be that ppolicy has an attribute that lists if the account is locked or not. This would also be useful when using pwdLockoutDuration. If I'm using pwdLockoutDuration and pwdAccountLockedTime is set, I don't really know if the account is locked because I then have to do the math and take the pwdAccountLockedTime and add the value of pwdLockoutDuration for the policy applied to that user and see if their account is in fact locked. If ppolicy just provided a true/false in addtion to the LockedTime, that would be much more useful.
A script syncing SSH keys to the system can use whatever attributes are already available.
Ciao, Michael.
Change the users she'll to nologin.
Mike
On Nov 25, 2013, at 1:23 PM, "Howard Chu" hyc@symas.com wrote:
Viviano, Brad wrote:
Hello, I've searched the archives of this list, the web as best I can, and have this same question asked to the sssd-devel mailing list and can not seem to find an answer this my question. I have a RHEL 6.4 server with OpenLDAP 2.4.23-32.el6_4.1 and sssd 1.9.2-129.el6, both installed as standard RPM's from Redhat. I have ppolicy configured in slapd and on another RHEL6.4 system have sssd setup as a client. Everything works fine with password expires, grace periods, etc and sssd, if the user has to enter their password. But, if the user is using an SSH public key, setting the account as locked or the password is expired still allows them to log in. I can't seem to find a good solution that forces the user to change their password before they can login.
Why would you expect anything to validate their password if they are using an SSH public key? pam only gets the ppolicy info if it performs an LDAP Bind with the user's password.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Autocorrect "shell"
On Nov 25, 2013, at 1:33 PM, "Michael" mlstarling31@hotmail.com wrote:
Change the users she'll to nologin.
Mike
On Nov 25, 2013, at 1:23 PM, "Howard Chu" hyc@symas.com wrote:
Viviano, Brad wrote:
Hello, I've searched the archives of this list, the web as best I can, and have this same question asked to the sssd-devel mailing list and can not seem to find an answer this my question. I have a RHEL 6.4 server with OpenLDAP 2.4.23-32.el6_4.1 and sssd 1.9.2-129.el6, both installed as standard RPM's from Redhat. I have ppolicy configured in slapd and on another RHEL6.4 system have sssd setup as a client. Everything works fine with password expires, grace periods, etc and sssd, if the user has to enter their password. But, if the user is using an SSH public key, setting the account as locked or the password is expired still allows them to log in. I can't seem to find a good solution that forces the user to change their password before they can login.
Why would you expect anything to validate their password if they are using an SSH public key? pam only gets the ppolicy info if it performs an LDAP Bind with the user's password.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
openldap-technical@openldap.org
-
Howard Chu -
Liam Gretton -
mahao_boy -
Michael -
Michael Ströder -
Turbo Fredriksson -
Viviano, Brad