Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have been trying to get squid running with kerberos for a few days, but I'm in big pain. I have double checked all the configuration files they all seems OK.

Here is my question, today I have captured the packets with wireshark and I saw that my client browser sends and get the HTTP packets before getting the tickets from KDC.

I can connect the Internet over squid, but it uses NTLM instead of Kerberos, I am thinking that authorization fallsback to NTLM, because it tries Kerberos Auth before it gets the ticket from KDC. (it can get the tickets later)

What could cause to KDC that it is not able to send the tickets while the authentication period?

If needed; you can get the full wireshark log from here.
update: updated wireshark logs, please check this instead of first one

update2: squid conf file:

Thanks a lot.

share|improve this question
I was under the idea that Squid can't un-encrypt the Kerbros tickets, so that you'll have to re-auth (and that's possibly where NTLM kicks in). Or am I way off here? – pauska Jan 14 '12 at 2:34
Hi pauska, I'm really not sure how can I check if squid can un-encrypt the tickets or not, but on wireshark logs I don't see anything erronous (still I'm not sure) on kerberos part. – Muhammet Can Jan 16 '12 at 9:10

I see no challenge from the proxy for authentication in the trace you sent. The only Kerberos traffic I see is a TGT for Realm: LABRISTEST.COM issued to test1.

If the proxy were enforcing authentication, I would expect a trace with "StatusCode: 407, Proxy authentication required" returned by proxy. See for example of a likely trace where proxy requires auth.

I dont see any NTLM or Kerberos based auth to the proxy.

The client will only request tickets if it has to (i.e. proxy says auth required). Until then it does not know what tickets to request and tries anonymously. So you should see a ticket request after accessing proxy anonymously. And that too, only if there is no cached ticket locally at the client side. Its also possible that despite no ticket locally cached, you see no request because of a negative cache (cached the fact that previous request for ticket failed).

I also note you are not using IE (UserAgent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20100101 Firefox/8.0) for testing this. I suggest you use IE for testing unless you are certain firefox is configured to respond to auth requests correctly.

Update (16th Jan): You should always flush DNS cache (ipconfig /flushdns) and kerberos cache before collecting traces. This allows seen KDC detection related DNS traffic and kerberos ticket requests success/failure.

Its also important to know how you configure the proxy settings in the browser as this has some say in the tickets requested. The proxy port appears to be 3128 and the name is labris-1. So, you will likely need to register http/labris-1:3128 and http/ SPN on the AD object used by the proxy service. You also need to add the reg key from;EN-US;908209 for all IE greater than V6. Make sure the keytab is updated and accessible on the squid server.

share|improve this answer
Hello maweeras, thanks for taking time and looking to logs, I'm not sure why that time it didn't require proxy_auth, although I haven't changed anything since posting the question, now it requires proxy_auth, I have updated my question, put new logs and my squid.conf file, I would greatly appreciate if you can look at once more. thanks again. – Muhammet Can Jan 16 '12 at 9:05
updated my answer. – maweeras Jan 16 '12 at 15:32

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.