Hi Simon,
This looks like a client PC issue. Can you check with kerbtray that the
client gets a TGS for HTTP/<squid-fqdn> ? If you can look at the traffic
between the client and AD with wireshark you should see first an AS request
from the client to AD on port 88 and when you the user opens IE and accesses
squid you should see a TGS request from the client to AD.
Regards
Markus
BTW I would not recommend using ktpass and a user account. ktpass uses DES
as a default which is not anymore supported by newer MS systems and secondly
user accounts in AD have usually (depending on your AD setting) a password
expiry which would make you keytab invalid.
"Simon Dwyer" <m...@simmyd.net> wrote in message
news:1334540222.28105.17.ca...@sdwyer.federalit.net...
Have found that proper credentials will work if entered when prompted.
so it seems the credentials that get tried first do not work.
Whats the best way to work out what is going on?
On Mon, 2012-04-16 at 10:22 +1000, Simon Dwyer wrote:
On Mon, 2012-04-16 at 09:49 +0930, Brett Lymn wrote:
> On Mon, Apr 16, 2012 at 09:41:19AM +1000, Simon Dwyer wrote:
> > Further upon this i have updated to 3.1.19 and i get the same errors.
> > I
> > have fresh installed the machine back to how it was when the first
> > email
> > when out.
> >
>
> Is the keytab readable by the user running squid? The kerberos
> messages
> are not always the most helpful of things. You could also try writing
> a
> script wrapper around the authenticator to strace the start up to see
> if
> that gives you any more clues.
>
the keytab is readable by squid.
I have changed the account in AD to a user account and i get the same
error. But now when the user is prompted for a password and he enters
it it works correctly and cache.log shows kerberos authentication. So
it seems i am having trouble with the sso part now?
