Thanks to Kevin. Keeps me from going crazy!
To answer the other questions:
On Sep 16, 2004, at 9:01 AM, [EMAIL PROTECTED] wrote:
To: [EMAIL PROTECTED] Subject: Re: [OpenAFS-devel] What is this Packet Anyway? Date: Wed, 15 Sep 2004 23:22:01 -0400 From: Marcus Watts <[EMAIL PROTECTED]>
"Henry B. Hotz" <[EMAIL PROTECTED]> claims:Contrary to popular rumor it appears that the Windows AFS client (Transarc 3.6 2.48 anyway, not talking about 1.3.x) does *not* use standard Kerberos 4 (though it does use port 750) for its authentication exchanges. Neither does it use RX.
The authentication request I captured is the following (and is identical for two different versions of Windows). The Ethernet, IP, and UDP headers are stripped, leaving the following:
0000 63 03 62 87 f8 b9 73 c2 a7 01 68 6f 74 7a 00 00 c.b...s...hotz.. 0010 4a 50 4c 2e 4e 41 53 41 2e 47 4f 56 00 44 3f 47 JPL.NASA.GOV.D?G 0020 41 bf 61 66 73 00 00 A.afs..
There is no RX header. It doesn't start off with the "04 02" or "04
03" that a Kerberos 4 request would. What is this thing? It fails all
the Heimdal code checks for what it might be and winds up not causing
any action whatever.
I will note that if you strip off the first 10 bytes the remainder is
the same as what you get if you strip off the first 2 bytes of a normal
Kerberos 4 authentication request.
If no one knows what this is, can they at least give me some pointers
to where the kaserver code would handle the request? I get lost in all
the RX stuff (that shouldn't even be relevant since this isn't an RX
packet).
kaserver is prepared to handle requests on up to 3 ports: 7004 rx 750, 88 udp udp stuff is all handled in 1 file -- src/kauth/krb_udp.c It's very straight-forward. I've never seen a version of kaserver that was prepared to deal with anything but standard K4 stuff on port 750 (and 88).
I did *eventually* find that, but thanks. (The code's a little scary in that if you have an /etc/services which defines "kerberos" as 88 (normal) but doesn't define "kerberos-iv" it will do the "wrong thing" (TM). Suppose it's not worth fixing though.)
The version of 3.6 source I have has windows specific code in
kauth/user_nt.c that contains a "k4" version of ka_UserAuthenticateGeneral .
That looks to be doing absolutely standard k4 stuff as well, no hanky-panky.
Have to look at this.
It's a real shame that you only included one fragment of one packet --
I can't tell if that's from the client or the server, and it would be
handy to know whether it's from or to port 88, 750, or 7004. Is that
actually the whole packet too? (I ask since tcpdump defaults to silently
trimming packets at 82 bytes unless you say "-s 1500"...) Have you
tried running this client against kaserver or fakeka? It would be
interesting to see the entire packet exchange for a "successful" run
before drawing too many conclusions about what's happening.
I had lots of packets, but they were all the same. What I posted was the auth request, minus the Ethernet, IP, and UDP headers. In other words what a server program would have gotten from its recv() call.
At the time I had no reply packets to post or look at. Since then I have done some snoops on our operational cell and the reply is a bog-standard K4 packet. Nothing funny at all.
I suppose it's conceivable transarc might have wanted to do something
besides straight k4 on their windows machines - if so, they're likely
trying to do some sort of pre-authentication like they do with RX.
But I suppose it's also possible this is some sort of bad library clash.
Is there any particular reason you want to use this particular afs client
on windows rather than a recent openafs version?
The usual. Existing installed base. We expect to switch to OpenAFS sometime next FY (which starts October), but we want to ditch the kaserver sooner than that!
------------------------------------------------------------------------ -----Marcus
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
_______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
