Description
Currently, if a user configures LDAP authentication, they can end up in a state with a very hard to debug authentication failure. They may be passing valid credentials, but be rejected because the SASL list-mechs specified by the cluster prioritizes SCRAM-SHA, which is incompatible with saslauthd and thus LDAP in current releases.
This is changing a bit in MH and there is opportunity to improve it in SDK 3.
At the moment, there are three options:
1) Leverage an existing KV setting to have it advertise PLAIN when configured for external auth (http://src.couchbase.org/source/xref/trunk/kv_engine/daemon/start_sasl_auth_task.cc#78-83)
2) Have the SDKs default to PLAIN unless otherwise configured (not-secure, functionally complete by default)
3) Have the SDKs follow list-mechs unless otherwise configured (slightly-more-but-still-not-secure, broken by default for LDAP)
The argument for Option 2 is that anyone who really cares about security should use TLS anyway.
The argument for Option 3 is that it's slightly more secure in that it's harder to get the credentials which lets you mutate data so you can just steal data (see, slightly more secure!) and it would pass more security audits as credentials will be encrypted on the wire.
Option 1 may or may not be possible in MH with current design. This is being looked into.
Attachments
Issue Links
- relates to
-
GOCBC-1139 dcpagent Authentication Mechanism is incorrectly for TLS
- Resolved
-
MB-39570 Revert MB-34751: Don't Dynamically Change Offered SASL Mechanisms Based on External Auth Being Configured
- Closed