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

Luke Kenneth Casson Leighton lkcl at
Tue Dec 28 20:37:47 GMT 1999

On Tue, 28 Dec 1999, Nicolas Williams wrote:

> On Wed, Dec 29, 1999 at 06:47:29AM +1100, Luke Kenneth Casson Leighton wrote:
> > > 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)
> > > 
> > 
> > no, because:
> > 
> > 1) this has security implications for people who join their own samba
> > server to a domain, and people start relying on the SIDs being for a
> > particular server, and then they get changed????
> > 
> > 2) if you specify a different SID base you then exclude the users in the
> > domain you just changed it from.
> So? Those SIDs had local meaning only anyways. If those SIDs were reused
> on NT filesystems then the worst you do is orphan those SIDs in those
> files' ACLs.

ok.  so let's say you have a local user on a server.  you want to grant
that local user the rights to use a specific file on another workstation.

the local user log in (not to the domain, but to the local workstation).
they access the file, the SD is found to conain a SID with a remote
workstation's SID on it, and the remote workstation is asked to resolve
the SID to a pretty name.

this is acceptable (allowable) behaviour.

using the algorithmic mapping system in 2.0.x, you can't get this kind of
granularity / behaviour.

> And for new installations this is not a problem. So the option would be
> nice. Could an administrator use it to shoot him or herself in the
> foot? Sure. But that's true in worse ways now (e.g., setting up a Samba
> server as a PDC for a domain with an existing NT PDC). So for
> consistency's sake it's not a bad idea to givem more rope...


More information about the samba-technical mailing list