ADV190023 | LDAP channel binding support

[Isaac Boukris]

Hi metze

On Tue, Feb 18, 2020 at 5:48 PM Stefan Metzmacher <metze at samba.org> wrote:
>
> > I tested net-ads-search from a joined machine configured with "ldap
> > ssl ads = yes", and it works once I also set "client ldap sasl
> > wrapping = plain".
> >
> > However it doesn't work when I configure the DC to require
> > channel-binding with LdapEnforceChannelBinding=2 as per ADV190023.
>
> I think that's expected, can you paste the error message?

See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1804121

$ net ads -U"administrator at ACME.COM%Secret123" -d3 search cn=admin

Successfully contacted LDAP server 192.168.0.120
Connected to LDAP server adc.ACME.COM
StartTLS issued: using a TLS connection
ads_sasl_spnego_bind: got OID=1.3.6.1.4.1.311.2.2.30
ads_sasl_spnego_bind: got OID=1.2.840.48018.1.2.2
ads_sasl_spnego_bind: got OID=1.2.840.113554.1.2.2
ads_sasl_spnego_bind: got OID=1.2.840.113554.1.2.2.3
ads_sasl_spnego_bind: got OID=1.3.6.1.4.1.311.2.2.10
kinit succeeded but ads_sasl_spnego_gensec_bind(KRB5) failed for
ldap/adc.acme.com with user[administrator] realm[ACME.COM]: Invalid
credentials
ads_sasl_spnego_gensec_bind(KRB5) failed for ldap/adc.acme.com with
user[administrator] realm=[ACME.COM]: Invalid credentials
return code = -1

> Is it possible to reproduce with ldbsearch as well?

Yes.

$ ldapsearch -h adc.acme.com -b dc=acme,dc=com cn=isaac -Y GSSAPI -O
maxssf=0 -ZZ
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
    additional info: 80090346: LdapErr: DSID-0C090569, comment:
AcceptSecurityContext error, data 80090346, v4563

> But do the default settings still work?

For now yes, but that's about to change, if i understand correctly.

Quote:
"A further future monthly update, anticipated for release the second
half of calendar year 2020, will enable LDAP signing and channel
binding on domain controllers configured with default values for those
settings."

> > Has anyone looked into channel-binding or has any idea what is needed
> > to implement in samba (or upstream) for this to work?
> > Is there other ldap client code in samba that would also be impacted?
>
> Yes.
>
> > BTW, I noticed windows clients use both singing and sealing, should we
> > consider changing the defaults of "client ldap sasl wrapping" to seal?

Notice the last question wasn't about channel-binding, but about
signing vs sealing (the GPO from the advisory only enforces signing
afaict).

> I looked at it a bit, see
> https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=ac8fd11f1d4b9deb48d6c7942af0c83b52d69d7f

Thanks! I'll play with that.

I'm unclear about the implementation details but I think it would be
nice to have some kind of flag to both require channel-binding over
TLS and disable sasl-wrapping in that case.

> I think we need input from dochelp to answer 2 questions:
> 1. which kind of channel bindings are expected/used by windows?
>    I assume tls-server-end-point. I guess MS-ADTS would be the place
>    to define these details for ldaps.

I'll try to formulate a question to dochelp on this.

> 2. how is the ChannelBindingsUnhashed blob constructed for
>    NTLMSSP (MS-NLMP)
>
> metze
>