LDAP Authentication: (unknown error: 6)

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.

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;

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?

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

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

Experienced the same "Authentication result id=0 auth_result=6 (unknown error: 6)" error while reconfiguring after a D6 to D7 upgrade. The server was able to connect and the user was authenticated, but I was redirected to an error page. The error logs reported "PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'USERNAME' for key 'authname'". I don't know the technicalities, but there was an authorization conflict in the "authmap" table. Once I dropped all the users (DELETE FROM authmap WHERE module = 'ldapauth'), I was able to re-map and successfully log in using LDAP/AD credentials.

no update for > 12 months - closing

Hello,

Same issue is happening in 8.3.aplha2 version.

Can anybody please let me know what could be the code changes to fix the issue.

I am attaching the screenshot for the error and also copy pasting the error below. Please help me out ..

Authentication result id=0 auth_result=6 (Success.)
Derived drupal username from attribute userPrincipalName returned no username for authname jon.doe@company.com

Thanks in advance ..

--
Best
Prashanth

The problem is exists for alpha3, for alpha2 all fine via my LDAP config.

Same here. alpha2 works fine, but with alpha3 I get the following error:

[myusername] : Success at connecting to ldap_1
ldap_search() call: base_dn: dc=blah,dc=blah,dc=blah, filter = (uid=myusername), attributes: , attrsonly = 0, sizelimit = 0, timelimit = 0, deref = , scope = 3
myusername : Authentication result is 6 (unknown error: 6)

Hi

Please don't reopen old issues if they are not clearly the same cause. It's highly unlikely that this issue fits due to the significant refactoring in that component and multiple causes for an unknown authentication error.

Please also try dev first and see this information for potential causes: https://www.drupal.org/node/2843518

If your problem remains please report back at https://www.drupal.org/node/2848546