WeBWorK Main Forum

automatically logged back in with LDAP on v.2.14

automatically logged back in with LDAP on v.2.14

by Andras Balogh -
Number of replies: 13
After timeout users are logged back into WeBWorK automatically with LDAP without asking for password after upgrading to v. 2.14.

After logging in with LDAP, and after not working on a page for a long time, when the user tries to do something on a webwork page there is a warning message:
  • AUTH LDAP: bind error 48: The server requires the client which had attempted to bind anonymously or
  • without supplying credentials to provide some form of credentials
However, the user is not kicked back to the login page like it happened before with v. 2.13. Instead, normal operation is resumed with the user logged in.

Using a local account the user is kicked back to the login prompt for a password after timeout as it is supposed to happen.

In reply to Andras Balogh

Re: automatically logged back in with LDAP on v.2.14

by Michael Gage -
Thanks for the report.


Has anyone else been able to repeat this behavior?

I couldn't immediately find
any changes to the LDAP authorization code that were made within the last five years.

Does this behavior happen with 2.13?
In reply to Michael Gage

Re: automatically logged back in with LDAP on v.2.14

by Danny Glin -
I'm not seeing this with 2.14, but I'm also running a custom version of the LDAP module that would probably have overridden any changes that appeared in 2.14.

Also, this issue may only appear when using the LDAP code to authenticate to a Windows Active Directory server, since the error message quoted talks about trying to bind anonymously, which is allowed in openLDAP but not in AD.
In reply to Danny Glin

Re: automatically logged back in with LDAP on v.2.14

by Andras Balogh -
Yes, It is a Windows Active Directory server, and the authen_ldap.conf file hasn't been changed since 2015.
 
With 2.13 I am certain that the red error message did not show on the webwork pages and after timeout the user had to log in. However, looking at old server logs they do contain the same occasional "binderror 48 ..." lines even from before the update.

Even as local user I seem to remember that after timeout there was some kind of"dueto inactivity" message with the login prompt, but now the message with the login prompt is"incorrectpassword".

Of course it could be also due to possible changes in our Windows Active Directory server, but I am not aware of any such thing.

Using GitHub I can switch back to rel2.13 to test the situation, right?
In reply to Andras Balogh

Re: automatically logged back in with LDAP on v.2.14

by Michael Gage -

Using GitHub I can switch back to rel2.13 to test the situation, right?


Yes. That's on of the big advantages of github and version control. Sometimes if you have made database changes you will have trouble switching back and forth ( although not always, most database changes are backwards compatible) but otherwise it is fairly easy to back out of an upgrade, either temporarily for testing, or permanently while you wait for a fix.


In reply to Andras Balogh

Re: automatically logged back in with LDAP on v.2.14

by Danny Glin -
Now that you mention it I'm noticing that the error message for timed out sessions has changed. In 2.13 we used to get the same "due to inactivity..." message. In 2.14 I now get an "incorrect username or password" message.

Perhaps something changed with respect to session management which is not playing nice with LDAP authentication?
In reply to Andras Balogh

Re: automatically logged back in with LDAP on v.2.14

by Andras Balogh -
In v.2.14 after timeout the login screen is "skipped" and the user name with empty password is automatically resubmitted. For local user this fails with error message "incorrect password" because they "usually" don't have empty passwords, but for LDAP users the local password is usually empty, and hence the local authentication works.
  • How can we prevent the automatic resubmission of username and empty password after timeout, like it was before to get an "due to inactivity..." message?
  • I did modify authen_ldap.conf with failover => "local", so that LDAP accounts are not checked against local database anymore, but still the error message "AUTH LDAP: bind error 48:" is there, which might confuse the user.
  • Were empty passwords possible before?

In reply to Andras Balogh

Re: automatically logged back in with LDAP on v.2.14

by Danny Glin -
This matches what I see on my server, so I can believe that this autosubmission is happening.

It is likely a result of some change in code between 2.13 and 2.14 that is only causing issues when LDAP is used for authentication.

Is anyone able to look into this? I don't know if I will have time until the end of the month.
In reply to Danny Glin

Re: automatically logged back in with LDAP on v.2.14

by Andras Balogh -
I don't think is is just about LDAP.
I can create a local user with empty password, and that will automatically logs in using some kind of autosubmission. In my opinion that is also an issue. Both the empty password and the autosubmission.
In reply to Danny Glin

Re: automatically logged back in with LDAP on v.2.14

by Nathan Wallach -
I'm still a bit new to the codebase, but decided to take a look to see if I can notice something which may be relevant. Someone with more experience and understanding may find the comments below useful in focusing their attention and finding the real issue.

