On 12/23/05, Eric Wedel <ewedel@xxxxxxxxxxx> wrote:
> > checked in
>
> Thanks!
>
> > i assume you run it over tcp?
>
> Yeah, our QA guys love to test using giganto PACs,
> which forces kerb / kpasswd to TCP.
>
> > maybe you can ... upload your example capture
>
> Added to http://wiki.ethereal.com/SampleCaptures, under
> your existing kerberos section. :-)
>
> This is a bit silly, but I got lost trying to figure out
> how to add a protocol page. It appears that both
> Protocols/kpasswd and kpasswd should be created, with the
> former being a redirect to the latter? If there's a page
> in there that describes how to add a protocol, I didn't
> find it.
just type in the url http://wiki.ethereal.com/kpasswd and use the
ProtocolTemplate.
the redirects can be added later.
>
> > did you check that kpasswd decryption still works over tcp
>
> If you mean ethereal, I've never tried turning on kerb
> decryption in ethereal.
>
> Hmm, not quite sure how to test that -- would need to get the
> keytab of the system which the AP-REQ is aimed at, and that's
> an AD DC in our case (win2k or win2k3). Any idea how to derive
> a keytab for an AD DC?
You would only need the keytab of the DC to decrypt the ticket in the
AP-REQ part.
But the Authenticator in the AP-REQ as well as the KRB-PRIV part in
the request that contains the account name and password should decode
fine using the keytab of the member server.
It should decrypt just using the keytab for your box. No need for a
keytab containing the secret for the DC.
If you wanted to create a keytab of the DC it used to be a bit tricky
requiring you to extract the password from it and use ktutil to
manually hash it into a keytab.
Nowadays it is quite easy to do :
http://lists.samba.org/archive/samba-technical/2005-December/044418.html
but you rarely need to.
(I think you will find it much more useful to decrypt packets that are
encoded using your box's secret key, such as SessionSetup blobs from
clients mapping shares on your box. And i assume there will be
little problem for you to extract your own box's keytab )
You should try the decryption feature. It is very useful for troubleshooting.
It allows you to decrypt the security blob sent from clients to your
box in the sessionsetup call allowing you to see under which users
credentials the user is mapping the share (i.e. as the user or as
the machineaccount or as someone else).
Since ethereal then also dissects the actual PAC itself it is very very useful.
>
> regards, Eric
>
> -----Original Message-----
> From: ronnie sahlberg [mailto:ronniesahlberg@xxxxxxxxx]
> Sent: Thursday, December 22, 2005 7:46 PM
> To: Ethereal development
> Cc: Eric Wedel
> Subject: Re: patch to dissect kpasswd over tcp
>
>
> checked in
>
>
> nice. i have never seen kpasswd over anything else than udp myself
> before but i assume you run it over tcp?
>
> anyway nice,
> maybe you can add a small kpasswd page to the wiki and upload your
> example capture to that page?
>
> (did you check that kpasswd decryption still works over tcp it
> should work but it wouldnt hurt to test)
>
>
> best regards
> ronnie s
>
>
> On 12/23/05, Eric Wedel <ewedel@xxxxxxxxxxx> wrote:
> > Hi..
> >
> > RFC 3244 says kpasswd can use UDP or TCP, the dissector was only doing
> UDP.
> > The attached patch adds TCP support, including PDU reassembly. The
> > reassembly
> > code is modelled on the kerberos dissector, and in fact TCP "record mark"
> > handling
> > is shared between the two dissectors.
> >
> > Comments and/or checkin appreciated.
> >
> > A sample capture showing kpasswd-over-TCP is also attached.
> >
> > thanks,
> > Eric Wedel
> >
> >
> >
> > Eric, BlueArc Engineering
> >
> >
> >
>
