Recently, i have hit a rather unique, and annoying, error with ldap. it seems that using pam with ldap, allows *any* password as valid. Im not really sure what i have done here, and any help would be apprecitaed. find my /etc/ldap.conf attached, as well as pam.d/ssh
etc/ldap.conf
base dc=chocolate,dc=lan suffix dc=chocolate,dc=lan uri ldap://ldap.chocolate.lan ldap_version 3 scope sub timelimit 3 bind_timelimit 3 bind_policy soft pam_filter objectclass=posixAccount pam_login_attribute uid pam_groupdn cn=login,ou=Nemo,ou=Group,dc=chocolate,dc=lan pam_member_attribute memberUid pam_password clear pam_password exop nss_base_passwd ou=Users,dc=chocolate,dc=lan?sub nss_base_shadow ou=Users,dc=chocolate,dc=lan?sub nss_base_group ou=Nemo,ou=Group,dc=chocolate,dc=lan?sub ssl on ssl start_tls tls_cacert /usr/local/etc/openldap/keys/cacert.crt
tls_checkpeer no
pam.d/sshd
auth sufficient pam_opie.so no_warn no_fake_prompts auth requisite pam_opieaccess.so no_warn allow_local auth sufficient /usr/local/lib/pam_ldap.so no_warn use_first_pass auth sufficient pam_unix.so no_warn try_first_pass
account required pam_nologin.so account required pam_login_access.so account optional pam_unix.so account optional /usr/local/lib/pam_ldap.so
session required pam_permit.so session optional /usr/local/lib/pam_ldap.so
password sufficient /usr/local/lib/pam_ldap.so no_warn use_athtok use_first_pass password sufficient pam_unix.so no_warn try_first_pass
I came across a similar bug where enabling chaining between a master and slave allows invalid passwords to be accepted by pam_ldap. Unfortunately, no word from OpenLDAP or pam_ldap maintainers on the issue. I have been looking at pam_ldap source code but haven't been able to pinpoint the issue. In my case, it has something to do with password policy not being handled properly when chaining is enabled. I suggest try tweaking those "pam_password" statements and see if you can deduce anything.
I will update the list if I find anything conclusive about this bug.
Thanks,
Siddhartha
On 6/5/10 7:00 AM, "Indexer" indexer@internode.on.net wrote:
Recently, i have hit a rather unique, and annoying, error with ldap. it seems that using pam with ldap, allows *any* password as valid. Im not really sure what i have done here, and any help would be apprecitaed. find my /etc/ldap.conf attached, as well as pam.d/ssh
etc/ldap.conf
base dc=chocolate,dc=lan suffix dc=chocolate,dc=lan uri ldap://ldap.chocolate.lan ldap_version 3 scope sub timelimit 3 bind_timelimit 3 bind_policy soft pam_filter objectclass=posixAccount pam_login_attribute uid pam_groupdn cn=login,ou=Nemo,ou=Group,dc=chocolate,dc=lan pam_member_attribute memberUid pam_password clear pam_password exop nss_base_passwd ou=Users,dc=chocolate,dc=lan?sub nss_base_shadow ou=Users,dc=chocolate,dc=lan?sub nss_base_group ou=Nemo,ou=Group,dc=chocolate,dc=lan?sub ssl on ssl start_tls tls_cacert /usr/local/etc/openldap/keys/cacert.crt
tls_checkpeer no
pam.d/sshd
auth sufficient pam_opie.so no_warn no_fake_prompts auth requisite pam_opieaccess.so no_warn allow_local auth sufficient /usr/local/lib/pam_ldap.so no_warn use_first_pass auth sufficient pam_unix.so no_warn try_first_pass
account required pam_nologin.so account required pam_login_access.so account optional pam_unix.so account optional /usr/local/lib/pam_ldap.so
session required pam_permit.so session optional /usr/local/lib/pam_ldap.so
password sufficient /usr/local/lib/pam_ldap.so no_warn use_athtok use_first_pass password sufficient pam_unix.so no_warn try_first_pass
On Saturday, 5 June 2010 22:52:10 Siddhartha Jain wrote:
I came across a similar bug where enabling chaining between a master and slave allows invalid passwords to be accepted by pam_ldap. Unfortunately, no word from OpenLDAP or pam_ldap maintainers on the issue.
Did you file an ITS?
I have been looking at pam_ldap source code but haven't been able to pinpoint the issue. In my case, it has something to do with password policy not being handled properly when chaining is enabled. I suggest try tweaking those "pam_password" statements and see if you can deduce anything.
Well, the first thing would be to be absolutely sure the PAM config is correct, I haven't had time to compare, my PAM config is quite a bit more complex (with pam_ccreds in the mix), but I do have a required pam_deny.so at the end of mine ... (and I can't remember if it is a requirement because of the two "sufficient"'s, or because of the pam_ccreds stuff which follows).
Regards, Buchan
I have solved this issue, unfortunately i don't think i sent it back to the mailing list. It was to do with my combination of required and sufficient, and i lacked pam_deny.so I replaced it with
auth sufficient pam_opie.so no_warn no_fake_prompts auth requisite pam_opieaccess.so no_warn allow_local auth sufficient /usr/local/lib/pam_ldap.so no_warn auth required pam_unix.so no_warn use_first_pass
And this seems to have corrected the behaviour.
On 07/06/2010, at 7:31 PM, Buchan Milne wrote:
On Saturday, 5 June 2010 22:52:10 Siddhartha Jain wrote:
I came across a similar bug where enabling chaining between a master and slave allows invalid passwords to be accepted by pam_ldap. Unfortunately, no word from OpenLDAP or pam_ldap maintainers on the issue.
Did you file an ITS?
I have been looking at pam_ldap source code but haven't been able to pinpoint the issue. In my case, it has something to do with password policy not being handled properly when chaining is enabled. I suggest try tweaking those "pam_password" statements and see if you can deduce anything.
Well, the first thing would be to be absolutely sure the PAM config is correct, I haven't had time to compare, my PAM config is quite a bit more complex (with pam_ccreds in the mix), but I do have a required pam_deny.so at the end of mine ... (and I can't remember if it is a requirement because of the two "sufficient"'s, or because of the pam_ccreds stuff which follows).
Regards, Buchan
pam.d/sshd
auth sufficient pam_opie.so no_warn no_fake_prompts auth requisite pam_opieaccess.so no_warn allow_local auth sufficient /usr/local/lib/pam_ldap.so no_warn use_first_pass auth sufficient pam_unix.so no_warn try_first_pass
account required pam_nologin.so account required pam_login_access.so account optional pam_unix.so account optional /usr/local/lib/pam_ldap.so
session required pam_permit.so session optional /usr/local/lib/pam_ldap.so
password sufficient /usr/local/lib/pam_ldap.so no_warn use_athtok use_first_pass password sufficient pam_unix.so no_warn try_first_pass
This is more of a pam config problem than openldap related... but your account section probably needs either ldap or unix to be required/sufficient rather than optional. As it is now it will check that there is no nologin file, and then check through your pam login.access file, it will check that the user exists in passwd or ldap but wont fail if it isnt, just that it meets criteria set in the access file, which might be setup to allow anything in. Also, your auth section is setup such that if opie succeeds, you are auth'd, it wont bother to check ldap or unix because if it fails, it will return failure immedaitely (that's what requisite does). Id be careful with the use of "optional" in pamconfig, espcially around the auth and account sections. I would reserve its use for session (if anywhere), as its more of a "try it, if it works Ok, if not, so what" rule, good for homedir creation or displaying motd (so if it fails, you still get in, since its not critical you see motd or have a homedir, but nice if it does work).
-T
This is more of a pam config problem than openldap related... but your account section probably needs either ldap or unix to be required/sufficient rather than optional. As it is now it will check that there is no nologin file, and then check through your pam login.access file, it will check that the user exists in passwd or ldap but wont fail if it isnt, just that it meets criteria set in the access file, which might be setup to allow anything in. Also, your auth section is setup such that if opie succeeds, you are auth'd, it wont bother to check ldap or unix because if it fails, it will return failure immedaitely (that's what requisite does). Id be careful with the use of "optional" in pamconfig, espcially around the auth and account sections. I would reserve its use for session (if anywhere), as its more of a "try it, if it works Ok, if not, so what" rule, good for homedir creation or displaying motd (so if it fails, you still get in, since its not critical you see motd or have a homedir, but nice if it does work).
-T
Thank you for this, I will definitely take your advice, and go over pam more throughly, as it was one of my weaker areas of understanding.
Your help is appreciated
William
openldap-technical@openldap.org
-
Buchan Milne -
Indexer -
Mackey, Theral -
Siddhartha Jain -
Thierry Lacoste