[SERVER-41083] Update LDAP logging to include connection failures to LDAP servers and retry logic Created: 10/May/19 Updated: 23/Jul/19 Resolved: 23/Jul/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Logging |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Kip Iwakiri (Inactive) | Assignee: | Jonathan Reams |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Sprint: | Security 2019-06-03, Security 2019-06-17, Security 2019-07-01, Security 2019-07-15, Security 2019-07-29 |
| Participants: |
| Description |
|
Follow up from Update LDAP logging to include connection failures to LDAP servers and retry logic: Current logs below show a successful authentication that is missing a failed authentication attempt:
Suggested Update:
In addition, the logs indicating the LDAP server connections are only exposed with verbosity 3 on accessControl. At least the retries and failures should be listed in the default logging for troubleshooting outages. |
| Comments |
| Comment by Kip Iwakiri (Inactive) [ 22/Jul/19 ] |
|
I think most of the problems we were trying to fix are mostly resolved somewhere in https://jira.mongodb.org/browse/SERVER-41939.
Customer would still like to see connection failure logs but, based on our conversations, I don't think it'll be necessary for them to proceed further. Should be good to close this ticket. |
| Comment by Kip Iwakiri (Inactive) [ 21/May/19 ] |
|
I'll have to test the logging in the new connection pooling to see. As long as we can see discrete connection attempts I believe customers will have enough to start the troubleshooting process without relying on packet captures to guess at what's happening. |
| Comment by Jonathan Reams [ 21/May/19 ] |
|
kip.iwakiri, the connection callback we added in |