[IPA] SID allocation using DNA plugin

[Endi Sukma Dewata-3]

Andrew,

I have a question related to this proposal:
http://www.freeipa.org/page/Samba_4_SID_Allocation_using_DNA_Plugin

Please take a look at dsdb/samdb/ldb_modules/password_hash.c. During an add operation
the password_hash module tries to extract the domain SID from the object SID.

static int password_hash_add(struct ldb_module *module, struct ldb_request *req)
{
        ac->domain_sid = samdb_result_sid_prefix(ac, req->op.add.message, "objectSid");
        ret = build_domain_data_request(ac);
}

The domain SID will be used to create a search filter to find the domain object in the
following method:

static int build_domain_data_request(struct ph_context *ac)
{
        attrs[] = { "pwdProperties", "pwdHistoryLength", NULL };
        ldb = ldb_module_get_ctx(ac->module);

        filter = talloc_asprintf(ac,
                                 "(objectSid=%s)",
                                 ldap_encode_ndr_dom_sid(ac, ac->domain_sid));

        return ldb_build_search_req(&ac->dom_req, ldb, ac,
                                    ldb_get_default_basedn(ldb),
                                    LDB_SCOPE_BASE,
                                    filter, attrs,
                                    NULL,
                                    ac, get_domain_data_callback,
                                    ac->req);
}

It seems like the use of search filter here is redundant because the base DN and
the scope point to the domain object directly. Is it correct?

If that's case can we use a NULL filter in this search, so we don't need the domain
SID, meaning we don't need to check the objectSid in the previous method. This way
the SID can be generated by the backend. Is this correct?

Thanks!

--
Endi S. Dewata

[Andrew Bartlett]

On Mon, 2009-10-26 at 23:03 -0400, Endi Sukma Dewata wrote:

> Andrew,
>
> I have a question related to this proposal:
> http://www.freeipa.org/page/Samba_4_SID_Allocation_using_DNA_Plugin
>
> Please take a look at dsdb/samdb/ldb_modules/password_hash.c. During an add operation
> the password_hash module tries to extract the domain SID from the object SID.
>
> static int password_hash_add(struct ldb_module *module, struct ldb_request *req)
> {
> ac->domain_sid = samdb_result_sid_prefix(ac, req->op.add.message, "objectSid");
> ret = build_domain_data_request(ac);
> }
>
> The domain SID will be used to create a search filter to find the domain object in the
> following method:
>
> static int build_domain_data_request(struct ph_context *ac)
> {
> attrs[] = { "pwdProperties", "pwdHistoryLength", NULL };
> ldb = ldb_module_get_ctx(ac->module);
>
> filter = talloc_asprintf(ac,
> "(objectSid=%s)",
> ldap_encode_ndr_dom_sid(ac, ac->domain_sid));
>
> return ldb_build_search_req(&ac->dom_req, ldb, ac,
>    ldb_get_default_basedn(ldb),
>    LDB_SCOPE_BASE,
>    filter, attrs,
>    NULL,
>    ac, get_domain_data_callback,
>    ac->req);
> }
>
> It seems like the use of search filter here is redundant because the base DN and
> the scope point to the domain object directly. Is it correct?
>
> If that's case can we use a NULL filter in this search, so we don't need the domain
> SID, meaning we don't need to check the objectSid in the previous method. This way
> the SID can be generated by the backend. Is this correct?

This is a reasonable assumption.  We had in the past written parts of
Samba in a more generic way, trying to support the creation of multiple
domains in a single Samba server.  We don't try this any more, and a
patch to remove this would be gladly accepted.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

[Endi Sukma Dewata-3]

Andrew,

Please take a look at the attached patches.

Patch #0004 removes the redundant usage of SID in password_hash module as
we discussed previously.

Patch #0005 adds an "sid generator" parameter to flip the switch for using
the DNA plugin for SID allocation:
http://www.freeipa.org/page/Samba_4_SID_Allocation_using_DNA_Plugin

I think the patch #0004 can be applied independently from patch #0001-0003
that I've submitted previously, but patch #0005 is dependent on all of them.
Please let me know if you want me to resubmit these patches.

Thanks!

--
Endi S. Dewata


----- "Andrew Bartlett" <abartlet@...> wrote:

> > It seems like the use of search filter here is redundant because the
> base DN and
> > the scope point to the domain object directly. Is it correct?
> >
> > If that's case can we use a NULL filter in this search, so we don't
> need the domain
> > SID, meaning we don't need to check the objectSid in the previous
> method. This way
> > the SID can be generated by the backend. Is this correct?
>
> This is a reasonable assumption.  We had in the past written parts of
> Samba in a more generic way, trying to support the creation of
> multiple
> domains in a single Samba server.  We don't try this any more, and a
> patch to remove this would be gladly accepted.

[Andrew Bartlett]

On Wed, 2009-10-28 at 17:00 -0400, Endi Sukma Dewata wrote:

