Impersonate fails to authenticate user against LDAP

RESOLVED FIXED in Bugzilla 6.0

Status

()

RESOLVED FIXED
11 years ago
3 years ago

People

(Reporter: brian, Assigned: LpSolit)

Tracking

Bugzilla 6.0

Details

(Whiteboard: [Fixed by blocker])

(Reporter)

Description

11 years ago
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
(Reporter)

Updated

11 years ago
Version: unspecified → 3.0
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
(Reporter)

Comment 2

11 years ago
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

11 years ago
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...)

Updated

11 years ago
Target Milestone: --- → Bugzilla 3.0
Well, that's what it already says. (Bugzilla->login.) Bugzilla->login returns the e-mail address, even for LDAP authenticated logins.

Comment 5

11 years ago
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

11 years ago
Oh, I meant Bugzilla->user->login.

Comment 7

11 years ago
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.
(Reporter)

Comment 8

11 years ago
(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.
(Reporter)

Comment 9

11 years ago
(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.
(Assignee)

Comment 10

10 years ago
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.
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2
(Assignee)

Comment 11

9 years ago
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).
Target Milestone: Bugzilla 3.2 → ---

Comment 12

6 years ago
I just had the same using Bugzilla 4.2.5

Comment 13

5 years ago
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

5 years ago
Still there in 4.4
(Assignee)

Comment 15

3 years ago
Fixed by bug 1185241.
Assignee: user-accounts → LpSolit
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Depends on: 1185241
Resolution: --- → FIXED
Whiteboard: [Fixed by blocker]
Target Milestone: --- → Bugzilla 6.0
You need to log in before you can comment on or make changes to this bug.