[IPA] SID allocation using DNA plugin

[Endi Sukma Dewata]

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.

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

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

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

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

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

For now I'd like to get something working first. Once we're sure the
mapping is sufficient we can discuss how restructure it.

Thanks.

--
Endi S. Dewata