<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body>
<div dir="ltr">
<div></div>
<div>
<div dir="ltr">Hello,</div>
</div>
<div dir="ltr"><br>
</div>
<div id="id-b7f8c4e9-9516-442e-bff1-f25568ad5640" class="ms-outlook-mobile-reference-message">
<meta content="text/html; charset=us-ascii">
<div>
<div>
<div style="direction:ltr">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.</div>
<div><br>
</div>
<div style="direction:ltr">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.</div>
<div><br>
</div>
<div style="direction:ltr">So has anybody seeing failing TLS binds yet and if so, in which condition?</div>
<div><br>
</div>
<div style="direction:ltr">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.</div>
<div><br>
</div>
<div style="direction:ltr">Gruss</div>
<div style="direction:ltr">Bernd</div>
</div>
<div><br>
</div>
<div class="ms-outlook-ios-signature">
<div><br>
</div>
<div style="direction:ltr">-- </div>
<div style="direction:ltr">http://bernd.eckenfels.net</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Michael Osipov <1983-01-06@gmx.net><br>
<b>Gesendet:</b> Saturday, January 18, 2020 9:39:08 PM<br>
<b>An:</b> Bernd Eckenfels <ecki@zusammenkunft.net>; security-dev@openjdk.java.net <security-dev@openjdk.java.net><br>
<b>Betreff:</b> Re: LDAP Channel Binding</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">Am 2020-01-16 um 11:32 schrieb Bernd Eckenfels:<br>
> Hello,<br>
><br>
> Some updates:<br>
><br>
> Microsoft moved their automatic update of the LDAP policies in Windows Server updates to March 2020 (but still recommend to activate it earlier).<br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
That is confusing because: <a href="https://bugs.openjdk.java.net/browse/JDK-6491070">
https://bugs.openjdk.java.net/browse/JDK-6491070</a><br>
<br>
I am excited to see your GSSAPI mech results. You cannot test SPENGO<br>
because the Java SASL factory does not suppor the GSS-SPNEGO SASL mech.<br>
<br>
> PS: testcode <a href="https://gist.github.com/ecki/cdd7a14575b7dca10da8d362974731a0">
https://gist.github.com/ecki/cdd7a14575b7dca10da8d362974731a0</a><br>
<br>
You code looks wrong. Retrieving data from RootDSE does not require a<br>
successful bind. It will work anonymously. You need to go down the tree.<br>
<br>
Look at ldapsearch(1), if you don't provide -Y GSSAPI, it will perform a<br>
simple search for supportedSASLMechanisms and pick the best one it<br>
supports. This is the same as obtaining the root naming contexts, this<br>
can be done anonymously too.<br>
<br>
Michael<br>
</div>
</span></font></div>
</div>
</div>
</body>
</html>