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

[Luke Kenneth Casson Leighton]

On Tue, 6 Mar 2001, Elrond wrote:

> On Wed, Mar 07, 2001 at 06:04:47AM +1100, Luke Kenneth Casson Leighton wrote:
> [...]
> > ... *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 is exactly, what I've outlined in my
> dbmsrv-paragraph. ;)

oh, okay :)
 
> [...]
> > > 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"
> 
> You mean: Apply the mappings? Right?

yep.
 
> 
> > then put result through NETLOGON authentication.
> 
> That wont work!
> 
> I try to log in as remotedom\elrond, it maps me to
> remotedom\uninterestinguser and THEN tries to ask
> netlogon.
> 
> I don't know the pw for that user!!

you _are_ that user.  it just has several apparent names.
 
> (Remember my big style scenario, you don't want all the
> people in the university to have the same pw, do you? ;-))

> netlogon will fail!

well of course it will
 
> What am I missing?

you're still thinking in terms of many-to-one being allowed different
passwords and different user contexts.

to be allowed access to a unix system, each and every user must have a
unique identity (i.e. a uid).

therefore, there must be a one-to-one mapping between unix and NT security
models.

applying "map username" externally to that is a way to make usernames that
are not in that mapping appear to exist.

e.g. the most sensible entry[ies] to place in "map username" is
Administrator=root and possibly Guest=nobody


i know what you're thinking.  you'd like to map multiple NT users to
single unix users (many-to-one)

for unix-related security reasons, that's a bad idea.

it's what PC netlink (codename cascade) does, in a multi-threaded daemon.

you can get race conditions on file access because of it.

> > 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!]
> 
> Okay, that sounds fine again.
> 
> 
> [...]
> > > 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* :)
> 
> Well... I was thinking about static-linking platforms and
> doubled code and the like and having one central daemon
> dealing with exactly one job.

i  know.  me too.

well, you can static-link to libsamr* with no problems.

as for one daemon dealing with exactly one job, and isolated interfaces
between them: there is circumstantial evidence that microsoft, too, had
this, and they moved away from this to multi-linked, bypassing the DCE/RPC
marshalling/unmarshalling step.

c'est la vie.


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