[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 SERVER-37155

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:

2019-05-10T09:56:04.661-0500 D ACCESS   [conn20] Binding to LDAP server "default" with bind parameters: {BindDN: mongodb, authenticationType: simple}
2019-05-10T09:56:04.663-0500 D ACCESS   [conn20] Connected to LDAP server at 10.0.8.254:389 with LDAP URL: ldap://dcs:389

Suggested Update:

2019-05-10T09:56:01.661-0500 D ACCESS   [conn20] Binding to LDAP server "default" with bind parameters: {BindDN: mongodb, authenticationType: simple}
 
---List "default" servers---
 
2019-05-10T09:56:02.663-0500 E ACCESS   [conn20] OperationFailed: LDAP operation <ldap_sasl_bind_s>, failed to bind to LDAP server at 10.0.8.200:389 with LDAP URL: ldap://dcs:389. (-1/Can't contact LDAP server): No error could be retrieved from the LDAP server.. Bind parameters were: {BindDN: mongodb, authenticationType: simple}
 
2019-05-10T09:56:03.663-0500 D ACCESS   [conn20] Retrying LDAP connection to server at 10.0.8.254:389 with LDAP URL: ldap://dcs:389
 
2019-05-10T09:56:04.663-0500 D ACCESS   [conn20] Connected to LDAP server at 10.0.8.254:389 with LDAP URL: ldap://dcs:389

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 SERVER-37155 only gets called on successful connections. I can't find a way in the openldap library to get callbacks for each connection retry/failure. If you're using connection pooling (in the latest 4.0 and have turned it on or you're using 4.2), then there will be lots of logging about connection health and connect/reconnect attempts because we don't rely on openldap to track/maintain connections - is that sufficient?

Generated at Thu Feb 08 04:56:46 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.