Re: [squid-users] Re: Re: squid_kerb_auth received type 1 NTLM token

Dear Markus,

You have to be recommended for your patience!!
Turns out that my keytab file was wrong all along due to a stupid
mistake from my side. (as to be expected :-/)
I did have the principal for the realm but not for the proxy server
itself. Thus the HTTP-keytab was recreated with the msktutil, this time
with correct principal information.
Now it works fine, I can see the clients authenticating in the cache.log

bottomline: my bad knowledge about kerberos made me look for the wrong
reasons.

thank you very much for your help.

Cheers !

Lieven

Markus Moeller wrote:
> Changing the name may not be enough. Delete the AD entry and the keytab
> and create a new entry with keytab.
>
> Regards
> Markus
>
> "Lieven" <lievendp_at_gmail.com> wrote in message
> news:4BE9C40A.1090900_at_gmail.com...
>> That seems to clarify my problems. thank you.
>>
>> After the mkstutil, I saw that a new computer object had been made in
>> the AD.
>> In adsiedit, I opened this squid3-proxy computeraccount and checked
>> it's principalname service.
>> There was only "HTTP/domain.local" so I manually added
>> "HTTP/squid3-proxy.domain.local".
>> Then after I did a new webrequest via the proxyserver, I saw this
>> HTTP/squid3-proxy.domain.local service principal in kerbtray.
>> Only, it still pops up with a authentication request so I'm not yet
>> there.
>>
>> Anyway, tomorrow I'll have access to the local pc and a wireshark
>> trace will probably help me solve this further.
>>
>> thanks for all the effort already.
>>
>> cheers.
>> Lieven
>>
>>
>> Markus Moeller wrote:
>>> Hi Lieven,
>>>
>>> The problem seems to be the krb5kdc_err_s_principal_unknown error. If
>>> you took the capture earlier shoudl have seen a TGS REQ in wireshark
>>> for HTTP/squid3-proxy.domain.local and AD says it does not anything
>>> about this principal. Can you search AD if you have an entry with
>>> serviceprincipalname=HTTP/squid3-proxy.domain.local using
>>> adsiedit.msc for example ?
>>>
>>> If you would have got a successful reply it would be a TGS REP and
>>> kerbtray would show
>>> DOMAIN.LOCAL
>>> |_ cifs/adserver1.domain.local
>>> |_ krbtgt/DOMAIN.LOCAL
>>> |_ krbtgt/DOMAIN.LOCAL
>>> |_ LDAP/adserver1.domin.local/domain.local
>>> |_ ProtectedStorage/adserver1.domain.local
>>> |_ HTTP/asquid3-proxy.domain.local/domain.local
>>>
>>>
>>> Regards
>>> Markus
>>>
>>> "lieven" <lieven_at_ba.be> wrote in message news:4BE94D3C.6040509_at_ba.be...
>>>> Hello again,
>>>>
>>>> This time, I got access to a pc in the AD domain.
>>>>
>>>> When I monitor for both udp and tcp port 88, there is krb communication
>>>> to be seen but it doesn't look right.
>>>> From AD server to client I see the following error:
>>>> krb5kdc_err_s_principal_unknown
>>>>
>>>> It looks like this: (only krb5 and some tcp lines)
>>>> 1. server -> client: Krb Error: krb5kdc_err_s_principal_unknown
>>>> 2. client -> server: AS-REQ
>>>> 3. server -> client: KRB Error: krb5kdc_err_preauth_required
>>>> 4. client -> server: AS-REQ
>>>> 5. server -> client: AS-REP
>>>> 6. client -> server: AS-REQ
>>>> 7. server -> client: KRB Error: krb5kdc_err_preauth_required
>>>> ...{4-7} X7
>>>>
>>>> this sequence, starting from 3 is repeated a few times, as many
>>>> times as
>>>> I had to enter credentials in IE popup.
>>>>
>>>> Here is a detail from the error packet principal unknown:
>>>> No. Time Source Destination
>>>> Protocol
>>>> Info
>>>> 6 0.009940 X.X.X.X X.X.X.X KRB5 KRB
>>>> Error: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN
>>>>
>>>> Frame 6 (179 bytes on wire, 179 bytes captured)
>>>> Ethernet II, Src: Vmware_7e:84:97 (00:0c:29:7e:84:97), Dst:
>>>> Dell_48:f3:90 (00:24:e8:48:f3:90)
>>>> Internet Protocol, Src: X.X.X.X (X.X.X.X), Dst: X.X.X.X (X.X.X.X)
>>>> Transmission Control Protocol, Src Port: kerberos (88), Dst Port: 65248
>>>> (65248), Seq: 1, Ack: 1660, Len: 125
>>>> Kerberos KRB-ERROR
>>>> Record Mark: 121 bytes
>>>> Pvno: 5
>>>> MSG Type: KRB-ERROR (30)
>>>> stime: 2010-05-11 10:44:11 (UTC)
>>>> susec: 313474
>>>> error_code: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN (7)
>>>> Realm: DOMAIN.LOCAL
>>>> Server Name (Service and Instance): HTTP/squid3-proxy.domain.local
>>>> Name-type: Service and Instance (2)
>>>> Name: HTTP
>>>> Name: squid3-proxy.domain.local
>>>>
>>>> On this client pc, it is a windows vista, I have different kerberos
>>>> tickets: (as per kerbtray)
>>>>
>>>> DOMAIN.LOCAL
>>>> |_ cifs/adserver1.domain.local
>>>> |_ krbtgt/DOMAIN.LOCAL
>>>> |_ krbtgt/DOMAIN.LOCAL
>>>> |_ LDAP/adserver1.domin.local/domain.local
>>>> |_ ProtectedStorage/adserver1.domain.local
>>>>
>>>> The encryption types are for all tickets:
>>>> Kerberos AES256-CTS-HMAC-SHA1-96 (both for ticket and key encryption
>>>> type)
>>>>
>>>> The client principal is userid_at_DOMAIN.LOCAL
>>>>
>>>>
>>>> I also traced DNS on udp and tcp 53, this seems to work ok; it shows a
>>>> lookup of the requested site and then a reply from the adserver (also
>>>> dns) with the ip of the site.
>>>> I don't see any lookup of the proxy-server fqdn that is put as the
>>>> connection proxy setting in the browser. (it is
>>>> squid3-proxy.domain.local)
>>>>
>>>>
>>>>
>>>> Next, I tried to follow the requests on port 3128 tcp to the
>>>> proxyserver:
>>>>
>>>> 1) the client requests a webpage to the proxyserver on port 3128: "GET
>>>> http://www.google.be/ HTTP/1.1" (http protocol)
>>>> 2) proxy sends back a 407: (http) "HTTP/1.0 407 Proxy Authentication
>>>> Requied (text/html)"
>>>> 3) client responds with (http) "GET http://www.google.be/ HTTP/1.1 ,
>>>> NTLMSSP_NEGOTIATE"
>>>>
>>>> Between each point there is some tcp syn/ack/fin traffic which I can
>>>> post if needed.
>>>>
>>>> The last 2 points are repeated a few times where the proxy requests
>>>> authentication, expecting kerberos and the client responding with ntlm
>>>> for some reason.
>>>>
>>>> In Firefox, It is the same as IE, proxy auth required followd by an
>>>> ntlmssp_negotiate from the client.
>>>>
>>>>
>>>>
>>>> Why I don't get kerberos to work is a mistery to me as it seems to work
>>>> in the domain itself when computers authenticate to get access to
>>>> shares
>>>> etc...
>>>>
>>>> Any clues welcome.
>>>>
>>>> thanks,
>>>>
>>>> Lieven
>>>>
>>>> --
>>>>
>>>> Please Visit us at V-ICT-OR shopt IT
>>>> 25 May 2010 - De Montil - Affligem
>>>>
>>>> Lieven De Puysseleir
>>>> BA N.V. - http://www.ba.be
>>>> Dalemhof 28, 3000 Leuven
>>>> tel: 0032 (0)16 29 80 45
>>>>
>>>
>>>
>>
>
>
Received on Wed May 12 2010 - 08:59:33 MDT