Support for non-anonymous binds?

Amen brother! I haven’t found anything for wordpress for this and I’m unable to code a non-anonymous bind custom plugin. Strange. Is this a wordpress limitation???

This is obviously less than ideal, but here’s what I did to make it work (couldn’t find a filter or hook to override the defaults).
In the __construct function, you’ll see an array where the adLDAP instance is created, I just added ad_username & ad_password with the necessary credentials to bind:

$this->adldap = new adLDAP(
     array (
          "account_suffix"        =>      $this->get_setting('account_suffix'),
          "use_tls"               =>      str_true( $this->get_setting('use_tls') ),
          "base_dn"               =>      $this->get_setting('base_dn'),
          "domain_controllers"    =>      (array)$this->get_setting('domain_controllers'),
          "ad_port"               =>      $this->get_setting('ldap_port'),
          "ad_username"           =>      "put_your_bind_username_here",
          "ad_password"           =>      "put_your_bind_password_here"
     )
);

There’s a philosophical difference here.

Firstly, there aren’t any anonymous binds because the plugin attempts to bind with the entered username / password at login time. If it can’t bind, it’s an authentication failure. If it can, it’s a success.

I’ve intentionally built the plugin to not require a separate binding user, as I think this causes two things:
1) It’s insecure. We shouldn’t be storing plain text passwords in the database.
2) It should be unnecessary. If a login is able to bind, that verifies that they are a valid user and their account should have all the permissions necessary to check their group memberships.

I’m open to suggestions. This is just my philosophy behind the current design.

Clif

For my environment, it’s more a policy issue than a technical one. The folks in charge of our AD environment have decided that anonymous binds won’t be allowed, period.

Our AD group creates special bind users for situations like this, whose privileges are very limited (probably functionally equivalent to that of an anonymous user). Philosophically, I agree that it’s unwise to keep cleartext passwords around (or stored in an easily-reversible hash), but I’m not sure there’s a functional alternative in this case.