unknown RPC opcodes during join+logon

[Luke Howard]

>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.

Right, but if the client sends 0x0007FFFF along with the authenticator, the
server _must_ be able to support that algorithm, because no negotiation
takes place beforehand. Now, admittedly I didn't try returning 0x000001FF;
perhaps the client will retry with the old algorithm. But I did note that
0x000001FF forces an NT-style SAM logon. 

Perhaps there is some combination of flags where the old algorithm is used
but a Windows 2000-style logon is attempted.

>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.

That is very odd, and I'm not sure how easy it will be for us to test as
we are using the OSF IDL compiler and runtime, but I'll give it a go.

What made you try 0x6B? :-)

cheers,

-- Luke
--
Luke Howard | PADL Software Pty Ltd | www.padl.com