refactoring idmap code in smbd

[Andrew Bartlett]

On Thu, Jul 10, 2003 at 11:01:59AM -0500, Gerald (Jerry) Carter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Thu, 10 Jul 2003, Gerald (Jerry) Carter wrote:
> 
> > I don't care if you want to code up a winbindd_passdb backend.  I don't
> > care if you check it into the tree.  But it will not be the default
> > behavior.  At least not initially.  And it better not be any more
> > invasive to winbindd than the rpc_methds or ads_methods.
> 
> Simo and I have had a long chat on #samba-technical.  The one point
> that has been left out of the winbindd_passdb discussion.
> While Simo might disagree with this assessment, winbindd_passdb+idmap
> is an attempt to remove the need for an 'adduser script' altogether.

This has been one of my primary motivations.  One of my hopes in this was
to reduce admin complexity, in particular in migration senerios.  I like the
idea of all the different presentations of user data being dynamic off
the one source.  (Be that the NT domain controller or the Samba passdb)

> Think of the current implementation of samr_create_user().
> 
>   does user exist in passdb?  if yes fail ALREADY_EXISTS)
>   does unix user by this name exist?  
>     no? - call adduser_script() or winbind_create_user()
>     still no user?  Fail.
>   unix user exists now so add to passdb.
> 
> The new code with winbindd_passdb would be
> 
>   does user exist in passdb?  if yes fail ALREADY_EXISTS)
>   add user to passdb (idmap would allocate a uid for you)
> 
> The problems for the 3.0 release was that we only had idmap.  
> You really need both of these things to go hand in hand to make 
> sense.  

Now it was my impression that for the users side of things, we were 
about as close on the winbind_passdb as with your 'unix users in
winbind' soltuion.  That may or may not have been the case, but
I still think it would have been the more elegent solution.

> So now we have one working implementation (in current code) and 
> one on paper (winbindd_passdb+idmap).
> 
> So beyond 3.0, we can revisit this.  Whether winbindd_passdb 
> is the right thing to do or not, is unknown.  And which competing 
> solution will be in future versions of Samba is also unknown.  I 
> think we would all agree that having 3.0 out the door so we _can_ 
> move on is what's best right now.  

I can agree with that, now that the reasons for all the positions are
better understood.

> > But you don't need to do this.  I have a gut feeling that
> > winbindd_passdb was based out of the assumption that you couldn't run
> > winbindd on a Samba PDC as a domain member.  Since we know that is not
> > the case, why bother with passdb?  Why not just use the rpc functions
> > already used as a member of any domain?
> 
> scratch this argument.  It is invalid and will loop.

This is the reason we started on this.  

Andrew Bartlett