There is no option for manually editing the email field.

If a user has no email from ldap and the account is created with an empty email field; then there is no way to manually edit the account at as because drupal will complain of an empty email field. Since the only two options from ldap are to not show the email field or to disable the email field, there is nothing that can be done without editing the database.

Why does ldap obliterate any ability to manually change the email of an account instead of offering a third choice to leave the email field manually editable?

Members fund testing for the Drupal project. Drupal Association Learn more


johnbarclay’s picture

Why are you using 7.x-2.x-dev ?

endiku’s picture

That's a mistake. I'm using 7.x.1.x-dev
The issue remains however, there is no way to change the email field. This is a rather detrimental feature.

johnbarclay’s picture

Version: 7.x-2.x-dev » 7.x-1.x-dev
Category: bug » feature

Email field is required in Drupal accounts, so can never be empty. Just let us know the following:

- What the wording should be in "Email Behavior" option(s) you are proposing.
- The behavior you expect the option to produce with regard to SSO, accounts be provisioned on logon, accounts being provisioned manually, account be provisioned by feeds, both on logon and after and for both user and account admin.

endiku’s picture

With LDAP enabled, a person logs in via LDAP, their Drupal account is created. Their drupal email is populated by their LDAP retrieved email attribute.
But if the person has no email for LDAP to retrieve then they have an account with an empty email field.
Now when you go to manually update this account in drupal you cannot make any changes because LDAP has locked the email field. Since the email field is empty but required by drupal, you are unable to do anything to the account.

Drupal's email requirement is not at issue here. The issue is LDAP has only two choices, 1- hide the email field, 2- disable the email field. What about a 3rd choice which is to allow editing of the email field. then if the email is missing from the ldap source it will leave the manually entered email, if an email is present it can overwrite it.

johnbarclay’s picture

Thats the part I don't understand. How do you create a drupal account without an email value. Just point me in the right direction as far a function that will do that.

endiku’s picture

The specific case I have experience with is as follows.

LDAP gathers from Active Directory. In Active Directory, the account(s) in question have an empty email field in the general properties of the account.
LDAP settings are that "mail" is used to populate the "Email attribute". So Active Directory email property is populating the drupal email field.

Authentication is Mixed mode, drupal fails, ldap is checked. Drupal User Account Creation is that "Associate local account with the ldap entry" and "Create accounts automatically for ldap authenticated users".

So the Active Directory user successfully logs into Drupal, their account is created on their first login even though they have a blank email property in ldap, so their drupal account has an empty email field. They can login and operate just fine, only their account can't be updated via the direct "/users/username" because the the email requirement. They can be updated in the "admin/people" list.

In my specific case I had also migrated from Drupal 6 to 7 where many of these empty email fields existed. In 7 it seems only one "empty email account" can be created because then additional ones collide on creation by having duplicate emails (duplicate empty but still duplicate). However that actually only lends more weight to the argument that removing the ability to change the email field is detrimental. A better behavior is that if all the users logging in via LDAP had no email, then they should be able to manually enter one on their first attempt instead of being told they can't login at all and having no recourse at that point.
ie. If you had 100 users in Active Directory that had no email, only the first could create account and the other 99 would be told they can't login.

This is easy enough to fix in the database for existing accounts, and of course the AD is obviously setup incorrectly, but that is beside the point =)

johnbarclay’s picture

Title: Email behavior » LDAP Authentication: Allow entering of email on initial logon before acct created and editing of email afterward

Thanks. this is clear now. I've renamed the title also.

mellon’s picture

Thanks for opening and clarifying this issue. I agree that the proper fix is to use AD as a Directory, but we have *thousands* of users with blank email addresses (around 10,000), and absolutely do not want to store or manage passwords.

