[squid-users] Re: Re: Re: Help with Kerberos Configuration

> ----- Original Message -----
> From: brendan kearney
> To: Markus Moeller
> Sent: Tuesday, January 15, 2013 12:42 PM
> Subject: Re: [squid-users] Re: Re: Re: Help with Kerberos Configuration
>
>
> Markus,
>
> thank you for your continued efforts. i appreciate the help.
>
> i did run the helper with the -d parameter, and have cache.log output from
> both instances. the helper that i used is configured as (on Fedora 16 64
> bit, kernel 3.6.10-2, squid version 3.2.5):
>
> auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -s
> GSS_C_NO_NAME
> auth_param negotiate children 10
> auth_param negotiate keep_alive on
>
> i added the -d to the first line on both proxies and restarted the
> services. in the cache.log for the second proxy, i got:
>
> negotiate_kerberos_auth.cc(199): pid=8515 :2013/01/15 07:14:48|
> negotiate_kerberos_auth: ERROR: gss_accept_sec_context() failed:
> Unspecified GSS failure. Minor code may provide more information.
> 2013/01/15 07:14:48 kid1| ERROR: Negotiate Authentication validating user.
> Error returned 'BH gss_accept_sec_context() failed: Unspecified GSS
> failure. Minor code may provide more information. '
>

Can you do the following check ? kinit -kt <squid keytab> HTTP/squid-fqdn
? It shouldn't create any error (example below)

#kinit -kt /etc/squid/squid-suse.keytab HTTP/opensuse12.suse.home
 # klist -e
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: HTTP/opensuse12.suse.home_at_SUSE.HOME

Valid starting Expires Service principal
01/19/13 13:39:05 01/19/13 23:39:05 krbtgt/SUSE.HOME_at_SUSE.HOME
        renew until 01/20/13 13:39:05, Etype (skey, tkt): arcfour-hmac,
arcfour-hmac

> it seems interesting that only the second proxy throws the error, as the
> above lines do not show up in the first proxies log at all. even though
> only the second proxy throws the error, eventually both proxies begin
> denying access.
>

When the secnd proxy denies the connection do you see anything in cache.log
( I assume you use -d for squid_kerb_auth) ?

> let me know if you would like additional log info, from cache.log,
> access.log or any other info.
>
> a quick point that i just considered, that may or may not be an issue: the
> keytab file that squid uses only has HTTP principals in it, and no host
> principals. I am not sure if the host principals should be in the same
> keytab file as the HTTP principals. i was debating if i would put the
> HTTP principals into the same keytab file as the host principals,
> reconfigure squid to use the new keytab file and restart. note sure if it
> makes a difference, but figured i would mention it.
>
>
> "Markus Moeller" <huaraz_at_moeller.plus.com> wrote in message
> news:kcpohc$c29$1_at_ger.gmane.org...
> Which error do you see in the squid log ? Can you run the squid_kerb_auth
> helper with -d ?
>
> Markus
>
>
> "brendan kearney" <bpk678_at_gmail.com> wrote in message
> news:CAARxGtgzUOc5u0rQ=Mhbxw25RP=DKODdOKwiqRe9FCzj7jetUA_at_mail.gmail.com...
>>i have removed the keytab from the load balancer, and added the proxy
>> principal to the keytab file on each server. the keytab file for
>> server1 has entries for HTTP/proxy.bpk2.com (the VIP) and
>> HTTP/server.bpk2.com. server2 has entries for HTTP/proxy.bpk2.com and
>> HTTP/vpn.bpk2.com (matching hostnames and DNS names in both cases).
>>
>> i get one squid instance denying access for some time, then they
>> switch and the other is denying access. after several page loads and
>> refreshes, etc both instances begin denying all access even though i
>> have valid tickets.
>>
>> i must be missing something... i checked permissions on the keytab
>> files. squid is owner and group, with 600 ownership (-rw-------).
>> below are some krb logs that seem to indicate the tickets are ok and
>> valid:
>>
>> 2013-01-09T20:34:30.268856-05:00 server krb5kdc[12337]: AS_REQ (4
>> etypes {18 17 16 23}) 192.168.1.97: ISSUE: authtime 1357781670, etypes
>> {rep=18 tkt=18 ses=18}, brendan_at_BPK2.COM for krbtgt/BPK2.COM_at_BPK2.COM
>> 2013-01-09T20:34:38.779822-05:00 server krb5kdc[12337]: TGS_REQ (4
>> etypes {18 17 16 23}) 192.168.1.97: ISSUE: authtime 1357781670, etypes
>> {rep=18 tkt=18 ses=18}, brendan_at_BPK2.COM for
>> HTTP/proxy.bpk2.com_at_BPK2.COM
>>
>> what would i be missing?
>>
>> On 1/9/13, brendan kearney <bpk678_at_gmail.com> wrote:
>>> i must have misunderstood you when you said that i need a third entry in
>>> the keytab for the VIP. I took that to mean that the device hosting the
>>> VIP should have a keytab on it with the HTTP principal in the keytab.
>>>
>>> from what you are saying now, it looks like i just need the squid
>>> instances
>>> to have 2 HTTP principals in each of their keytabs, one for the local
>>> proxy
>>> instance and one for the VIP instance. I'll give that a shot. Thanks.
>>>
>>
>
>
>

Markus
Received on Sat Jan 19 2013 - 13:41:20 MST