[IPA] SID allocation using DNA plugin

Endi Sukma Dewata edewata at redhat.com
Tue Nov 3 19:29:31 MST 2009


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

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.

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


Endi S. Dewata

More information about the samba-technical mailing list