Re: [squid-users] Re: squid 3.3.x and machines that aren't domain members

On 23/07/2013 1:50 p.m., Brendan Kearney wrote:
> On Tue, 2013-07-23 at 00:07 +0100, Markus Moeller wrote:
>> Hi Eugene,
>>
>> Looks like an interesting problem. Can you wireshark the traffic on your
>> home machine on port 88 ( Kerberos ). If the negotiate wrapper says you got
>> a Kerberos token you should see traffic on port 88.
>>
>> Markus
>>
>>
>> "Eugene M. Zheganin" <emz_at_norma.perm.ru> wrote in message
>> news:51ED7F3B.3080501_at_norma.perm.ru...
>>> 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.
>>>
>>
> your "home machine", is it part of the domain that the work proxies are
> authenticating against? You would never be able to retrieve a kerberos
> ticket from the domain to use for authentication to the proxies if your
> home machine is not part of the domain. as for ntlm, you should be able
> to use the proxies if they force auth and support ntlm.

NOTE: but only with NTLMv1 or older LanManager protocols, which are
terribly insecure. NTLMv2 with any kind of security has the same domain
membership limits as Kerberos (or slighty worse - one must be actively
connected to the domain).

Amos
Received on Tue Jul 23 2013 - 02:24:06 MDT