> Andrew,
>
> Please take a look at the attached patches.
>
> Patch #0004 removes the redundant usage of SID in password_hash module as
> we discussed previously.
>
> Patch #0005 adds an "sid generator" parameter to flip the switch for using
> the DNA plugin for SID allocation:
> http://www.freeipa.org/page/Samba_4_SID_Allocation_using_DNA_Plugin
>
> I think the patch #0004 can be applied independently from patch #0001-0003
> that I've submitted previously, but patch #0005 is dependent on all of them.
> Please let me know if you want me to resubmit these patches.

These look good.

Is there any chance you can, once you have submitted the patches for
review on the list, place them in a git repository?

I've been slower than I would prefer in applying the correct patches,
and I don't want to loose your fine work.

Thanks,

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

[Endi Sukma Dewata-3]

Andrew,

I've put the 5 patches into this repository under the development branch:
http://github.com/endisd/samba/tree/development

Thanks!

--
Endi S. Dewata


----- "Andrew Bartlett" <abartlet@...> wrote:

> On Wed, 2009-10-28 at 17:00 -0400, Endi Sukma Dewata wrote:
> > Andrew,
> >
> > Please take a look at the attached patches.
> >
> > Patch #0004 removes the redundant usage of SID in password_hash
> module as
> > we discussed previously.
> >
> > Patch #0005 adds an "sid generator" parameter to flip the switch for
> using
> > the DNA plugin for SID allocation:
> > http://www.freeipa.org/page/Samba_4_SID_Allocation_using_DNA_Plugin
> >
> > I think the patch #0004 can be applied independently from patch
> #0001-0003
> > that I've submitted previously, but patch #0005 is dependent on all
> of them.
> > Please let me know if you want me to resubmit these patches.
>
> These look good.
>
> Is there any chance you can, once you have submitted the patches for
> review on the list, place them in a git repository?
>
> I've been slower than I would prefer in applying the correct patches,
> and I don't want to loose your fine work.
>
> Thanks,
>
> Andrew Bartlett
>
> --
> Andrew Bartlett                              
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team           http://samba.org
> Samba Developer, Cisco Inc.

[Endi Sukma Dewata-3]

Hi Andrew,

I noticed that the patches have been applied to the master branch,
thank you very much. However, when I tried to test it I found that
the provisioning tool failed with the following error:

Traceback (most recent call last):
  File "./setup/provision", line 213, in <module>
    nosync=opts.nosync,ldap_dryrun_mode=opts.ldap_dryrun_mode)
  File "bin/python/samba/provision.py", line 1195, in provision
    domainsid=domainsid)
  File "bin/python/samba/provisionbackend.py", line 184, in __init__
    domainsid=domainsid)
  File "bin/python/samba/provisionbackend.py", line 579, in provision_fds_backend
    retcode = subprocess.call([setup_ds_path, "--silent", "--file", result.paths.fedoradsinf], close_fds=True, shell=False)
NameError: global name 'subprocess' is not defined

Are you still in the middle of restructuring the provisioning tool?
Please let me know if there's anything I could help. Thanks!

--
Endi S. Dewata



----- "Andrew Bartlett" <abartlet@...> wrote:

> On Wed, 2009-10-28 at 17:00 -0400, Endi Sukma Dewata wrote:
> > Andrew,
> >
> > Please take a look at the attached patches.
> >
> > Patch #0004 removes the redundant usage of SID in password_hash
> module as
> > we discussed previously.
> >
> > Patch #0005 adds an "sid generator" parameter to flip the switch for
> using
> > the DNA plugin for SID allocation:
> > http://www.freeipa.org/page/Samba_4_SID_Allocation_using_DNA_Plugin
> >
> > I think the patch #0004 can be applied independently from patch
> #0001-0003
> > that I've submitted previously, but patch #0005 is dependent on all
> of them.
> > Please let me know if you want me to resubmit these patches.
>
> These look good.
>
> Is there any chance you can, once you have submitted the patches for
> review on the list, place them in a git repository?
>
> I've been slower than I would prefer in applying the correct patches,
> and I don't want to loose your fine work.
>
> Thanks,
>
> Andrew Bartlett
>
> --
> Andrew Bartlett                              
> http://samba.org/~abartlet/
> Authentication Developer, Samba Team           http://samba.org
> Samba Developer, Cisco Inc.

[Andrew Bartlett]

On Mon, 2009-11-02 at 12:24 -0500, Endi Sukma Dewata wrote:

> Hi Andrew,
>
> I noticed that the patches have been applied to the master branch,
> thank you very much. However, when I tried to test it I found that
> the provisioning tool failed with the following error:
>
> Traceback (most recent call last):
>   File "./setup/provision", line 213, in <module>
>     nosync=opts.nosync,ldap_dryrun_mode=opts.ldap_dryrun_mode)
>   File "bin/python/samba/provision.py", line 1195, in provision
>     domainsid=domainsid)
>   File "bin/python/samba/provisionbackend.py", line 184, in __init__
>     domainsid=domainsid)
>   File "bin/python/samba/provisionbackend.py", line 579, in provision_fds_backend
>     retcode = subprocess.call([setup_ds_path, "--silent", "--file", result.paths.fedoradsinf], close_fds=True, shell=False)
> NameError: global name 'subprocess' is not defined
>
> Are you still in the middle of restructuring the provisioning tool?
> Please let me know if there's anything I could help. Thanks!

