Security Identifier (SID) to User Identifier (uid) ResolutionSystem

[Luke Kenneth Casson Leighton]

On Tue, 28 Dec 1999, Jeremy Allison wrote:

> Ok, let me explain *why* I am fighting tooth and nail to
> keep Luke's SID mapping table out of Samba.
> 
> It is simply the wrong place to put such a thing.
> 
> If we step back and look at the actual problem we are
> trying to solve, then we see that hacking Samba with
> mapping tables is the wrong approach.
> 
> The problem as I see it is that people want to have
> a common account database between NT and UNIX systems,
> with only one place to update to add/delete users.
> People want to have only *one* user or group identifier
> to uniquely identify a name. NT uses RIDs relative to
> a domain SID, POSIX uses uid and gid numbers.

this is why i propsed the auto-population algorithms.

> If we adopt Luke's mapping table approach then we have
> not acheived this goal, as creating a table to map particular
> SID entries to POSIX uid/gids allows an artificial unification
> between the NT and UNIX databases, but there is no *real*
> unification.

correct.  unfortunate, and correct.  we just have to live with that.

> If someone updates the NT account db, or the
> UNIX one, without editing this mapping file, the admin is
> hosed.

adding to the NT account db or the Unix one is fine.

modifying the NT account db or the unix one (moving uids and SIDs around)
is HOPEFULLY a known security risk to admins, particularly those in a
security-conscious environment, so they won't attempt to reuse SIDs or
uids.

if they _do_, then yes: they're screwed.

> This is not a scalable or workable solution.

as outlined in the opening paragraphs of the auto-population section,
which is why i propose auto-pop.

> IMHO the correct way to approach this problem is to
> actually unify the account databases. If we do this
> then the arguements between SID -> uid/gid mapping
> just go away, as the accounts *really* only exist in
> one place (the NT SAM db).

ummm... not quite :)  you still need to choose a local POSIX uid/gid (i
take it you're talking about appliance mode, here), so you _still_ need a
SURS table.  _or_, you attempt to implement NT file security, which you
can't actually do without a POSIX uid to map to (even temporarily), as you
get race condiutions if you attempt to create a file and then set
permissions (as root).

> Unfortunately the account db has to be held in the
> NT format (although not neccessarily on an NT machine)

weelll... it only has to be _+presented_ in NT-format, and the external
presentation is MSRPC, and we already have a 99% complete implemtation of
\PIPE\samr, so that's no problem: all we need now is a comprehensive
password db api im,plementation.

> as MS don't release enough information to replace the
> authentication and authorization code on NT. On UNIX
> however, we have PAM (for replacable authentication)
> and nsswitch (for replacable authorization - ie. enumerating
> user and group lists).

i know enough about NT stuff to know what to do, and on unix.  i'm still
following you, here.

> Now imagine that we write the winbind daemon on
> UNIX systems with nsswitch. Quick update for people
> who haven't followed samba-technical for a bit - 
> winbind is a nsswitch module for UNIX systems entered
> into an NT Domain that allows *all* user/group lookups
> to be remoted to an NT-format PDC or BDC. ie. when 
> getpwnam() is called a lookup is done to a PDC or BDC
> and a UNIX struct passwd entry is synthesized from the
> SAM database entry returned.

yess :) fantastic.

> This synthesis includes
> mapping from the SIDs returned in the SAM db entry to
> a UNIX uid and gid list for the user. Note that as a 
> UNIX machine can only be in one NT domain then we can
> take the NT RID directly as a 32 bit value from every
> SID and use it directly as a UNIX uid_t or gid_t (on
> 32 bit uid_t and gid_t UNIX systems).

ok.  again, exactly the same problem applies to winbind as it does in
samba.

someone needs to make the decision about how to _create_ SIDs, and someone
else needs to make the decision about how to map SIDs to uids/gids.

the synthesis you describe above is one possible implementation.  that
implementation sufferws from exactly the same limitations that samba 2.0.x
has, because you are confusing (i think) the role of SID creation with
SID/uid mapping in exactly the same way for both samba 2.0.x and winbind.
 
> *THIS* is the correct place to do the SID -> uid/gid
> mapping, not Samba. And when you look at the problem
> this way, with the correct abstraction layer, suprise,
> suprise, it becomes very easy.

not really.

> Once we have this then it makes perfect sense to have
> a completely unified SID/uid/gid space, as this is what
> we actually have.

unfortunately, not quite.
 
> Given a working winbind, when Samba is queried for ACL entries
> it can then be set up to create SIDs in the ACE entries
> that are *actual domain SIDS* in the NT domain. ie. we
> will know that for uid/gid's > 1000 that these are actually
> domain RIDs, which should be prefixed by the domain SID
> in which the Samba server has been added as a member
> server. For uid/gid's < 1000 we know that these are really
> users that exist in the local /etc/passwd database, and
> so they must be prefixed by the local machine SID.

oh no.  you thinjk that by creating winbind, we can optimise uids/gids /
RID lookups?

no.  please.  if you start thinking that's acceptable, you're _really_
going to mess this up and continue to argue with me about this.
 
> ie. Luke - the above is the only way you can conclusively
> distinguish between local and remote users on POSIX, when
> you know you're talking to an authentication source that
> actually does so (an NT PDC/BDC).

ah.  i begin to understand where you're coming from, now.  it's a very
broken concept, but at least i begin to understand.  i will have to think
about this.  i still have a lot more work to do to describe how SURS
tables work to _really_ solve this problem.

> SAMBA IS NOT AN OPERATING SYSTEM.
> 

someone asked me this, recently.  "at what point do you start to consider
samba to be an OS?" :)_