Mapping of RIDs to uid_t and gid_t

Luke Kenneth Casson Leighton lkcl at switchboard.net
Fri Apr 3 14:39:33 GMT 1998


On Fri, 3 Apr 1998, Jeremy Allison wrote:

> I have been doing some thinking of late on the
> mapping of UNIX uid_t's and gid_t's to NT domain
> 32 bit RID's. Here are my thoughts so far.
> 
> Comments are welcome, as I'm going to be coding
> these up for Samba soon :-).
> 
> The problem:
> 
> The last component of an NT SID is a 32bit
> unsigned 'RID' - or relative ID. Both users
> groups, aliases (whatever *they* are :-) and
> machine accounts in an NT SAM map into this
> space, and NT has some 'well known' numbers
> that must be the same across different domains 
> - they're hard-coded into the include files for 
> NT (just to be helpful :-).
> 
> The possible different types of RID are :
> 
> User, Group, Domain, Alias, WellKnownGroup,
> Deleted, Invalid and Unknown.
> 
> The 'well known' numbers are:
> 

> Well known group id's
> ---------------------
> 
> Administrators - 544
> Users          - 545
> Guests         - 546

these are domain groups
 
> Well known aliases (what *exactly* are these ?)
> -----------------------------------------------
> 
> Administrators  - 544
> Users           - 545
> Guests          - 546
> Power users     - 547
> Account operators - 548
> System operators  - 549
> Printer operators - 550
> Backup operators  - 551
> Replicator        - 552

these are _local_ machine groups.

when you do a lookup on a stand-alone NT server (LsaQueryInfoPolicy) that
is a member of a domain, and you look up level "3", you get back the SID
of the domain that that computer is a member of.

when you do a lookup at level "5", you get back the SID of the _machine_.
the _machine_ has its own local "domain", if you like.

the well-known aliases apply to these "local domains", whereas the well
known groups apply to the "remote domain".

does that make sense?  does anyone agree / disagree / know better / can
explain this better?  mr john terpestra, any ideas / comments?

luke



More information about the samba-technical mailing list