[squid-users] Kerberos Authentication Failing for Windows 7+ with BH gss_accept_sec_context() failed

Sat Oct 25 09:41:14 UTC 2014

I was recently receiving this (incredibly vague) error. Turns out my squid user didn’t have permission to read the keytab.

On Sat, Oct 25, 2014 at 8:37 PM, Pedro Lobo <palobo at gmail.com> wrote:

> 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 at FAKE.NET 
> (arcfour-hmac)
> 	   2 10/24/2014 22:59:50 HTTP/proxy01tst.FAKE.net at FAKE.NET 
> (aes128-cts-hmac-sha1-96)
> 	   2 10/24/2014 22:59:50 HTTP/proxy01tst.FAKE.net at FAKE.NET 
> (aes256-cts-hmac-sha1-96)
> 	   2 10/24/2014 22:59:50 host/proxy01tst.FAKE.net at FAKE.NET 
> (arcfour-hmac)
> 	   2 10/24/2014 22:59:50 host/proxy01tst.FAKE.net at FAKE.NET 
> (aes128-cts-hmac-sha1-96)
> 	   2 10/24/2014 22:59:50 host/proxy01tst.FAKE.net at FAKE.NET 
> (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 at gmail.com> wrote in message 
>> news:40E1E0E7-50C6-4117-94AA-50B06573430A at gmail.com...
>> 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 at pt.clara.net
>> 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 at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
>> _______________________________________________
>> squid-users mailing list
>> squid-users at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
> Cumprimentos
> Pedro Lobo
> Solutions Architect | System Engineer
> pedro.lobo at pt.clara.net
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20141025/992b5b9a/attachment.html>