----- Original Message -----
From: brendan kearney
To: Markus Moeller
Sent: Tuesday, January 15, 2013 12:42 PM
Subject: Re: 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@xxxxxxxxx
Valid starting Expires Service principal
01/19/13 13:39:05 01/19/13 23:39:05 krbtgt/SUSE.HOME@xxxxxxxxx
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@xxxxxxxxxxxxxxxx> wrote in message
news:kcpohc$c29$1@xxxxxxxxxxxxx...
Which error do you see in the squid log ? Can you run the squid_kerb_auth
helper with -d ?
Markus
"brendan kearney" <bpk678@xxxxxxxxx> wrote in message
news:CAARxGtgzUOc5u0rQ=Mhbxw25RP=DKODdOKwiqRe9FCzj7jetUA@xxxxxxxxxxxxxx...
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@xxxxxxxx for krbtgt/BPK2.COM@xxxxxxxx
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@xxxxxxxx for
HTTP/proxy.bpk2.com@xxxxxxxx
what would i be missing?
On 1/9/13, brendan kearney <bpk678@xxxxxxxxx> 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
