For Nubus4K8S, LDAP is running in a container without TLS secured context. The SASL module provided by crudeoauth doesn't allows this, leading to the generic error message: $ ldapsearch -H ldap://localhost:389 -Q -Y OAUTHBEARER -w "$token" -s base ldap_sasl_interactive_bind: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: No worthy mechs found This is caused in the client due to missing security flags: https://github.com/cyrusimap/cyrus-sasl/blob/master/lib/client.c#L798-L811 > myflags = conn->props.security_flags; > > /* if there's an external layer with a better SSF then this is no > * longer considered a plaintext mechanism > */ > if ((conn->props.min_ssf <= conn->external.ssf) && > (conn->external.ssf > 1)) { > myflags &= ~SASL_SEC_NOPLAINTEXT; > } > > /* Does it meet our security properties? */ > if (((myflags ^ m->m.plug->security_flags) & myflags) != 0) { > break; > } From `include/sasl.h`: ```cpp #define SASL_SEC_NOPLAINTEXT 0x0001 #define SASL_SEC_NOANONYMOUS 0x0010 ``` Debug output: `myflags: 0x0011, plug->security_flags: 0x0010, props.security_flags: 0x0011` So we have the following flags: ```cpp myflags: 0x0011 // SASL_SEC_NOPLAINTEXT | SASL_SEC_NOANONYMOUS plug->security_flags: 0x0010 // SASL_SEC_NOANONYMOUS ``` Our connection doesn't fit `conn->external.ssf` > 1 so that the flag is not added. → we should add the flag to the plugin definiton, as we are also checking TLS /SSF again in our code. And we should make our own TLS check configurable, so in Nubus4K8s we can disable it.
https://git.knut.univention.de/univention/ucs/-/merge_requests/1415
A new option has been added, which disabled TLS enforcement, and can be enabled via: /etc/ldap/sasl2/slapd.conf oauthbearer_no_tls: 1 It can be enabled via the UCR variable ldap/server/sasl/oauthbearer/no-tls=true. univention-management-console (14.1.2) 5bf4b0ccfc51 | feat(oauthbearer): add 'ldap/server/sasl/oauthbearer/no-tls' configuration option crudeoauth (1.0.0-3) 1bdc8692504a | feat: add configration option to ignore non TLS based connections 404de125388f | feat: add debug code for enabling of logging crudeoauth.yaml 81008310f396 | chore(univention-management-console): update advisory univention-management-console.yaml 81008310f396 | chore(univention-management-console): update advisory
Ok, also had to set echo 'sasl-secprops none,minssf=0' >> /etc/ldap/slapd.conf systemctl restart slapd to see OAUTHBEARER listed in the output of ldapsearch -x -s base -b '' -H "ldap://$(hostname -f):7389" supportedSASLmechanisms and to accept auth via ldapsearch -Y OAUTHBEARER -s base -b '' -H "ldap://$(hostname -f):7389" supportedSASLmechanisms But that adjustment of `sasl-secprops` is not specific to the OAUTHBEARER mech, it also exposes other mechs (LOGIN, SAML, PLAIN), and even if I disable ldap/server/sasl/oauthbearer/no-tls again, OAUTHBEARER is still advertised. Anyway, seems to improve behavior in the K8s context.
To make OAUTHBEARER available without TLS, it's important that "noplain" is not part of the slapd "sasl-secprops" (default: noanonymous,noplain) and that minssf is zero: > echo "sasl-secprops noanonymous,minssf=0" >> /etc/ldap/slapd.conf man slapd.conf explains: > The noplain flag disables mechanisms susceptible to simple passive attacks. where "simple passive attacks" is eavesdropping (possible without TLS/SSL). As proposed via chat, we can do that by adjusting sasl_server_plug_t to flag SASL_SEC_NOPLAINTEXT there directly (just as we do in sasl_client_plug_t). When doing that, we only need to set "sasl-secprops minssf=0" to disable our dynamic default check for ssf=256 in mech_step_init.
6c0cf382637 | chore(crudeoauth): update advisory 463cb64a16c | fix(crudeoauth): fix TLS check for server side Successful build Package: crudeoauth Version: 1.0.0-5 Branch: 5.2-0 Scope: errata5.2-1
<https://errata.software-univention.de/#/?erratum=5.2x77> <https://errata.software-univention.de/#/?erratum=5.2x78>