unknown RPC opcodes during join+logon

[Luke Howard]

>Well, it was Luke who claimed to figure it out, and even then, from what I 
>can tell, he could not get past the first exchange :-)
>
>Secondly, an XP client, when I switch off Sign&Seal, is happy with the 
>standard 0x1FF flags that Samba returns, but does not like it when 
>Sign&Seal is in force and simply stops communicating at that point.

Right, there are two issues here, which can be confused by the definition
of the "secure channel". In Luke's book, the "secure channel" refers to 
the DCE RPC authentication flavour that is negotiated when SignAndSeal
is enabled, and the normal NetLogon exchange is referred to as the 
"NetLogon credentials chain". Microsoft use the term "secure channel"
to refer to both these, as will I below.

- if SignAndSeal is enabled, then the NetrReqChallenge() and some variant of
  NetrServerAuthenticate() are used to negotiate a session key, and subsequent
  NETLOGON RPCs are made over a new RPC connection with the rpc_c_authn_netlogon
  flavour (a client identifier is passed in the BIND PDU so that the server 
  can look up the previously negotiated session key)

  Note that SignAndSeal exists on NT 4 (post SP4) and Windows 2000 machines and
  can be disabled via a registry setting. For the purposes of our testing, we
  have disabled it.

- Windows 2000 clients call NetrServerAuthenticate3() over ncacn_ip_tcp 
  when establishing the secure channel (which may or may not be SignAndSealed
  depending on registry settings) which is used for, amongst other things,
  PAC validation. It appears that by sending the 0x0007ffff flags the 
  client is indicating that a different algorithm was used to calculate the
  authenticator, which is sent in the NetrServerAuthenticate3 request PDU.

  It appears some bits are used to indicate that a Kerberos (rather than SAM)
  logon should be attempted.

>That 0x6b flag looks important, because I seem to recall that it was the 
>flags sent or returned by WinXP. Perhaps the AD client ignores the lower 
>bits when Sign&Seal is in use.

I haven't seen this, probably because I don't have WinXP. :-) But I have 
seen 0x0007bfff from Win2K.

regards,

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