Am 2020-01-20 um 21:07 schrieb Bernd Eckenfels:
Hello,

Ok, so I have tested the GSSAPI method with a non-native (endured,
non delegated) Kerberos login and it works with and without TLS no
matter if channel binding is enforced or not. (GSS without TLS fails
as expected with auth when request signing is required).

So this either means the enforcing does not work on Windows Server
2019 or the enforcing is not for TLS binding in GSSAPI handshakes.

Can you double check that this really is enabled?

I will publish the traces later.

Please provide them.

BTW1 when using GSS with TLS and requesting Auth-int and/or auth-conf
the MS DS will actually terminate the connection with a "wrong
parameter" error (on the server side event log) and close the socket
with no proper error.

This is correct. Active Directory does not support auth-int or auth-conf
over a TLS channel.

BTW2 i tested anonymous binds, it rejects RootDSE queries in my
case.

You need to stick to the base scope (same level).

-- http://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




Reply via email to