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

[Nicolas Williams]

On Wed, Dec 29, 1999 at 06:39:51AM +1100, Luke Kenneth Casson Leighton wrote:
> On Tue, 28 Dec 1999, Nicolas Williams wrote:
> 
> > 
> > Luke/Jeremy,
> > 
> > The algorythmic mapping of uids/gids<->sids in Samba works fine as it
> 
> well... not really.  it's very brain-damaged.
> 
> 1) it excludes S-1-5-32 so you can't map any BUILTIN groups such as
> Administrators and "Account Operators" etc.
> 
> 2) multiple samba servers as members of the same domain need
> same-user-name-same-smbpasswd locally on each server, and they _still_
> produce different SIDs for the same damn username, which i am sure is a
> security risk, i just can't think it through clearly, it's that brain-dead
> and complicated an issue.

Some context here: where I work we have only NT DCs and NT fileservers;
our Unix fileservers also run Samba so that users can access their Unix
home directories and some application-specific Unix directories from
their NT workstations. Thus there is no smbpasswd file here.

So, if you have no Samba DCs and thus no smbpasswd you have no problem.

As for Samba DCs for the same domain generating different SIDs for the
same entity, I see that it works, now, but it's silly. Have a master and
let the others sync to it instead. Of course, that only works if all the
*nix hosts running Samba as members of that domain should have the same
/etc/passwd|NIS domain|whatever so that the same uids/gids mean the same
users/groups on all those *nix servers; otherwise the current scheme has
to be continued.

> > is, except that when looking at ACLs on on Unix files via Samba the
> > usernames and groupnames are shown as <Samba hostname>/<user/group name>
> > on Windows systems. This is annoying if you happen to have standards in
> > place which guarantee that any given uid or gid represent the same
> > user/group on a group of *nix hosts.
> 
> ... which is most unix installations.

... because anything more than a handful of hosts with disjoint
administration domains (i.e., each host has diff passwd/group/netgroup/
hosts/services/whatever) administered by the same staff is _insanity_
and so is having a few hosts per-administrator... at large sites.

> > Two possible improvements over this are:
> > 
> >  - allow administrators to specify a different SID to use as the base
> >    for uid/gid<->sid conversions, such as a domain SID whose domain name
> >    might indicate to users that the SID represents an entity in a domain
> >    of *nix systems (the domain's PDC would have to be a Samba server OR
> >    the mapping algorythm would have to match NT's POSIX subsystem's)
> 
> hmm... interesting.

> >    (Would there have to be trusts between a domain with an NT PDC and a
> >     domain with a Samba PDC for NT clients to be able to resolve SIDs
> >     from the Samba domain to human readable names? I would guess the
> >     answer is "no"; the clients would probably find the Samba DCs using
> >     NetBIOS and ask them to do the SID->name lookups.)
> 
> ok, it depends (i think).  trusted DC sids a PDC is expected to be able to
> do lookups using a _recursive_ call to LsaLookupNames on behalf of the
> client.

> there are situations, however, in which a client will go direct to the SAM
> database of the server that owns the SID.

So, if there is no trust the lookups would be direct? OTOH, how could a
client map a SID to a domain if the client does not belong to that
domain and that domain is not trusted by the client's domain?

> >  - implement SURS
> 
> by definition, both the SURS database and the algorithms are SURS tables.
> it's just that using algorithms is a really bad, restrictive and
> unecessarily restrictive, idea.

Doh. Sorry. I meant a SURS algorythm based on table lookups, rather than
algorythmic mapping.

> > To help in transitioning to SURS it would be nice if Samba would
> > fallback to the algorythmic mapping when there are no valid SURS
> > mappings.

> or better, pre-populate the SURS table database with algorithmic,
> auto-generated SURS table entries.

Ok.

> > Here's some details of the configurationa dn the interface to SURS as I
> > imagine them:
> > 
> >  - a share-wise parameter "guid2sid mapping" whose value is of the form:
> 
> share-wise?  no, it has to be global.  or, if you can get a samba server
> to reconfigure itself to use a different unix password database, you also
> need it to use a different SURS table, basically: that's the only
> circumstances.

Yes, I see.

> >    [path to SURS shared lib] [default]
> > 
> >    If a path is given that should be the path to a library to dlopen().
> > 
> >    If the "default" is specified then the algorythmic mapping should be
> >    used when the SURS mappings fail or if no SURS library path was
> >    given.
> > 
> >    Examples:
> >    
> >     guid2sid mapping = /usr/local/lib/samba/surs-nis.so default
> >     guid2sid mapping = /usr/local/lib/samba/surs-nis.so
> >     guid2sid mapping = default
> 
> hmmmm... i like that.
>  
> >  - a share-wise parameter "guid2sid base sid" whose value is either a
> >    SID, or a NetBIOS host/domain name
> 
> i like this slightly less.

It's the same thing of which you said "hmm... interesting" :)

I can see that you might not like using a NetBIOS name as the SID
reference, as that's not secure. OTOH, you guys did end up adding
automatic DC finding via NetBIOS just the way MS clients do it. Besides,
you could code the search to be based on DNS and SRV RRs, the way w2k is
supposed to do it. Not that UDP-based DNS is secure, but if you're
paranoid enough you can force the resolver to use TCP.

> >  - a share-wise parameter "guid2sid mapping args" whose value is a
> >    string to be passed to the init function of the SURS library.
> > 
> > The SURS library would present Samba with an API consisting of the
> > following functions:
> > 
> > surs_handle *	surs_init(char * arg, sid_t base_sid);
> > surs_handle *	surs_destroy(surs_handle * handle);
> > int 		surs_uid2sid(surs_handle* handle, uid_t uid, sid_t * sid);
> > int 		surs_gid2sid(surs_handle* handle, gid_t gid, sid_t * sid);
> > int 		surs_sid2gid(surs_handle* handle, sid_t sid, gid_t * gid);
> > int 		surs_sid2uid(surs_handle* handle, sid_t sid, uid_t * uid);
> 
> i like this.
> 
> i'm thinking, actually, more along these lines:
> 
> > int 		surs_sid2unix(surs_handle* handle, sid_t sid, gid_t **
> gid, uid_t **uid);
> 
> the reason for this is that SIDs can be mapped to either a uid _or_ a gid.

This is why I had an int return value to specify success or failure+a
reeason. If you try to map a group SID to a user you shuld get an
error. Besides, the code calling SURS should be able to determine the
SID's type.

> > The int return value of the mapping functions is to be used to indicate
> > success or failure and the reason for the failure.
> > 
> > The third argument of each mapping function call is a return value.
> 
> cool.
> 
> > The surs_init() function should probably also have an SMB share
> > connection structure as an argument.
> 
> no, because SURS tables are associated with unix password databases, not
> with shares.

Right. I see that now.

> > Thoughts?
> 
> i like it.

:)

Hell, the current algorythmic mapping functions could probably be
separated into their own .so...

:)

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.