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

John E. Malmberg wb8tyw at
Thu Dec 30 08:59:00 GMT 1999

Luke Kenneth Casson Leighton <lkcl at> wrote:
> the solution to this is a work-around.  what you must do is make sure that
> even when you have the concept of domains, you must ensure that all
> usernames (NT-space) are flat.  you _cannot_ allow this:
> DOMAIN1\fred
> DOMAIN2\fred
Actually, this situation will cause all sorts of interesting problems in a
PURE MICROSOFT environment.

Much of Windows NT does not know the difference between the two accounts and
will get them confused.

only one "fred" will be recognized in the WINS database, and will receive
all messages directed to either "fred" account.

Large NT sites with multiple domains typically have to assign a prefix or a
suffix code to the username to indicate the domain just to prevent this type
of mess :-)

Most of the arguments presented seem to be getting circular.

The current mapping scheme is adequate for what SAMBA does now.  It only
fails if an NT domain needs to trust a SAMBA PDC, and wants the SAMBA PDC to
play by it's security rules.

Also this SURS table or Trusts are mainly useful for those POSIX systems
that have ACLs built into them.  For those systems that do not have ACLs, it
will be a hard sell.  A very hard sell.

What the trust allows is the sharing of GROUP lists on ACLs for access to
resources.  A user coming from a POSIX system with out ACLS has no list to
share.  An NT user coming in to a POSIX system with out ACLS has nothing
that can understand his group list no matter how it is presented.

The SID is not used to authenticate a user or a group, it is merely a token
for convenience after the authentication has taken place.

With out ACLs, implementing a true trust relationship does not generate much
benefit unless you simulate ACLS on behalf of the host operating system.  I
am very familiar with a program that does it, and I am not pleased with the
way it was done.

I understand why they did it that way, but I think that a better way could
be done, but not inside of the LANMAN server product.  IMHO that is not the
place to do it.  It should be able to translate between the host and client
security model, but not introduce a new layer that requires you to use
multiple tools just to see who has access to an object.

An external tool that uses a SURS database to automagically manage a POSIX
database may be the best way of demonstrating the real good and bad issues
about it.

In my "real world" mapping of NT groups to POSIX Users/UIDs, I only use the
text names, and never a SID to create the USERS.  A SID only comes into play
after authentication, and is only needed for a NT system to participate in a

And I do not just use the DOMAIN name and the remote username, I also use a
subset of NT groups to make the decisions on how to assign the UIDs.  I only
map those users that are in the subset of NT groups that I have designated
for access, all others are rejected.

The tool that I am using in the scripts seems to be similar to the RPCCLIENT
The script also handles deletion of access by disabling users.  auto-unpop.

An unrelated sweeper tool notifies me of dead accounts, so that a proper
cleanup can be done.

More information about the samba-technical mailing list