Search squid archive

squid 3.3.x and machines that aren't domain members

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi.

I'm still getting issues with squid 3.3.x. :) I don't want to misreport any of the issues, thus making the developers to do some extra work, instead of just answering in the maillist, so I decided to ask here first. (Once again: I use squid in the corporate AD environment, lots of domain controllers, ldap, all the stuff). Everything is fine about domain members and everything is fine about basic auth from various software running on these domain members machines. But. I have a home machine, and it seems like there's no way of letting it throught the VPNed proxies: they refuse to authenticate this machine. I tried to use a SPNEGO/NTLM proxy with a kerberos_ldap_group helper, and I tried different proxy with NTLM auth and the good ol squid_ldap_group helper. I tried chrome/FF, they behave identically. On the SPNEGO/NTLM proxy I'm getting (lots of these):

===Cut===
2013/07/23 00:40:18| negotiate_wrapper: Got 'YR YIGeBgYrBgEFBQKggZMwgZCgGjAYBgorBgEEAYI3AgIeBgorBgEEAYI3AgIKonIEcE5FR09FWFRTAAAAAAAAAABgAAAAcAAAAN05UVacRCxcGu+HRovNodg9kxO5KzyBFBwm/EkKTwW6F/WWzC6Av1PmXT1oFIorlAAAAAAAAAAAYAAAAAEAAAAAAAAAAAAAAEVyfDIyRYtIv9kqa6BepAo=' from squid (length: 219). 2013/07/23 00:40:18| negotiate_wrapper: Decode 'YIGeBgYrBgEFBQKggZMwgZCgGjAYBgorBgEEAYI3AgIeBgorBgEEAYI3AgIKonIEcE5FR09FWFRTAAAAAAAAAABgAAAAcAAAAN05UVacRCxcGu+HRovNodg9kxO5KzyBFBwm/EkKTwW6F/WWzC6Av1PmXT1oFIorlAAAAAAAAAAAYAAAAAEAAAAAAAAAAAAAAEVyfDIyRYtIv9kqa6BepAo=' (decoded length: 161).
2013/07/23 00:40:18| negotiate_wrapper: received Kerberos token
negotiate_kerberos_auth.cc(315): pid=95629 :2013/07/23 00:40:18| negotiate_kerberos_auth: DEBUG: Got 'YR YIGeBgYrBgEFBQKggZMwgZCgGjAYBgorBgEEAYI3AgIeBgorBgEEAYI3AgIKonIEcE5FR09FWFRTAAAAAAAAAABgAAAAcAAAAN05UVacRCxcGu+HRovNodg9kxO5KzyBFBwm/EkKTwW6F/WWzC6Av1PmXT1oFIorlAAAAAAAAAAAYAAAAAEAAAAAAAAAAAAAAEVyfDIyRYtIv9kqa6BepAo=' from squid (length: 219). negotiate_kerberos_auth.cc(378): pid=95629 :2013/07/23 00:40:18| negotiate_kerberos_auth: DEBUG: Decode 'YIGeBgYrBgEFBQKggZMwgZCgGjAYBgorBgEEAYI3AgIeBgorBgEEAYI3AgIKonIEcE5FR09FWFRTAAAAAAAAAABgAAAAcAAAAN05UVacRCxcGu+HRovNodg9kxO5KzyBFBwm/EkKTwW6F/WWzC6Av1PmXT1oFIorlAAAAAAAAAAAYAAAAAEAAAAAAAAAAAAAAEVyfDIyRYtIv9kqa6BepAo=' (decoded length: 161). negotiate_kerberos_auth.cc(200): pid=95629 :2013/07/23 00:40:18| negotiate_kerberos_auth: ERROR: gss_acquire_cred() failed: No credentials were supplied, or the credentials were unavailable or inaccessible.. unknown mech-code 0 for mech unknown 2013/07/23 00:40:18| negotiate_wrapper: Return 'BH gss_acquire_cred() failed: No credentials were supplied, or the credentials were unavailable or inaccessible.. unknown mech-code 0 for mech unknown' 2013/07/23 00:40:18 kid1| ERROR: Negotiate Authentication validating user. Error returned 'BH gss_acquire_cred() failed: No credentials were supplied, or the credentials were unavailable or inaccessible.. unknown mech-code 0 for mech unknown'
===Cut===

In the wireshark I see that NTLM/SPNEGO authentication is running and the client machine is sending authentication back to the proxy, but for some reason squid doesn't think they are valid, so squid just answers with 407.
Is this a bug, or, again, some misconfiguration ?

Thanks.
Eugene.




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux