On Wed, 12 Nov 1997 rlh@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@switchboard.net" > Luke Kenneth Casson
Leighton </a>
<a href="http://mailhost.cb1.com/~lkcl"> Samba Consultancy and
Support </a>