[IPA] SID allocation using DNA plugin

[Andrew Bartlett]

On Tue, 2009-11-03 at 20:19 -0500, Dmitri Pal wrote:
> Andrew Bartlett wrote:
> > On Tue, 2009-11-03 at 17:50 -0500, Endi Sukma Dewata wrote:
> >   
> >> Andrew,
> >>
> >> Please take a look at the attached patch files.
> >>
> >> The first patch contains bug fixes for some minor issues.
> >>
> >> The second patch contains a number of additional schema mapping. When
> >> I tested the patches that I submitted previously, the schema mappings
> >> seemed to be enough for avoiding conflicts between AD schema and FDS
> >> schema. But now it seems there has been some changes so I have to add
> >> some more mappings.
> >>     
> >
> > OK. 
> >
> >   
> >> In this patch I'm renaming some AD object classes using 'samba4' prefix
> >> because there are already FDS object classes with the same name/OID.
> >> I don't think we can just skip the AD classes and use the FDS classes
> >> because although they may look the same they are actually different.
> >> The AD classes are subclasses of samba4Top which requires AD-specific
> >> attributes.
> >>     
> >
> > I would prefer a more elegant solution.  Perhaps not loading those
> > classes in FDS, and allowing the FDS users to see the inheritance from
> > Samba4Top?  However, this is your mapping, and in the end I don't mind
> > how you do it (make sure you update the simple_ldap_map however!)
> >   
> 
> I am not sure it is possible since this implies that the FDS user has to
> decide whether or
> not to load the conflicting schema before he starts to use his instance
> of FDS as a Samba
> back end. The general assumption about any DS instance OpenLDAP, FDS or
> any other IMO
> should be that it has been deployed before customer decided to use it as
> Samba back end with it.

This is an assumption that you have for FreeIPA, but it's not the way
the OpenLDAP backend works at the moment (because the things Samba4
needs are far, far more than just the Schema, it's also the whole tree
layout).  It is admirable goal however, and RedHat's research in this
area will make Samba4 easier to deploy to users happy with the 'Samba3'
approach. 

It also raises an important point - if we take one particular class as
an example:

Why should a bootableDevice ever be called samba4BootableDevice?  Is
there a client-observable difference between the two?  

> I know that it adds more burden to Samba but I think respecting this
> assumption would make
> Samba 4 more attractive to people who already deployed some kind of DS
> based solution and want to add Windows users and machines to it.

But that's actually why we should use common classes, and never inflict
this Samba4* on our users.  

If the only reason is because they inherit from Samba4top, why not just
modify "top" when Samba4 is added to a DS instance?

The Samba4top thing is a hack actually - The only reason it exists is
because "top" is hardcoded in OpenLDAP.  Otherwise I would have just
replaced top and been done with this mess.  It wasn't meant to change
the schema - only be added as an extra class to every ObjectClass list
to make things work.  

BTW, currently the FDS backend uses extensibleObject, which is even an
worse hack...

Finally, why is the Samba4 schema not always loaded in a FreeIPA
instance?   Isn't the plan to use Samba4's hdb-samba4 as the backend
behind the KDC?  It uses the (horrible, but understood) AD key format,
and so you will need the Samba4 schema loaded for that to work anyway. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20091104/8124ff14/attachment.pgp>