Ldap.php error checks

[josef_fortier]

We use Novells eDirectory, but I imagine the same issue applies to OpenLDAP or any non Active Directory LDAP server

VERSION: 2.6.13 (current stable)

ISSUE: LDAP Authentication fails

I've worked around the issue, but it's a crude workaround. Hopefully this is of use to someone.

FILE: ./inc/Ldap.php around line 269, i.e. in the __construct() call for the PMF_Ldap class

FIRST ISSUE

There is a block of error checking that assumes that ldap_user and ldap_password have to be set (I assume this is in config/ldap.php) I'm not entirely clear on the intent of the code. I'd expect the code to attempt to bind as the proffered login user and not need a hard coded password in the config file.

MY WORKAROUND comment out
.... return false;
when the check fails. The real workaround is probably to have several failure mode sections instead of one long || statement

SECOND ISSUE

The ds value is never set up (most likely from the first issue) even though the ldap_connect() call only needs a server (and optional port). This has several consequences:

1) The subsequent error call
..... $this->error = 'Unable to connect to LDAP server...
fails, as the object has no ds

2) All subsequent calls to the object fail, as there is no $self->ds

My Workaround: set up the ldap_connect() without checking (I know my ldap parameters are correct....). Clearly this is not suitable for released code, but it gets LDAP working for me.

I think the sanity check code up front should first check for ldap_server and setup a connection first, then check for the rest of the parameters expected.

[Thorsten]

Hi,

I'll check it... but I don't see line 269 in ./inc/Ldap.php.

bye
Thorsten

[josef_fortier]

I'll check it... but I don't see line 269 in ./inc/Ldap.php.

Must have been a Friday thing, it's not line 269. I managed to a) add a 2 b) switch the 6 and the 9.
Sorry.

Here is more complete code snippet (around line 96)

88 public function __construct($ldap_server, $ldap_port, $ldap_base, $ldap_user = '', $ldap_password = '')
89 {
90 global $PMF_LDAP;
91
92 $this->base = $ldap_base;
93
94 // joe_fortier workarounds for LDAP assumptions
95 // joe_fortier -- Force the connect (the first fix)
96 // This is a crude workaround
97 $this->ds = ldap_connect("THIS_WOULD_HAVE_MY_LDAP_SERVER");
98
99 if (!isset($ldap_user) || !isset($ldap_server) || $ldap_server == "" ||
100 !isset($ldap_port) || $ldap_port == "" || !isset($ldap_base) ||
101 $ldap_base == "" || !isset($ldap_password)) {
102
103 // joefortier -- If the password is not set, then none of the rest executes
104 // workaround, comment out the return
105 //return false;
106 }
107
108 if (empty($ldap_password)) {
109 $this->error = 'Unable to connect to LDAP server (Error: '.ldap_erro r($this->ds).')';
110 $this->errno = ldap_errno($this->ds);
111 return false;
112 }

[Thorsten]

Hi,

so you're trying a first connect to the LDAP server before checking the parameters?

bye
Thorsten

[josef_fortier]

I only worked through this enough to figure out how to patch it for my environment.

From what I can tell, the class is instantiated for a variety of LDAP lookups.

Without setting it up the LDAP connection the class would fail to produce anything meaningful after, for example the call to

if (!$this->ds) {
$this->error = 'Unable to connect to LDAP server (Error: '.ldap_error($this->ds).')';
$this->errno = ldap_errno($this->ds);
}

Fails, as the error call expects $this->ds

In our environment I can pretty confidently set up the LDAP connection, as LDAP is at the core of our environment (a lot of things break if LDAP is down). In the more general case, I'd probably test first for a server name in the config, and whatever other sanity checks that you'd want to take at that point before calling the connect.

I think the core of this is Active Directory LDAP code often needs a privileged user to do informational queries. Our case is not like that:

1) We allow anonymous binds internally (with limited info returned)
2) We don't really need the extra queries. All we are looking for is "can the user dn bind with the password they provided". I very much suspect that this is all you need as well.

If you get to LDAP groups (MS AD, eDir and openLDAP all handle these differently) then a privileged LDAP user makes some things a lot easier. In this case though all I'm looking for is authentication.

From what I can tell, the code expects a privileged user, and my crude workaround is just that, a workaround to get it to ignore the lack of a privileged LDAP user.