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

["Markus Moeller" <huaraz@xxxxxxxxxxxxxxxx>]

I would expect that a proxy Negotiate auth request creates a popup into 
which you can type your username as user@domain and your domain password. 
If  your home PC points to the corporate WINS server via the VPN your PC 
will get the domain controller name to authenticate you against.

Markus


"Amos Jeffries" <squid3@xxxxxxxxxxxxx> wrote in message 
news:51EDE943.6030101@xxxxxxxxxxxxx...
> 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@xxxxxxxxxxxxx> wrote in message
> > > news:51ED7F3B.3080501@xxxxxxxxxxxxx...
> > > > 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