Hello, I have now repeated the tests with LdapEnforceChannelBinding=2 and I could see the rejection with error code 80090346 for GSSAPI and DIGEST-MD5 with TLS.
The simple bind with TLS and the GSSAPI or DIGEST-MD5 without TLS but with auth-int/conf all work with signing and binding required (I.e after Microsoft charged defaults in March) (Which makes the TLS binding a bit useless, but we should still think about supporting it.) Jgss seems to already allow to set it, so only JSSE needs to provide an api for sasl/jndi. Gruß Bernd -- https://Bernd.eckenfels.net ________________________________ Von: Michael Osipov <1983-01...@gmx.net> Gesendet: Sonntag, Januar 19, 2020 11:15 AM An: Bernd Eckenfels Cc: security-dev@openjdk.java.net Betreff: Re: LDAP Channel Binding Am 2020-01-19 um 08:02 schrieb Bernd Eckenfels: > 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. The problem is that JSSE Sun Impl documentation does not even mention TLS channel binding. To make things worse, I agree with you, Microsoft's documentation is horrible. It does not say whether we are talking about GSS-API channel binding or TLS channel biding. The best I have comeup with is https://github.com/WinRb/rubyntlm/issues/27 https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2008/dd639324(v=vs.90)?redirectedfrom=MSDN > So has anybody seeing failing TLS binds yet and if so, in which > condition? Yes, see https://stackoverflow.com/q/59756206/696632 What I can say is tht in our company auth-int has been mandatatory for several months now and my Java code always used auth-conf with GSSAPI mech w/o any flaws. > 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...@gmx.net> Gesendet: Saturday, January 18, > 2020 9:39:08 PM An: Bernd Eckenfels <e...@zusammenkunft.net>; > security-dev@openjdk.java.net <security-dev@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 >
