LDAP Channel Binding

[Bernd Eckenfels]

Hello,

The getattribute is not needed for the test, the new signing policy server setting will abort already at the bind call with an exception. But yes, you can also use other searches to be sure. They did not fail with simple bind inside TLS even with mandatory channel binding.

You said it is confusing, but the bug you mentioned is only a valid feature request, it does not talk about failing binds. I would assume that Kerberos needs the binding token and the others not. Unfortunatelly the doc from Microsoft is quite incomplete and confusing.

So has anybody seeing failing TLS binds yet and if so, in which condition?

It is also not clear why AD proposes the auth. quality of protection from digest-md5 if it is configured to reject it. So if somebody can get Microsoft to look into this and provide details, that would be great.

Gruss
Bernd


--
http://bernd.eckenfels.net
________________________________
Von: Michael Osipov <1983-01-06 at gmx.net>
Gesendet: Saturday, January 18, 2020 9:39:08 PM
An: Bernd Eckenfels <ecki at zusammenkunft.net>; security-dev at openjdk.java.net <security-dev at openjdk.java.net>
Betreff: Re: LDAP Channel Binding

Am 2020-01-16 um 11:32 schrieb Bernd Eckenfels:
> Hello,
>
> Some updates:
>
> Microsoft moved their automatic update of the LDAP policies in Windows Server updates to March 2020 (but still recommend to activate it earlier).
>
> And I did some tests: when you turn on the mandatory LDAP Signing, then simple binds or Digest-md5 binds over LDAP are rejected by NTDS. Both work over ldaps: (Implicite TLS, did not check STARTTLS). DIGEST-MD5 without TLS is also possible, but you have to request qop=auth-int. (Sidenode AD will reject digest-md5 with Auth-int over TLS). I did not Test GSSAPI or SPNEGO yet.
>
> The mandatory LDAP channel binding does not seem to make a problem/change. I suspect it only applies to Kerberos or NTLM which I still need to test.

That is confusing because: https://bugs.openjdk.java.net/browse/JDK-6491070

I am excited to see your GSSAPI mech results. You cannot test SPENGO
because the Java SASL factory does not suppor the GSS-SPNEGO SASL mech.

> PS: testcode https://gist.github.com/ecki/cdd7a14575b7dca10da8d362974731a0

You code looks wrong. Retrieving data from RootDSE does not require a
successful bind. It will work anonymously. You need to go down the tree.

Look at ldapsearch(1), if you don't provide -Y GSSAPI, it will perform a
simple search for supportedSASLMechanisms and pick the best one it
supports. This is the same as obtaining the root naming contexts, this
can be done anonymously too.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20200119/27a73e03/attachment.htm>