Re: [squid-users] Re: Error validating user via Negotiate. Error returned 'BH received type 1 NTLM token'

Hi Markus and all,

The 'Network Identity Manager' is running on the client, yes it is
from MIT (NetIDMgr 1.3.1.0) but it is just an app for renewing
credentials and checking them. I'm trying both firefox and IE, nothing
different.

By the way, I have come up with something strange on wireshark logs
after using negotiate_wrapper, I've always checked if my server and
client gets the tickets from KDC, I and couldn't figure out the
problem, because they both had the tickets. But, (important but here)
today, i see that, my client machine requests and get the tickets
AFTER the browser send and gets the HTML packets. I mean, kdc seems to
work after the connection fallsback to NTLM, If this is a problem,
what may cause it?

you can get the full pcap of my capture from here;
(http://muhammetcan.net/labris/kerb-logs.rar)

I have also checked the gpedit.msc on the client,
Under the Computer Configuration -> Windows Settings -> Security
Settings -> Local Policies -> Security Settings I got an option;
Network Security: LAN Manager Authentication Level which is undefined,
I have some options for LM and NTLM, and NTLMv2 and some more, but
there is nothing about Kerberos.

Thanks again.

On Fri, Jan 13, 2012 at 1:58 AM, Markus Moeller <huaraz_at_moeller.plus.com> wrote:
> 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_at_gmail.com> wrote in message
> news:CANYNOnryekSbXPj8QQ2ikyuoOCiA0bc2qr1RW8v0AQEV6FcY6g_at_mail.gmail.com...
>
> 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_at_treenet.co.nz> 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_at_LABRISTEST.COM
>>>
>>> --> 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
>
>

-- 
code is poetry!
muhammetcan.net