[IPA] SID allocation using DNA plugin

[Endi Sukma Dewata]

Andrew,

I think if we agree that Samba requires a separate DS instance which is
never going to be shared with any other applications it would simplify
a lot of things. We don't need to worry about conflicting schema at all.
But still I think it would be nice if Samba allows flexible mapping
configuration so the admin would have more deployment options in case
it's needed.

----- "Andrew Bartlett" <abartlet at samba.org> wrote:

> Ahh.  I think I wasn't clear with what my requirement regarding
> "SambaSid" was.  Rather than import all of the Samba3 schmea, perhaps
> only import the parts we actually use?  In particular, import the
> attributes, but not the classes. 

In DS the schemas are packaged into separate LDIF files. During instance
creation we could specify the path of the schema files we want to
load in fedorads.inf. If we want to include only Samba 3 attributes
we'd have to create a new LDIF file containing those attributes. This file
will need to be maintained in Samba source tree. Is this ok?

> > The mapping that I submitted in the last patch actually was the minimum
> > required for FDS backend. It only renames the conflicting names/OID only.
> > Other AD attributes/classes that don't conflict with FDS schema aren't
> > renamed.
> 
> Only because you loaded the Samba3 schema, right?  

If we only use Samba 3 attributes there might still be a few mappings,
but it should be much simpler. I'll have more info once I get it working.

> I did have this working (years ago) without this mapping.  Other than
> the suggestion to use the Samba3 SambaSID etc, what changed?

Not quite sure, but I think the content of the DS schema files have been
rearranged so the dependencies are different now.

Thanks.

--
Endi S. Dewata