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

[John E. Malmberg]

> On Fri, 24 Dec 1999, Luke Kenneth Casson Leighton wrote:
>
> http://www.cb1.com/~lkcl/cifs/draft-lkcl-sidtouidmap-00.txt (and .html)

The first issue that comes to mind is that it defeats a "Security Feature"
that Microsoft Implemented as part of it's SID structure.

A SID generated for a group or a user is guaranteed unique for all time,
never to be seen again.  No reuse.

If a user or group is deleted, that SID is also gone, never to be seen
again.

This is guard against a new user or group inheriting unwarranted access from
the reuse of a user identification number.

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.

A few years later, the Group number is reused for E-mail accounts for
non-privileged mail runners and other gophers.  And someone gets a surprise
when they poke around.

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.  And as another thread recently covered, it is not good
publicity for SAMBA to be associated with this type of a security problem.

The press is never really interested in the details or the true guilty
parties.  The boss is not either, and the person telling the story to him
may have a vested interest in deflecting blame.


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.

Automatically generating these SIDS should be easily done, either by keeping
track of the last SID generated by the authoritative server, or possibly
encoding the current date/time down to the second as part of the SID.


Automatically generating a POSIX account and UID based on a SID generating
an NT system has it's own problems.  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.

While the ideal case is that you can start out with a clean security policy,
in most cases the reality is that you will be given the task of reconciling
the POSIX and NT security environment where at least one or more of them is
already populated.  And in many cases not by someone who did any advance
planning.

The solution that I would recommend on creating the POSIX accounts is to
ignore the value of the NT SIDs entirely.  Instead use the named NT group
membership of the account to determine how to create the POSIX account.

A database that maps NT groups to Posix groups could be a useful aid in this
conversion.
Or some global parameters in a config file or script can be set to identify
what NT groups correspond to what POSIX security groups.  A priority list
parameter can be used to resolve what primary GID the POSIX account can be
generated when the NT account is a member of more than one group.

NT has the concept of a primary group designation for POSIX purposes, and
this designation is ignored under the NT ACL security.  SAMBA might be able
to take advantage of this for deciding what Posix GID to assign to the
account.  However it may be prudent to for the design to allow for the case
where the NT primary group can not be used.

So designating the GID automatically is basically no problem, and most
sysadmins that I am aware of have scripts for adding accounts that
automatically generate a unique UID values, along with creating the home
directory.  It is this sort of script that SAMBA would need to invoke,
passing the other parameters.

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.


As a practical example:

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.

A host based script uses Pathworks to dump the members of selected groups.
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.

-John
wb8tyw at qsl.net