Closed (won't fix)
Project:
LDAP integration
Version:
5.x-1.3
Component:
Code
Priority:
Normal
Category:
Support request
Assigned:
Reporter:
Created:
23 May 2006 at 19:39 UTC
Updated:
6 Aug 2011 at 18:33 UTC
The following patch has been filed against core: http://drupal.org/node/64483. The patch attempts to introduce new permissions that prevent users from changing their password or e-mail address. It is argued that people using LDAP want to disable that. I'm thinking that a better solution would be for the LDAP module to use form_alter to modify the user module's form. I'm not sure this is an option but I figured I'd mention it here.
Comments
Comment #1
kreaper commentedI would second this feature. I use the LDAP integration module and authenticate drupal users to Active Directory (basically moving my intranet off to drupal!). We already have a password changing mechanism in place and prefer not have another "forgot password" or any of such utils. All I am looking for is a "User login" box.
In addition, this could be too much to ask, but can the text "User login" be customized ? Then admins in distributed password database environment can speicfy which account to use to login (e.g. "Unix Login", or "Windows Login" etc)...
kreaper
Comment #2
Bèr Kessels commentedI read three different issues in one:
* Dissalow users changing their passwords.
* Dissalow users to change emailadresses.
* Dissalow password retrieval
I will deal with them for 4.7 using FAPI overrides, and will provide some patches.
Comment #3
jeffvogelsang commentedI've been testing user_protect to do essentially the same thing... lock out users from editing their profile. So far it's working for me.
Comment #4
Bèr Kessels commentedThe emailadress is hardwired into Drupals user.module, this gives trouble when no email address is present (often the case when using only ldapauth) or when we use form alter to simply remove the email field from the form.
More info here: http://drupal.org/node/64483#comment-196180
Comment #5
Bèr Kessels commentedtried and tested userprotect. I think it is a good idea to makr this issue won't fix, and distribute this task/feature to that dedicated module.
What do you people think? Should I make a patch that includes 80% of the code from userprotect into ldaputh, or should we trust on this third-party module?
Comment #6
scafmac commentedI'm not familiar with userprotect, but I'm just uploading a new branch of the ldap integration module that provides some of this functionality in 5.0. It provides a UI to:
Additional functionality is included - I presume disabling the email address change fields is also important? It will be easy to add that to a new release.
I didn't create the patch for 4.7 because some of the form alter stuff is not so easy, so perhaps relying on userprotect for the 4.7 version makes sense if it works so well.
Comment #7
Bèr Kessels commentedThis is exactly what userprotect does. I think it is a bad idea to duplicate that functionality.
Comment #8
scafmac commentedIs it LDAP aware as well? The password change function only applies to LDAP accounts. That way a site can prevent LDAP users from trying to change their passwords without effecting Drupal accounts. Also a minor change I'm going to make will allow altering the "Request new password" form instead of overriding it. This can be used to direct LDAP users to an alternate method of reseting a password, without preventing Drupal user accounts from using the built-in functionality.
These changes dovetail with other LDAP options to support a number of popular configurations. I'm not convinced it makes sense to rely on other modules for such an integral piece of configuration. That's not to say that changes to core wouldn't make the functionality obsolete.
Comment #9
scafmac commentedBèr Kessels - Just re-reading the discussion. FWIW the Drupal-5--2-dev branch also allows for email syncing (read only) with just ldapauth.module; as you noted the absence of an email is a problem for Drupal.
Comment #10
scafmac commentedErr, that should have been 5--1-2 - Anyhow most of those changes are in head now.
Comment #11
scafmac commentedThe changes I mentioned in comment #8 plus removing or disabling the email address for LDAP users are now in LDAP_integration HEAD, for any 5.x users. The changes are most useful if you do not want to install userprotect to restrict just one or two things for LDAP users or have both LDAP & Drupal accounts that you want to support independently.
Anyone using 4.7 should look into userprotect. I'm changing this to Version 5.x because AFAIK, no one plans to back port to 4.7, though patches welcome.
Comments appreciated.
Comment #12
baturin commentedHello!
I have a somewhat opposite question: I have configured LDAP auth, but LDAP data does not have e-mails. This is directory of the students and they do not have any common e-mail service. How is it possible to tell Drupal ask users to enter correct e-mail on first login? Because it is definitely required for a site to have e-mail.
Any ideas or suggestions?
Thank you very much in advance!
Comment #13
ckngI would suggest making user changing ldap profile a configurable option. Generally people using LDAP has other existing mechanism for password changing, but there are cases where they would like to use Drupal as the front end to do so.
Comment #14
Papayoung commentedWithout spending a bunch of time sorting out the various version/branch issues above, I though it might help someone to offer my solution. I used hook_form_alter() in my 5.x custom module to check to see if it's an LDAP-managed user, then pass through the required values:
Comment #15
actdigital commentedJust a note - I am using LDAP modules 5.x-1.3. I love the notion of removing password fields for LDAP users - unfortunately it is removing the fields for all users, not just LDAP users.
As I understand it, it's not supposed to work this way. Any ideas to fix this?
Thanks,
-Michael
Comment #16
WorldFallz commentedjust an update-- the http://drupal.org/project/user_readonly module works great for fine grained control here. If you assign 2 different roles for locally created accounts and ldap created accounts you can pick and choose, with complete control, what fields are editable by whom.
Comment #17
johnbarclay commentedClosing 5.x issues to clean out issue queue.