2

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: http://pastebin.com/k1pafHfH

Thanks a lot.

2
  • 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, 2012 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. Jan 16, 2012 at 9:10

1 Answer 1

3

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 http://technet.microsoft.com/en-us/library/bb984870.aspx 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/labris-1.labristest.com:3128 SPN on the AD object used by the proxy service. You also need to add the reg key from http://support.microsoft.com/default.aspx?scid=kb;EN-US;908209 for all IE greater than V6. Make sure the keytab is updated and accessible on the squid server.

2
  • 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. Jan 16, 2012 at 9:05
  • updated my answer.
    – maweeras
    Jan 16, 2012 at 15:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .