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

Michael Stockman pgmtekn at
Thu Dec 30 02:01:03 GMT 1999


I've tried to follow this discussion and have written a lengthy mail
this afternoon on the topic that I will save you from reading :) I'll
keep this short.

As far as I can see the algorithmic solution is good for all users
samba accepts that belong to samba's SAM (implemted in smbpasswd,
LDAP, NIS or whatever). However it seems to me that this is not the
case when samba is supposed to accept users belonging to a remote SAM.
In that case samba must be able to obtain SIDs from the remote owner
of the user (or possible store SID previously obtained).

An example of how I would imagine the relevant fields in a smbpasswd
[POSIX uid]:[NT name]:[NT owner]:[RID]:...

[POSIX uid] is the uid on the local system.
[NT name] is the name the user is known as in NT world
[NT owner] is the SAM owning the NT user (which may be the local
server or a remote server/domain)
[RID] is optional but could be used if a very stable RID usage is
desired (probably only for accounts owned by this SAM)

If we are sent a SID or a DOMAIN\USERNAME pair this could always (as
far as I can see) be combined into sufficient information the resolve
any remote host to authenticate against and POSIX uids on the local
machine (if the user is properly defined).

I feel that this is the basic required information and samba should
need this in any case. Doing it this way should minimize the amount of
tables that need to be maintained (smbpasswd et al., domain user map,
local user map, SURS tables etc) down to one, possibly two if groups
cannot get entries in smbpasswd (eg through a group flag in the ACB
I don't think samba can work without a smbpasswd file of some kind
without loosing compatibility with all passwd based systems (or making
huge assumptions about them). I consider smbpasswd/LDAP/NIS*/mysql
solutions equivalent (and refers to them as smbpasswd because that is
what I've got).

Best regards
  Michael Stockman
  pgmtekn-micke at

More information about the samba-technical mailing list