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

[Luke Kenneth Casson Leighton]

On Sun, 26 Dec 1999, John E. Malmberg wrote:

> In the SURS database, allong with the UID and SID keys, you need a way of
> mapping the SID to the domain that issued it.

yesp.  this is an implementation-specific issue.  when you establish a
trust relationship, you obtain the SID.

the implementation of LsaLookupSids therefore resolves remote SIDS on your
behalf (as an NT client), using a table with SID/Domain name entries in
it, as you describe below.

i'm glad to see that you're actually thinking about these issues, john -
you're coming up with exactly the same stuff i did, whci is very
reassuring.

luke
 
> Probably best in a separate table to save space, with the two keys.  After
> all you need the text domain name to do the network look up for the text
> name that goes with the SID.
> 
> 
> 
> Luke Kenneth Casson Leighton <lkcl at samba.org> wrote:
> 
> I seem to have missed some concepts of what you wrote on the first pass.  I
> think we are in aggreement in general purposes that a database is required
> for this.
> >
> > >  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?
> 
> Re: Proposal: Good Neighbor Policy.
> 
> The issue of if SAMBA should take extra steps to make sure that an
> inexperienced SYSADMIN does not cause a problem on a corporate network so as
> not to hurt SAMBA's reputation.
> 
> >
> > > 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.
> 
> A re-read of it confirms that there is a disclaimer to that effect built in.
> 
> However the subject is discussed in it extensively as building your case for
> the SURS database.  It really is difficult to separate the two subjects.
> 
> It actually seems that more of the document is discussing the ways to
> generate the mappings than the actual implentation of the SURS database.
> 
> Without a SURS database, you are limited in what policies are used.  With
> the SURS database, much better flexability is built in.
> 
> However to really take advantage of it, the SAMBA server needs to be able to
> deal with ACLs on the files.
> 
> Otherwise the main benificiaries of this could be SMBMNT and SMBCLIENT.
> 
> Oh, yeah I forgot for a moment about domain trusts.  The SIDs used in them
> must play by Microsoft's rules.
> 
> > 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.
> 
> In section 5. Automatic SURS Table Population:
> 
> The implication from the document is that the SID of
> (S-1-5-21-domain1-100501) would be mapped to the uid (501).
> 
> It is only later in the document that the problems inherent with this
> approach are pointed out.
> 
> 
> > >  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".
> 
> In the PATHWORKS product, there is an account known as PWRK$DEFAULT that
> handles this.  It is for remote access where the user never needs any direct
> access to the host system.
> 
> This is not a guest account, as it requires the user to have authenticated
> credentials that a guest account does not.
> 
> It does require that the server keep track of the security permissions
> separately from the host operating system.
> 
> 
> PATHWORKS also has it's own ACL/ACE security mechanism that is grafted on
> the host operating system.  This can be an anoyance because when you check
> the security on the file from the host operating system, all you get is a
> line saying that there is a PATHWORKS ACE on the file.  You have know idea
> at this point on what rights that ACE grants.  You must go into the
> Pathworks Administration utility to view what rights are assigned to the
> Pathworks user.
> 
> Native host security can optionally be used.  If so, then those users will
> also be restricted to access explicitly granted by the operating system to
> the PWRK$DEFAULT or the actual host UID that is mapped to their account.
> 
> This could be going off of the topic as it relates as to how the SAMBA
> server would use remote SIDs instead of how they should be mapped and
> stored.
> 
> > 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.
> >
> 
> This is a possible point of confusion.  The document references methods used
> to map uids to SIDS, and their advantages/disadvantages.  But it also
> references a mapping table otherwise known as a SURS database.
> 
> It is virtually impossible to separate the two concepts if you want to play
> by the rules that Microsoft has implemented, and still survive in an
> existing POSIX security domain.
> 
> So in your document you are specifically taking the stand that such a
> database needs to exist, but leaving it for a future document as how to
> populate it.
> 
> And the issue of how to deal with mapping the ACEs to the host operating
> system security is also not really at issue there, but some convention
> probably needs to be addressed.
> 
> This is something that I have been trying to figure out how to do correctly
> on an OpenVMS system.
> 
> >
> > > 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.
> >
> >
> > 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.
> 
> The concept of SIDs are not in OpenVMS.  The security model is basically UID
> based.
> 
> I assume that you meant ACE/ACLs.  They both have them.  There are
> differences in their implementation that can cause the unwary great pain.
> This may also be the case if there is an attempt to map NT ACLs to UNIX ACLs
> for those flavors that support them.
> 
> The rights Identifiers added to OpenVMS are really UIDs in a range that can
> not be assigned to real users.
> 
> -John
> wb8tyw at qsl.net
>