ldap.m.o/passwordreset/ fails to send 401 when "Cannot Bind to Ldap Server" due to bad credentials

RESOLVED FIXED

Status

Infrastructure & Operations
Infrastructure: Other
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: atoll, Assigned: jabba)

Tracking

Details

(Reporter)

Description

6 years ago
After changing my password, I accidentally navigated back to the passwordreset page. My basicauth was cached and permitted with the old password, but the application itself returned the plain ASCII response "Cannot Bind To Ldap Server", presumably associated with a bind failure due to invalid credentials.

Consider returning a 401 when a bind failure returns "invalid credentials".
(Assignee)

Comment 1

6 years ago
Interesting that it happened like that. I think the app grabs the credentials from the http basic auth, which I thought would have failed and returned the 401. I'm not sure if this is something that can be fixed in the auth section of apache, but regardless I agree it should be fixed.

rtucker - can you tweak the passwordreset page to return 401 when a bind failure happens?
Assignee: server-ops → rtucker
Component: Server Operations → Server Operations: Infrastructure
QA Contact: phong → jdow
(Reporter)

Comment 2

6 years ago
What's LDAPCacheTTL set to?  Default is 10 minutes, which would explain why trusting Apache is insufficient.
jabba:
It would be a global 401 response for a bind failure happening. I don't think it would cause any problems by having a 401 globally for all bind failures. Thoughts?
(Assignee)

Comment 4

6 years ago
I'm wondering if there is a failure of the bind that the bind user does to search for the actual user, if that should not be a 401 but rather a 500 or something different, since it's a different type of error.

I don't think there currently is a LDAPCacheTTL setting at all, which would indeed explain the issue there. Perhaps setting it explicitly to 0 would be a good fix?
jabba,
That very well will fix it, but would the additional load of doing a new lookup every time be too much for the seamicros?
(Reporter)

Comment 6

6 years ago
(In reply to Rob Tucker [:rtucker] from comment #3)
> jabba:
> It would be a global 401 response for a bind failure happening.

The bind failure reason is available for inspection. It would be misleading (but probably harmless) return 401 for *all* failure code when you only want to return it for a single specific failure code.

(In reply to Justin Dow [:jabba] from comment #4)
> I don't think there currently is a LDAPCacheTTL setting at all, which would
> indeed explain the issue there. Perhaps setting it explicitly to 0 would be
> a good fix?

You may want to lower it gradually, rather than shutting off caching entirely. A cache of even just 10 seconds would presumably stop 95%+ of all LDAP queries that would otherwise be sent to the slaves (due to images, styles, etc). A cache of 0 seconds would amplify the # of LDAP queries from "1 per page view at minimum" to "1 per page resource at minimum", which can be 10-20x or more on some pages.
(Assignee)

Updated

5 years ago
Assignee: rtucker → jdow
(Assignee)

Comment 7

5 years ago
I lowered the LDAPCacheTTL to 10, and tested changing my password on https://ldap-dev.allizom.org/passwordreset. After successfully changing, I hit enter in the URL bar to get the page again and it prompted me again for basic auth and did not accept my firefox-stored "old" password. I think this is fixed. Added to puppet for production as well.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Component: Server Operations: Infrastructure → Infrastructure: Other
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.