I took a look at the changes from the PR of 2.14 https://github.com/openwebwork/webwork2/pull/865/files to see if I could notice something which may be related, and the also took a look at lib/WeBWorK/Authen.pm to see what I can find.

I'm not sure where the auto-submission could be triggered, but there are some options to consider regarding the acceptance of null passwords.

  1. I'm guessing that the lack of a password prompt is somehow related to the setting of "failover" in $authen{ldap_options} as described in http://webwork.maa.org/wiki/LDAP_Authentication and Andras' comment that setting it to "local" helps solve the problem seems to confirm this.
  2. In the 2.14 changes to lib/WeBWorK/Authen.pm a new trim() function was added, and is called to "clean up" $self->{password}.
  • It seems to be the one of the possibly relevant recent change to the authentication code which is why I'm noting it down here.
  • I'm don't know if this is related to the current issue, but maybe there is something I am not considering, or it is related to how the auto-submission is happening.
  • Could there have been something which used to set the password for "auto-submission" to a string which only contained white-space which only in 2.14 is changed to an empty string, in which case things may have behaved properly (auto-submission with the gake password rejected) before the "trim" was added to 2.14, but now misbehaves as the user really has a null local password?
The checkPassword() function in lib/WeBWorK/Authen.pm does not have any check for the case where the received $possibleClearPassword is a null string.
  • I think the simplest fix to the issue being discussed may be to just reject null passwords right after they are received by this function.
  • So long as rejecting null passwords is an acceptable policy, it quickly would prevent successful fallback authentication for a user with a null "local" password.
If rejecting empty passwords at the start of checkPassword() is not an acceptable solution, then maybe a mechanism to set random passwords for users with null passwords should be considered:
  • Maybe some random "local" password should be set for LDAP users if the system sees they have a null password.
  • The create_user() function in lib/WeBWorK/Authen/LTIAdvanced.pm also does not seem to create any password record for a user added via LTI. I'm guessing that that may trigger the creation of a null or empty password later on. Maybe here a random password should be created and immediately set, as "new" LTI users are not expected to log on using a "local" password (which they don't know) in any case.
In reply to Nathan Wallach

Re: automatically logged back in with LDAP on v.2.14

by Michael Gage -
Tani has submitted a PR to fix the empty password issue. Andras could you check whether this pull request update works on your site?

Any others who can help test this would be welcome.

In reply to Michael Gage

Re: automatically logged back in with LDAP on v.2.14

by Nathan Wallach -
Please hold on testing. The PR is under revision.

It already blocks the empty password, but I am almost done (I think) getting back the message about needing to reauthenticate due to session timeout.

A corrected PR should be ready soon. Sorry.
In reply to Nathan Wallach

Re: automatically logged back in with LDAP on v.2.14

by Nathan Wallach -
I just finished work on the pull request https://github.com/openwebwork/webwork2/pull/911 which is intended to totally disable local authentication using an empty password or a password which is all white-space. I think that it is pretty reasonable to forbid such passwords.

It also should fix the issues which prevented triggering the message
Your session has timed out due to inactivity. Please log in again.

About the "auto-submission" - this is not an old feature, but a change to lib/WeBWorK/Authen.pm from 2.14 seems to have inadvertently changed behavior which prevented the session timeout error from being triggered.
  • When verify_normal_user() of lib/WeBWorK/Authen.pm is called,
  • it makes a call to check_session(),
  • and if the session has expired ($timestampValid is false) or one of the other return values from check_session() is "bad",
  • then the code calls authenticate().
  • On a positive return value that creates a new session,
  • while a 0 return value will be treated as an authentication failure.
  • Only a negative return value triggers the session timeout message.
  • However, authenticate() will only issue a -1 return value when $self->{password} is not defined.
  • The trim() function which was added to 2.14 is called to clean-up the value of $self->{password} but in the process it was replacing the "undef" value with an empty string.
  • The new PR avoids the "undef" value from being changed by trim().
  • It also avoids the "session timeout" error message for the login screen from being overridden when it was set.
I'm pretty confident that the pull request will fix the issues being discussed in this thread.

Andras - the only changed file is lib/WeBWorK/Authen.pm and you can download the patched version of the file from

Nathan

In reply to Nathan Wallach

Re: automatically logged back in with LDAP on v.2.14

by Andras Balogh -
Thanks Nathan,
Everything works perfectly with the revised Authen.pm file.
Local, LDAP, LTI accounts all time out with the correct message, and empty passwords are not accepted.
Thank you very much!