[squid-users] Squid, Kerberos and FireFox (Was: Re: leaking memory in squid 3.4.8 and 3.4.7.)

[Victor Sudakov]

Eugene M. Zheganin wrote:
> >
> > I am attaching a traffic dump.
> >
> > Please look at Frame No. 36, where a ticket is requested for
> > "HTTP/proxy.sibptus.transneft.ru", and then at Frame No. 39, where
> > the ticket is granted, but for the wrong principal name.
> >
> The thing is, valid exchange should not and does not contain the
> KRB5KRB_AP_ERR_MODIFIED error, and yours does. 

I thought as much. This error seems suspicious. But why does a second
request not cause the same error?

> This indicates something
> is wrong between these two hosts (as I understand, 10.14.134.4 is a
> Windows Server, and .122 is a workstation). 

Correct.

> You need to investigate on
> your DC what's happening, Probably these are the etype errors (may be
> not). 

I will ask our Windows admin to enable Kerberos event logging. Maybe
we'll find something there.

The huge problem is the absence of legible diagnostics on the
squid's side (the helper or the Heimdal library produce very
hard-to-interpret and too generic debug output).

> If your DC is really w2k (not w2k3 or w2k8) 

Unfortunately, it is really w2k. 

> and the workstation is
> of different generation, this can happen. 

The workstations are Windows XP and Windows 7, both giving mixed
results.

> Also, lots of howtos spread
> around the Internet, make an engineer believe that he should kreate the
> keytab with only one encryption type for squid, insted kreating the
> keytab with all of available on the DC ciphers, This can also lead to
> complicated situations.

We have tried both ways (enabling all ciphers and enabling only
arcfour-hmac-md5), but it made no difference. Currently we are using
the keytab with one arcfour-hmac-md5 key only:

Vno  Type              Principal
  1  arcfour-hmac-md5 HTTP/proxy.sibptus.transneft.ru at SIBPTUS.TRANSNEFT.RU

Which of the ways is correct, in your opinion? Could you repeat?

> 
> There's also a decent article there:
> http://blogs.technet.com/b/askds/archive/2008/06/11/kerberos-authentication-problems-service-principal-name-spn-issues-part-3.aspx

Thanks for the link. I guess it boils down to two possibilities:

1. There is a duplicate SPN somewhere in the forest, or

2. Replication problem between the DCs, the principal's passwords
don't match.

> 
> Could help you as it did help me one day.

Which was your situation when the article helped?


-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
sip:sudakov at sibptus.tomsk.ru