Basic authentication seems not to work

[holger_haas]

Hello community,

I seem to have similar problems as described in

According to a trace with tcpdump, the clients gets a 407 message and is offered three authentication methods: Kerberos, NTLM and basic. The client then does not answer and the connection runs into a timeout.

My NTLM configuration looks like this, with basic authentication enabled:

While the authentication rules where taken from the library:

The auth debug log looks like this:

[2015-11-20 16:14:03.231 +01:00] [5622] NTLM (25821, 10.xxx.xxx.xxx) URL: https://cfdi.timbrado.com.mx

[2015-11-20 16:14:03.231 +01:00] [5622] NTLM (25821, 10.xxx.xxx.xxx) Configuration: NTLM Connection: 0x7f940ca3fe50 RR: 0x7f93fb672c70

[2015-11-20 16:14:03.231 +01:00] [5622] NTLM (25821, 10.xxx.xxx.xxx) Authentication didn't return values, failure ID: 4, authentication failed: 0

[2015-11-20 16:14:03.231 +01:00] [5622] NTLM (25821, 10.xxx.xxx.xxx) Added authentication method: Basic realm="McAfee Web Gateway"

[2015-11-20 16:14:03.231 +01:00] [5622] NTLM (25821, 10.xxx.xxx.xxx) Added authentication method: NTLM

[2015-11-20 16:14:03.232 +01:00] [5622] Kerberos (25822, 10.xxx.xxx.xxx) URL: https://cfdi.timbrado.com.mx

[2015-11-20 16:14:03.232 +01:00] [5622] Kerberos (25822, 10.xxx.xxx.xxx) Configuration: Kerberos Connection: 0x7f940ca3fe50 RR: 0x7f93fb672c70

[2015-11-20 16:14:03.232 +01:00] [5622] Kerberos (25822, 10.xxx.xxx.xxx) Added authentication method: Negotiate

[2015-11-20 16:14:03.232 +01:00] [5622] Kerberos (25822, 10.xxx.xxx.xxx) Authentication didn't return values, failure ID: 4, authentication failed: 0

[2015-11-20 16:14:03.258 +01:00] [5580] NTLM (25823, 10.xxx.xxx.xxx) URL: https://cfdi.timbrado.com.mx

[2015-11-20 16:14:03.258 +01:00] [5580] NTLM (25823, 10.xxx.xxx.xxx) Configuration: NTLM Connection: 0x7f93dbff8c60 RR: 0x7f931e468bf0

[2015-11-20 16:14:03.258 +01:00] [5580] NTLM (25823, 10.xxx.xxx.xxx) Incoming credentials: Negotiate TlRMTVNTUAABAAAAt4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==

[2015-11-20 16:14:03.258 +01:00] [5580] NTLM (25823, 10.xxx.xxx.xxx) NTLM cache returned status 0 Not in cache

[2015-11-20 16:14:03.259 +01:00] [5580] NTLM (25823, 10.xxx.xxx.xxx) Authentication didn't return values, failure ID: 0, authentication failed: 0

[2015-11-20 16:14:03.259 +01:00] [5580] NTLM (25823, 10.xxx.xxx.xxx) Added authentication method: Basic realm="McAfee Web Gateway"

[2015-11-20 16:14:03.259 +01:00] [5580] NTLM (25823, 10.xxx.xxx.xxx) Added authentication method: Negotiate TlRMTVNTUAACAAAAAAAAAAAAAAA1gongVmmhuiEGb0AAAAAAAAAAAAAAAAAAAAAA

[2015-11-20 16:14:03.259 +01:00] [5580] NTLM (25823, 10.xxx.xxx.xxx) Stored NTLM cache keys in the connection

You can see, that basic authentication is offered, but the client does not seem to react to this.

Does anyone have an idea?

Thank you and best regards,

Holger

[holger_haas]

I made a wrong interpretation of the logs here, this seems to have nothing to do with basic authentication.

The problem can be avoided by using "<USER>@domain.tld" as syntax for the username (according to the users, "<DOMAIN>\<USER>" did not work in every case).

• In a tcpdump capture, you can see that in the first (non-working, no domain suffix) case the client responds to the first 407 request from the proxy with a NTLM header (Negotiate TlRM). The proxy then sends another 407, to which the client does not respond:   
• In the second case (working, with domain suffix), the client responds to the 407 with a Kerberos ticket and is successfully authenticated:

This behaviour was different before, as we used BlueCoat Proxy SG machines as proxy, however, the authentication mechanisms were the same (Kerberos with fallback to NTLM and basic).

Can someone explain what happens here, and maybe even how to change this behaviour so the domain suffix is not needed anymore?

Looking forward to your ideas,

Holger

[Former Member]

Hi Holger,

What you're seeing is the client send a Negotiate with a NTLM token (TlRM). The rules you have imported (which I helped create) will reject Kerberos with a NTLM token. The client is likely failing to get a kerberos ticket in the first scenario.

This is the same problem mentioned here:

Best Regards,

Jon

edited

[holger_haas]

Hello Jon,

I finally found the time to replicate this issue again. I tested it with your  true ntlm fallback with kerberos v2 ruleset from the before mentionend article, but the behaviour is unfortunately similar:

• without domain suffix, the client gets a 407 request with all auth mechanisms offered, and responds with "Negotiate TlRM". The proxy sends another 407 request, this time only with NTLM as auth mechanism, but this time the client does not respond at all.
• with domain suffix, the client responds with "Negotiate YII..." in the first place and gets access. The same, btw., if you use <domain>\<user>  as username.

For normal applications, this is not a big issue, but I would have a better feeling with the old (bluecoat) behaviour, because I fear that we might run into problems with webapplications here...

Best Regards,

Holger