[squid-users] Debugging NTLM problem

[Amos Jeffries]

On 3/09/2016 3:06 a.m., akn ab wrote:
> Hello Amos,
> auth_param ntlm keep_alive off
> unfortunately does not solve the problem.
> I did more investigation about the problem and i found informations.
> Every time a user get the browser popup requesting credentials, i found on squid 
> log this event:
> Login for user [DOMAIN]\[user]@[PC_XXXX] failed due to [Access denied]
> NTLMSSP BH: NT_STATUS_ACCESS_DENIED
> 2016/09/02 16:56:13 kid1| ERROR: NTLM Authentication validating user. Result: 
> {result=BH, notes={message: NT_STATUS_ACCESS_DENIED; }}

That is ntlm_auth (on behalf of AD) telling Squid the user credentials
are not correct. There is no NTLM protocol problem.

Consider this NT_STATUS_ACCESS_DENIED as if a user entered the wrong
password. Why do you want to allow them access in that case?


> It's not easy to do more debug because i have 9000 concurrent connections, but 
> if you think that can help me, i try to set debug_option to something like 29,5
> Sometimes users left the office letting the browser open.
> After 1 hour (more or less), they return to the pc and popup show as soos as 
> mouse point to a new link on the open browser.
> It's probably because something cached expire, but i cannot demostrate it so 
> easily beceuse, as you said, ntlm never cache.
> On my samba/winbind logs i see many
> rpccli_netlogon_sam_network_logon: credentials chain check failed
> So it's very strange to understand if some problem occur beetween squid and 
> browser or samba and Active Directory.
> What do you think about?
> Thanks.
> Giulius.
> 
> On 1/09/2016 12:37 a.m., akn ab wrote:
>  > Dear all,
>  > i'm facing a strange problem using squid 3.5.20 with ntlm transparent
>  > authentication.
>  > I cannot use kerberos auth because i need to pass DOMAIN\user to my parent proxy
>  > with x-authenticated-user header, and the form USERNAME at DOMAIN is not supported.

I suggest you use an external_acl_type helper that takes the %LOGIN
format parameter and sends 'OK upstream_user_="..." ' back to Squid. Use
the %note{upstream_user_} in your request_header_add directive to send
the right header value upstream.

That will allow you to at least keep your part of the proxy chain using
secure Negotiate authentication even though the parent proxy allows
anyone to inject traffic spoofing your user accounts.

Amos