[Haqa]

Originally Posted by warhau

Excellent. Good to know that it's possible without modifying the vb code (login.php or global.php). I'm still completely stuck with the failed login message on new account creation.

Interestingly I was having your problem of password changes not updating from the external source. I added some debug code and found that without

define('DISABLE_PASSWORD_CLEARING', 1);

in config.php, the first test in the plugin was failing

$vbulletin->GPC['vb_login_password'] == '' was true

That is because as you hit the login button the javascript in the page encrypts your password and deletes the unencypted copy (in the field) - Ever noticed that the field goes blank as you hit login? That's why. This is a sort of security feature so no one snooping on the wire can see the plain text password, however a plugin of this sort needs the plain text password to work, so if my plugin see the field empty it just gives up early because there is nothing it can do.

Originally Posted by jaikumarm

Okay looks like I got lucky.. here's what I did to fix the first time login failure..

edit the product-ldap_auth-1.5.xml either in notepad and reimport or edit the plugin in admin panel->plugin manager

Find:

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

at the very end of the product xml file

Add:

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

So you are basically re-running the login logic (It's also called earlier in the plugin), and this solves the problem? Cool.

May I include your patch in the next release?

H.

[Blinker]

I tried jaikumarms code: it works perfect, new users become no error message ! Thanks for that.

And special thanks to Haqa for this Mod !!!

[n0manarmy]

Originally Posted by warhau

Excellent. Good to know that it's possible without modifying the vb code (login.php or global.php). I'm still completely stuck with the failed login message on new account creation.

Interestingly I was having your problem of password changes not updating from the external source. I added some debug code and found that without

define('DISABLE_PASSWORD_CLEARING', 1);

in config.php, the first test in the plugin was failing

$vbulletin->GPC['vb_login_password'] == '' was true

so the plugin was exiting. I re-added the line to config.php, and password changes work. However, I did notice that, because of the way my plugin is written, the old VB password will continue to work until the new external password is entered. This is because my plugin fails over to internal users if external auth fails.

Unforunately when the new external password for an existing user is set in VB upon login, I still get the failed login error message, even though the new password gets set, and you can log in using the new password by refreshing the page.

There's obviously something missing from my plugin that should be setting some cookies and/or session stuff correctly. Can't figure it out.

I can't seem to get this working. I've got everything up and going with being able to log in and authenticating against LDAP. It immediately processes the login and the user's away and posting.

I can't get password changes working though. I tested it with an account, as soon as the password changes, they can't log in with the new password, they can only log in with the old password.

Also,

If someone changes their password through their CP, it not only breaks their old password from working, but the new one doesn't work as well.

Also Also,

It appears that by changing my password through the CP it has broken my ability to create new users....?

EDIT For follow up:

I edited the line
$show['nopasswordempty'] = defined('DISABLE_PASSWORD_CLEARING') ? 1 : 0; // this nees to be an int for the templates
To appear like above

I was able to log in again with accounts. I don't know if this was somehow reset during my monkeying or not. Everything appears to be working now, including password changes.

[Haqa]

Ohh... hmmm
You probably want the "Disable vBulletin Users" turned on. That should (might) make it prefer the LDAP users.

What you are describing with the passwords not changing is that the user update isn't working correctly. This puzzles me because it's relatively simple code, and it's working for some people.

What kind of LDAP server are you reading from? Do you have access to the query logs to ensure that the user is validating and querying their entry correctly?

H.

[jaikumarm]

Originally Posted by Haqa

So you are basically re-running the login logic (It's also called earlier in the plugin), and this solves the problem? Cool.

May I include your patch in the next release?

H.

Yes, that's was the idea, to trigger the re-login in-code, so that the user does not have to.

Sure, go ahead and include my patch. Thanks much for plugin, it has for sure saved me tons time.

J.

[warhau]

Thanks everyone. With the new redirect code, I can got straight in via our SOAP authentication.

I did have a problem with jaikumarm's patch code, when retaining client-side MD5 encoding. The last line "do_login_redirect()" was causing a loop and eventual PHP memory crash. This appears to be due to the global_complete hook being called in print_output in functions.php, which was looping back into the login process. In the original code, there was a line:

$vbulletin->GPC['vb_login_password'] = '';

This kept the plugin from firing when global_complete was called. Without vb_login_md5password being cleared, the plugin was firing everytime it would reach "do_login_redirect()", resulting in the loop.

I also notice that in jaikumarm's code, he is still using

$vbulletin->GPC['vb_login_password']

in his call to verify_authentication. Theoretically, as part of the original code, isn't vb_login_password empty at this point? I'm not sure how verify_authentication would work there with a blank password. Anyway, I didn't have problem with that, but I did have to clear vb_login_md5password just prior to calling do_login_redirect, since my opening logic in the plugin prevents firing if md5 password is empty.

Finally, in the original code, I noticed:

$vbulletin->GPC['cookieuser'] = $vbulletin->GPC['vb_login_username'];

As I was going through login.php, I noticed that it looks like cookieuser is supposed to be BOOL. Not sure this would cause any problems, but I just removed the line completely and everything works fine.

Thanks to Haqa for a good example, that allowed me to write exactly what I needed, and to jaikumarm for helping to complete the puzzle!

[paul41598]

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

???

[Haqa]

Ahh... You haven't installed LDAP support for PHP.

Requirements

* PHP 4.3+ with LDAP support.

It can't work without it, sorry.

H.

[paul41598]

Yah I've enabled it now. Still doesnt work when trying to log in as a test AD user. Just keeps saying invalid username /password.

I've read every page of this thread and cannot get this to work. I've follow the instructions completely, put that DEFINE piece of code in my config.php, uploaded the XML to the includes/xml dir. NOTHING.

Running Win2k 2003 with AD

[warhau]

Originally Posted by paul41598

Yah I've enabled it now. Still doesnt work when trying to log in as a test AD user. Just keeps saying invalid username /password.

I've read every page of this thread and cannot get this to work. I've follow the instructions completely, put that DEFINE piece of code in my config.php, uploaded the XML to the includes/xml dir. NOTHING.

Running Win2k 2003 with AD

I'm not sure about Windows, but the Centos RPM distro of PHP does not come with ldap support built in. I needed to install the php-ldap library.

Looks like there is a thread at http://forums.devshed.com/showthread.php?p=1173879 which covers installing PHP LDAP support for Windows, just in case.

[Haqa]

When I get the next release of this out attached to a better hook point I think the experience will be better. Can you put a screenshot of your settings up (Or pm me your settings) so I can take a look? It sounds like you are either not querying the correct branch of the AD's LDAP or you aren't pulling the correct attributes out.

H.

[warrentr2]

Thanks for this mod Haga,

I seem to be stuck when I hit any error cases. Specifically using the vB standard_error function from within the global_complete hook causes browsers to hang when they hit this error. As a test I tried the following from the forumhome_start hook, and it was successful:

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

But it just wont work from global_complete...

I am running vB 3.8.2. Have you come across anything like this? Thanks

[kamalrij]

Worked for me as well.

Thanks
Kamal

[kamalrij]

Originally Posted by jaikumarm

Okay looks like I got lucky.. here's what I did to fix the first time login failure..

edit the product-ldap_auth-1.5.xml either in notepad and reimport or edit the plugin in admin panel->plugin manager

Find:

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

at the very end of the product xml file

Add:

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

This is basically the std login code for vb. I have just ended up re-logging the user with the login credentials provided earlier.

So here is the quick retrace of steps.
Installation
1. Add the command define('DISABLE_PASSWORD_CLEARING', 1); to your includes/config.php - This will NOT be overwritten by upgrades, so only needs doing once.
2. Upload the file hooks_ldap_auth.xml to includes/xml under your forum.
3a. Edit product-ldap_auth-1.5.xml with the changes as above
3b. Install the modified product file using the Add/Import Product link on the Manage Products page under Plugins & Products in your AdminCP.
4. Edit LDAP Authentication Options and fill in your ldap details
5. Done.

This quick fix resolved the issue related to the error around first login for the user.

[Haqa]

The odd thing is that I am using this on a 3.8.2 without this alteration and it appears to be working properly. Odd...

As for the errors not working, I've not experienced that either. Due to a fault in the AD replica I rely on a number of users password didn't get updated last time they changed them (It's still got their previous password), so they get login errors if they forget and use their current password.

I think the best (though not necessarily the easiest) solution is to persuade Jellsoft to add a hook in the login process, as IMHO that would solve almost all the problems being reported here.

I'll ask them and see what they say.

H.