outsourcing DCE/RPC to alternate programs - runtime config option

Sun Dec 12 22:39:31 GMT 2004

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Luke,

Luke Kenneth Casson Leighton wrote:
| On Sun, Dec 12, 2004 at 07:50:22PM +0100, Jelmer Vernooij wrote:
|>Luke Kenneth Casson Leighton wrote:
|>| On Sun, Dec 12, 2004 at 05:21:59PM +0100, Jelmer Vernooij wrote:
|>Why not negotiate
|>once again, just like you would've done with external (non-local)
|>connections?
|  because in the case of NT authentication, that's really expensive!!
Granted, there might be a little more requirement for optimizations then
I originally thought. See below for some proposed possible solutions.

|  plus, if you're using a security-context-inheriting implementation of
|  ncalrpc as an inter-server communication mechanism between the
|  components _of_ the NT authentication mechanism (which is what i do in
|  samba tng for netlogond, lsarpcd and samrd), then you are stuck.
See below - I don't really consider this much of an issue.

Not necessarily - what samr calls strictly need to run as root? SAMR is
mostly
just a custom database.

|  you _really_ want each service to contact the PDC?  *gibber*!

|>(one could negotiate a very simple low-cost mechanism).
|  such as having a root-only-accessible credentials cacheing mechanism,
|  to deal with the scenario outlined above?
|
|  ... mmmm... there's a place where that information can be stored - in a
|  structure associated with the connection, and in FreeDCE there's
|  already some places which can do that, along with a fully supporting
|  API that caters for exactly this purpose!!
The issue here is really how to efficiently authenticate an incoming
connection from smbd in the process it is outsourcing data to. I'm by no
means an expert in CIFS/RPC/Samba's authentication system, but I'm
thinking of something like:

~ - Having a new DCERPC_AUTH_TYPE_SAMBA that just receives the username
of the NT user and takes it for granted if the receives it from a
process owned by the same user
~ - Doing caching in lsarpc / samr / netlogon - not sure where this
happens and always using the local instance of an interface to verify
credentials (which can then ask the DC if necessary) rather then always
asking the DC.

Though no doubt others in the team with more experience in this area
have better ideas.

|>If optimisation is very important (and you don't care
|>running as root), you could always compile your interface implementation
|>as a plugin and load that into smbd.
|  ah, no - definitely not.
|
|  that's _exactly_ what _can't_ be done.
|
|  FreeDCE is a completely different runtime environment from
|  samba (it's more complete and better understood, for a start -
|  note i didn't say more secure / less able to deal with buffer
|  overrun attacks!)
|
|  it'd be a god-awful job to have to ask people to understand and code
|  for both the samba 4 _and_ the FreeDCE runtime environments.
|
|  it's just too much to ask.
Why would one want to use FreeDCE when you're already using Samba 4?
What does FreeDCE that Samba4 does not? Samba 4 provides for an endpoint
mapper, for example.

I can understand you would want to use FreeDCE in combination with Samba
when using Samba completely without RPC subsystems and just for the
ncacn_np transport, having FreeDCE provide for the endpoint mapper, etc.

|>|  if you use the samba tng ncalrpc implementation, then you dig up the
|>|  (vuid and pid) index associated with the netlogond, initiate a
|>|  connection to the samrd using that (vuid+pid) to indicate to the samrd
|>|  that it should use the same [root] security context that netlogond is
|>|  presently running as, and netlogond will successfully convey its
|>|  present security context over to samrd with an absolute minimum of
|>|  effort.
|>|
|>|  have you considered this issue?
|>I think it makes things more complex then they have to be,
|  that's what andrew said, in 2000.
My problem with this solution is that it is a bit ad-hoc. Where are you
going to get the vuid+pid when the connection came in over  TCP/IP or
UDP/IP? With remoting you would get a nicer solution, almost for free,
eventually combined with one of the two solutions mentioned above.

This way ncalrpc(tng-ncalrpc) becomes something that smbd can use to
'outsource' interfaces. Other local non-root utilities can't talk to it
directly and root utilities will have to construct the blob somehow. In
order to connect to such interfaces they'll have to talk to smbd which
forwards their data to the specific interface implementation.

|   by not having a security-inheriting ncalrpc mechanism, you can't
|   realistically use DCE/RPC at all to implement the inter-server
|   communication mechanism between netlogond, samrd and lsarpcd.
|
|   in other words, you are forced to design and use your own
|   APIs: you can't use the APIs that are already designed for
|   the job [the netlogon API, the samr API and the lsa API!!!!]
|
|   well you can, but you have to bypass the DCE/RPC bits.
|
|   in other words, by making the decision that you have, you end up,
|   for "simplicity", putting all netlogond samrd and lsarpcd into one
|   single monolithic program.
I don't consider that much of a problem at all - what is the issue with
implementing 3 interfaces in one daemon? We're not trying to build an
exact copy of windows - we're building network services compatible with
Windows on a POSIX-compatible operating system.

Wine and ReactOS are more or less clones of Windows while Samba tries to
be compatible at network level - Samba's design doesn't need to be a
clone of Windows' design nor can it be - we have to make sure we can
work with and map to POSIX. Sure, there are various parts that are
similar to Windows because we're talking the same protocol but it's not
a copy, just another implementation of the network protocol.

|   by following the example laid down by NT, and emulating what i
|   believed the underlying infrastructure to be, i was able to simplify
|   the design and implementation of the NT services.
|
|   ... for example, the trick about implementing a msrpc_netlogon_auth()
|   function that accepted "\\." as a shortcut to use ncalrpc rather than
|   ncacn_np meant that the same code that did "security = domain" could
|   also be used for "security = user".
|
|   _and_ the same code could be used for inter-domain trust account
|   authentication.
I think that's a really neat trick - though it does not require what you
are proposing.

|>it can support multiple interfaces at one endpoint. And it can forward
|>endpoints to other endpoints.
|  ah ha.
|
|  that's what rich was referring to about the udp forwarding trick, yes?
Yes, if you mean s/rich/tridge/ and s/udp/RPC transport/ :-)

|  bearing this in mind, perhaps people will appreciate exactly
|  _why_ i started adding into the samba tng msrpc libraries the
|  ability, just as NT does, to "cache" and reuse both SMB IPC$
|  connections, MSRPC connections and ncalrpc connections.
|
|  that's why NT maintains SMB IPC$ connections (see output of NET USE
|  after logging in to an nt domain).
|
|  if you want to prove to yourself that it has an effect, on the PDC run
|  service control manager, examine the connections being held to the PDC,
|  kill them off and then try doing something on the domain member
|  workstation (e.g. accessing a second domain workstation's files as a
domain
|  user).
|
|  the operation is delayed until the SMB IPC$, and the NETLOGON
|  connection _over_ the SMB IPC$ connection, is reestablished.
|
|  try reconnecting to the second domain workstation _without_ killing the
|  first workstation's connection to the PDC and the connection is made
|  much quicker.
Samba 4 supports this - it can make secondary RPC connections of one SMB
~ connection.

Cheers,

Jelmer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBvMiiPa9Uoh7vUnYRAnG7AJ9mf6FH6boTWcaYwvi+9Mv+DZN3qgCfTDiN
4mt0JQumG70x9h7UIae+70k=
=hbhn
-----END PGP SIGNATURE-----