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

[Luke Kenneth Casson Leighton]

On Thu, 30 Dec 1999, Leslie M. Barstow III wrote:

> On Thu, 30 Dec 1999, Jeremy Allison wrote:
> > Luke Kenneth Casson Leighton wrote:
> > > On Tue, 28 Dec 1999, Jeremy Allison wrote:
> 
> > > > Ok, let me explain *why* I am fighting tooth and nail to
> > > > keep Luke's SID mapping table out of Samba.
> 
> > > > It is simply the wrong place to put such a thing.
> 
> > > > If we step back and look at the actual problem we are
> > > > trying to solve, then we see that hacking Samba with
> > > > mapping tables is the wrong approach.
> 
> > > firstly, it's not a hack.  if it _can_ be defined to be a hack, it's a
> > > hack that needs to sit on top of _all_ posix-compliant software that also
> > > wishes to be NT-domain-compliant.  that includes absolutely anyone.  sun,
> > > syntax, at & t, sco, absolutely everyone needs to implement the functional
> > > equivalent of a SURS table.  the open source projects i know of that need
> > > to implement the functional equivalnt of a SURS tabhle are:
> 
> > > - pam_ntdom
> 
> Shouldn't need it - PAM only authenticates a name against a [series of]
> key[s]i, and returns only success or failure.  It would be *nice* if the
> PAM module were able to update the SURS table, though - it gets the SID
> back as part of the authentication process.

personally, i don't think that pam_ntdom should _update_ the SURS table,
unless is't a self-populating (auto-populating one).  see other message i
sent.

actaully, see thinkj about mapping from NT naem to unix name, which _is_
important, so you do need to reference the SURS table.  se other message
for details.