SURS is not SAM (was Re: FW: Speed comp. TNG & 2.2.alpha (fwd))

[Luke Kenneth Casson Leighton]

> > that's the whole point :)
> > 
> > the SAM database is totally independent.
> > 
> > a finished samrd you could literally recompile on NT and shut down
> > SAMSRV.EXE and run SAMRD.EXE instead.
> 
> If I remember correctly, you would need to replace lsarpc
> and netlogon at the same time, because all three run in one
> single process on NT: lsass.exe, or am I wrong?

... yes, you are correct.

and for exactly the same security reasons that we force netlogond to link
directly with the samr database library, you have to replace all three...

hmmm.

but you get the picture.

> You might mean samsrv.dll? ;)

no, i don't.

although, that is an option, if you get the DLL entrypoints exactly
right _and_ the function parameters.

> > [wait a bit for the implications of that to sink in a bit :) :)]
> > 
> > the only point at which surs should be used is in smbd's
> > reply_session_setup().
> > 
> > when you obtain a NET_USER_INFO_3 by making a NETLOGON authentication
> > [inside reply_session_setup: see TNG's version of this function], you need
> > to translate the NT-style user / group info into unix user / group info.
> > 
> > _that's_ where SURS is involved.  and it is the _only_ place where it is
> > involved.
> 
> No.
> 
> spoolssd.
> 
> printjobs should be owned by the right unix user. ;)

... *thinks* ...

> 
> Okay, spoolssd will inherit its complete security context
> from smbd, including the unix-sec-ctx.

true.  _however_: you are correct.  it is possible to over-ride this when
an authenticated DCE/RPC connection is requested.

which means that *grumpy* two places will be needed.

one in smbd, one... embedded in the dce/rpc code, somewhere.

*grump*.  don't really like that, but there's not a lot of other choice.

you want unix looking like nt?  you want unix-security with an nt
interface?  you want a _consistent_ look to your unix security with an nt
interface?

:) 

> But think of NEW dcerpc-daemons, for example, the db, I'm
> currently working with, has a remote-admin tool, you can
> even fudge arround in the fs remotely with it, or basicaly
> run "add_devspace /work/lotsofdiskspace/db-data", well,
> db-data should be owned by the right user... so the dbmsrv
> needs to do this as the right user, and if it talks
> directly to local netlogond, it wont get the unix-sec-ctx,
> that smbd has made up.
> 
> 
> > now, the debate is, whether to simplify things by doing the "map username"
> > on the NT-style user/group info *BEFORE* the SURS translation or *AFTER*.
> > 
> > the difference is very significant, as one way is very simple and
> > efficient and after-surs-translatnion is utterly horrible.
> 
> 
> While the before-SURS has some other horrible complex
> stories...

urrr.... i think you may be thinking of the wrong thing.

take entries in "map username".

take smbd sesssetupX request username and domain name.

put through "map username"

then put result through NETLOGON authentication.

then put NETLOGON result through SURS to get uid and gids from user-RID
and group-RIDs all concatenated with the domain SID which is implicit, 
[and don't forget other-SIDs!]

> > 
> > well, i considered allowing netlogond to IPC.  but that's not exactly very
> > secure.
> 
> hehe... I do remember... I once was requesting this
> somewhat, because I didn't want to see netlogond linking to
> libsamrpass.so. ;)

*sigh*.  yeah.  but it hammers the ncalrpc interface for not exactly a
good reason.  *sigh* :)

luke

 ----- Luke Kenneth Casson Leighton <lkcl at samba-tng.org> -----

"i want a world of dreams, run by near-sighted visionaries"
"good.  that's them sorted out.  now, on _this_ world..."