503092 - With the LDAP,DB user_verify_class, users can update their DB password and then have two passwords (which is confusing)

Status: NEW

(Bugzilla :: User Accounts, enhancement)

Description

[Daniel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)
Build Identifier: 3.2.3

In a mixed environment with internal LDAP users (in my case MS AD) and external DB users the following strange behaviour appears:
A LDAP user can authenticate with his LDAP name or his e-mail address, which is a nice feature. But when he changes his password in the user interface, he can authenticate in two ways:
1. LDAP user name + LDAP password
2. e-mail + DB password

Reproducible: Always

Steps to Reproduce:
1. Log in with LDAP user
2. Change password
Actual Results:  
Two Logins for one user.

Expected Results:  
Disable password changes for LDAP users.

Could the LDAP users be marked as LDAP to gray out or disable the password change?

Comment 1

[Michael Thomas (Mockodin)]

Hmm, something I'd like as well.

Regardless of auth type type we used, we would need to store the auth type to the current session and the session cookie for reloading on page change. Bugzilla::Auth and Bugzilla::Auth::Cookie seem a good place to start.

I'd be willing to tackle this.

Comment 2

[Michael Thomas (Mockodin)]

The mechanism for hiding the fields is already in place, for example if you only use ENV, LDAP, RADIUS auth it already hides the password change fields.

Where to store the flag is the question, after initial log in, cookies are used for any subsequent interaction.

The most likely place might be the 'logincookies' table with a new field to record how a particular log in occurred, in fact would make for a nice record anyhow since we are storing history even if only temporarily there.

Comment 3

[Max Kanat-Alexander]

The thing to do here, I think, is to store in the user's profile the last Auth Login and Verify methods they used successfully that weren't a cookie. This would handle a lot of various architectural issues that I had with determining how the UI should be displayed based on the currently-configured login schemes.

Comment 4

[Max Kanat-Alexander]

Oh, logincookies is an even better idea, Michael. :-) That way if people log in from multiple machines it won't mess things up.

However, that won't work if we don't issue a cookie! (For example, in Env auth.) Any ideas what to do about that?

Comment 5

[rojanu]

This looks like the bug I raised Bug 567729. To me this is very important and we are not using LDAP for that reason.

Comment 7

[txomon1]

I want to say my opiniion. Using LDAP and storing the password in the Database is just counterproductive.

The idea of LDAP is somehow having a OAuth service (plus some other things), but not independant from the server requesting (he has access to the real password).

So I would please ask that at least, storing (or not) the password on ldap users should be optional.

Comment 8

[Marshall]

WORKAROUND:  Set profiles.cryptpassword = '*' for users created by authenticating via LDAP.

Caveat:  If users can be created via DB, but later switch their auth method to LDAP or RADIUS; I'm not completely sure if this workaround is complete.  This of course applies to switching from any auth method to another one.