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

[Nicolas Williams]

On Tue, Dec 28, 1999 at 02:34:36PM -0800, 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.
> 
> 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. If someone updates the NT account db, or the
> UNIX one, without editing this mapping file, the admin is
> hosed.
> 
> This is not a scalable or workable solution.

Oh, but that's the thing. For some ppl it IS!

To wit:

 - Microsoft includes a NIS server with w2k that makes lookups via LDAP
   into ActiveDirectory. The account/principal/uid/sid/whatever
   information is all in one place.

 - Luke Howard's XAD project would yield an ActiveDirectory work-alike.
   So the same thing goes for it as for the MS NIS server I just
   mentioned. Samba would be a big piece in XAD, at least some of the DC
   functionality in Samba would find it's way into XAD.

 - I work with a namespace management tool that is name service
   independent and scales very, very well to very large organizations
   and which can master NIS, DNS, LDAP, whatever namespace data. All in
   one place.

So, make the feature available through some shared lib system as I
imagined in a previous email and let the ppl use it who can provide
the necessary SAM/NIS/whatever consistency.

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

Bingo. ActiveDirectory, XAD, or namespace management tools layered ontop
of other name services.

> Unfortunately the account db has to be held in the
> NT format (although not neccessarily on an NT machine)
> 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).

Again, see the XAD effort.

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

Or PAM_LDAP. Same thing. With win2000 you get an LDAP interface to
ActiveDirectory.

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

Ok, yes. But we're not there yet. The namespace-management-tool-
layered-ontop-of-existing-name-services is workable today, at least for
me. Thus my interest in Luke's initiative.

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

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

> 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).
> 
> Rather than working on adding this mapping to Samba,
> we *should* be working on winbind, which will solve
> this problem tranparently to Samba and as a seperately
> maintainable component.

Yes. XAD. But since XAD plans to borrow from Samba...

> Then the people who want this unification can run winbind,
> and those who prefer to keep Samba serving out existing
> POSIX uid's can just run Samba and we don't keep adding
> more (unneeded) functionality into Samba.

Right.

> I think the moral of this story is :
> 
> SAMBA IS NOT AN OPERATING SYSTEM.

No. It isn't. Neither is ActiveDirectory. It's just a name service. The
interface I proposed is just like an API to a nameservice. You want that
to work via the NSS, but there are no NSS calls that involve SIDs. Thus
the need for a new API, for now one that's external to the NSS.

> :-) :-).
> 
> Jeremy.
> 

:)

We're getting somewhere now! :)

There really is no argument here. Is there?

Nico
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.