[IPA] SID allocation using DNA plugin

[Andrew Bartlett]

On Wed, 2009-11-04 at 02:41 -0500, Endi Sukma Dewata wrote:
> Andrew,
> 
> ----- "Andrew Bartlett" <abartlet at samba.org> wrote:
> 
> > > > 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. 
> 
> At least in the initial implementation we will be using Samba only to
> read Samba data and we will synchronize Samba and IPA data using another
> synchronization tool. This way we don't have to implement IPA-specific
> mapping within Samba code, although we'll keep that option open to improve
> the performance and robustness in the future. But even so it's not going
> to reduce the mapping because the standard DS schema doesn't accommodate
> AD-specific attributes so they still need to be mapped somewhere else.
> So it still requires mapping, only in a different form.
> 
> I don't think we can avoid renaming the schema either. See reasons below.
> 
> > > 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?
> 
> Yes, a DS instance can only load 1 set of non-conflicting schemas.
> 
> So the first reason, regardless of IPA, is that we want to use sambaSID
> attribute belonging to Samba 3 schema which depends on several other
> schemas including the inetOrgPerson schema (this is specified in
> setup/fedorads.inf). The AD schema contains quite a few attributes/
> classes with the same name/OID as in these FDS schema but they aren't
> exactly compatible. The DS won't start with these conflicts.

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. 

> The second reason has to do with Samba-IPA integration. In this scenario
> the LDAPI interface is shared between Samba & IPA, but it's still private
> because no clients can access it directly.
> 
> There are 2 cases that we have considered previously:
> 1. Put Samba & IPA data in the same DS instance. This definitely requires
>    renaming maybe even more schema to avoid conflicts.

I don't think this is viable.  Even if we resolved all the conflicts,
imposing a performance cost on every query as we rename things, the
schema will still show up on the IPA side of things, as available
attributes and classes.  I don't think you want that. 

> 2. Put Samba & IPA in different DS instances. Here we don't need to worry
>    about the second reason, but the first reason is still applicable.

Either in different instances, or with DS understanding that the
different directories have 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. 
> 
> Yes, if we decide to implement a FreeIPA backend we will need to modularize
> Samba code. I think it requires significant effort to restructure the code.

Yes, but one I think may simply be required.  It's really not *that*
much work (generating the simple_ldap_map table dynamically). 

> > 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. 
> 
> My concern is that once we start doing that the schema becomes less
> relevant and the schema enforcement will become Samba's responsibility.

Schema enforcement is already Samba's responsibility anyway (we have to
do it for LDB), but it's good if the LDAP backend also has a correct
schema. 

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

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

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