User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1 (.NET CLR 3.5.30729) the pam passthrough plug-in with pamIDMapMethod:RDN does not verify the existence of the complete DN before binding. Only the RDN part is validated. As a result the server my connect a user successfully but with an inexistent DN meaning the final rights are the same as an anonymous user. Reproducible: Always Steps to Reproduce: 1. Configure a pam passthrough plug-in (with kerberos or /etc/passwd or any other way) to use the "pamIDMapMethod: RDN" and "pamIDAttr: uid" (default value) 2. Create a user "uid=me,ou=MyUnit,ou=SomeLargeThing,dc=example,dc=com" 3. Give any special right to this user (for example, put him/her into the administrative group) 4. Make an ldapsearch binding by '-D "uid=me,ou=MyUnit,ou=SomeLargeThing,dc=example,dc=com"'. Everything is fine. 5. Make an ldapsearch binding by '-D "uid=me,ou=SomeLargeThing,dc=example,dc=com"' or even '-D "uid=me,dc=example,dc=com"'. Actual Results: The bind is successful and the ldapsearch rights are that of an anonymous user. The LDAP logs indicate that a user is bound successfully as "uid=me,dc=example,dc=com" : [21/Jul/2009:20:24:03 +0200] conn=1525 fd=128 slot=128 SSL connection from xxx.xxx.xxx.xxx to yyy.yyy.yyy.yyy [21/Jul/2009:20:24:03 +0200] conn=1525 SSL 256-bit AES [21/Jul/2009:20:24:03 +0200] conn=1525 op=0 BIND dn="uid=me,dc=example,dc=com" method=128 version=3 [21/Jul/2009:20:24:03 +0200] conn=1525 op=0 RESULT err=0 tag=97 nentries=0 etime=0.014000 dn="uid=me,dc=example,dc=com" [21/Jul/2009:20:24:03 +0200] conn=1525 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(uid=me)" attrs="nscpentrywsi" [21/Jul/2009:20:24:03 +0200] conn=1525 op=1 RESULT err=0 tag=101 nentries=1 etime=0.001000 Expected Results: The server should reply that the object does not exist (the DN the user tries to bind with is inexistant) The plug-in should first verify that the DN exists. If it doesn't it should return a failure immediately. If the DN exists in the tree the plug-in can proceed as usual.
I think this should be configurable. There are some cases where you might not want to verify the existence of the entry, you might want to allow the bind to proceed. This is how the current (non-pam) passthrough auth works - the authentication is passed through to a remote ldap server, and the auth identity is set to the remote DN. This allows you to specify ACIs on the local server that apply to that DN, even though the entry with that DN does not exist on the local server. The same thing may apply (in the future) to certain types of SASL binds, such as SASL GSSAPI (the user exists in kerberos but does not have to have an entry in the DS) and EXTERNAL (the user's cert exists and can be verified, but does not have to have an entry in the DS).
Configurable is ok. The thing is that the current behaviour desorientates users/developers - they put an erroneous DN in the bind DN and put their (correct) password. They are successfully bound. But when they try to make any reads/modifications they do not have all their rights.
Hi Andrey, it seems that the functionality to verify the bind DN existence already exists using pamIDMapMethod: ENTRY and pamIDAttr: uid. As the method name implies, the ENTRY method will verify the entry's full DN whereas the RDN method will verify just the RDN part. Will this work for you? Thanks.
Hi Endi, Yes, your solution is exactly what i wanted and it works as i expected (ldap_bind: No such object (32) error where necessary). Thank you! I think we can close this bug.