On Thu, 19 Sep 2002, Vijay Kota wrote: > Some clarification is in order. The traces I sent you are for > actual Win2K machines (*not* my samba server). Basically I > wanted to know if anybody has come across that 0x6B I am > seeing.
Well, because I think that is padding, we might not have come across that exactly. > I was messing with Samba code to see if I could get around my > original problem of losing the serviceprincipalname in Active > Directory even if Authenticate2 (in the unmodified samba code) > succeeds. > > -----Original Message----- > From: Richard Sharpe [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 19, 2002 8:22 PM > To: Vijay Kota > Cc: [EMAIL PROTECTED] > Subject: RE: unknown RPC opcodes during join+logon > > On Thu, 19 Sep 2002, Vijay Kota wrote: > > > I too think the algorithm is not the same since I implemented the RPC > > using the same algorithm (cred_session_key() and > cred_create(zerotime)) > > but got 0xC0000022. This was with a flags value of 0x0007FFFF. > However, > > the PDC returns STATUS_SUCCESS if flags = 0x000001FF. So the flags > field > > seems to be significant. > > Hang on. Here, you are saying that you implemented the server side of > ServerAuthenticate3 and generated the response. > > > Strangely though, if I don't align after the challenge and push a > > 0x006B006B (or 0x0000006B) before the neg_flags (= 0x0007FFFF), I > could > > get it to work. I am not claiming that the preceding statement was > very > > logical :-)) but it would be great if someone could verify it and at > > least disprove it. > > Are you saying you had to push this into the response? > > In the trace I have, Ethereal dissects the response as (courtesy of > Luke Howard) > > Credentials (via a pointer) 8 bytes > Flags, in this case 0x0007ffff > Unknown UINT32: 0x00000452 > Status: SS_SUCCESS (0) > > And the flgs are properly aligned. > > > Vijay > > > > -----Original Message----- > > From: Luke Howard [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, September 19, 2002 12:56 AM > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > > Subject: Re: unknown RPC opcodes during join+logon > > > > > > >The return code always follows the last top-level [out] value, but > > there > > >is an additional [out] ULONG in NetrServerAuthenticate3. > > > > > >The algorithm for calculating credentials is the same. > > > > Actually, I'm no longer sure this is the case. It seems that the > > algorithm for NetrServerAuthenticate3 is the same if the client > > thinks the domain is an NT4 domain (in which case it talks to it > > over SMB), but it looks like the algorithm is different in a > > Windows 2000 domain (where the RPC is made over ncacn_ip_tcp), > > as unlikely as this seems (given they are the same RPC). Note > > that the flags are ostensibly irrelevant, because the client > > sends the authenticator before it receives the flags from the > > server. > > > > -- Luke > > > > -- > > Luke Howard | PADL Software Pty Ltd | www.padl.com > > > > -- Regards ----- Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
