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

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 Tue May 11 2010 - 21:04:59 MDT