[IPA] SID allocation using DNA plugin

[Andrew Bartlett]

On Wed, 2009-11-04 at 20:47 -0500, Endi Sukma Dewata wrote:
> 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.

Good. 

> 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.

And I look forward to you writing me an nice flexible mapping
configuration tool :-)

> ----- "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?

It already is in the Samba source tree (we are the upstream for this
file).  Just like Samba4Top, it can be added to the generated schema -
and would preferably read the Samba3 schema we ship as input.  We even
have a conversion tool From the OpneLDAP format to the AD-LDIF,
currently provided as bin/oLschema2ldif.

In fact, both the samba4Top and these elements should be added only to a
separate instance of a Schema object in provision, used by the FDS and
OpenLDAP backends, and not shared with the main LDB, so that we don't
put samba4Top or SambaSID into Samba4's AD schema. 

The existing 'skip' facility could skip the attributes/classes we don't
want to import. 

(I think FDS should not ship the Samba3 schema at all, but run a
conversion script over the openldap formatted one included in the Samba3
package, but that's another matter). 

> > > 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.

Great. 

> > 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.

OK.

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/20091105/18691cc3/attachment.pgp>