It would be great to just prompt them for a valid email address if the LDAP/AD mail attribute is returned blank. (Obviously this LDAP integration is for internal sites, so we're not expecting spammers.)

johnbarclay’s picture

I agree. A patch that allowed either or both of the following flow would be excellent:

When creating drupal accounts on logon:

  1. user jdoe has no drupal account
  2. user jdoe authenticates
  3. no email is found in ldap entry
  4. user is allowed to enter email account
  5. account is created with that email
  6. user is logged in

I believe this is doable, but not a simple patch because the convoluted login process has to be suspended while the user is presented with an email form. A fake email template might make the workflow in the patch better and allow the user to edit their entire profile and email upon logon.

When creating drupal accounts with cron or other batch processes

  1. A fake placeholder email address was made for the mail field
  2. In user->data it was noted that the user needed to supply a real email on logon.
  3. on logon the user was presented with an email form.
ottawadeveloper’s picture


I'm still pretty new at this, so please forgive me if anything is out of place :).

I had to fix this same issue, for the launch of the University of Ottawa's new Drupal-based multi-site configuration. After reading this issue, I decided to code the second option presented in #9 as a separate module.

To use it, you would specify a fake email template using the email template available the LDAP module already, using another unique property and a fake sub-domain like for example. Then you can configure my module to look for users with those emails as they login and force them to update their information.

If you'd like to include this in your larger LDAP module, that would be great, if not I'll see if I can make it a full project so that people can add it in as needed to fix this issue.

johnbarclay’s picture

This looks good to me. It should go in ldap_user in the 2.x branch I believe. The other thing is maybe add a validation function on the the user update to check that the email is not the fake one.

ottawadeveloper’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Assigned: Unassigned » ottawadeveloper
Status: Active » Needs review
19.16 KB

Here's my first attempt at a patch (ever!) to include this in ldap_user. I've added the hook to update email on login, and configuration settings to the Users tab for setting the regular expression for temporary (or 'fake') emails created by LDAP. I also, as you recommended, added validation options - it will check to make sure it does not match the fake email and also provides an option to match against a valid pattern (in case you want to specify that it has to be a corporate email for example).

johnbarclay’s picture

This looks good. I ran across some other use cases for a fake email template. Some of this functionality should be in drupal core which requires email in the UI but not in user_save() function or the user table schema. Here are some related core issues #189544: Allow administrator to edit account without email address (regression: accounts can be created without email addresses also),

What do you think about a list of checkboxes for such as:

Missing email template (text field) : [property.uid]

Use missing email template as follows: (checkboxes)
[x] to populate duplicate/conflicting emails for separate ldap driven drupal accounts
[x] when ldap entry configuration does not provide an email
[ ] require users to replace template when updating or activating account
[ ] disable and hide email field on all user account forms
[ ] send all emails using fake template to site administrator. (This is to alert admins that email functionality is being used by drupal core or contrib and would use hook_email_alter() to implement.)

ottawadeveloper’s picture

I like it - should we move it into ldap_servers though (so you can use a different LDAP attribute for each server)? Perhaps beneath the Email Template field that's already there. I really combining the fields - it will make for a cleaner user experience when using this feature.

johnbarclay’s picture

Yes. I think anything specific to a server configuration should go in ldap server. From a user perspective it may belong in ldap_authentication or ldap_user (in 7.x-2.0), but I think its best to have it in ldap_server.

mshaver’s picture

If a site is primarily using the ldap_user provisioning parts to provision accounts to ldap, there should also be an option in the email fieldset to allow entering an email on registration and updating it. This will allow the provisioning code to push those updates to the ldap server. Does this make sense?

johnbarclay’s picture

yes. I'll make sure this is added in.

johnbarclay’s picture

Status: Needs review » Needs work

I've added the ability to leave the email field editable.

Email Behavior *
 O Don't show an email field on user forms. LDAP derived email will be used for user and connot be changed by user
 O Show disabled email field on user forms with LDAP derived email. LDAP derived email will be used for user and connot be changed by user
 O Leave email field on user forms enabled. Generally used when provisioning to LDAP or not using email derived from LDAP.

ottawadeveloper's patch will deal with the issue of empty email fields when provisioning drupal users. The third option simply helps when provisioning to LDAP or when a user's email derived from ldap is known to be bad, fake, or editable by the user. This is committed to 7.x-2.x-dev.

I'm leaving this as needs work for ottawadeveloper's patch.

johnbarclay’s picture

A patch for this is in #1803246: Do not update account mail information if LDAP mail field is empty which I'm marking as a duplicate.

johnbarclay’s picture

Status: Needs work » Needs review

Please try out the patch referenced in #19.

yjchen’s picture

1. User fields such as email and password would be editable in mixed mode. 2. These visible fields such email could be default value when empty in ldap.

ref. editable email: 5f61fac3017cc83f4e93579b99359636e08e9d3a

johnbarclay’s picture

Priority: Normal » Major
ottawadeveloper’s picture

I apologize for my long absence - I got hung up at work with a big launch. With that out of the way, I'm going to work on a patch for this now that will include:

- the email empty settings from #1803246: Do not update account mail information if LDAP mail field is empty
- an additional setting for notifying the site admin when somebody creates an account using the template and for requiring them to put in an email on login if they have the empty one (as discussed in #13)
- the form I have in my sandbox module for requiring the email on login (#10)

Finally, I noticed there is currently a bug that causes the email to be reprovisioned from LDAP on login which is playing havoc with my sandbox module. Will have to track that down so that we can test properly.

ottawadeveloper’s picture

Alright - I've attached a patch that hopefully makes handling missing emails from LDAP in a better and consistent fashion. Here's a summary of what I've added:

  • Under Authentication, I've added a setting to configure a template (that can use the Drupal username via @username). It comes with a setting to control when it is used: you can never use it, always use it or only use it when the LDAP email is blank. I put it under Authentication because it makes more sense to me to be able to replace a blank email with the template regardless of which server left the template blank (the server's email template, in my mind, is better used if you can programmatically determine the email address from the LDAP record).
  • There is an additional checkbox to use this template should there be a conflict with an existing Drupal account (different account names, same email). This will cause the template to be used instead of the LDAP entry.
  • Still under Authentication (since it relates to the Authentication process), there's a section for User Email Prompt. You can provide a regex that will match your email template (I let you customize the regex in case you want to handle older patterns as well).
  • There are two checkboxes which control when the user's email is checked to see if it matches this pattern. When prompting on every page load, code in hook_init() will check the logged in user to see if we should redirect them to the form to update their email address. When redirecting after logging in, the login form will take them to that page if they need to update their email address. Note that prompting on every page load does not handle the first page after the user logs in (don't ask me why, it just doesn't - perhaps the user object isn't populated then).
  • Instead of manually creating an email notification, I opted to do a bit of Rules integration - when an account is created by LDAP Authentication, it fires a new Rules event for the account being created, which includes a flag for whether the template was used or not. Using this and Rules, one can easily send emails to anybody they want if these conditions are met. This is an optional integration, so Rules is not required.

I've reviewed my own test case extensively with this patch:

  1. Set the Email and Email Template to blank in the LDAP Server settings (causes a warning, not sure if we should take it out?)
  2. Set the following in LDAP Authentication:
    • Email Behaviour: Leave email on user forms enabled.
    • Email Update: Don't update stored email if LDAP email differs at login.
    • Email Template Handling: Use the template if no email address provided.
    • Email Template:
    • If a Drupal account already exists: FALSE
    • Prompt user for email on every page load: TRUE
    • Redirect the user to the form after logging in: TRUE
    • Template Regex: .*@fake-domain\.com
  3. Log in with an LDAP user who is not in Drupal already.
  4. Verified that the fake address was created successfully and I am now being shown the form to update my email address.
  5. Verified that attempts to go to other pages take me back to the form to update my email address.
  6. Verified that filling out a valid email address that does not match the regex and does not exist in the system updates my account.
  7. Verified that I am able to access all pages now without being redirected.
  8. Logged out
  9. Logged back in
  10. Verified that I do not see the email address update form and that I was able to browse through the site without seeing it.

If others who are looking to fill in the blanks for email addresses could also verify that this fits their own use cases, that would be awesome - I'm happy to tweak things or add new settings if there are other common cases that need to be adddressed.

ottawadeveloper’s picture

Oops - I missed a few minor things in my last patch (just forgot to commit last bits of cleanup). This one should be good.

johnbarclay’s picture

Thanks. Appreciate the thoroughness. I committed patch #25. Please test.

larowlan’s picture

Status: Needs review » Closed (fixed)

#26 indicates this went in

grahl’s picture

Version: 7.x-2.x-dev » 8.x-3.x-dev
Status: Closed (fixed) » Active

Somehow this is only partially present in 8.x with the profile form, need to bring that back apparently.

  • grahl committed 5c91cc1 on 8.x-3.x
    Issue #1321258 by grahl: LDAP Authentication:  Allow entering of email...
grahl’s picture

Status: Active » Fixed


Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.