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

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 - 18:49:51 MDT