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

[Luke Kenneth Casson Leighton]

jeremy,

more thinking :-)

couple of scenarios that i'd like you to consider.

1) samba as a BDC to an NT PDC.

under these circumstances, samba does not control the SID-space.  it
does, however, control the uid-space.  to generate SIDs from uids
(create a SAM) is going to create a disparate set of SIDs for the same
users.

this might not be a problem - yes, i know you think it might not be,
and the reasoning goes something like this: because the files on
the samba server are local to the samba server, we can do whatever
the hell we like, and create SIDs that only have meaning to the local
samba server, because NT clients will only come to us to resolve the
SIDs that _we_ created.

well, it is a problem when samba is a BDC to an NT PDC.  GetAnyDCname()
(implemented as a UDP 138 GetDC call) can obtain _either_ the samba server's 
name _or_ the PDC's name.  this is to distribute the load of Domain
handling between multiple DCs.  it doesn't matter which DC you go to,
because they give exactly the same responses.  right?

wrong.  if a samba server creates its own SIDs from uids, then an NT
client will get different responses from if it tried to resolve the
same SIDs at the NT PDC.  this is really bad, and cannot be allowed.

a possible solution, you are going to tell me, is that we need to
implement a BDC-scenario work-around, whereby instead of answering
LsaLookupSids and LsaLookupNames calls ourselves, we resolve them
against the PDC.  well, we just doubled, tripled etc (depending on
how many samba BDCs there are) the SID/name resolution load and made
the PDC a single point of failure... again, which defeats the point of
having a BDC in the first place: we might as well not bother.

which brings me on to another possible solution: avoid the problem.
tell people that if they want to migrate from NT to samba PDCs / BDCs
they must do it in one hit.  you must either have all NT or all samba,
not both.  i think i know what admins will do or be told to do: they'll
be told, sorry, you can't have samba on the network as a BDC, if that's
the kind of requirements: we need to prove that it works, first, before
replacing our NT PDC server which has been in [unreliable, but
devil-you-know] operation for the last few years.

i am interested to know what possible solution you might consider to
solve this one.


2) samba as a trusted DC.

someone accesses a samba server as a trusted DC user.  at the moment,
they must be verified against a local samba account with the same name,
stripping off the domain name and granting them a SID in the local SAM
database.  When they attempt to access a file on the samba server with
permissions granted to one of their own domain's groups, the SID they are
accessing the samba server as is different from their _real_ SID,
therefore the permissions will be confused / denied / granted.

how do you distinguish between the two users using the same local samba
account?  how do you grant permissions to one user but not the other?
do you expect administrators to restrict the workstations from which
the two users can access the samba server?
do you expect administrators to use the domain name in some way, to
do include = smb.conf.%D?

according to the Rule Of Least Surprises, this is not very acceptable
behaviour or acceptable work-arounds.