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

[Nicolas Williams]

On Thu, Dec 30, 1999 at 05:59:15AM +1100, Luke Kenneth Casson Leighton wrote:
> On Wed, 29 Dec 1999, Nicolas Williams wrote:
> 
> > On Wed, Dec 29, 1999 at 09:41:50PM +1100, Luke Kenneth Casson Leighton wrote:
> > > > > ... ok.  the only reason that you might want all the *nix hosts to use the
> > > > > same uids/gids is to maintain consistency to unix-only users.
> > > > 
> > > > Yes. And if those users also have matching NT accounts in a domain that
> > > > is for the same site and purposes as the Unix domain, then I'd like the
> > > > Unix uids/gids to be resolved into NT usernames/groups relative to the
> > > > NT domain, from the NT client perspective.
> > > 
> > > that is a reasonable configuration.
> > > 
> > > > This is a particularly situation though and not every organization has
> > > > that kind of ono-to-one relationship between Unix and NT domains.
> > > 
> > > > So, the algorythmic mapping is perfectly ok to use. There is nothing
> > > 
> > > only in the very specific situation that you describe.  if other sites
> > > require different, more complex configurations, then ithe [particular]
> > > algorithmic mapping is just not enough.
> > 
> > No. Algorythmic mapping is ok to use all the time. Table lookups are ok
> 
> describe to me the situations in which algorithmic mappings are
> acceptable.  i already know about the one where samba is a PDC and you can
> only have domain users for that one domain, supported, and no others.

See below.

> > if you can establish the mappings offline, so to speak (which you claim
> > one can, via auto-population of SURS tables - agreed).
> 
> ... ok, very cool.  another potential convert to db-based SURS tables.

I am. I have been from the beginning. See below.

> > > > wrong with it except that it hides any equivalence you might have
> > > > between a Unix domain and an NT domain, if you happen to have such an
> > > > equivalence.
> > > 
> > > ok, there is a distinction between creating a SAM and mapping between SAM
> > > SIDs and uids.
> > 
> > Yes. We don't have any interest in Samba PDCs where I work, thus we have
> > no Samba PDCs, no Samba SAMs (i.e., no smbpasswd file).
> > 
> > > the algorithmic approach does both jobs, and what you just said tells me
> > > that you are confusing the two tasks.
> > 
> > ?
> 
> to explain further.  the algorithm in samba 2.0.x is used in two places.
> 
> 1) the SAM database in samba is actually created from the unix uid
> /etc/passwd (or whatever) pwdb.  unix uids are converted to a RID, the RID
> is cappended to the SAM SID, you haev your SID.
> 
> 2) when _any_ SID comes in, the same rid-uid function is used.  any SIDS
> that do not match the SAM SID at the front are REJECTED.
> 
> the rejection bit is what i object to about this algorithm.

Ay! I have been looking at Samba 2.0.5a served shares from an NT4 host
since Tuesday, but I never tried using an NT account from a different
domain.

This is bad. We've got this braindead multiple-NT domain situation here
with an NT domain per-continent and we've been telling ppl that they'll
be able to use Samba servers from other continents when we upgrade to
Samba 2.x.x.

Where necessary we've been using the virtual server approach to make a
Samba 1.9.18p10 server authenticate users against a PDC of one domain
where the PDC name is dependent on the NetBIOS name that the user used
to refer to the Samba server (i.e., "include = /some/path/using/%L").

Even though we have more than one NT domain there's really only one set
of real users and the domain trust relationships reflect this.

Ok, so the current algorythmic mapping will now definitely not satisfy
the needs of the environment where I work.

Ok, hurry up then. Implement the external SURS DB API. I might implement
a module.

:(

:/

:)

> if a SURS table existed, (db implementation) we could map, say,
> SAMBASERVERDOMAIN\user1 to uid500, and DOMAIN2\user1 to uid501, and
> DOMAIN3\user1 to uid502, where uid500 has a unix pw entry name of user1,
> uid501 has D"user1 and 502 has D3user2.  slightly painful, but not as
> stupidly limiting as thininkg that i think remote users exist on POSIX!

We need this. See above.

> > > _even_ if you use a SURS database table, samba will _still_ need to have
> > > an algorithmic mapping to create SIDs in its own SAM, from uids/gids,
> > 
> > This is true only for Samba PDCs. In the context of XAD (which is how
> > this whole thread got started in the first place) Samba wouldn't be
> > responsible for maintaining the SAM directly: XAD would be, and Samba
> > would simply provide the LSA RPC and MS RPC interfaces to XAD.
> 
> 
> yes, yesm, and eys some more.  oops i'm not going to spell-correct that, i
> like it :-)

Hee.

[...]
> > > correct.  just like NT, if you can't contact the DC for the SID, you get
> > > "unknown" in the display stuff, and the SID in the security descriptor is
> > > ignored because it's irrelevant, anyway.
> > 
> > Ok, so forget my suggestion about letting the Samba admin provide a base
> 
> *whew* i was worried for a minute, there.  you're not just giving up on
> me, are you, you do realise why i think it's a bad idea?  btw thanks for
> going at this with me, and you too, jeremy, i know this isn't exactly a
> trivial area.

I'm not giving up. I see that that idea was not a good one. BTW, I'm not
an expert in this area, so you can see why I might have thought it was a
good idea. But I'm not hard-headed.


[...]
> > > got to get some sleep.  that's my excuse, anyway :_)
> > 
> > Heh.
> 
> :) you might have noticed, i got some.  sleep, that is :)  hur hur.

Yes. You post too fast man. Slow down :)

My carpals are hurting...

Nico
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.