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

Luke Kenneth Casson Leighton lkcl at samba.org
Thu Dec 30 06:14:05 GMT 1999


> > if we use winbind, we can create users in a SAM database, and because we
> > control that SAM, the users in that SAM, when mapped to unix, can be
> > considered to be your definition of "local" posix users, therefore because
> > they are local POSIX uids (whatt you call "real" unix users), this is
> > acceptable.
> >
> > is this a reasonable approximation of your understanding of "real" unix
> > users, and how to create an NT world from a unix one?
> > 
> > i really need to know.
> 
> Nope. You are not understanding me.

no - i'm not!
 
> Consider a UNIX box running winbind to be *identical* to
> an NT server in a domain.

for the duration of this thread, i will consider the hypothesis you
propose.
 
> Any users fetched from the PDC are "domain" users, and
> the RID fetched from the PDC becomes the uid or gid.

ok.  there are actually two SAMs on a PDC.  1) MYSAMNAME 2) BUILTIN.  if
you don't believe  me, do this:  rpcclient -S nthost -U% and at the
prompt, type "enumdomains".  every single NT box returns a list of two
domains.

so, let's assume that you are refering to 1), not 2).  any users fetched
from the PDC's "MYSAMNAME" sam are "domain" users, and you map the RID
directly to the uid.

this scheme automatically aexcludes Administrators, Power Users, Account
Operators right off the bat, but let's assume that this is acceptable, for
now, and proceed...

> Any users fetched from the /etc/passwd database are "local"
> users and the admin must make sure these have values lower
> than 1000 (so as not to collide with the RIDs from the 
> PDC database).

ok, this is also not very acceptable as there may be a pre-existing
/etc/passwd database with uids and files on the local system with uids >
1000, so the administarator would have to chown all these files and chgrp
too.

so we need to provide scripts to help admins to soert out the mess.

> If Samba needs to re-generate SIDs for ACL purposes in
> this system then any uid/gid > 1000 gets mapped to
> DOMAIN-PREFIX-<uid/gid>, and any uid/gid < 1000 gets
> mapped to MACHINE-PREFIX-<uid/gid>.

looks ok to me.

> This is *extremely* simple and is the "minimum neccessary
> change" to allow UNIX to play *very well* in an NT
> Domain environment.

actually, it's a pretty bad way to get unix into an nt domain environment,
if you ask me.

firstly, the target system may not be able to support 32-bit uids / gids.
there are plenty of systems still out there which haev broken NFS daemons
that typecast 32-bit uids to 16-bit and end up mappung 0x10000 to root.

secondly, your scheme excludes the BUILTIN dom,ain.

thirdly, your scheme excludes all trusted domains and all workstation SAM
databases.

fourthly, your scheme limits the number of local users and groups to 1000.

fifthly, your scheme does not provide a distinction, in the RID space
below 1000, between uids and gids.  so what would _actually_ need to be
done would be something like this:

if (RID < 500) it's a uid
if (500 <= RID && RID < 1000) it's a gid.


> No mapping tables needed.

jeremy, two things.  1) it's an algorithmic mapping table.  2) it's also a
means to create SIDS (all uids /gids below 1000).

you are making no distinction btween creating SIDS and
mapping-sids-to-uids.  trust me whne i say that this is a _really_
important distinction, so much so that i added the following to
draft-lkcl-sidtouidmap-00.txt, "introcuction", para 7:

This document does not specify how to generate SIDs associated with
users and groups in a Windows NT-compatible Accounts database (SAM database).
This document does not specify how to generate uids associated with
users and groups for a POSIX-based, or compatible, password database.
This document does not specify or dictate how SIDs are created, or
even whether they should be created, from uids, and vice-versa.


so, it's one implementation of a SURS table, jeremy (plus a SID-creation
system). it's also, if you ask me, not a very good one.  but it _does_
allow a limited representation of local SAM users and domain SAM users,
which i like.



More information about the samba-technical mailing list