On the test page, I can see the results for a test user just fine. But when I try to log in as the same user, I get a strange error. Here is what I see in the dblog:

  • first.last : Trying server DFS01 where bind_method = 1
  • first.last : Success at connecting to DFS01
  • ldap_search() call: base_dn: OU=Solutions,OU=HeadQuarters,OU=Staff,OU=Users,OU=COMPANY,DC=company,DC=local, filter = (samaccountname=first.last), attributes: , attrsonly = 0, sizelimit = 0, timelimit = 0, deref = , scope = 3
  • first.last : Authentication result id=0 auth_result=6 (unknown error: 6)

Has anyone had experience with this error? Does anyone know what the 6 means? This is using a MS Active Directory LDAP implementation.
For reference, someone else had the same issue at http://drupal.org/node/1539438.

Comments

I met the exactly same problem!
Adding some information:
1. a log message: Drupal account for authname=%authname account name=1993 does not exist and provisioning of Drupal accounts on authentication is not enabled.
2. LDAP user login in DRUPAL failure response message: Sorry, unrecognized username or password. Have you forgotten your password?

When I use "LDAP INTEGRATION" module(only for Drupal 6.x) with the similar settings which are configured in the LDAP module(for D7), I login with a LDAP user into Drupal successfully.
The configurations in "LDAP INTEGRATION" module(only for Drupal 6.x):
LDAP server:***.***.***.***
LDAP Port: 389
Base DNs:ou=people,dc=**.**.**
UserName attribute:uid
Email attribute:mail
DN for non-anonymous search:uid=ldapbinding,ou=people,dc=**.**.**
Password:****
All other items are default values.

1. So after some poking around it seems like error code 6 is not an actual error, but LDAP saying that it was able to match a comparison (reference). Is there a way to change the dblog error messages to reflect what's actually going on?

2. I had to turn provisioning on (creating Drupal accounts from LDAP entries), and then I was able to log in via LDAP credentials. However, I'd prefer to use LDAP authentication only. I know the setting exists under authentication, but I'm stopped by the previously mentioned error messages.

Status:Active» Needs review

Here's a patch to take care suggestion 1 by alan.pinkert. My next post will band-aid the issue raised by fishfry's comment and presumably address the original issue by alan.pinkert.

--- modules/ldap/ldap_authentication.inc 2013-01-10 15:04:37.633629492 -0600
+++ modules/ldap/ldap_authentication.inc.new 2013-01-10 16:43:01.333626806 -0600
@@ -609,6 +609,10 @@
$msg = t('Sorry, unrecognized username or password.');
break;

+ case LDAP_AUTHENTICATION_RESULT_SUCCESS:
+ $msg = t('Success.');
+ break;
+
case LDAP_AUTHENTICATION_RESULT_FAIL_GENERIC:
$msg = t('Sorry, unrecognized username or password.');
break;

Status:Needs review» Needs work

It seems the basedn value from the configuration screen is DOUBLY-serialized in the database. The LdapServerAdmin.class.php code itself serializes the value before writing, but the database schema (defined in the same file) also says to serialize that value (which drupal_write_record() then dutifully does), hence the DOUBLE-serialization.

But the values are read by the code in LdapServer.class.php, which seems to read the values directly from the database, ignoring the schema. (Presumably there exists a schema-respecting function, similar to drupal_write_record(), that will properly fetch the data, and such a function is not being used.) The code in LdapServer.class.php DOES do a defensive unserialize, but only once.

It seems that the correct patch would be two-fold:
(1) The save-the-values code in LdapServerAdmin.class.php does not need to itself serialize and then also use a schema-aware writing function with a schema that says to serialize.
(2) If consequently the database value is always serialized exactly once, then the read-the-values code in LdapServer.class.php can either do schema-aware reading (if such a function exists) without the need to itself also unserialize (not even defensively); or, for efficiency, to avoid slower schema code, continue to read the values directly as it currently does, and always do a single unserialize (no need for the defensive check).

However, correctly implementing (1) is beyond my drupal skillset. Meanwhile, here's a band-aid to get LDAP working for now, by defensively unserializing TWICE!

In modules/ldap/ldap_servers/LdapServer.class.php look for function initDerivedProperties, and you'll find the code block that does the single defensive unserialize, so the band-aid is to just add another repetition of that block:

// debug('initDerivedProperties'); debug($this->basedn);
if (!is_array($this->basedn)) {
$basedn_unserialized = @unserialize($this->basedn);
// debug('basedn_unserialized'); debug($basedn_unserialized);
$this->basedn = $basedn_unserialized;
}
+ // debug('initDerivedProperties'); debug($this->basedn);
+ if (!is_array($this->basedn)) {
+ $basedn_unserialized = @unserialize($this->basedn);
+ // debug('basedn_unserialized'); debug($basedn_unserialized);
+ $this->basedn = $basedn_unserialized;
+ }

Thank you, I'll try it.

Thanks!! It works!!

Thanks! It worked out!

This issue seems to be related with #1903014, isn't it?

StatusFileSize
new129.02 KB
new174.63 KB
new64.1 KB

The band aid in comment #4 didn't work. Still getting the error when trying to authenticate and authorize using LDAP without provisioning anything.

Test LDAP Authorization Configuration works fine and does provide the mapped use role.
Server testing with test users also works fine - except I get this message:Invalid multibyte sequence in argument in htmlspecialchars()

But when I try to use the login form it doesn't work and generates this unknown 6 error. Please checkout the screenshots.

I used the latest dev release, and using MS Active Directory on Windows 2008

Version:7.x-2.0-beta3» 7.x-2.x-dev
Status:Needs work» Closed (won't fix)

Please break this up into more specific issues. The serialization issue is covered elsewhere.

Status:Closed (won't fix)» Needs work

We are experiencing the same issue. Some LDAP queries return error code 6. But error code 6 isn't an error (cf. https://wiki.servicenow.com/index.php?title=LDAP_Error_Codes and http://www.openldap.org/doc/admin24/appendix-ldap-result-codes.html). Maybe the error handling of this module messes up with this specific error code?

Issue summary:View changes

additional information