New LDAP Users?

The what users? haha

Give me some more info on what an LDAP user is, and I'll look into whether or not I can implement this feature. Though as I said on the top page, new features will only be added for version 2, not version 1. I just want to work the bugs out and get a full release of version 1. But version 2 shouldn't be too far behind - the coding behind the module is relatively simple, and I don't foresee there being too many bugs in it.

I'm not finding an ldap_authentication module. There modules I'm finding are ldap_provisioning and ldap_indegration.

As for why ldap users aren't being forced to create a new password - my module adds a field to the {users} table in the database. The current user's data is automatically loaded from this table on each (or at least most) page loads. My module then checks to see if the field I created says to force the user to reset their password or not.

In the case of LDAP, it appears that the users data is saved to a different table, which means that my custom data isn't being loaded for each page load. There is a possibility that I can add this functionality, but first I will need to see how LDAP works. But I don't mind spending a bit of time doing this, as it will increase my knowledge a little bit one way or another.

But can I ask, why are you using this module? What are the benefits? I've not come across this before, and I'm interested to know more about it and what the advantages of using it are (maybe I will start using it if it matches some of my projects).

Edit: Ahh, I just found what you are talking about. The ldap_auth module is part of ldap_integration. Upon reading the documentation, the first thing I came across is this:

This LDAP integration module allows users to authenticate against a configurable Lightweight Directory Access Protocol directory. This is useful for organizations which have an existing organizational directory with usernames and passwords, and want Drupal to be able to authenticate against it.

If the user data table is stored outside Drupal, I very likely won't be able to make this module work for you.

Second Edit: Upon reading more, I have found that you *may* possibly be able to change the configuration of the module to work for you. You map Drupal fields to the LDAP fields at Administer >> Site configuration >> ldapdata . It's possible you may be able to map the database field my module creates to the LDAP data (I don't have a system to do any testing with, so I don't know if this is can be done or not, but you can try). The database field I created is called 'force_password_change'. See if you can map that to something in your LDAP module. Good luck!

Hi Jay,

I'm having the same problem with password change at login not working using LDAP authenticated users. I've determined that the problem lies in the order of the calls (as it usually does) between your module and the ldap_authenticate module.

Essentially, the ldap_authenticate module updates information from the LDAP directory to synchronise profile fields if you have this setup (which I do to play nice with other modules I'm using for profile functionality). This means that the LDAP module calls user_save() a couple of times during login.

Your force_password_change_user() function is called with $op == 'update' during the login procedure and it sets the force_password_change field to 0 long before the force_password_change_init() is called on the first logged in page, thus no login password reset.

Using the Utility module, I tried changing the weights of the modules so they happen before or after each other and it doesn't make a difference - either way results in LDAP authentication (with its user_save()'s) before the first _init() hook is called.

I'm trying to figure out an elegant way of solving the issue without making the modules aware of each other (I think that's nasty) so will report back if I can work it out.

Cheers,
Johan

Hi again,

I toyed with a few different options on how to fix this, and in the end I came up with the attached, very simple patch. Essentially it just ensures that in the user hook 'update' op that we came from the password change form by adding a hidden field in the form_alter hook.

I wouldn't say I've tested it extensively, but it's working really great against my LDAP directory - new users are being forced to change their password first thing, and editing a user and ticking the box is working on the next link the logged in user clicks.

Cheers,
Johan

Hello Johan

Thank you for the patch. I always appreciate when someone comes to me with not just a problem, but also a solution to said problem! Unfortunately, you caught me in the middle of an extremely busy week. I'll review this patch next week, and if it looks good, I will include it in the next update.

subscribe

I've looked at this patch, but I'm a little antsy about using it. I really don't like using hidden form fields for much of anything, as I find there is almost always another way around using them.

Johan: Can you go over your explanation of the order of things a little more specifically so I can understand the problem? I read, and re-read your last post a few times there, but I really didn't get what you are trying to say. If you could give me an ordered list of what is happening when, and then explain where and why the problem is, I can probably come up with a solution that works for both of us.

Jay

p.s. - ninjay, I like the name - I even used the same one as my cell phone email address a few years back!

Hi Jay,

Perhaps I can simplify. When the user logs in:

[ Start with a user who has force_password_change=1 ]

1. The ldapauth module checks the user's authentication against the LDAP directory
2. The ldapdata module (if enabled to synchronise) then synchronises the user's profile fields with the LDAP directory.
3. The previous step calls user_save() which results in:
force_password_user_change('update')
which results in
force_password_change=0
4. The first page loads and calls force_password_change_init, but by this point firce_password_change is 0 on the user, so no password reset is forced.

My patch simply makes sure that force_password_user_change('update') only changes the force_password_change flag on the user if the user has actually been edited from the edit form.

Works perfectly for me for about 900 users - I'm sure there's more elegant ways to solve it but I don't have time to find them.

Cheers,
Johan

Have you tried http://drupal.org/project/password_policy ? It has the same password expiration features, fewer bugs and doesn't tinker with core table schema.

Johan - thank you for the explanation, I appreciate the time you have taken to explain it. Now I can see what you did and why you did it - I think I have a solution in mind to fix this. If it doesn't work, then I will incorporate your patch.

afreeman - Bugs?! Please, open an issue for any bugs that you find, I am happy to fix them! I assumed there weren't any, seeing as this is the only bug issues open in my issue queue . I wonder why people wouldn't bother to report them if they found them. Seems strange considering there are at last count just shy of 100 users using the module. Seems pretty, pretty strange...

By the way Johan - I apologize if you are not sure exactly what that last exchange is all about. afreeman wanted to take over my module a while back, and wasn't impressed when I refused (which I can understand - but I prefer to work alone). We've also had some discussions as to whether my addition of a column to the {users} table is appropriate - he is of the opinion it's not, but I'm of the opinion that the change to the user's table is better than the significant number of extra queries it would require if I were to do it his suggested way.

Either way, you may want to read this thread to make the decision yourself about whether you want to use this module or not, based on the the discussion within.

Regardless, thanks again for your contribution to of the patch, I appreciate it.

Hello Johan

Thank you again for submitting the patch. I have applied it 99.9% as-is to the newest version of the module. I just made two slight changes:
I changed: array_key_exists('pending_force_password_change', $edit) to isset($edit['pending_force_password_change']), and I changed the additional $form element from type 'hidden' to type 'value'. But I stuck with your logic on the matter fully.

Can you please let me know if it works with your LDAP system? If it does, I will roll out version 2.0 of the module (not beta). Thank you.

Jay