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

[Luke Kenneth Casson Leighton]

ok, here's the off-line message about how to use auto-pop generation:

jeremy,

been thinking some more about the answer to your last question before i
left for the u.k.  there are two schemes: one actually answers your
question, and the other makes it unnecessary to answer the question.

a reminder: how do you distinguish between uids in a local /etc/passwd
and a remote NIS db, when the implementation of getpwnam() / getpwuid()
or equivalents is designed to hide exactly that from users?

scheme 1 is as i first answered: you have two SURS tables.  one is
maintained manually by the administrator [the administrator also
maintains the /etc/passwd entries, so why not add the extra burden
of maintaining a SURS table, too? :]

scheme 2 is: you don't _need_ to distinguish between uids in local and
remote unix pwdbs (which i refer to as a "hybrid" unix pwdb), if you are
prepared to potentially have one SURS table per hybrid pwdb.

section 3, "definition and uses of a SURS table", paragraph 3, bullet-point 3:

     Identical automatic SURS table population algorithms in use on
     multiple POSIX systems, the use of which MUST result in
     identical entries in the SURS table used by each POSIX system.
     Each table need not be identical, just the entries in each
     table.

let us define a potential auto-map algorithm.  using a table with wild-card
matching in it, have names of NT domain users associated with unix users.
the %n macro is a system to wild-card match in the same way as "*" and then
substitute what matches on one side of the equation to the other side of
the equation.

DOMAIN1\Administrator=root
DOMAIN1\Support%2=is%2
DOMAIN1\%1 = %1
DOMAIN1\* = guest1
DOMAIN1\* = guest2
DOMAIN1\* = guest3
DOMAIN2\Guest = guest4
DOMAIN3\Guest = guest5
DOMAIN3\Administrator = d3root
DOMAIN3\%3 = d3%3

let us now define a unix pwdb, with the following entries (mostly just
username, uid only, for simplicity)

root:0:0
issales:50:0
d3root:51:0
guest1:400:400
guest2:401:400
guest3:402:400
guest4:403:400
guest5:404:400
guest6:405:400
lkcl:500
jra:501
tridge:502
jfm:503
...
...
d3doej:10000
d3fred:10001

these users, as you like to say, jeremy, are real users.  they are real,
local users on the POSIX system that uses this unix pwdb.

before i begin, i am not going to specify which of DOMAIN1, DOMAIN2 and
DOMAIN3 are the SAM database that samba, pam_ntdom, winbind, pam_smb
or any other program uses to reference the SURS database, because it
doesn't matter.  if it helps you to conceptualise this all, then
you might like to imagine that one of these domains is owned by the
samba server that is running on the local POSIX system, but you
_certainly_ shouldn't let that limit you to thinking that SURS tables
can only resolve SIDs in the domain you choose.

now, we are going to run through what happens when the following users
access one of the four above programs, resulting in those programs
referencing the SURS database, and the auto-population algorithm is
triggered:

DOMAIN1\lkcl                S-1-5-21-domain1-1002
DOMAIN1\SupportEngineering  S-1-5-21-domain1-1003
DOMAIN1\SupportSales        S-1-5-21-domain1-1004
DOMAIN1\Administrator       S-1-5-21-domain1-1001
DOMAIN1\Guest               S-1-5-21-domain1-1002
DOMAIN3\doej                S-1-5-21-domain3-1002
DOMAIN3\fred                S-1-5-21-domain3-1003
DOMAIN1\doej                S-1-5-21-domain1-1005
DOMAIN1\fred                S-1-5-21-domain1-1006

DOMAIN1\lkcl.

the request matches DOMAIN1\%1=%1.
%1 is therefore substed on both sides for lkcl.
lkcl is an entry in etc/passwd uid 500.
the rid is 1002, so a SURS entry is added:

S-1-5-21-domain1-1002=500

DOMAIN1\SupportEngineering.

the entry matches DOMAIN1\Support%2=is%2.
%2 is therefore substed on both sides for Engineering.
engineering is NOT an entry in etc/passwd, therefore no SURS entry is added
and we move on to the next autopop entry.

the request matches DOMAIN1\%1=%1.
%1 is therefore substed on both sides for SupportEngineering.
SupportEngineering is NOT an entry in etc/passwd, therefore no SURS entry
is added and we move on to the next autopop entry.

the request matches DOMAIN1\*=Guest1.
guest1 is an entry in etc/passwd uid 400.
the rid is 1003, so a SURS entry is added:

S-1-5-21-domain1-1003=400

DOMAIN1\SupportSales.

the request matches DOMAIN1\Support%2=is%2.
%2 is therefore substed on both sides for sales.
sales is an entry in etc/passwd uid 50.
the rid is 1004, so a SURS entry is added:

S-1-5-21-domain1-1004=50

you get the picture?  DOMAIN3\doej and DOMAIN3\fred successfully result
in SURS entries because they match to d3doej and d3fred in the auto-pop
table.  DOMAIN1\Guest and DOMAIN1\doej get mapped to guest2 and guest3
respectively, but DOMAIN1\fred gets rejected because we have run out
of real, unix guest users to map unknown unix users to, using
DOMAIN1\* = guest2 and DOMAIN1\* = guest3.

the point is therefore that the use of the same auto-pop algorithm on
multiple machines does away with the need to know what part of a hybrid
unix pwdb a real unix uid is in.  so what if on one system issales is
uid 40, and uid 41 on another?  who cares!!!  only the local POSIX system
that uses that uid, and that's the only system that SHOULD care.


jeremy, i'm expecting you to say to the above auto-pop algorithm, "you
can't PUT remote domains in the SURS table or in the auto-pop table,
because as i keep repeating to you, remote users don't exist on posix".

please think REALLY hard about why i might think that this is an
unnecessary restriction.  please LOOK at the example unix password
database i created, which has users d3root, d3doej and d3fred as REAL,
LOCAL unix users - NOT remote users, because as i keep telling you i KNOW
posix doesn't support the concept remote users, so i created three LOCAL
ones instead!

and if you are going to tell me that _this_ cannot be dome [creation and
use of d3root, d3doej and d3fred], then i have to give up trying to explain
this to you, and i'll go with nico's .so architecture to implement the SURS
algorithm that you like so much and keep trying to justify, and provide an
alternative .so SURS implementation for people who _do_ understand.

i think the .so idea is a great one, anyway, as it allows multiple systems
(pam_ntdom, winbind, pam_smb and samba) to all use the same consistent
interface to map SIDs to uids, on the same local POSIX system, without
those people having to worry about how it is implemented.