Hi Muhammet,
Do you use Kerberos for Windows from MIT ? The 'Network Identity Manager'
is from there isn't it ? Which Browser do you use ?
Markus
"Muhammet Can" <muhitosan@xxxxxxxxx> wrote in message
news:CANYNOnryekSbXPj8QQ2ikyuoOCiA0bc2qr1RW8v0AQEV6FcY6g@xxxxxxxxxxxxxx...
Thank's for you reply Amos,
I have downloaded negotiate_wrapper and set my squid-config as Markus
described here;
http://squid-web-proxy-cache.1019090.n4.nabble.com/NTLM-Kerberos-Authentication-with-Windows-7-td3331448.html
Now I can connect the web over Squid, but it seems like it still use
the old NTLM system; here is the new log files;
--> tail -f cache.log
2012/01/12 16:00:24| negotiate_wrapper: Got 'YR
TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==' from squid
(length: 59).
2012/01/12 16:00:24| negotiate_wrapper: Decode
'TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==' (decoded
length: 40).
2012/01/12 16:00:24| negotiate_wrapper: received type 1 NTLM token
[2012/01/12 16:00:24, 3] libsmb/ntlmssp.c:debug_ntlmssp_flags(62)
Got NTLMSSP neg_flags=0xe2088297
2012/01/12 16:00:24| negotiate_wrapper: Return 'TT
<the ticket code removed to make the mail more clean>
'
2012/01/12 16:00:24| negotiate_wrapper: Got 'KK
<the ticket code removed to make the mail more clean>
from squid (length: 615).
2012/01/12 16:00:24| negotiate_wrapper: Decode
<the ticket code removed to make the mail more clean>
(decoded length: 458).
2012/01/12 16:00:24| negotiate_wrapper: received type 3 NTLM token
[2012/01/12 16:00:24, 3] libsmb/ntlmssp.c:ntlmssp_server_auth(747)
Got user=[test1] domain=[LABRISTEST] workstation=[DELL1-DESTEK]
len1=24 len2=276
[2012/01/12 16:00:24, 3] libsmb/ntlmssp_sign.c:ntlmssp_sign_init(337)
NTLMSSP Sign/Seal - Initialising with flags:
[2012/01/12 16:00:24, 3] libsmb/ntlmssp.c:debug_ntlmssp_flags(62)
Got NTLMSSP neg_flags=0xe2088215
2012/01/12 16:00:24| negotiate_wrapper: Return 'AF = test1
*******************
--> tail -f access.log
192.168.0.147 - - [12/Jan/2012:16:03:06 +0200] "GET
http://www.google.com.tr/ HTTP/1.1" 407 1524 TCP_DENIED:NONE
192.168.0.147 - - [12/Jan/2012:16:03:07 +0200] "GET
http://www.google.com.tr/ HTTP/1.1" 407 1773 TCP_DENIED:NONE
192.168.0.147 - test1 [12/Jan/2012:16:03:07 +0200] "GET
http://www.google.com.tr/ HTTP/1.1" 200 16160 TCP_MISS:DIRECT
192.168.0.147 - test1 [12/Jan/2012:16:03:07 +0200] "GET
http://www.google.com.tr/csi? HTTP/1.1" 204 413 TCP_MISS:DIRECT
*******************
As you can see in access.log my client computer (test1) is connected.
But if you look at cache.log you will see that it still gets NTLM 1
token instead of kerberos.
"2012/01/12 16:00:24| negotiate_wrapper: received type 1 NTLM token"
I have also checked the credentials on client side with 'Network
Identify Manager'
When I try to get new credentials it gives this error;
"Could not obtain Kerberos v4 credentials"
But my client seems to got Kerberos v5 credentials, since after trying
this, time stamp renewed to 10hours. (I'm not sure if v4 situation can
break anything)
So, for this point, can you give me some information about 'what
breaks the kerberos and it keeps falling back to NTLM' or at least,
where should I look for the debug and inspect what may effect the
kerberos auth.
Thanks again, and sorry for my English if it disturbs a lot.
On Thu, Jan 12, 2012 at 5:57 AM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
On 12/01/2012 1:18 a.m., Muhammet Can wrote:
Hi all,
I have been trying to get squid running with kerberos auth for a few
days but I'm in some trouble. The problem has been asked and replied
many times on both the squid-users list and on the web, I have read
them all, and tried to solve the problem. But still no luck.
Here is some of my log files and tests.
(config files are prepared with using wiki;
http://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos)
--> tail -f cache.log
2012/01/11 11:54:06| squid_kerb_auth: DEBUG: Got 'YR
TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==' from squid
(length: 59).
2012/01/11 11:54:06| squid_kerb_auth: DEBUG: Decode
'TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==' (decoded
length: 40).
2012/01/11 11:54:06| squid_kerb_auth: WARNING: received type 1 NTLM token
2012/01/11 11:54:06| authenticateNegotiateHandleReply: Error
validating user via Negotiate. Error returned 'BH received type 1 NTLM
token'
As no doubt you have seen in those earlier posts type 1 is Negotiate/NTLM.
The easiest solution is to use the negotiate_wrapper Marcus developed last
year. That should get things working for the users while the details about
why NTLM is being used get more of a look at.
--> tail -f access.log
192.168.0.147 - - [11/Jan/2012:11:54:08 +0200] "GET
http://www.google.com.tr/ HTTP/1.1" 407 1524 TCP_DENIED:NONE
192.168.0.147 - - [11/Jan/2012:11:54:08 +0200] "GET
http://www.google.com.tr/ HTTP/1.1" 407 1524 TCP_DENIED:NONE
I have tested kerberos on the server side with;
--> klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@xxxxxxxxxxxxxx
--> kinit -V -k -t /opt/labris/etc/labris-webcache/HTTP.keytab
HTTP/test2008.labristest.com
Authenticated to Kerberos v5
And, on the client side, I have used kerbtray, it seems client has the
tickets.
I have captured the packets with wireshark as suggested some of the
earlier messages, it looks like client still tries to authenticate
with NTLM while we want to use kerberos.
Here is the some of the parts of wireshark log;
(if needed, you can get the full log from here:
http://pastebin.com/btp9PzYu )
client to server;
Hypertext Transfer Protocol
GET http://www.google.com.tr/ HTTP/1.1\r\n
[Expert Info (Chat/Sequence): GET http://www.google.com.tr/
HTTP/1.1\r\n]
Request Method: GET
Request URI: http://www.google.com.tr/
Request Version: HTTP/1.1
Host: www.google.com.tr\r\n
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20100101
Firefox/8.0\r\n
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
Accept-Language: tr-tr,tr;q=0.8,en-us;q=0.5,en;q=0.3\r\n
Accept-Encoding: gzip, deflate\r\n
Accept-Charset: ISO-8859-9,utf-8;q=0.7,*;q=0.7\r\n
Proxy-Connection: keep-alive\r\n
server reply;
Hypertext Transfer Protocol
HTTP/1.0 407 Proxy Authentication Required\r\n
[Expert Info (Chat/Sequence): HTTP/1.0 407 Proxy
Authentication Required\r\n]
Request Version: HTTP/1.0
Status Code: 407
Response Phrase: Proxy Authentication Required
Server: squid/3.1.12\r\n
Mime-Version: 1.0\r\n
Date: Wed, 11 Jan 2012 11:28:01 GMT\r\n
Content-Type: text/html\r\n
Content-Length: 1152\r\n
X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0\r\n
Proxy-Authenticate: Negotiate\r\n
X-Cache: MISS from labris-1\r\n
X-Cache-Lookup: NONE from labris-1:3128\r\n
Via: 1.0 labris-1 (squid/3.1.12)\r\n
Connection: keep-alive\r\n
\r\n
client tries authentication;
Hypertext Transfer Protocol
GET http://www.google.com.tr/ HTTP/1.1\r\n
[Expert Info (Chat/Sequence): GET http://www.google.com.tr/
HTTP/1.1\r\n]
Request Method: GET
Request URI: http://www.google.com.tr/
Request Version: HTTP/1.1
Host: www.google.com.tr\r\n
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20100101
Firefox/8.0\r\n
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
Accept-Language: tr-tr,tr;q=0.8,en-us;q=0.5,en;q=0.3\r\n
Accept-Encoding: gzip, deflate\r\n
Accept-Charset: ISO-8859-9,utf-8;q=0.7,*;q=0.7\r\n
Proxy-Connection: keep-alive\r\n
Proxy-Authorization: Negotiate
TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==\r\n
NTLM Secure Service Provider
NTLMSSP identifier: NTLMSSP
NTLM Message Type: NTLMSSP_NEGOTIATE (0x00000001)
Flags: 0xe2088297
Calling workstation domain: NULL
Calling workstation name: NULL
That might be important. If the browser is not aware for some reason that
it
has a Windows domain.
Version 6.1 (Build 7601); NTLM Current Revision 15
Major Version: 6
Minor Version: 1
Build Number: 7601
NTLM Current Revision: 15
Please see me as a newbie,
I'd really appreciate a detailed solution to get squid working with
kerberos and what may cause the problem.
So far as this shows Squid is working well up to the point when the client
sends it NTLM response credentials. Those are rejected due to not being
Kerberos credentials.
Amos
--
code is poetry!
muhammetcan.net
