[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Heimdal / MS kpasswd differences?
Ah ok.
Both traces contain genuine rfc3244 ms kpasswd packets.
But wireshark gets the decode wrong.
The reason it gets it wrong is that prior to the KPASSWD packets you have
normal KRB5 packets coming from port 32768 on the client going to port 88 on the server.
When wireshark sees these KRB5 packets from the client it sets up state to decode any and all
packets between this server and this client and coming to/from the clients port 32768
and any port on the server to all be KRB5.
The reason for this is to handle the case when a KDC responds back to the client from a different port.
(client calls KDC on port 88, KDC responds from a different port)
This means when the kpasswd packet shows up going to 464 on the server, the client si still using the same udp port 32768
which we already set an override for to force to krb5.
(the reason it shows up as krb4 is due to a different heuristic, since many implementations talk krb4 on the same port as krb5 we just initially test if it looks like krb5 and if it doesnt then blindly assume it is krb4 instead)
Ill see how to fix this in the code tonight so that wireshark will decode these packets properly without breaking any of the other heuristics we need in the code.
what client are you using? I have never seen a client before that reuses the same clientside port between both krb5 and kpasswd
On 9/4/06, Michael B Allen <mba2000@ioplex.com> wrote:
On Sun, 3 Sep 2006 05:04:50 +0000
"ronnie sahlberg" <ronniesahlberg@gmail.com> wrote:
> Port 464 is rfc3244 which is what wireshark displayed as ms kpasswd
>
> I am intrigued by the other trace however that was also port 464 but
> was not decoded at all.
> Can you share that trace with me so i can see if this is a bug in wireshark?
Sure. They're from my test env. Hopefully the list doesn't mind two
small pcaps but I thought I should get the list because I noticed a further
inconsistency. If I use:
$ kpasswd --admin-principal=administrator@WIN.NET
HTTP/www6.foo.net@WIN.NET
I see a 1300 byte undecoded UDP packet. If I use:
$ kpasswd --admin-principal=user1@WIN.NET HTTP/www6.foo.net@WIN.NET
(user1 is in the Account Operators group and therefore can change
passwords) the packet is shown as 'Kerberos v4' message type 0xa4 and
is otherwise not decoded. So it looks like Heimdal might be doing
something funky here too.
I'm using Ethereal 0.10.14. See attachments.
> As far as windows clients themself are concerned, it is very very
> rare that they use this protocol to set/change passwords, most of the
> time they use sealed dcerpc interfaces instead.
This is exactly what I want to know about. I can do DCERPC or kpasswd. I
want to do what is most portable.
Do you happen to know what DCERPC is most common? I need to set the
initial password on a service account though so I don't know if I want
one of the SamrChangePasswordUser or a SamrSetInformationUser. I've seen
SamrSetInformationUser2 with SamrUserInfo25 used during a join which is
sort of what I'm doing but I can easily create the account with LDAP too.
Mike
--
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/