[IPA] SID allocation using DNA plugin

[Andrew Bartlett]

On Tue, 2009-11-03 at 21:29 -0500, Endi Sukma Dewata wrote:
> Andrew,
> 
> Attached is the patch for the minor bugs. Thanks.
> 
> ----- "Andrew Bartlett" <abartlet at samba.org> wrote:
> 
> > 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?
> 
> In my opinion this should not be an issue because the samba4* schema
> can be considered a private schema for Samba 4 server since the DS
> instance will only listen to a private LDAPI interface. Samba clients
> will never need to know about samba4* schema, they will only use AD
> schema (without samba4 prefix).

OK.  But if we avoid the samba4* prefix we have less mapping to do in
Fedora DS.  We may even get to a point where we can have Samba4 ldb_map
code (which is much more powerful than is exposed in the
'simple_ldap_map' module) read both DS partitions, for the 'Samba4' and
'IPA' data. 

> Also, the samba4* schema is generated dynamically by the provisioning
> tool, so there is no need to maintain parallel AD & Samba schema. The
> only thing that needs to be maintained is the schema mapping, which if
> we allow the admin to configure it it should not become a burden for
> Samba developers.

OK, so if it's private, why rename it at all?  If I recall correctly
this is because FDS can't load 2 different schemas?

If we do need to do this only for FreeIPA (and not for the normal case
of an FDS backend to Samba4), we should create the config-based mapping
module, and create 3 configurations:  OpenLDAP, FDS, FreeIPA. 

> > 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.  
> 
> One example is the person object class. In DS the person inherits
> from top and it requires cn and sn. In AD the person inherits from
> AD's top which requires instanceType, nTSecurityDescriptor, and
> objectCategory and the person itself only requires cn. Adding
> the requirement for AD-specific attributes into DS's top probably
> will make the schema unusable for existing DS clients because
> they don't know how to supply the AD-specific values. The AD & DS
> schemas are incompatible that they cannot be used interchangeably
> by the client applications.

If we really wanted to, we could work around these issues.  In the
OpenLDAP backend we have Samba4Top as an auxillary class.  For 'person',
we have the annoying difference on 'sn', but I do wonder what would
actually break if FDS just omitted it too. 

Anyway, I'm just keen to explore the 'less renaming' options as much as
possible, and I would like the FreeIPA mapping you are developing split
from the 'minimum to make FDS work as a backend' mapping we started
with, and all 3 mappings made configuration based.  Otherwise the route
you propose seems reasonable.  

(I know rewriting simple_ldap_map wasn't on your plans, but we will be
chasing bugs forever and a day if we allow these two to get out of sync.
I don't mind how you do it - generate the .c file, or read a config
file, or generate the schema-map file). 

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/497216b2/attachment.pgp>