Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.1.5

Bug #12876 Don't use Anonymous access !
Submitted: 2008-01-10 15:29 UTC
From: jerryzz Assigned: beni
Status: Closed Package: Net_LDAP (version 1.0.0)
PHP Version: 4.3.11 OS: Linux
Roadmaps: 1.1.0    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 30 - 20 = ?

 
 [2008-01-10 15:29 UTC] jerryzz (Jerome Schwartz)
Description: ------------ In ldap.php:(line 381), the script try an anonymous access to see if it can bind to the server, although i have specified binddn & bindpwd in my configuration file. After this frist bind, the connection bind it correctly (see examples bellow). If I specify bind dn & pwd, I will use it and never use anonymous bind. Thank you for your help. (sorry for my poor english) Test script: --------------- Actual: ldap.php: line 381: if (! @ldap_bind($this->_link)) { Temporar patch: ldap.php: line 381: if (! @ldap_bind($this->_link, $this->_config['binddn'], $this->_config['bindpw'] )) { Expected result: ---------------- Connection log: [10/Jan/2008:15:55:41 +0100] conn=32453 op=-1 msgId=-1 - fd=315 slot=315 LDAP connection from 10.XX.XX.XXto 10.XX.XX.XX [10/Jan/2008:15:55:41 +0100] conn=32453 op=0 msgId=1 - BIND dn="cn=MY_USERNAME,ou=MY_OU,o=MY_ORG" method=128 version=3 [10/Jan/2008:15:55:41 +0100] conn=32453 op=0 msgId=1 - RESULT err=0 tag=97 nentries=0 etime=0.001770 dn="cn=MY_USERNAME,ou=MY_OU,o=MY_ORG" [10/Jan/2008:15:55:41 +0100] conn=32453 op=1 msgId=2 - UNBIND [10/Jan/2008:15:55:41 +0100] conn=32453 op=1 msgId=-1 - closing - U1 [10/Jan/2008:15:55:41 +0100] conn=32453 op=-1 msgId=-1 - closed. Actual result: -------------- Connection log: [10/Jan/2008:15:52:17 +0100] conn=32260 op=-1 msgId=-1 - fd=289 slot=289 LDAP connection from 10.XX.XX.XX to 10.XX.XX.XX [10/Jan/2008:15:52:17 +0100] conn=32260 op=0 msgId=1 - BIND dn="" method=128 version=3 [10/Jan/2008:15:52:17 +0100] conn=32260 op=0 msgId=1 - RESULT err=0 tag=97 nentries=0 etime=0.000470 dn="" [10/Jan/2008:15:52:17 +0100] conn=32260 op=1 msgId=2 - BIND dn="cn=MY_USERNAME,ou=MY_OU,o=MY_ORG" method=128 version=3 [10/Jan/2008:15:52:17 +0100] conn=32260 op=1 msgId=2 - RESULT err=0 tag=97 nentries=0 etime=0.001710 dn="cn=MY_USERNAME,ou=MY_OU,o=MY_ORG" [10/Jan/2008:15:52:17 +0100] conn=32260 op=2 msgId=3 - UNBIND [10/Jan/2008:15:52:17 +0100] conn=32260 op=2 msgId=-1 - closing - U1 [10/Jan/2008:15:52:17 +0100] conn=32260 op=-1 msgId=-1 - closed. You can see here, on the 2nd line, the anonymous bind.

Comments

 [2008-01-14 09:07 UTC] beni (Benedikt Hallinger)
Bug confirmed, in fact the _connect method first tries an anonymous bind to see if the server is alive and responding. This is expected behavior and should not cause a problem. Reworking the lines 379 to 397 so first a privilegued bind (and if that fails a anonymous one) should be checked, however. Maybe we can optimize something there. Maybe it is enough to just bin inside _connect() and see if it worked - if so: fine, if not: record host as down since we are unable to bind. I have to dig into this deeper to be able to solve this, until then, treat this issue as expected behavior.
 [2008-01-17 10:09 UTC] beni (Benedikt Hallinger)
Thank you for taking the time to report a problem with the package. This problem may have been already fixed by a previous change that is in the CVS of the package. Please log into CVS with: cvs -d :pserver:cvsread@cvs.php.net:/repository login and check out the CVS repository of this package and upgrade cvs -d :pserver:cvsread@cvs.php.net:/repository co pear/Net_LDAP pear upgrade pear/Net_LDAP/package2.xml or pear upgrade pear/Net_LDAP/package.xml If you are able to reproduce the bug with the latest CVS, please change the status back to "Open". Again, thank you for your continued support of PEAR. I rewrote parts of the connection algorythm and refactored some code. Please checkout the latest CVS version and test - your issue should be gone now. Please confirm correct opration!
 [2008-01-17 12:49 UTC] jerryzz (Jerome Schwartz)
Hello beni. It works very fine now ! Thank you a lot for your prompt reponse ! Here the log of the LDAP server: $ fgrep "conn=21513" access [17/Jan/2008:13:40:35 +0100] conn=21513 op=-1 msgId=-1 - fd=360 slot=360 LDAP connection from 10.XX.XXX.XX to 10.XX.XXX.XX [17/Jan/2008:13:40:35 +0100] conn=21513 op=0 msgId=1 - BIND dn="cn=MY_USERNAME,ou=MY_OU,o=MY_ORG" method=128 version=3 [17/Jan/2008:13:40:35 +0100] conn=21513 op=0 msgId=1 - RESULT err=0 tag=97 nentries=0 etime=0.022210 dn="cn=MY_USERNAME,ou=MY_OU,o=MY_ORG" [17/Jan/2008:13:40:35 +0100] conn=21513 op=1 msgId=2 - SRCH base="ou=MY_OU,o=MY_ORG" scope=1 filter="(&(....)(....))" attrs="dn" (...) [17/Jan/2008:13:40:36 +0100] conn=21513 op=5 msgId=6 - UNBIND [17/Jan/2008:13:40:36 +0100] conn=21513 op=5 msgId=-1 - closing - U1 [17/Jan/2008:13:40:36 +0100] conn=21513 op=-1 msgId=-1 - closed. As you can see, it's a "perfect" binding ! Thank you !
 [2008-01-17 13:19 UTC] beni (Benedikt Hallinger)
Thank you for your fast feedback to confirm my tests. The solution will go into the next release (most probably 1.1.0.a2)