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

[Luke Kenneth Casson Leighton]

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.

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


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

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

> Thoughts?

i like it.