On Sun, Dec 12, 2004 at 05:21:59PM +0100, Jelmer Vernooij wrote:

> | is it possible to convey the security context that has been established
> | up until that point?
> Not yet, currently the whole thing is root-accessible-only. We do
> actually do auth over it, as does Windows (see
> http://msdn.microsoft.com/library/de...ng_binding.asp).


okay: there's a way to test what windows does.

1) write a simple MSRPC service and make it register on ncalrpc.

2) write a second MSRPC service that calls a function in the first
service.

3) in the service 1), call the ImpersonateRPCcontext function - or
whatever it is, and then either attempt some function that is known to
be restricted, or obtain the username and print it.

4) run service 1)

5) log in as an ordinary user, and run service 2)

6) log in as an administrator, and run service 2).

if you find that as 5) the username (or operation) is done as an
Anonymous User (the operation fails) then you can conclude from the
experiment that ncalrpc on windows is similar to the ncalrpc on samba
4.

if you find that the security context is carried over - namely that as
5) the operation fails, and as 6) it succeeds (or you get the ordinary
user printed out in 5 and the administrator printed out in 6) then you
can conclude from the experiment that ncalrpc on windows is similar to
the ncalrpc transport of samba tng.


NOTE THAT I DIDN'T SAY THIS:

2a) in calling the function in the first service, obtain the current
security context and make an authenticated connection to the first
service using the current security context.

... you see - the difference is very significant, yes?

in the samba 4 environment, you must *explicitly* carry over the
security context, thereby incurring performance penalties, and in the
samba tng environment, the security context is *implicitly and
automatically* carried [securely] between two services.

hope this helps,

l.