The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.I have LDAP User Module enabled and configured, and I get the following error when an LDAP user who does not have a corresponding Drupal User already created in the system:
PDOException: in field_sql_storage_field_storage_write() (line 448 of /opt/lampp/htdocs/product/modules/field/modules/field_sql_storage/field_sql_storage.module).
This same error occurs when I test using: /admin/config/people/ldap/user/test for any active LDAP user without a matching Drupal account.
If I test or log in using an account that has a matching username already created in Drupal, the Authorization works fine and they are assigned the proper Roles through the Authorization module. I just would like to avoid the step of creating the user in Drupal prior to them logging in using LDAP.
In the User configuration, I have my one LDAP server selected for providing provisioning data, "Create or Synch to Drupal user on successful authentication with LDAP credentials. (Requires LDAP Authentication module)" is selected under Drupal Account Provisioning Events, and "Associate Drupal account with the LDAP entry. This option is useful for creating accounts and assigning roles before an LDAP user authenticates" is selected for Existing Drupal User Account Conflict. I have tried both options under Application of Drupal Account settings to LDAP Authenticated Users with no difference in results.
Our LDAP server is an Active Directory server with groups set up to allow specific Drupal role access.
Thanks for any tips, suggestions, or workarounds you can provide.
Comments
Comment #1
sandkastle commentedIt appears this was being caused by having objectSid entered as the Persistent and Unique User ID Attribute under LDAP User to Drupal User Relationship. After reading about a similar issue, I had tried changing it to "samaccountname" through the web interface, but for some reason changes aren't being saved there, so I had to manually edit it in the database.
With the Persistent and Unique User ID Attribute set to samaccountname it works fine now. Thanks!
Comment #2
johnbarclay commentedAll of these user object fields provided by ldap modules need to have more validation to avoid such errors. They should throw watchdog errors indicating the data issue such that admins can more readily see configuration issues. I'm marking this as a feature request rather than a bug.
Comment #3
brettshI had the same problem, also due to using objectSid entered as the Persistent and Unique User ID Attribute under LDAP User to Drupal User Relationship.
My solution was to Tick the check box "Does PUID hold a binary value? " Apparently, Active Directory is setting PUID as a binary value.
Comment #4
johnbarclay commentedComment #5
emijayne commentedThank you, sandkastle and BrettSh! You both solved issues I was having! :)
Comment #6
larowlanAny takers for writing docs for this - in the handbook is fine?
Comment #7
escoles commentedSeeing this issue in the current release. Selecting 'Does PUID hold a binary value?' per BrettSH resolves the issue.
Note that for us this was an emergent issue: It only arose with regard to IDs stored in certain parts of our AD hierarchy. The objectSID values are not visibly different from ones that posed no problem. I.e., this change may not seem to make sense to you, but try it anyway.
Comment #8
grahlI've modified the field help text as follows:
Does the Persistent and Unique User ID Attribute hold a binary value?
You need to set this if you are using a binary attribute such as objectSid in ActiveDirectory for the PUID.
If you don't want this consider switching to another attribute, such as samaccountname.
Please reopen if you have a better description.