392311 - Impersonate fails to authenticate user against LDAP

Status: RESOLVED FIXED

(Bugzilla :: User Accounts, defect)

Description

[Brian Cook]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
Build Identifier: 

When you try to impersonate someone, you get the warning screen and are required to put in your password.  Your password does not work if your password only exists in LDAP.  Impersonating as a normal bugzilla DB user works fine.

Reproducible: Always

Steps to Reproduce:
1. log in as a user who can only be authenticated against LDAP, and who is in the bz_sudoers group
2. go to the edit user account page of another user
3. click impersonate
4. enter your password
5. bugzilla reports your password as invalid

Comment 1

[Marc Schumann [:Wurblzap]]

Confirming.

Technicals behind this: the form puts the user's e-mail address into the Bugzilla_login <input> field. This is not necessarily equal to the LDAP login name.

There are similar problems to be expected when using userprefs.cgi?tab=account.

Comment 2

[Brian Cook]

Thanks for the info.  I assume a present workaround then would be to change the 
LDAPuidattribute in parameters -> LDAP to be the same as LDAPmailattribute.

Comment 3

[Max Kanat-Alexander]

Oh, that should be as simple as putting Bugzilla->login instead of Bugzilla->email, I'd imagine.

(And it it isn't that simple, then it certainly *should* be...)

Comment 4

[Marc Schumann [:Wurblzap]]

Well, that's what it already says. (Bugzilla->login.) Bugzilla->login returns the e-mail address, even for LDAP authenticated logins.

Comment 5

[John Faith]

It seems that the LDAP login is not kept in the "profile" mysql table.  Even if the email address were not used for the Bugzilla_login parameter, where would the "real" LDAP login ID come from?  I wonder if a new column is needed in the profile table.

Would one workaround be to make the Bugzilla_login parameter in the HTML form not hidden, and have the user re-enter the ID?

Comment 6

[Max Kanat-Alexander]

Oh, I meant Bugzilla->user->login.

Comment 7

[TT]

This bug is preventing me from sending emails to mailing lists whenever a new bug is created.  

At my company, Bugzilla is configured to authenticate via LDAP, but I do not have the ability to create new LDAP users.  I can create a new Bugzilla user, but I cannot log in as him.  So I created a user with the email address of a mailing list, with the intent of configuring that "user" to receive an email whenever a new bug of a certain product is created.  However, the only way I can configure the user to impersonate him.  But I can't impersonate him because of this bug.

Comment 8

[Brian Cook]

(In reply to comment #7)
 You should be able to work around this if you have bugzilla auth set to LDAP, DB.  If the mailing list user is in the local DB and uses the email address as the login, you should be able to impersonate him.  

Of course, you can also use the workaround I suggested in comment #2, which is just change the LDAPuidattribute to be the same as the LDAPmailattribute.

Comment 9

[Brian Cook]

(In reply to comment #5)
> It seems that the LDAP login is not kept in the "profile" mysql table.  Even if
> the email address were not used for the Bugzilla_login parameter, where would
> the "real" LDAP login ID come from?  I wonder if a new column is needed in the
> profile table.
> 
> Would one workaround be to make the Bugzilla_login parameter in the HTML form
> not hidden, and have the user re-enter the ID?
> 

re-entering the user ID would work fine.  I don't think a new table row is needed.  There are 2 other possibilities.  

1. If auth is set to LDAP, do a query on LDAP to get the LDAPuidattribute from user whose email matches LDAPmailattribute.

2. Store the login name (regardless of what auth method you are using) in the cookie.  This is probably better since I would assume this bug exists for RADIUS users as well, and this would fix the problem for all auth methods.  Of course so would re-entering the user name manually.

Comment 10

[Frédéric Buclin]

The Bugzilla 3.0 branch is now locked to security bugs and dataloss fixes only. This bug doesn't fit into one of these two categories and is retargetted to 3.2 as part of a mass-change. To catch bugmails related to this mass-change, use lts081207 in your email client filter.

Comment 11

[Frédéric Buclin]

Bugzilla 3.2 is restricted to security bugs only. Moreover, this bug is either assigned to nobody or got no traction for several months now. Rather than retargetting it at each new release, I'm clearing the target milestone and the bug will be retargetted to some sensible release when someone starts fixing this bug for real (Bugzilla 3.8 more likely).

Comment 12

[Denis Eperonnier]

I just had the same using Bugzilla 4.2.5

Comment 13

[emmanuel orvain]

I just had the same issue too with 4.2.5 version. We can impersonate a user by using the password from DB, not with the LDAP password.

Comment 14

[mathias.tausig]

Still there in 4.4

Comment 15

[Frédéric Buclin]

Fixed by bug 1185241.