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

[Elrond]

On Tue, Mar 06, 2001 at 09:37:37PM +1100, Luke Kenneth Casson Leighton wrote:
> On Tue, 6 Mar 2001, Peter Samuelson wrote:
> 
> > 
> >   [Peter Samuelson]
> > > > 'guest user' should never be the same as the Unix side of the
> > > > "wildcard" entry in the 'username map' file (or the equivalent via SURS
> > > > or some other SAM backend implementation).
> > 
> > [lkcl]
> > > i'm mentioning this just in case you really think this, but also so that
> > > other people reading this _also_ don't get the wrong impression:
> > > 
> > > SURS is not a SAM database.
> > 
> > Right.  However, it's my understanding that, when complete, the SURS
> > infrastructure will be used by samrd as part of maintaining the SAM.
> > Yes?
> 
> no :) :) it won't :)
> 
> 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?
At least the pipe answers are all lsass (according to
rpc_parse/parse_rpc.c)

You might mean samsrv.dll? ;)


> [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. ;)


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


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...

Either you need to rewrite the whole NET_USER_INFO_3 with
the new name of the mapped-to-user, it's SID, etc.
This gets even horribler, when it comes to Groups, you only
get Group-SIDs (actualy rids), and you would need to
rewrite all of them, and a admin wont like it to have a
sid-map-table...
of couse, we could have a sid-map-cache, that can be filled
automaticaly from text-tables and rules (on demnad)...

Oh well... Guess what, I'm not going to write that.

That's basicaly, what it is all about... Did I miss
something?

[...]
> >  I'm kind of old-school, so I still have trouble
> > separating out account enumeration and authentication, since old Unix
> > implementations (including NIS) do both at once.  I know about PAM
> > versus NSS, though -- are netlogond and samrd similar to this model, or
> > different?
> 
> very similar.
> 
> the only thing is that... well... actually, netlogond is like a
> combination of PAM and NSS, with more emphasis on PAM than NSS.
> 
> samrd is like an instance of an NSS module.

That is, samrd is like "/etc/passwd", or nis.passwd or the
like.


> lsarpcd is like the NSS framework implementation itself: it is responsible
> for calling NSS-like-modules.

lsarpcd is also doing some other jobs, that are somewhat
"unrelated".

For example, it keeps the current "password policy", that
is, "minimal pw length", "pw history depth".

samr on NT uses this info, when you try to change a pw.

lsarpc also manages the Trusts (on w2k all Trusts) and
netlogond uses this info, when doing its job.

lsarpc on NT also keeps the list of "user rights" (this
"May login interactively", "May act as part of the OS"
stuff), and the SIDs, that have these "privileges".


> that's basically it.
> 
> the significant difference is that samrd has read/write - _Totaly_
> manageable, remotely, whereass NSS and PAM are a bit of a pain to manage.

netlogond is manageable too (directly and through lsarpcd).

lsarpc in itself too.


> > Basically, when netlogond, smbd and the other daemons need to look up
> > accounts, do they just IPC over to samrd or do they handle things
> > themselves?
> 
> 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. ;)

[...]
> want to do a PostgresQL-based SAM database that netlogond will use?

Since I'm currently doing some SQL for work, I was actualy
thinking for some minutes to write passdb-postgresql.


[...]
> cool, huh?


Yeah, I like all the modularity.


    Elrond


>  ----- 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..."