Showing results for 
Show  only  | Search instead for 
Did you mean: 

Basic authentication seems not to work

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, URL:

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

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

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

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

[2015-11-20 16:14:03.232 +01:00] [5622] Kerberos (25822, URL:

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

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

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

[2015-11-20 16:14:03.258 +01:00] [5580] NTLM (25823, URL:

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

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

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

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

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

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

[2015-11-20 16:14:03.259 +01:00] [5580] NTLM (25823, 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,


3 Replies

Re: Basic authentication seems not to work

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:    auth_pcap1.PNG
  • In the second case (working, with domain suffix), the client responds to the 407 with a Kerberos ticket and is successfully authenticated:auth_pcap2.PNG

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,


Former Member
Not applicable
Report Inappropriate Content
Message 3 of 4

Re: Basic authentication seems not to work

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,



Re: Basic authentication seems not to work

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,


You Deserve an Award
Don't forget, when your helpful posts earn a kudos or get accepted as a solution you can unlock perks and badges. Those aren't the only badges, either. How many can you collect? Click here to learn more.

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use our Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from product experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by employees.
Join the Community
Join the Community