Can not set LDAP Server Type to Active Directory

Hi

Thanks for the bug report, not being able to set type AD is unrelated to your problem, though thank you for reporting it, the commit above fixes that.

Would you be able to share your anonymized server configuration yaml file? This helps understand what could be causing issues in the connection string, right now it simply looks like it was given incorrect data.

Can you also elaborate from which beta in 3.x you came and if you could apply the updates (updb) without issue?

I have the same issue after patching. I checked the config as stored in the DB and it shows as ldaps://xxx but it seems that
#2 /var/www/html/d8/vendor/grahl/ldap/Adapter/ExtLdap/Connection.php(132): ldap_connect('ldap://ldaps://...')
does receive the address prepended by "ldap://" or at least the problem is with
$this->connection = ldap_connect($this->config['connection_string']);

I dug around a bit and found that /var/www/html/d8/vendor/grahl/ldap/Adapter/AbstractConnection.php does something to set this connection_string property at line 48 where it does set the protocol depending on the encryption.

What I tried next is to replace in the original file (/vendor/grahl/ldap/Adapter/ExtLdap/Connection.php line 132)
this->connection = ldap_connect($this->config['connection_string']);
with
$this->connection = ldap_connect($this->config['host'], $this->config['port']);

while I keep the protocol in my server config and it seems to work now.

This is in no way a fix but I hope it helps and save some time to the people with the knowledge to patch.

Thanks for the feedback, that helps!

At the very least it makes a good test case so that we can test for the protocol and throw an error if we pass something incorrect along to symfony/ldap.

I'll look into maybe creating an update hook to clean that up if that's an option without degrading connection preferences (namely https).

I just started testing with the latest dev release (commit 5a79126, contains c5b9ac4 above) and I'm getting the same error whether I use Default LDAP or Novell for server type, with or without the ldaps:// prefix in the field. This is on a fresh D9 install so nothing was copied from 8.x.

The connection works (as Novell type) on 389 with Start-TLS (which my network admin is trying to abolish.) I'll be watching this issue, too, but at least it's not a show-stopper for me right now.

Edit to confirm that I'm able to connect with ldaps:// using ldapsearch from command line from the same web server, and sites using 8.x-3.x are also working with ldaps:// from this server.

I am using version:
"drupal/ldap": "4.x-dev#958f3aa79902bb9bb0cd62431b2ac9c012e292c1",

And for OpenLDAP I also need to create a localized composer patch file that applies #6 to the -dev release of LDAP so that connections are succesful. Otherwise the Bind fails.

I can confirm I am facing the same issue in my setup as well.

I can connect to the LDAP server (OpenLDAP) in the command line using

ldapwhoami -H ldap://localhost:389 -x

However entering the same in the LDAP module server settings causing the Binding issues check error log message.

Hi, I can confirm I am facing the same issue in my setup as well.

Error logs:

Warning: ldap_connect(): Could not create session handle: Bad parameter to an ldap routine in Symfony\Component\Ldap\Adapter\ExtLdap\Connection->connect() (line 132 of /var/www/html/vendor/grahl/ldap/Adapter/ExtLdap/Connection.php)

LDAP bind failure: Could not set value "3" for option "protocol_version"..

#0 /var/www/html/web/core/includes/bootstrap.inc(301): _drupal_error_handler_real(2, 'ldap_connect():...', '/var/www/html/v...', 132, Array)
#1 [internal function]: _drupal_error_handler(2, 'ldap_connect():...', '/var/www/html/v...', 132, Array)
#2 /var/www/html/vendor/grahl/ldap/Adapter/ExtLdap/Connection.php(132): ldap_connect('ldap://ldaps://...')

In my setup I was able to solve the problem by simply removing the ldap protocol from the ldap url. So instead of ldap://domain.xyz, I simply added domain.xyz. This should have been obvious to me but I guess I overlooked that.

Hi,

@binnythomas It only works if the protocol is ldap; with ldaps it doesn't work

I'm running into this issue as well on 8.x-4.0-alpha3, and with ldaps. The fix in #6 resolved the issue for me.

