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

Luke Kenneth Casson Leighton lkcl at samba-tng.org
Tue Mar 6 10:37:37 GMT 2001


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.

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

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 we're on the subject, could you please explain (in one-syllable
> words, since I'm really a beginner when it comes to DCE/RPC and ntdom
> stuff): What exactly is the interaction between samrd, netlogond and
> the other daemons?

samrd has no dependencies.

lsarpcd depends on samrd [for local-SAM info, otherwise it goes
out-sourcing using remote LSA calls]

netlogond depends on lsarpcd and samrd.

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

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

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.

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

so, instead what i did was linked netlogond directly with sampasswddb.so
which means that netlogonldapd must link with samldapdb.so etc.

why?  because it's not very good to have user-passwords allowed to go over
an IPC connection, even on loop-back, that's why.

if MS decided to disable samr_get_userinfo(level 0x12) then heck, that's
good enough for me!  [level 0x12 obtains user password hashes, btw].


smbd?  smbd _does_ do IPC.  regardless - totally regardless - of the
account, whether it be a local SAM, a remote SAM, an invalid SPAM or a
trusted domain, it always, always calls net_sam_auth() - into the *local*
netlogond.

why?

because otherwise you end up duplicating the functionality behind the
authentication.

and you gain the extra benefit that all authentication can be replaced
behind a standard interface.

want to do a PostgresQL-based SAM database that netlogond will use?

no problem.

want to authenticate against a perl-based program?  sure, why not.  write
your own sam database in perl.

... how about using PC-netlink's DCE/RPC services with smbd to do the file
sharing?

whatever.

no code modifications required to smbd to do _any_ of these options.

cool, huh?

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





More information about the samba-technical mailing list