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. you may need to
configure your browser to use integrated windows authentication. IE vs
Firefox have different configs that have to be setup for each to work
with proxies that force authentication.
you may need to turn integrated windows authentication off too, in the
case where you are not part of the domain. otherwise the user "bob"
with a password of "blah" in the workgroup "kitchen PC" will be
presenting his creds to the proxies and will never be allowed to browse.
from the errors, it seems that no ticket is presented by your client. i
dont see anything about ntlm. you may have fallen into the "valid
failure" scenario, where the proxy and browser both support and agree to
NEGOTIATE / Kerberos auth, but your client cannot supply valid
credentials (in the form of a kerberos ticket), and therefore you are
not authenticated and not allowed to surf. you do not fall through to
the next auth type supported because the agreed upon auth method
returned an appropriate failure.
to get past that, and use an alternate auth method, such as ntlm, you
need to configure your browser to not use kerberos auth. again, IE and
Firefox will do be different in how you configure that.
Received on Tue Jul 23 2013 - 01:50:18 MDT
This archive was generated by hypermail 2.2.0 : Tue Jul 23 2013 - 12:00:40 MDT