I created a patch for grapl/ldap based on @nixar comment (#6). I am apply this during composer install/update. Might be helpful for someone.

{
  "patches": {
    "grahl/ldap": {
      "Patch to allow ldaps (see https://www.drupal.org/project/ldap/issues/3151284)": "patches/ldap/grahl-ldap-patch-for-3151284.patch"
    }
  }
}

Hey everyone

Thanks for the input above, that helped nail down the problem more quickly.

So since grahl/ldap is just a workaround around the d.o CI and really symfony/ldap. We don't want to patch over there, since that won't get in anyway.

Previously we had the split option of STARTTLS vs connection string with ldaps and port definition before this library was the base. Since symfony/ldap can handle abstracting that out for us it makes sense to align our server config to it.

The attached MR does the following:
- Add encryption field, remove tls field
- Update hook to derive sensible default for it
- Fix the server hostname description and filter out the ldap(s):// prefix.

That retains the custom port and adds ldaps where appropriate:

Test feedback is appreciated, would be especially great if people could give a positive feedback for each method (none, ssl, tls).

I can confirm the changes work for us. Tested all methods: (none, ssl, tls). We're using 389-ds with support for all three.

I can confirm that all methods work (none, ssl, tls). Confirmed using a 389-ds directory server.

Strange I could have swore I saw @winstan (on a video call as he's a new contributor and works with me) mark the status as RTBC... oh well.

I can confirm testing with STARTTLS and SSL methods against our Novell (Microfocus NetIQ eDirectory) servers on Drupal 9.1.0.

Thanks for the update!

Awesome, thanks so much for the detailed test feedback everyone!

If this issue is fixed why is the 4.x version still break? I applied this patch and it works, but it seem like it shouldn't be broke anymore to begin with.

Perhaps 'drupal/ldap:4.x-dev@dev' fixes it which if it does I can't install this because of this:

Your requirements could not be resolved to an installable set of packages.

Problem 1
- drupal/ldap_servers 4.0.0-beta3 requires drupal/ldap 4.0.0-beta3 -> satisfiable by drupal/ldap[4.0.0-beta3] but these conflict with your requirements or minimum-stability.
- drupal/ldap_servers 4.0.0-beta3 requires drupal/ldap 4.0.0-beta3 -> satisfiable by drupal/ldap[4.0.0-beta3] but these conflict with your requirements or minimum-stability.
- drupal/ldap_servers 4.0.0-beta3 requires drupal/ldap 4.0.0-beta3 -> satisfiable by drupal/ldap[4.0.0-beta3] but these conflict with your requirements or minimum-stability.
- Installation request for drupal/ldap_servers (locked at 4.0.0-beta3) -> satisfiable by drupal/ldap_servers[4.0.0-beta3].

My minimum stability is dev, it seems like ldap_servers has requirements that conflict.

Turns out my issue is that vendor/composer/installed.json won't allow it. Deleting the entry solves this, but is annoying none-the-less. Another issue we are having is this:

// Remove prefix to avoid user error.
$this->entity->set('address', preg_replace('#^ldaps?://#', '', $form_state->getValue('address')));

The only thing this avoids is connecting to our servers. If we need to connect through ldaps why remove it? Commenting it out solves it for us.

Thanks!

@couloir007 Regarding composer: Due to the meta-package you might need to list all sub-modules when upgrading, the easiest way for you might be to update everything with "composer update" if you don't want to explicitly list that. It's a quirk of how Drupal packages are present in packagist.

Regarding removal of the prefix: Please see the "Encryption" dropdown on the server configuration. If you have set that correctly and can still not connect, please open a new issue, I presume this is a misconfiguration on your side based on the test feedback we had from other users.

Under Server address I put ldaps://si-xxxx.xx.xxx.si.edu and choose SSL (i.e. the ldaps:// protocol). When I save the form only si-xxxx.xx.xxx.si.edu shows because the ldaps:// is stripped. Even though I selected the SSL above, it fails to connect. When I comment out the line that strips the ldaps:// and it saves as ldaps://si-xxxx.xx.xxx.si.edu it has no issue connecting to our servers.

This is a closed issue. Reiterating my previous statement: "If you have set that correctly and can still not connect, please open a new issue".