What I really need is 'make test' expanded to have tests with the LDAP
backend run on any compatible host.  Until we do that, mistakes such as
the one I made here will continue to happen.

(See the environments in selftest/target/Samba4.pm)

Patches to fix up my latest stuff-up most welcome, otherwise I'll look
at it later today.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

[Endi Sukma Dewata-3]

Andrew,

Please take a look at the attached patch files.

The first patch contains bug fixes for some minor issues.

The second patch contains a number of additional schema mapping. When
I tested the patches that I submitted previously, the schema mappings
seemed to be enough for avoiding conflicts between AD schema and FDS
schema. But now it seems there has been some changes so I have to add
some more mappings.

In this patch I'm renaming some AD object classes using 'samba4' prefix
because there are already FDS object classes with the same name/OID.
I don't think we can just skip the AD classes and use the FDS classes
because although they may look the same they are actually different.
The AD classes are subclasses of samba4Top which requires AD-specific
attributes.

There is still another problem with the provisioning tool that I'm
still investigating. Once this is working I will be able to look into
the 'make test'.

Thanks!

--
Endi S. Dewata


[bugs.patch]

---

diff --git a/source4/dsdb/samdb/ldb_modules/partition_init.c b/source4/dsdb/samdb/ldb_modules/partition_init.c
index f98b1d8..6a456aa 100644
--- a/source4/dsdb/samdb/ldb_modules/partition_init.c
+++ b/source4/dsdb/samdb/ldb_modules/partition_init.c
@@ -132,7 +132,7 @@ static int partition_reload_metadata(struct ldb_module *module, struct partition
  struct ldb_message *msg;
  struct ldb_result *res;
  struct ldb_context *ldb = ldb_module_get_ctx(module);
- const char *attrs[] = { "partition", "replicateEntries", "modules", NULL };
+ const char *attrs[] = { "partition", "replicateEntries", "modules", "ldapBackend", NULL };
  /* perform search for @PARTITION, looking for module, replicateEntries and ldapBackend */
  ret = dsdb_module_search_dn(module, mem_ctx, &res,
     ldb_dn_new(mem_ctx, ldb, DSDB_PARTITION_DN),
@@ -239,7 +245,7 @@ static int new_partition_from_dn(struct ldb_context *ldb, struct partition_priva
  ctrl->version = DSDB_CONTROL_CURRENT_PARTITION_VERSION;
  ctrl->dn = talloc_steal(ctrl, dn);
 
- ret = ldb_connect_backend(ldb, backend_url, NULL, &backend_module);
+ ret = ldb_connect_backend(ldb, (*partition)->backend_url, NULL, &backend_module);
  if (ret != LDB_SUCCESS) {
  return ret;
  }
diff --git a/source4/scripting/python/samba/provisionbackend.py b/source4/scripting/python/samba/provisionbackend.py
index 8f1b94f..f809202 100644
--- a/source4/scripting/python/samba/provisionbackend.py
+++ b/source4/scripting/python/samba/provisionbackend.py
@@ -31,6 +31,7 @@ import sys
 import uuid
 import time
 import shutil
+import subprocess
 
 from samba import read_and_sub_file
 from samba import Ldb
@@ -203,7 +204,7 @@ class ProvisionBackend(object):
 
         self.slapd_command_escaped = "\'" + "\' \'".join(self.slapd_command) + "\'"
         setup_file(setup_path("ldap_backend_startup.sh"), paths.ldapdir + "/ldap_backend_startup.sh", {
-                "SLAPD_COMMAND" : slapd_command})
+                "SLAPD_COMMAND" : self.slapd_command_escaped})
 
         # Now start the slapd, so we can provision onto it.  We keep the
         # subprocess context around, to kill this off at the successful

---

[schema-mapping.patch]

---

diff --git a/source4/setup/schema-map-fedora-ds-1.0 b/source4/setup/schema-map-fedora-ds-1.0
index 7bb3da3..c13cdb2 100644
--- a/source4/setup/schema-map-fedora-ds-1.0
+++ b/source4/setup/schema-map-fedora-ds-1.0
@@ -11,7 +11,6 @@ distinguishedName
 description
 cn
 dITContentRules
-top
 homePostalAddress
 info
 displayName
@@ -19,10 +18,14 @@ employeeNumber
 employeeType
 personalTitle
 co
+subSchemaSubEntry
 userSMIMECertificate
+
 #This should be provided by the LDAP server, only in our schema to permit provision
 aci
+
 #Skip ObjectClasses
+
 #MiddleName has a conflicting OID
 2.16.840.1.113730.3.1.34:1.3.6.1.4.1.7165.4.255.1
 #defaultGroup has a conflicting OID
@@ -47,6 +50,8 @@ aci
 1.3.6.1.4.1.1466.115.121.1.43:1.3.6.1.4.1.1466.115.121.1.15
 
 #Remap into existing schema
+top
+top:samba4Top
 unixHomeDirectory
 unixHomeDirectory:homeDirectory
 pwdLastSet
@@ -87,6 +92,8 @@ objectSid:sambaSID
 1.2.840.113556.1.4.481:schemaUpdate-oid
 
 #Resolve conflicting object classes
+subSchema:samba4SubSchema
+2.5.20.1:samba4SubSchema-oid
 domain:samba4Domain
 rFC822LocalPart:samba4RFC822LocalPart
 mailRecipient:samba4MailRecipient
@@ -100,3 +107,63 @@ residentialPerson:samba4ResidentialPerson
 2.5.6.10:samba4ResidentialPerson-oid
 inetOrgPerson:samba4InetOrgPerson
 2.16.840.1.113730.3.2.2:samba4InetOrgPerson-oid
+room:samba4Room
+0.9.2342.19200300.100.4.7:samba4Room-oid
+posixGroup:samba4PosixGroup
+1.3.6.1.1.1.2.2:samba4PosixGroup-oid
+posixAccount:samba4PosixAccount
+1.3.6.1.1.1.2.0:samba4PosixAccount-oid
+organizationalUnit:samba4OrganizationalUnit
+2.5.6.5:samba4OrganizationalUnit-oid
+oncRpc:samba4OncRpc
+1.3.6.1.1.1.2.5:samba4OncRpc-oid
+nisObject:samba4NisObject
+1.3.6.1.1.1.2.10:samba4NisObject-oid
+nisNetgroup:samba4NisNetgroup
+1.3.6.1.1.1.2.8:samba4NisNetgroup-oid
+locality:samba4Locality
+2.5.6.3:samba4Locality-oid
+ipService:samba4IpService
+1.3.6.1.1.1.2.3:samba4IpService-oid
+ipProtocol:samba4IpProtocol
+1.3.6.1.1.1.2.4:samba4IpProtocol-oid
+ipNetwork:samba4IpNetwork
+1.3.6.1.1.1.2.7:samba4IpNetwork-oid
+ipHost:samba4IpHost
+1.3.6.1.1.1.2.6:samba4IpHost-oid
+ieee802Device:samba4Ieee802Device
+1.3.6.1.1.1.2.11:samba4Ieee802Device-oid
+groupOfUniqueNames:samba4GroupOfUniqueNames
+2.5.6.17:samba4GroupOfUniqueNames-oid
+groupOfNames:samba4GroupOfNames
+2.5.6.9:samba4GroupOfNames-oid
+document:samba4Document
+0.9.2342.19200300.100.4.6:samba4Document-oid
+device:sambaDevice
+2.5.6.14:sambaDevice-oid
+cRLDistributionPoint:samba4CRLDistributionPoint
+2.5.6.19:samba4CRLDistributionPoint-oid
+country:samba4Country
+2.5.6.2:samba4Country-oid
+certificationAuthority:samba4CertificationAuthority
+2.5.6.16:samba4CertificationAuthority-oid
+bootableDevice:samba4BootableDevice
+1.3.6.1.1.1.2.12:samba4BootableDevice-oid
+applicationProcess:samba4ApplicationProcess
+2.5.6.11:samba4ApplicationProcess-oid
+account:samba4Account
+0.9.2342.19200300.100.4.5:samba4Account-oid
+documentSeries:samba4DocumentSeries
+0.9.2342.19200300.100.4.9:samba4DocumentSeries-oid
+domainRelatedObject:samba4DomainRelatedObject
+0.9.2342.19200300.100.4.17:samba4DomainRelatedObject-oid
+friendlyCountry:samba4FriendlyCountry
+0.9.2342.19200300.100.4.18:samba4FriendlyCountry-oid
+organization:samba4Organization
+2.5.6.4:samba4Organization-oid
+organizationalRole:samba4OrganizationalRole
+2.5.6.8:samba4OrganizationalRole-oid
+shadowAccount:samba4ShadowAccount
+1.3.6.1.1.1.2.1:samba4ShadowAccount-oid
+simpleSecurityObject:samba4SimpleSecurityObject
+0.9.2342.19200300.100.4.19:samba4SimpleSecurityObject-oid

---

[Andrew Bartlett]

On Tue, 2009-11-03 at 17:50 -0500, Endi Sukma Dewata wrote:

> Andrew,
>
> Please take a look at the attached patch files.
>
> The first patch contains bug fixes for some minor issues.
>
> The second patch contains a number of additional schema mapping. When
> I tested the patches that I submitted previously, the schema mappings
> seemed to be enough for avoiding conflicts between AD schema and FDS
> schema. But now it seems there has been some changes so I have to add
> some more mappings.

OK.

> In this patch I'm renaming some AD object classes using 'samba4' prefix
> because there are already FDS object classes with the same name/OID.
> I don't think we can just skip the AD classes and use the FDS classes
> because although they may look the same they are actually different.
> The AD classes are subclasses of samba4Top which requires AD-specific
> attributes.

I would prefer a more elegant solution.  Perhaps not loading those
classes in FDS, and allowing the FDS users to see the inheritance from
Samba4Top?  However, this is your mapping, and in the end I don't mind
how you do it (make sure you update the simple_ldap_map however!)

Renames are great where this a problem we can't solve any other way, but
I would hate to inflict Samba4* on the world where we could come up with
better solutions.

If you are going to rename this much, then I suggest you may wish to, as
you proposed earlier, rewrite simple_ldap_map to use a real
configuration file, shared with the schema mapping code.  Otherwise,
these will get out of sync.

> There is still another problem with the provisioning tool that I'm
> still investigating. Once this is working I will be able to look into
> the 'make test'.

Any chance you can post these (particularly the first patch) as
git-format-patch?

Thanks,

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

[Dmitri Pal]

Andrew Bartlett wrote:

> On Tue, 2009-11-03 at 17:50 -0500, Endi Sukma Dewata wrote:
>  
>> Andrew,
>>
>> Please take a look at the attached patch files.
>>
>> The first patch contains bug fixes for some minor issues.
>>
>> The second patch contains a number of additional schema mapping. When
>> I tested the patches that I submitted previously, the schema mappings
>> seemed to be enough for avoiding conflicts between AD schema and FDS
>> schema. But now it seems there has been some changes so I have to add
>> some more mappings.
>>    
>
> OK.
>
>  
>> In this patch I'm renaming some AD object classes using 'samba4' prefix
>> because there are already FDS object classes with the same name/OID.
>> I don't think we can just skip the AD classes and use the FDS classes
>> because although they may look the same they are actually different.
>> The AD classes are subclasses of samba4Top which requires AD-specific
>> attributes.
>>    
>
> I would prefer a more elegant solution.  Perhaps not loading those
> classes in FDS, and allowing the FDS users to see the inheritance from
> Samba4Top?  However, this is your mapping, and in the end I don't mind
> how you do it (make sure you update the simple_ldap_map however!)
>  

I am not sure it is possible since this implies that the FDS user has to
decide whether or
not to load the conflicting schema before he starts to use his instance
of FDS as a Samba
back end. The general assumption about any DS instance OpenLDAP, FDS or
any other IMO
should be that it has been deployed before customer decided to use it as
Samba back end with it.
I know that it adds more burden to Samba but I think respecting this
assumption would make
Samba 4 more attractive to people who already deployed some kind of DS
based solution and want to add Windows users and machines to it.
     

> Renames are great where this a problem we can't solve any other way, but
> I would hate to inflict Samba4* on the world where we could come up with
> better solutions.
>
> If you are going to rename this much, then I suggest you may wish to, as
> you proposed earlier, rewrite simple_ldap_map to use a real
> configuration file, shared with the schema mapping code.  Otherwise,
> these will get out of sync.
>
>  
>> There is still another problem with the provisioning tool that I'm
>> still investigating. Once this is working I will be able to look into
>> the 'make test'.
>>    
>
> Any chance you can post these (particularly the first patch) as
> git-format-patch?
>
> Thanks,
>
>  

--
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

[Andrew Bartlett]

On Tue, 2009-11-03 at 20:19 -0500, Dmitri Pal wrote:

> Andrew Bartlett wrote:
> > On Tue, 2009-11-03 at 17:50 -0500, Endi Sukma Dewata wrote:
> >  
> >> Andrew,
> >>
> >> Please take a look at the attached patch files.
> >>
> >> The first patch contains bug fixes for some minor issues.
> >>
> >> The second patch contains a number of additional schema mapping. When
> >> I tested the patches that I submitted previously, the schema mappings
> >> seemed to be enough for avoiding conflicts between AD schema and FDS
> >> schema. But now it seems there has been some changes so I have to add
> >> some more mappings.
> >>    
> >
> > OK.
> >
> >  
> >> In this patch I'm renaming some AD object classes using 'samba4' prefix
> >> because there are already FDS object classes with the same name/OID.
> >> I don't think we can just skip the AD classes and use the FDS classes
> >> because although they may look the same they are actually different.
> >> The AD classes are subclasses of samba4Top which requires AD-specific
> >> attributes.
> >>    
> >
> > I would prefer a more elegant solution.  Perhaps not loading those
> > classes in FDS, and allowing the FDS users to see the inheritance from
> > Samba4Top?  However, this is your mapping, and in the end I don't mind
> > how you do it (make sure you update the simple_ldap_map however!)
> >  
>
> I am not sure it is possible since this implies that the FDS user has to
> decide whether or
> not to load the conflicting schema before he starts to use his instance
> of FDS as a Samba
> back end. The general assumption about any DS instance OpenLDAP, FDS or
> any other IMO
> should be that it has been deployed before customer decided to use it as
> Samba back end with it.

This is an assumption that you have for FreeIPA, but it's not the way
the OpenLDAP backend works at the moment (because the things Samba4
needs are far, far more than just the Schema, it's also the whole tree
layout).  It is admirable goal however, and RedHat's research in this
area will make Samba4 easier to deploy to users happy with the 'Samba3'
approach.

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?  

> I know that it adds more burden to Samba but I think respecting this
> assumption would make
> Samba 4 more attractive to people who already deployed some kind of DS
> based solution and want to add Windows users and machines to it.

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.  

BTW, currently the FDS backend uses extensibleObject, which is even an
worse hack...

Finally, why is the Samba4 schema not always loaded in a FreeIPA
instance?   Isn't the plan to use Samba4's hdb-samba4 as the backend
behind the KDC?  It uses the (horrible, but understood) AD key format,
and so you will need the Samba4 schema loaded for that to work anyway.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

[Dmitri Pal]

Andrew Bartlett wrote:

> On Tue, 2009-11-03 at 20:19 -0500, Dmitri Pal wrote:
>  
>> Andrew Bartlett wrote:
>>    
>>> On Tue, 2009-11-03 at 17:50 -0500, Endi Sukma Dewata wrote:
>>>  
>>>      
>>>> Andrew,
>>>>
>>>> Please take a look at the attached patch files.
>>>>
>>>> The first patch contains bug fixes for some minor issues.
>>>>
>>>> The second patch contains a number of additional schema mapping. When
>>>> I tested the patches that I submitted previously, the schema mappings
>>>> seemed to be enough for avoiding conflicts between AD schema and FDS
>>>> schema. But now it seems there has been some changes so I have to add
>>>> some more mappings.
>>>>    
>>>>        
>>> OK.
>>>
>>>  
>>>      
>>>> In this patch I'm renaming some AD object classes using 'samba4' prefix
>>>> because there are already FDS object classes with the same name/OID.
>>>> I don't think we can just skip the AD classes and use the FDS classes
>>>> because although they may look the same they are actually different.
>>>> The AD classes are subclasses of samba4Top which requires AD-specific
>>>> attributes.
>>>>    
>>>>        
>>> I would prefer a more elegant solution.  Perhaps not loading those
>>> classes in FDS, and allowing the FDS users to see the inheritance from
>>> Samba4Top?  However, this is your mapping, and in the end I don't mind
>>> how you do it (make sure you update the simple_ldap_map however!)
>>>  
>>>      
>> I am not sure it is possible since this implies that the FDS user has to
>> decide whether or
>> not to load the conflicting schema before he starts to use his instance
>> of FDS as a Samba
>> back end. The general assumption about any DS instance OpenLDAP, FDS or
>> any other IMO
>> should be that it has been deployed before customer decided to use it as
>> Samba back end with it.
>>    
>
> This is an assumption that you have for FreeIPA, but it's not the way
> the OpenLDAP backend works at the moment (because the things Samba4
> needs are far, far more than just the Schema, it's also the whole tree
> layout).  It is admirable goal however, and RedHat's research in this
> area will make Samba4 easier to deploy to users happy with the 'Samba3'
> approach.
>
> 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?  
>
>  
>> I know that it adds more burden to Samba but I think respecting this
>> assumption would make
>> Samba 4 more attractive to people who already deployed some kind of DS
>> based solution and want to add Windows users and machines to it.
>>    
>
> 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.  
>
> BTW, currently the FDS backend uses extensibleObject, which is even an
> worse hack...
>
> Finally, why is the Samba4 schema not always loaded in a FreeIPA
> instance?   Isn't the plan to use Samba4's hdb-samba4 as the backend
> behind the KDC?  It uses the (horrible, but understood) AD key format,
> and so you will need the Samba4 schema loaded for that to work anyway.
>
>  

I am rising a use case. Unfortunately I am knowledgeable enough to come
up with
the answer. DSs are full of history and hacks as you pointed out. I
doubt it would be easy
to change. If we can load Samba 4 schema at the moment of IPA or DS
installation we
probably should do it if it:
* Does not contradict exiting RFCs or legacy features that DS can't fix
and has to live with forever
* Does not contradict with core features of the product (IPA schema is
flat on purpose)
* Does not cause issues with migration for people who already use DS and
upgrade to new version
with Samba schema included
* Makes deployment of Samba 4 easier

If this is the case I am all for it. But I suspect this is not the case.
This is why we were planing
to use 2 different instances of DS and replicate between them. But again
I am all for
better alternatives if they exist. As for KDC it looks like what  Luke
has done with
KDC and HDB layer is not directly usable by us.

We still plan to use enhanced DAL layer that would be able to go either
to IPA's DS tree directly
or will switch to Samba tree. We will not use it directly (that would be
insane)
but rather via either part of the HDB bridge Luke created or via iRPC
mechanism
you proposed when I was on the CIFS conference in September.
This will be prototyped. Simo will start working on this pretty soon.

But the point is that the area that stores Samba schema and IPA schema
are two separate schemas
and instances of DS. At least this is what was planned originally.
I am not sure how these two can be integrated.

But I was not concerned about IPA in my comment.
I was concerned more about a customer who has a DS (not IPA) now and wants
to add Samba 4 on top of it. Would be nice to be able
to just use what he has if the default tree is RFC compliant.
In IPA we removed OUs but standard schema has them so the standard
schema is closer to AD schema than IPA one so IPA is in worse
situation (for its own reasons).
Is it possible to not I do not know. You tell me.
May be it is something that would never be possible and
even DS user would have to migrate if they want to
start using Samba 4. I see this a barrier to adoption
this why I am asking.


> Andrew Bartlett
>
>  


--
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

[Endi Sukma Dewata-3]

Andrew,

Attached is the patch for the minor bugs. Thanks.

----- "Andrew Bartlett" <abartlet@...> 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.

Thanks.

--
Endi S. Dewata

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

[Andrew Bartlett]

On Tue, 2009-11-03 at 21:20 -0500, Dmitri Pal wrote:

> But I was not concerned about IPA in my comment.
> I was concerned more about a customer who has a DS (not IPA) now and wants
> to add Samba 4 on top of it. Would be nice to be able
> to just use what he has if the default tree is RFC compliant.
> In IPA we removed OUs but standard schema has them so the standard
> schema is closer to AD schema than IPA one so IPA is in worse
> situation (for its own reasons).
> Is it possible to not I do not know. You tell me.
> May be it is something that would never be possible and
> even DS user would have to migrate if they want to
> start using Samba 4. I see this a barrier to adoption
> this why I am asking.

So, my 'evil plan' has been to work with Endi to make as much of his
work viable for this exact thing.  That is, by using SambaSID and other
'existing' attributes and objectClass names as much as possible, another
talented individual may be able to complete enough of the mappings (and
adjust their schema for the rest) such that this works.

For example, we can emulate instanceType (it follows strict rules, only
distinguishing partition heads - which we know at runtime).  We can
store extra information such as the ntSecurityDescriptor, we can relax
the rules around 'person' on the DS side and and we can map the
sambaNTPassword into the unicodePwd, the uid to samAccountName.

It remains a lot of work, but the benefits are equally high.   We also
have the ldb_map code which is underutilised in the current code, but
still works (by the very good fortune of having a testsuite).

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

[Endi Sukma Dewata-3]

Andrew,

----- "Andrew Bartlett" <abartlet@...> 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

[Endi Sukma Dewata-3]

Andrew,

Attach is another patch for the other problem I found during
provisioning. The relax control wasn't defined in the list
so the ldap_encode() failed and the request was never sent
to FDS.

I also found another problem in the provisioning tool. The script
invokes post_setup() to execute additional backend-specific tasks:

    provision_backend.post_setup()

For FDS, the post_setup is configured as follows:

    result.post_setup = fds_post_setup

The fds_post_setup() is defined within provision_fds_backend()
as follows:

    def fds_post_setup(self):

The provision_fds_backend() itself is not a member function, so
the self parameter is considered a regular parameter, not a pointer
to the object, so this invocation fails because it's missing an
argument:

    provision_backend.post_setup()

I think ideally this problem should be addressed using polymorphism
instead of function pointer. So we need to create 2 subclasses of
the ProvisionBackend called OpenLDAPBackend and FDSBackend. The
base class should include an empty post_setup() and this should be
overriden in the FDSBackend. In the main code the code should
instantiate the class as follows:

    if backend_type == "fedora-ds":
        provision_backend = FDSBackend(...)

    if backend_type == "openldap":
        provision_backend = OpenLDAPBackend(...)

    provision_backend.post_setup()

We could also do this on other parts of the code to cleanly separate
FDS and OpenLDAP code. What do you think?

Thanks.

--
Endi S. Dewata

[0001-s4-Added-LDB_CONTROL_RELAX_OID-into-ldap_known_con.patch]

---

From eb6170e691cf477ca64e3e70c037b615df689171 Mon Sep 17 00:00:00 2001
From: Endi S. Dewata <edewata@...>
Date: Wed, 4 Nov 2009 15:21:57 -0600
Subject: [PATCH] s4 - Added LDB_CONTROL_RELAX_OID into ldap_known_controls.

---
 source4/libcli/ldap/ldap_controls.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/source4/libcli/ldap/ldap_controls.c b/source4/libcli/ldap/ldap_controls.c
index 86493c8..8b744a6 100644
--- a/source4/libcli/ldap/ldap_controls.c
+++ b/source4/libcli/ldap/ldap_controls.c
@@ -1273,6 +1273,8 @@ static const struct ldap_control_handler ldap_known_controls[] = {
  { "1.3.6.1.4.1.7165.4.3.2", NULL, NULL },
 /* DSDB_EXTENDED_REPLICATED_OBJECTS_OID is internal only, and has no network representation */
  { "1.3.6.1.4.1.7165.4.4.1", NULL, NULL },
+/* LDB_CONTROL_RELAX_OID is internal only, and has no network representation */
+ { "1.3.6.1.4.1.4203.666.5.12", NULL, NULL },
  { DSDB_OPENLDAP_DEREFERENCE_CONTROL, decode_openldap_dereference, encode_openldap_dereference},
  { NULL, NULL, NULL }
 };
--
1.6.0.6

---

[Andrew Bartlett]

On Wed, 2009-11-04 at 17:07 -0500, Endi Sukma Dewata wrote:
> Andrew,
>
> Attach is another patch for the other problem I found during
> provisioning. The relax control wasn't defined in the list
> so the ldap_encode() failed and the request was never sent
> to FDS.

OK.  The patch's comment is incorrect however - it does have a network
representation - it is a well-known and well-defined OID for LDAP
network operations.

> I also found another problem in the provisioning tool. The script
> invokes post_setup() to execute additional backend-specific tasks:
>
>     provision_backend.post_setup()
>
> For FDS, the post_setup is configured as follows:
>
>     result.post_setup = fds_post_setup
>
> The fds_post_setup() is defined within provision_fds_backend()
> as follows:
>
>     def fds_post_setup(self):
>
> The provision_fds_backend() itself is not a member function, so
> the self parameter is considered a regular parameter, not a pointer
> to the object, so this invocation fails because it's missing an
> argument:
>
>     provision_backend.post_setup()

Ahh, oops :-)

