I have a build for kinetic which has two changes: - enable channel binding - allow setting maxssf=0 when using GSS-SPNEGO
The later might not be needed, as GSSAPI already supports maxssf=0, and adcli will forcibly select GSSAPI instead of GSS-SPNEGO if ldaps (ssl) is being used, exactly because not everybody might have that patch: https://git.launchpad.net/ubuntu/+source/adcli/tree/library/adconn.c?h=ubuntu/kinetic- devel#n1090 const char *mech = "GSSAPI"; (...) /* There are issues with cryrus-sasl and GSS-SPNEGO with TLS even if * ssf_max is set to 0. To be on the safe side GSS-SPNEGO is only used * without LDAPS. */ if (adcli_conn_server_has_sasl_mech (conn, "GSS-SPNEGO") && !adcli_conn_get_use_ldaps (conn)) { mech = "GSS-SPNEGO"; } But without the second patch, using GSS-SPNEGO over ldaps:// against windows won't work (because -O maxssf=0 is ignored), so it's good to have I think. I tested this against windows 2016 with LdapEnforceChannelBinding=2 and LDAPServerIntegrity=2 in the registry, and could verify that without the sasl changes, joining the domain with adcli/realmd run with --use-ldaps would not work. On kinetic so far. I'm now trying to determine if I also need to pull in https://github.com/cyrusimap/cyrus- sasl/commit/8735185e9d5550e0f11e1ce4b77e391a16e4145b. There was a very technical discussion in the related issue at https://github.com/cyrusimap/cyrus-sasl/issues/637 involving RFCs and in the end the above commit landed, but only in master/main. I'm still unsure why that was needed if SASL_CBINDING defaults to "none": SASL_CBINDING <none/tls-unique/tls-endpoint> The channel-binding type to use, see also LDAP_OPT_X_SASL_CBINDING. The default is none. I'm currently testing the patched library with other sasl-enabled services via gssapi and gss-spnego, to see if any of them complain about the channel binding patch. The openldap test suite has a nice test for this at https://git.launchpad.net/ubuntu/+source/openldap/tree/tests/scripts/test077-sasl- gssapi?h=ubuntu/kinetic-devel#n175 I was expecting to be able to get ldap to fail if I enable it on the server, and not on the client, i.e.: dn: cn=config changetype: modify replace: olcSaslCBinding olcSaslCBinding: tls-unique But whatever SASL_CBINDING setting I used on the client, the bind always worked (gssapi/gss-spnego + ldaps), so I'm still unsure if it's working as expected. This on kinetic with openldap 2.5.12. ** Bug watch added: github.com/cyrusimap/cyrus-sasl/issues #637 https://github.com/cyrusimap/cyrus-sasl/issues/637 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1912256 Title: Missing channel binding prevents authentication to ActiveDirectory Status in cyrus-sasl2 package in Ubuntu: In Progress Status in openldap package in Ubuntu: Confirmed Bug description: > Are you uncertain if your issue is really a bug? Effect is an authentication error. Root case is a "missing feature" (see below) and requires updating dependencies, downporting. > If you are certain this is a bug please include the source package the bug is in. It's in the interaction between three libraries: openldap, cyrus-sasl, krb5 > 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About Ubuntu Broken in 18.04 and also in 20.10 (I guess it's also broken in anything inbetween) > 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center libsasl2-modules-gssapi-mit: 2.1.27+dfsg-2ubuntu1 ldap-utils: 2.4.53+dfsg-1ubuntu1.2 libgssapi-krb5-2: 1.17-10ubuntu0.1 > 3) What you expected to happen # kinit $ export LDAPSASL_CBINDING=tls-endpoint $ ldapwhoami -O minssf=0,maxssf=0 -N -Y GSSAPI -H ldaps://<DC-fqdn> SASL/GSSAPI authentication started SASL username: <some-username> SASL SSF: 0 u:<some-username> > 4) What happened instead SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090346: LdapErr: DSID-0C090597, comment: AcceptSecurityContext error, data 80090346, v4563 --------------- Microsoft ActiveDirectory has "LDAP Channel Binding" and recommends activating this as a required feature. See https://access.redhat.com/articles/4661861 Authentication to any AD DC which has mandatory channel binding fails. Channel binding requires at least an update to cyrus-sasl, which is not in any release as far as I can see: https://github.com/cyrusimap/cyrus- sasl/commit/975edbb69070eba6b035f08776de771a129cfb57 It also needs this commit in openldap: https://git.openldap.org/openldap/openldap/-/commit/3cd50fa8b32a21040a9892e2a8a7a9dfc7541ce6 Which as far as I can tell is v2.5 (branch OPENLDAP_REL_ENG_2_5). RH also mentions it needs up-to-date krb5 libraries, but I can't tell what minimum version this needs. I can build all libraries from source, current master (except for krb5 where I've used 1.18.3) and can confirm that channel binding works when using those libraries. I'm not sure if Samba is affected, but at least adcli, ldap-utils, and I would guess by extension also SSSD and realmd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1912256/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
