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

[John E. Malmberg]

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.

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