Version 7.x-2.0-beta5+7-dev
When LDAP User Module is enabled, it prevents the manual and automatic creation of Drupal accounts. The following error message is received after attempting to manually create a user account:
* Warning: htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in check_plain() (line 1559 of /var/www/html/new/includes/bootstrap.inc).
* Warning: htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in check_plain() (line 1559 of /var/www/html/new/includes/bootstrap.inc).
* Warning: htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument in check_plain() (line 1559 of /var/www/html/new/includes/bootstrap.inc).
* PDOException: in field_sql_storage_field_storage_write() (line 451 of /var/www/html/new/modules/field/modules/field_sql_storage/field_sql_storage.module).
There are no additional logs at admin/reports/dblog (Detailed LDAP Watchdog logging is enabled.) Attached you'll find the output from "Issue Reporting."
Comments
Comment #1
johnbarclay commentedThis should be the case when synching of ldap to drupal attributes is enabled and some of the fields are binary. Binary fields should either not be mapped or dealt with with tokens so they can be converted.
Please try to narrow it down to a specific field that is causing the issue. Turn this back into a bug report after you determine all the fields are being dealt with correctly.
Comment #2
musicalvegan0 commentedAs far as I can tell, I'm not synching any binary values. I've attached an image that lists the tokens that I am synching. This bug appears to only exist when synching from LDAP to Drupal as disabling synching from Drupal to LDAP does not eliminate the error messages.
Also, I've discovered that this bug only occurs when creating a Drupal account for an already existing LDAP/AD account; brand new, unassociated accounts are created fine. I've changed the issue title to reflect this.
I'm not sure how to go about verifying that the other fields are being handled correctly.
Comment #3
haydeniv commentedobjectsid is a binary field coming from Active Directory. I had the same problem. You need to check "Does PUID hod a binary value?" under Servers > Edit.
Comment #4
musicalvegan0 commented@haydeniv Thanks! This solved the issue.
Comment #5
musicalvegan0 commentedComment #6
escoles commentedNote: you may get inconsistent behavior -- some IDs may create successfully, others not.
I.e., if NOT ALL puids contain binary data, it might still work MOST of the time, but fail sporadically.
haydeniv's solution at #3 worked for me in such a case.