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

[Luke Kenneth Casson Leighton]

> An example is a Corporate Auditing Group that is assigned a group number for
> high access for a visiting Audit.  The group leaves and the accounts are
> deleted.  But someone forgets to remove the group from the ACE on the
> sensitive files.

deleted groups and deleted users are actually _marked_ as deleted.  a SID
_cannot_ be recreated except by manually editing the SAM database (with a
registry editor on NT) which is highly discouraged.
 
> I realize that most sites would be expected to keep better records and other
> controls, but the Microsoft method prevents this type of security accident
> from happening.

yes, it does.

>  And as another thread recently covered, it is not good publicity for
> SAMBA to be associated with this type of a security problem.

which thread?
 
> In order for a SAMBA generated user or group SID to behave as expected in an
> NT domain, it must also have a lifetime unique value.  This basically means
> marrying the RID with an always increasing number for each SID issued.  Of
> course that also means that the RID is unique for the SAMBA or POSIX
> security area.

the document i wrote does not cover how Samba (or any POSIX-based,
NT-Domain-compliant system) should generate a SAM database or its
contents.

the document does not describe or cover in any way the security issues
associated with the generation or maintenance of a SAM database.

the document simply covers the mapping of SIDs to uids.

if you think i should make that absolutely clear, please let me know.


> Automatically generating a POSIX account and UID based on a SID generating
> an NT system has it's own problems.

and vice-versa.

yes it does, and i'm trying to outline exactly why the automatic system
used in samba 2.0.x, already released, should be removed and replaced with
a table (cached in memory, for speed of access, if required).

>  The exact SID that the NT will generate
> for a specific user can not be predicted, and as such any automatic mapping
> would have to assume that no existing POSIX accounts with the same UID.
> 
> Therefore, any creation of POSIX accounts or UIDs would need some
> customization for the local security policies.

creation of POSIX accounts is being considered for "appliance" mode.
actually, it would just be "use this UID, don't bother creating an
account".

under these circumstances, it's REALLY important to have a mapping table,
not an algorithm, as the only place that the account name can be obtained
from is the SAM database (uid->SID->lookupaccount(SID)).

but this, again, has nothing to do with the document, which simply and
purely outlines how to map uids to SIDS.
 
> NT has the concept of a primary group designation for POSIX purposes, and

it does?  cool!

> After the POSIX account is created, a local copy of the external NT SID or
> Pathworks SID could be maintained in a lookup database to speed up security
> related functions.

that's the job, the exact job, of the "SURS" table.

> Currently I have an OpenVMS UAF (POSIX UID Compliant) database automatically
> maintained by scanning an NT database.  In this case SAMBA is not used, but
> Pathworks is.  The same principles apply though.

interesting.
 
> A host based script uses Pathworks to dump the members of selectedgroups.
> The members of these groups are compared with the OpenVMS UAF database.  If
> there are new accounts, they are added with the appropriate POSIX group
> based on a priority algorithm built into the script.  If an existing user is
> found to now be a member of a new group, then that group is added .  Then
> the any group memberships that the existing users that hold, that the NT
> users no longer hold are removed.
> 
> While it is not done in the real-time fashion described in Luke's document,
> the basic principles to make it so should not be difficult to implement.

excellent, excellent.  a practical, real-world, pre-existing example, i'm
so pleased.

pathworks, of course, running on VMS.  VMS, of course, being what dave
cutler's team reimplemented (at least, the security model), including the
concept of SIDs.