Pedro, By default, Windows 7 (and later) does not support weak encryption types in Kerberos, e.g. DES. Since Windows 7 clients are working with domain controller on Windows 2000 functional level, it is very likely the Kerberos encryption type on the TGT ticket is DES. You can verify that on Windows XP/2003. If so, you need to re-enable the support of weak encryption types in Kerberos on Windows 7 by GPO or editing registry. http://blogs.msdn.com/b/openspecification/archive/2011/05/31/windows-configurations-for-kerberos-supported-encryption-type.aspx http://technet.microsoft.com/en-us/library/dd560670%28v=ws.10%29.aspx Regards, John Mok On Tue, Oct 28, 2014 at 6:22 AM, Pedro Lobo <palobo@xxxxxxxxx> wrote: > Thanks Paul, > > I'll surely look into that too, but given that authentication seems o work > for a day or so and then stop (was working Saturday, no longer today) I > highly doubt it's related. Still worth checking I'm sure. > > Pedro Lobo > > On 27 Oct 2014, at 21:12, Paul Freeman <paul.freeman@xxxxxxxxxxxxxx> wrote: > > Pedro, > > This sounds similar to a problem I had a couple of years ago when using > Kerberos authentication with Squid (3.1.x) on Ubuntu (10.04 at that stage). > (see RE: Re: Authentication using squid_kerb_auth with > Internet Explorer 8 on Windows Server 2008 R2, squid-users group Nov 3 2010) > > > > What I discovered after debugging the Kerberos authentication process with > gdb was the MIT Kerberos version distributed with that version of Ubuntu did > not support one of the encryption types requested by the newer versions of > Windows (7, 2008). This was a reported issue with the version of Kerberos > used in Ubuntu. I ended up patching the Ubuntu MIT Kerberos source (a > trivial patch) and compiling the packages manually. This corrected the > problem. > > > > I am unsure whether this is the root cause of your issue though but thought > it might be worth mentioning. I have not kept up with the MIT Kerberos > packages included with Ubuntu 12.04 and 14.04 to know whether the patch is > included in the later versions. > > > > Regards > > > > Paul > > > > From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On > Behalf Of Pedro Lobo > Sent: Tuesday, 28 October 2014 7:26 AM > To: Markus Moeller > Cc: squid-users@xxxxxxxxxxxxxxx > Subject: Re: Kerberos Authentication Failing for Windows 7+ > with BH gss_accept_sec_context() failed > > > > Hi Markus Moeller, > > > Hi Markus, > > Yeah, I'm currently using that option and permissions are correct too. > > > On 27 Oct 2014 19:47, Markus Moeller wrote: > > Hi Pedro, > > > > Did you try the –s GSS_C_NO_NAME option ? > > > > Markus > > > > "Pedro Lobo" <palobo@xxxxxxxxx> wrote in message > news:94F74226-F24B-4910-95B7-B86ACE815995@xxxxxxxxx... > > Hey Everybody, > > Seems as though I celebrated too soon on Saturday. Today things are back to > not working for Windows 7+ machines and XP/2003 machines are working just > fine. > > I've also checked the permissions on the keytab file and they haven't > changed since Saturday, so it's not that... ARGH!!!! > > Craving ideas and solutions right now... Pilot users are less than satisfied > ;) > > Cheers, > Pedro > > On 25 Oct 2014, at 14:13, Markus Moeller wrote: > > Hi Pedro, > > I wonder if he upper case in the name is a problem. Can you try > > auth_param negotiate program /usr/lib/squid3/negotiate_kerberos_auth -d -r > -s GSS_C_NO_NAME > > instead of > > auth_param negotiate program /usr/lib/squid3/negotiate_kerberos_auth -d -r > -s HTTP/proxy01tst.fake.net > > Markus > > "Pedro Lobo" palobo@xxxxxxxxx wrote in message > news:FD6832B9-3F1F-48C6-A76F-47A224F1697B@xxxxxxxxx... > Hi Markus, > > I used msktutil to create the keytab. > > msktutil -c -s HTTP/proxy01tst.fake.net -h proxy01tst.fake.net -k > /etc/squid3/PROXY.keytab --computer-name proxy01-tst --upn > HTTP/proxy01tst.fake.net --server srv01.fake.net --verbose > Output of klist -ekt: > > 2 10/24/2014 22:59:50 proxy01-tst$@FAKE.NET (arcfour-hmac) > 2 10/24/2014 22:59:50 proxy01-tst$@FAKE.NET (aes128-cts-hmac-sha1-96) > 2 10/24/2014 22:59:50 proxy01-tst$@FAKE.NET (aes256-cts-hmac-sha1-96) > 2 10/24/2014 22:59:50 HTTP/proxy01tst.FAKE.net@xxxxxxxx (arcfour-hmac) > 2 10/24/2014 22:59:50 HTTP/proxy01tst.FAKE.net@xxxxxxxx > (aes128-cts-hmac-sha1-96) > 2 10/24/2014 22:59:50 HTTP/proxy01tst.FAKE.net@xxxxxxxx > (aes256-cts-hmac-sha1-96) > 2 10/24/2014 22:59:50 host/proxy01tst.FAKE.net@xxxxxxxx (arcfour-hmac) > 2 10/24/2014 22:59:50 host/proxy01tst.FAKE.net@xxxxxxxx > (aes128-cts-hmac-sha1-96) > 2 10/24/2014 22:59:50 host/proxy01tst.FAKE.net@xxxxxxxx > (aes256-cts-hmac-sha1-96) > Yep, using MIT Kerberos > > Thanks in advance for any help. > > Cheers, > Pedro > > On 25 Oct 2014, at 1:26, Markus Moeller wrote: > > Hi Pedro, > > How did you create your keytab ? What does klist –ekt <squid.keytab> show ( > I assume you use MIT Kerberos) ? > > Markus > > "Pedro Lobo" palobo@xxxxxxxxx wrote in message > news:40E1E0E7-50C6-4117-94AA-50B06573430A@xxxxxxxxx... > Hi Squid Gurus, > > I'm at my wit's end and in dire need of some squid expertise. > > We've got a production environment with a couple of squid 2.7 servers using > NTLM and basic authentication. Recently though, we decided to upgrade and > I'm now setting up squid 3.3 with Kerberos and NTLM Fallback. I've followed > just about every guide I could find and in my testing environment, things > were working great. Now that I've hooked it up to the main domain, things > are awry. > > If I use a machine that's not part of the domain, NTLM kicks in and I can > surf the web fine. If I use a Windows XP or Windows Server 2003, kerberos > works just fine, however, if I use a machine Windows 7, 8 or 2008 server, I > keep getting a popup asking me to authenticate and even then, it's and > endless loop until it fails. My cache.log is littered with: > > negotiate_kerberos_auth.cc(200): pid=1607 :2014/10/24 23:03:01| > negotiate_kerberos_auth: ERROR: gss_accept_sec_context() failed: Unspecified > GSS failure. Minor code may provide more information. > 2014/10/24 23:03:01| ERROR: Negotiate Authentication validating user. Error > returned 'BH gss_accept_sec_context() failed: Unspecified GSS failure. Minor > code may provide more information. ' > The odd thing, is that this has worked before. Help me Obi Wan... You're my > only hope! :) > > Current Setup > Squid 3.3 running on Ubuntu 14.04 server. It's connected to a 2003 server > with function level 2000 (I know, we're trying to fase out the older > servers). > > krb5.conf > > [libdefaults] > default_realm = FAKE.NET > dns_lookup_kdc = yes > dns_lookup_realm = yes > ticket_lifetime = 24h > default_keytab_name = /etc/squid3/PROXY.keytab > > ; for Windows 2003 > default_tgs_enctypes = rc4-hmac des-cbc-crc des-cbc-md5 > default_tkt_enctypes = rc4-hmac des-cbc-crc des-cbc-md5 > permitted_enctypes = rc4-hmac des-cbc-crc des-cbc-md5 > > [realms] > FAKE.NET = { > kdc = srv01.fake.net > kdc = srv02.fake.net > kdc = srv03.fake.net > admin_server = srv01.fake.net > default_domain = fake.net > } > > [domain_realm] > .fake.net = FAKE.NET > fake.net = FAKE.NET > > [logging] > kdc = FILE:/var/log/kdc.log > admin_server = FILE:/var/log/kadmin.log > default = FILE:/var/log/krb5lib.log > squid.conf > > auth_param negotiate program /usr/lib/squid3/negotiate_kerberos_auth -d -r > -s HTTP/proxy01tst.fake.net > auth_param negotiate children 20 startup=0 idle=1 > auth_param negotiate keep_alive off > > auth_param ntlm program /usr/bin/ntlm_auth --diagnostics > --helper-protocol=squid-2.5-ntlmssp --domain=FAKE.NET > auth_param ntlm children 10 > auth_param ntlm keep_alive off > Cheers, > Pedro > > Cumprimentos > Pedro Lobo > Solutions Architect | System Engineer > > pedro.lobo@xxxxxxxxxxxx > Tlm.: +351 939 528 827 | Tel.: +351 214 127 314 > > Claranet Portugal > Ed. Parque Expo > Av. D. João II, 1.07-2.1, 4º Piso > 1998-014 Lisboa > www.claranet.pt > > Empresa certificada ISO 9001, ISO 20000 e ISO 27001 > > ________________________________ > ________________________________ > > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > > ________________________________ > > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > > Cumprimentos > Pedro Lobo > Solutions Architect | System Engineer > > pedro.lobo@xxxxxxxxxxxx > Tlm.: +351 939 528 827 | Tel.: +351 214 127 314 > > Claranet Portugal > Ed. Parque Expo > Av. D. João II, 1.07-2.1, 4º Piso > 1998-014 Lisboa > www.claranet.pt > > Empresa certificada ISO 9001, ISO 20000 e ISO 27001 > > ________________________________ > ________________________________ > > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > > ________________________________ > > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > > ________________________________ > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > > > > __________ Information from ESET Smart Security, version of virus signature > database 10628 (20141027) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com > > > > __________ Information from ESET Smart Security, version of virus signature > database 10628 (20141027) __________ > > The message was checked by ESET Smart Security. > > http://www.eset.com > > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
