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

Jeremy Allison jeremy at
Tue Dec 28 22:34:36 GMT 1999

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

This is not a scalable or workable solution.

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

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

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

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

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.

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.

I think the moral of this story is :


:-) :-).


Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.

More information about the samba-technical mailing list