NTDOM: 1.9.18alpha11

[Luke Kenneth Casson Leighton]

On Wed, 12 Nov 1997 rlh at cppuk.co.uk wrote:

> 
> Dear All,
> 	I have successfully used 1.9.18alpha11 with an NTrigue system
> (NT 3.51 variant) and happily get the "Welcome to the XXX domain" message.

wow!  amazing!  let us know if you can *still* access your system in 
exactly one weeks' time, when the nt clients attempt to change their 
long-term session key password...

> This stuff must have taken a lot of sweat to figure out!

... yep.  and it may not surprise you to know that it's going to take 
man-years to work it all out completely.

> I still can't use "User Manager for Domains" or get user -level sharing
> control to work from Win95 seats though.

i cannot even *begin* to describe to you how many man-months' work it would
take to implement these.  i may be underestimating about the man-months. 

it's DCE/RPC over a named pipe.  i have been kindly informed that DCE/RPC is
documented in: 

<a href="http://www.rdg.opengroup.org/onlinepubs/9629399/toc.htm">dce on-line</a>

microsoft have implemented their own version of DCE/RPC, in particular they
have implemented it over a "named pipe", the named pipe being the "SMB
Transaction" pipe.  once you've read this documentation (which i really don't
want to do: it looks horrendous.  i'll probably be reading it *once* i've
been staring at DCE/RPC packets long enough to have a handle on what the heck
is going on) then you will be aware that this is not even *remotely* the end
of the story. 

[this is beginning to remind me of the bit in "mission impossible", where tom
cruise says, "relax, luther: it's *much* worse than you think"]

the next stage is to decode the "stub data".  that's where it gets really,
really hairy, because it's the main means of communication with the NT 
services.

for example, the pipes identified (and only partially understood) are:

\PIPE\lsarpc

	local security authority rpc.   you do open policy, query info 
	policy to translate a SID into a domain; you generally query
	the status of a pdc / bdc on this pipe.  some of this is
	well documented in Net Monitor.  some of it is not.

\PIPE\samr

	SAM replication.  you contact this pipe to make copies of SAM
	database entries, and to create new ones.  the crucial data is
	encrypted.  further reverse engineering will be required, unless
	microsoft wants to document this for us.

	[some of the samr pipe commands look suspiciously like some of those
	 on the NETLOGON pipe: in particular, the LSA LOOKUP NAMES and
	 LOOKUP RIDS.  this will need further investigation].

\PIPE\NETLOGON

	"workstation / bdc / trusted domain" verification.  this is
	actually quite well documented (you'd think that this was done
	deliberately...) and the rest is not...

	some of the stuff on this pipe is misleading.  if you use NLTEST.EXE,
	available on the MSDN (level 2 and above) NT Server Resource Kit,
	then you will be able to make queries on this pipe, using this
	program, that *shouldn't* interfere with the day-to-day running of
	the primary and backup domain controllers.  after all, it's a test
	and informational querying program.

\PIPE\srvsvc

	Server Service.  you can do "NetShareEnum" and "NetServerEnum" on
	this pipe.  these have their direct equivalents in the SMB Trans2
	IPC$ calls.  no, they are *not* the same: yes, they *do* provide
	*exactly* the same information.

\PIPE\wkssvc

	i *think* this is the workstation trust account pipe.  connections
	on this pipe can be established for days at a time.  if you can
	connect to a server with this pipe, then you have established a
	"trust relationship" with that server.

	i think.

\PIPE\winreg

	remote registry access.  this has been identified and implemented
	by someone else who has contacted us recently.  it was interesting
	to hear that he has implemented his own SMB and DCE/RPC parsing.



the DCE/RPC bind request, and the bind response, seem to indicate that you
also have *versions* of these above-mentioned interfaces.  for example, the
\PIPE\srvsvc is at abstract-interface version 3 (preceded by 16 id bytes,
obtainable from Net Monitor traces).  this method is fully documented in the
DCE/RPC specification, which i had a brief look at when i couldn't work 
out what the heck was going on, here.




> BTW, I found  a couple of nits in the code:
> 
> In the rpc_pipes subdirectory, lint said:
> 
> ntclientpipe.c:
> (124) warning: array subscript cannot be > 1: 2
> (124) warning: array subscript cannot be > 1: 3
> 
> *****                   Methinks SSVAL should be used in place of SIVAL!

you, sir, are absolutely correct.  thank you!

> pipes.c:
> (234) error: identifier redeclared: api_LsarpcSNPHS
> 	current : function(int, int, pointer to char, pointer to char, int, int, pointer to pointer to char, pointer to pointer to char, point...
> 	previous: function(int, int, pointer to char) returning int : "./../proto.h", line 674

[um... that will be a mistake, then, in the auto-prototype generation.  
if you want to correct this yourself, do "make proto".  make sure you have 
nawk or gawk].


richard, thank you for your report: please keep in touch, particularly in 
one weeks' time :-)

best regards,

luke


<a href="mailto:lkcl at switchboard.net"  > Luke Kenneth Casson Leighton  </a>
<a href="http://mailhost.cb1.com/~lkcl"> Samba Consultancy and Support </a>