RE: [squid-users] Re: Squid_kerb_auth problem after long login times.

2008-06-19 Thread Plant, Dean
Markus Moeller wrote:
 Can you use kerbtray on the client ( it is available as part of the
 support tools or resource tools). I suspect that your ticket has
 expired. The ticket will usually be renewed when you lock/unlock your
 screen or access a share. XP should also renew when IE accesses a web
 server or proxy with negotiate (although I have heard of some issues
 here). 
 
 Can you try to lock and unlock the screen instead of logout/login.
 
 Markus
 
 BTW What does the squid logfile say when you use  squid_kerb_auth -d
 -i  ... ?

Thanks for your reply.

The tip, locking and unlocking the screen, does renew tickets and fix
the issue when on XP SP2. I had never tried this before, leaving my test
machines overnight meant they were already locked. The first action in
the morning was to unlock and test the proxy connection, locking and
unlocking a second time does fix the issue.

I managed to fix this issue by simply installing XP SP3. I have now run
for days without any overnight proxy authentication issues or requiring
logout/login lock/unlock. Either from leaving machines logged in or
putting machines into hibernate or standby. :-)

I had been using kerbtray to debug kerberos. At SP2 level kerbtray would
show the ticket expired when I first unlocked the screen but then go
green within seconds as the machine renewed it tickets, authentication
with the proxy would still fail. It would seem though that with XP SP2
the issues lie at this unlocking the screen stage as mentioned above
locking and unlocking the screen a second time seems to correctly renew
the tickets so communication to the proxy is restored.

On a side note,

The reason I started looking at squid_kerb_auth was that we were
suffering from random pop-ups in Firefox with our transparent NTLM
authentication. With this kerberos authentication system I have not seen
one random pop-up yet so thank you very much for your work.

Dean  

 
 Plant, Dean [EMAIL PROTECTED] wrote in message

news:[EMAIL PROTECTED]
k...
 Testing squid-2.6.STABLE20 on CentOS 5 with WinXP clients that are
 part 
 of and AD domain.
 
 I have been testing the Kerberos authentication and have noticed that
 after a few days I can no longer use the proxy. My Kerberos tickets
 are valid on the proxy and on the client and I can access windows
 network resources normally. If I login to different machine I can use
 the proxy 
 so all seems well with the proxy configuration. If I logout of the
 affected machine and then login again proxy access is restored.
 
 I have tested this with a few other users who have been logged in for
 over a week with the same results. All were denied access until
 logging 
 out and in again.
 
 Time is correct on all machines.
 
 Any ideas for the best way to debug the Kerberos handshake.
 
 Thanks in advance.
 
 Dean.


[squid-users] Re: Squid_kerb_auth problem after long login times.

2008-06-11 Thread Markus Moeller
Can you use kerbtray on the client ( it is available as part of the support 
tools or resource tools). I suspect that your ticket has expired. The ticket 
will usually be renewed when you lock/unlock your screen or access a share. 
XP should also renew when IE accesses a web server or proxy with negotiate 
(although I have heard of some issues here).


Can you try to lock and unlock the screen instead of logout/login.

Markus

BTW What does the squid logfile say when you use  squid_kerb_auth -d -i  ... 
?


Plant, Dean [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]

Testing squid-2.6.STABLE20 on CentOS 5 with WinXP clients that are part
of and AD domain.

I have been testing the Kerberos authentication and have noticed that
after a few days I can no longer use the proxy. My Kerberos tickets are
valid on the proxy and on the client and I can access windows network
resources normally. If I login to different machine I can use the proxy
so all seems well with the proxy configuration. If I logout of the
affected machine and then login again proxy access is restored.

I have tested this with a few other users who have been logged in for
over a week with the same results. All were denied access until logging
out and in again.

Time is correct on all machines.

Any ideas for the best way to debug the Kerberos handshake.

Thanks in advance.

Dean.