[IPA] SID allocation using DNA plugin

[Dmitri Pal]

Andrew Bartlett wrote:
> 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. 
>
>   
I am rising a use case. Unfortunately I am knowledgeable enough to come
up with
the answer. DSs are full of history and hacks as you pointed out. I
doubt it would be easy
to change. If we can load Samba 4 schema at the moment of IPA or DS
installation we
probably should do it if it:
* Does not contradict exiting RFCs or legacy features that DS can't fix
and has to live with forever
* Does not contradict with core features of the product (IPA schema is
flat on purpose)
* Does not cause issues with migration for people who already use DS and
upgrade to new version
with Samba schema included
* Makes deployment of Samba 4 easier

If this is the case I am all for it. But I suspect this is not the case.
This is why we were planing
to use 2 different instances of DS and replicate between them. But again
I am all for
better alternatives if they exist. As for KDC it looks like what  Luke
has done with
KDC and HDB layer is not directly usable by us.

We still plan to use enhanced DAL layer that would be able to go either
to IPA's DS tree directly
or will switch to Samba tree. We will not use it directly (that would be
insane)
but rather via either part of the HDB bridge Luke created or via iRPC
mechanism
you proposed when I was on the CIFS conference in September.
This will be prototyped. Simo will start working on this pretty soon. 

But the point is that the area that stores Samba schema and IPA schema
are two separate schemas
and instances of DS. At least this is what was planned originally.
I am not sure how these two can be integrated.

But I was not concerned about IPA in my comment.
I was concerned more about a customer who has a DS (not IPA) now and wants
to add Samba 4 on top of it. Would be nice to be able
to just use what he has if the default tree is RFC compliant.
In IPA we removed OUs but standard schema has them so the standard
schema is closer to AD schema than IPA one so IPA is in worse
situation (for its own reasons).
Is it possible to not I do not know. You tell me.
May be it is something that would never be possible and
even DS user would have to migrate if they want to
start using Samba 4. I see this a barrier to adoption
this why I am asking.


> Andrew Bartlett
>
>   


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/