[samba-tng] status

[Luke Kenneth Casson Leighton]

ok.  the results back from the very first rpctorture test, an ntlogin 100
times, showed that it was essential to reuse connections.

the "logintest" command, tested like this:

bin/rpctorture -S samba_thg-srv -U root%password -l log
[root at samba-tng-srv$ ] logintest -o 100 DOMAINNAME\username password

is quite a comprehensive test.  it does:

- a root%password-based connection to the local machine (which happens to
also be samba-tng-srv) to \PIPE\lsarpc to obtain the local copy of the
trust account password.  this connection is then closed, because it's
policy-handle-based.  lsa_open_policy("\\samba-tng-srv",..),
lpsa_open_secret(), lsa_query_secret(), lsa_close(secret_hnd),
lsa_close(pconnection_hnd). the last close reduces the connection-count
on \\samba-tng-srv and the connection is closed automatically.

- a root%password-based connection to the remote machine to
\PIPE\NETLOGON, over which the login - to samba-tng-srv - is carried out.
netr_* - e.g NetrSamLogon - is _not_ policy-handle-based, therefore the
connection is _not_ terminated, it is persistent.

herein lies the problem.  _each_ ntlogin test was carrying out a _new_
connection, from the same rpctorture process, to the target smbd process.
_each_ \PIPE\NETLOGON was creating a new netlogond (through smbd).
however, there is a hard limit of 64 pipes per smbd process, so the 65th
and subsequent logins failed.

now, i modified the code so that it reuses MSRPC connections.  sounds
simple, huh?  in theory... yes :)

the factors to be taken into ocnsideration are:

1) you can't reuse another user's connections.  that's not on.  if you do
a "net use \\server /user:user1" and "net use \\server2 /user:user2", you
don't expect on NT that the connection to \\server will suddenly use
user2's password!

2) loop-back is distinguished with a name of "\\." from oher server names.
the code must work regardless of the target name, though.

3) smbd and other msrpc daemons accept connections, however they must also
be able to _make_ connections.  if a connection is made as the result of
servicing an _incoming_ connection, the credentials to use to make the
_outgoing_ connection must be picked up from the _incoming_ connection.

4) if an msrpc loop-back connection is reused by multiple user-contexts
from the same smbd process, the user contexts must also not be confused /
reused / ignored.

i am having a really hard time making sure that these user credentials are
kept separate and are distinguished.

it's not acceptable _not_ to reuse connections if the same user context
exists, as shown by the logintest.

the state i am in now is that i can issue msrpc calls that will reuse a
connection.  _however_, when they reach smbd and are redirected to the
msrpc daemon, they cannot be distinguished by the target msrpc daemon from
any other user contexts.

i know what to do, i just really didn't want to have to do it at this
stage.

i basically have to add proper multi-user-context support between smbd and
the msrpc daemons.  it wil be based on the [pid, vuid] key.  it will be a
lookup table.

hmm...  you know... i think i don't need to, i think i just have a bug...

this stuff isn't simple.  and when it's not simple, it worries me.
not-simple things have a habit of coming crashing down on your head by
simply picking at one thread.

i wonder if there's a way to _make_ it simple...


<a href="mailto:lkcl at samba.org" > Luke Kenneth Casson Leighton    </a>
<a href="http://cb1.com/~lkcl"  > Samba and Network Development   </a>
<a href="http://samba.org"      > Samba Web site                  </a>
<a href="http://www.iss.net"    > Internet Security Systems, Inc. </a>
<a href="http://mcp.com"        > Macmillan Technical Publishing  </a>
 
ISBN1578701503 DCE/RPC over SMB: Samba and Windows NT Domain Internals