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

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

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.

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.

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

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.)

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.

Hi,

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.

http://drupal.org/sandbox/ottawadeveloper/1678050

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 @fake-email.uottawa.ca 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.

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.

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).

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), http://drupal.org/node/286401#comment-6220436

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

Missing email template (text field) : [property.uid]@devnull.blah.com

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.)

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.

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.

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?

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

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.

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.

Please try out the patch referenced in #19.

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.

• [mail] attribute and default email: [%username@example.com] when empty

ref. editable email: 5f61fac3017cc83f4e93579b99359636e08e9d3a

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.

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: @username@fake-domain.com
   • 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.

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

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

#26 indicates this went in

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

Ported.