Hi Nick,
I would interpret this as if IE has somewhere still squid3 as proxy
configured.
Markus
"Nick Cairncross" <Nick.Cairncross@xxxxxxxxxxxxxxx> wrote in message
news:C86A4A85.BB32%nick.cairncross@xxxxxxxxxxxxxxxxxx
Hi Markus,
I admit that it could be preferable to do it for each one if the KVNO was to
change, but the AD account I use is a dummy computer account and has no
physical host so doesn't change. That said, I have tried to do it with a
separate account and I get the same result: 2 work one fails. I have even
tried renaming the squid server, disjoining from domain, regenerating the
keytab etc. The server is now called squid4 (was squid3)
I have just pcapped port 88 from the client and I have noticed the
following:
KRB5 KRB Error: KRB5KDC ERR S PRINCIPAL UNKNOWN
The S principal mentioned is the old server (squid3). Obviously that won't
work...
HOWEVER, If I do it from another machine I see everything working ok!
Kerberos capture, ticket etc are all fine with the right name - I don't
understand! How can it work for one and not the other? I have destroyed the
tickets on both, rebooted etc.
Could it be something more specific on my clients? It just doesn't make
sense that it is so hit and miss..
Thanks,
Nick
On 17/07/2010 12:09, "Markus Moeller" <huaraz@xxxxxxxxxxxxxxxx> wrote:
Hi Nick,
This is a unusual setup. I wonder how you could get it to work as a keytab
extraction changes usually the AD entry and therefore the key for your
2nd/3rd squid server. I suggest to create three separate AD entries and
remove any SPN for HTTP/<short-hostname>.
Regards
Markus
"Nick Cairncross" <Nick.Cairncross@xxxxxxxxxxxxxxx> wrote in message
news:C8665961.B8AC%nick.cairncross@xxxxxxxxxxxxxxxxxx
Hi list,
I think I have a problem with one of my SPNs/keytab - wondered if someone
could confirm this:
3 x squid boxes on different sites, squid1, squid2 and squid3 are their
hostnames. I have one AD account with the SPNs of all on it. Using fqdn for
the proxy address to 2 of them results in Kerberos tickets:
HTTP/<squid1>.fqdn@FQDN and HTTP/<squid2>.fqdn@FQDN and everything is fine.
However on the third one I get a ticket: HTTP/squid3@ i.e. No fqdn or @FQDN
I have both 'squidx' and 'squidx.fqdn' in my AD SPN for all boxes. I'm
thinking the working two are using the squid.fqdn and the non-working one is
using just 'squid3' hence the issue. Does this sound feasible. I think the
answer is drop the 'squidx' from my SPNs and stick with the 'squidx.fqdn',
regenerate my keytab and that's it.
I have cloned one of the working squid boxes and replaced the non-working
one, so this leads me to believe it is the SPN/keytab and not the server.
Thoughts welcome!
Nickcx
The information contained in this e-mail is of a confidential nature and is
intended only for the addressee. If you are not the intended addressee, any
disclosure, copying or distribution by you is prohibited and may be
unlawful. Disclosure to any party other than the addressee, whether
inadvertent or otherwise, is not intended to waive privilege or
confidentiality. Internet communications are not secure and therefore Conde
Nast does not accept legal responsibility for the contents of this message.
Any views or opinions expressed are those of the author.
The Conde Nast Publications Ltd (No. 226900), Vogue House, Hanover Square,
London W1S 1JU
The information contained in this e-mail is of a confidential nature and is
intended only for the addressee. If you are not the intended addressee, any
disclosure, copying or distribution by you is prohibited and may be
unlawful. Disclosure to any party other than the addressee, whether
inadvertent or otherwise, is not intended to waive privilege or
confidentiality. Internet communications are not secure and therefore Conde
Nast does not accept legal responsibility for the contents of this message.
Any views or opinions expressed are those of the author.
The Conde Nast Publications Ltd (No. 226900), Vogue House, Hanover Square,
London W1S 1JU
