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
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
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.
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...)
Well, that's what it already says. (Bugzilla->login.) Bugzilla->login returns the e-mail address, even for LDAP authenticated logins.
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?
Oh, I meant Bugzilla->user->login.
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.
(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.
(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.
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
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 → ---
I just had the same using Bugzilla 4.2.5
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.
Still there in 4.4
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.