Feature Request: LDAP auth retry on network failure.

[csawyerYumaed]

Feature Request:
When using TLS auth configured like this:
vault write auth/ldap/config url="ldaps://ad.example.com" starttls=true insecure_tls=false

and DNS ad.example.com resolves to >1 A/AAAA records.

If there is a network error, vault doesn't try again with a different host, instead it just fails. Assuming the error is a Network error, It would be nice if it would try again, with a different host.

Obviously, if you retry authentication, it will likely try a diff. host, so you can eventually auth, but you have to manually retry.

Environment:

• Vault Version: Version: 0.8.1
• Operating System/Architecture: Linux/x86

Vault Config File:

Startup Log Output:

Expected Behavior:

On Network Failure, it would try again. Assuming there are more hosts from DNS A records to try again.

Actual Behavior:

Error making API request.

URL: PUT https://vault.service.consul:8200/v1/auth/ldap/login/
Code: 400. Errors:

• 1 error occurred:

• error connecting to host "ldaps://ad.example.com": LDAP Result Code 200 "Network Error": x509: certificate is valid for SHDC.example.com, not example.com

The x509 cert problem is obviously MY problem (and it's being worked on, internally). I don't expect you to fix my cert issues :) For the time being we are using insecure_tls=true, until the AD team can figure out their cert problems, but at least they turned certs ON finally! :)

Steps to Reproduce:

Have a network error on an LDAP server, and watch vault fail, without retry.

Important Factoids:

References:

[vishalnayak]

Issues that are not reproducible and/or not had any interaction for a long time are stale issues. Sometimes even the valid issues remain stale lacking traction either by the maintainers or the community. In order to provide faster responses and better engagement with the community, we strive to keep the issue tracker clean and the issue count low. In this regard, our current policy is to close stale issues after 30 days. Closed issues will still be indexed and available for future viewers. If users feel that the issue is still relevant but is wrongly closed, we encourage reopening them.

Please refer to our contributing guidelines for details on issue lifecycle.