[squid-users] problem with basic_ldap_auth

[Amos Jeffries]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/10/2014 11:33 p.m., masterx81 wrote:
> Hi to all! I'm having an issue on squid 3.3.13 using
> basic_ldap_auth. I'm using the following helpers: auth_param
> negotiate program /usr/local/bin/negotiate_wrapper --ntlm 
> /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
> --domain=DOMAIN --kerberos /usr/local/bin/squid_kerb_auth -s
> GSS_C_NO_NAME auth_param negotiate children 10 auth_param negotiate
> keep_alive on
> 
> auth_param ntlm program /usr/bin/ntlm_auth 
> --helper-protocol=squid-2.5-ntlmssp --domain=DOMAIN auth_param ntlm
> children 10 auth_param ntlm keep_alive on
> 
> auth_param basic program /usr/local/squid/libexec/basic_ldap_auth
> -v 3 -R -b "dc=domain,dc=local" -D squid at domain.local -W
> /etc/squid/ldappass.txt -d -f sAMAccountName=%s -h
> srv-dc1.domain.local auth_param basic children 10 auth_param basic
> realm Proxy DOMAIN auth_param basic credentialsttl 1 minute
> 
> NTLM and kerberos are working correctly, but the basic helper seem
> to not work well. The browser ask me 3 times the password, then
> give me the cache error. After this, windows save the credentials
> in it's cache (seen in account manager) and if i close and reopen
> the browser it work but seem to use NTLM as i get the ticket in the
> cache.log. In che cache.log i not see any line of the basic helper
> also with the -d switch. If i call the helper manually from command
> line it works and give me "OK" if i pass correct user/pass and "ERR
> Success" if i pass wrong credentials.
> 
> Before the 3.3.13 i was using a 3.4.x version, and all was working
> ok, but i've had the need to go back as on 3.4 i have huge cpu
> utilization using NTLM. On the 3.3.13 cpu usage is really low but
> seen that there is this throuble with basic helpers.... Some have a
> suggestion for me?

Firstly the popup does not mean Basic. It only means the browser is
not able to automatically find any credentials that work.

If it is "saving" the NTLM credentials in password manager it means
those are the credentials which eventually worked after the user input.

The way auth is supposed to work is that the browser tries the most
secure method it is offered then falls back to ever less secure methods.

So what *should* be happening is the following. The first one to
succeed is used:

 1. automatic attempt to use Negotiate/Kerberos
 2. automatic attempt to use Negotiate/NTLM
 3. automatic attempt to use NTLM
 4. automatic attempt to use Basic
 5. popup request for Negotiate/Kerberos credentials
 6. popup request for Negotiate/NTLM credentials
 7. popup request for NTLM credentials
       --> the one you say is working.
 8. popup request for Basic credentials
 9. display error page sent in last received 401/407/403 message.

* The password manager or system API lacking any of the credentials
may skip the HTTP transaction part of 'automatic' steps.
* User clicking cancel may skip the HTTP part of the popup steps.
* 403 response skips from any point to step 9.

You can test this a bit better by placing some strange text in the
Basic auth "Realm" parameter. Only if that text appears in the popup
box is Basic auth being requested.

debug_options 11,2 can be used to get a trace of teh HTTP traffic.
Which can be used to see the auth types being attempted by the client.

Also, the helpers should all provide -d parameter to print debug info
about their actions.

Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUNgPeAAoJELJo5wb/XPRj164IAOKM/YeG6AKdaxMAT6kPELPG
TEbxLOZyZ13eFIZpY5kR1u0Wx6jZL/nsmSk7vs7UmEOdVc4YQSYktTjxf8cfpbrP
NF2fc2+6IPrnSzyoJ7aNatqDSMBnwPneo0AG6xj9/jFsSeCN/HAqELf5ngIOZFXQ
eMSodljKBWzp4epXyB/J8BvQL4Ng0hCy1yisAR1fsQupo8SLgCwVaMrZ10ZJxrsR
ourgX57M/qvOmEknSHDGO3PZAa1iFBY2iwEyDMa31P2oLZxJ/SiXUoeDSs3zkXJb
hzgFUxTzsyoQTr8g9ZekMlmAa3+QAw0NwST/Y6s2AZcbOKKBVcH3evO2FKyvvjg=
=aiaz
-----END PGP SIGNATURE-----