(Clearly I've not tested this.  Sorry).

> I think ideally this problem should be addressed using polymorphism
> instead of function pointer. So we need to create 2 subclasses of
> the ProvisionBackend called OpenLDAPBackend and FDSBackend. The
> base class should include an empty post_setup() and this should be
> overriden in the FDSBackend. In the main code the code should
> instantiate the class as follows:
>
>     if backend_type == "fedora-ds":
>         provision_backend = FDSBackend(...)
>
>     if backend_type == "openldap":
>         provision_backend = OpenLDAPBackend(...)
>
>     provision_backend.post_setup()
>
> We could also do this on other parts of the code to cleanly separate
> FDS and OpenLDAP code. What do you think?

Yes, this is the approach I was trying to head towards.  Just make sure
we don't run the LDB specific functions when we are trying to use
OpenLDAP or Fedora DS.

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

[Andrew Bartlett]

On Wed, 2009-11-04 at 02:41 -0500, Endi Sukma Dewata wrote:

> Andrew,
>
> ----- "Andrew Bartlett" <abartlet@...> 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.

[Endi Sukma Dewata-3]

Andrew,

----- "Andrew Bartlett" <abartlet@...> wrote:

> > Attach is another patch for the other problem I found during
> > provisioning. The relax control wasn't defined in the list
> > so the ldap_encode() failed and the request was never sent
> > to FDS.
>
> OK.  The patch's comment is incorrect however - it does have a network
> representation - it is a well-known and well-defined OID for LDAP
> network operations.

So do we need to write handlers for this control? Or do we still want to
remove it before sending the request to the backend (i.e. internal only)?
Please see the updated patch.

> Yes, this is the approach I was trying to head towards. Just make sure
> we don't run the LDB specific functions when we are trying to use
> OpenLDAP or Fedora DS.

Ok, I'll try to make several incremental changes rather than one big
change. Thanks.

--
Endi S. Dewata

[0001-s4-Added-LDB_CONTROL_RELAX_OID-into-ldap_known_con.patch]

---

From eb6170e691cf477ca64e3e70c037b615df689171 Mon Sep 17 00:00:00 2001
From: Endi S. Dewata <edewata@...>
Date: Wed, 4 Nov 2009 15:21:57 -0600
Subject: [PATCH] s4 - Added LDB_CONTROL_RELAX_OID into ldap_known_controls.

---
 source4/libcli/ldap/ldap_controls.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/source4/libcli/ldap/ldap_controls.c b/source4/libcli/ldap/ldap_controls.c
index 86493c8..8b744a6 100644
--- a/source4/libcli/ldap/ldap_controls.c
+++ b/source4/libcli/ldap/ldap_controls.c
@@ -1273,6 +1273,8 @@ static const struct ldap_control_handler ldap_known_controls[] = {
  { "1.3.6.1.4.1.7165.4.3.2", NULL, NULL },
 /* DSDB_EXTENDED_REPLICATED_OBJECTS_OID is internal only, and has no network representation */
  { "1.3.6.1.4.1.7165.4.4.1", NULL, NULL },
+/* LDB_CONTROL_RELAX_OID is internal only */
+ { "1.3.6.1.4.1.4203.666.5.12", NULL, NULL },
  { DSDB_OPENLDAP_DEREFERENCE_CONTROL, decode_openldap_dereference, encode_openldap_dereference},
  { NULL, NULL, NULL }
 };
--
1.6.0.6

---