LDAP Channel Binding

[Michael Osipov]

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-06 at gmx.net> Gesendet: Sonntag, Januar 19,
> 2020 11:15 AM An: Bernd Eckenfels Cc: security-dev at 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-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
>>
>
>