Endi, since you are an LDAP backend expert of s4, do you have some time to investigate this bug? We think that it's only related to backends (maybe also 389 directory server).

Hi, I noticed this happens with 389 DS too using a recent Samba build. I will investigate this.

I just pushed three fixes regarding this kindly provided by Endi. I hope he is willing to help us also with the last issue pointed out on the mailing list.

Created attachment 5216 [details]
Patch #1

Created attachment 5217 [details]
Patch #2

Created attachment 5218 [details]
Patch #3

Hi, I added the 3 patches into this bug for reference. I will address the additional issues mentioned by Andrew in a separate patch. Thanks.

Hi Endi,
thanks. After applying the patches, I can provision.

Regards,
  Dirk

Created attachment 5219 [details]
Patch #4

Hi Dirk,

It turns out the patches that have been accepted were patch #2-4. Patch #1 did fix the problem, but I'm currently working to replace it with a different mechanism.

Comment on attachment 5217 [details]
Patch #2

Applied

Comment on attachment 5218 [details]
Patch #3

Applied

Comment on attachment 5219 [details]
Patch #4

Applied

I as QA person wouldn't say fully fixed since you (Dirk) probably made also use of patch 1. This, as Endi pointed out, wasn't accepted and an improved version will make it into our source tree. Only then this issue can be closed as "FIXED".

Created attachment 5223 [details]
Patch #5

Patch #5 replaces patch #1 by removing the LDB_CONTROL_AS_SYSTEM_OID and DSDB_CONTROL_DN_STORAGE_FORMAT_OID controls after being used by the LDB modules.

with installing only patches 2-5, the provisioning process works for me.
I have strange effects after joining with a Win XP Sp3 client and browsing the AD, though: After a few clicks (opening / closing the structures), I get the error message "The Server is not responding". This can be temporarely overcome by restarting the samba daemon. 
Not sure whether this is dependand to this bug or just another one.

Ah, didn't see - both bugs (7040, 7042) were reported by you :) . Let us see what we can do. I change the title of this to "Provisioning fails with directory backends" - this is more expressive.

It would be nice if tridge could comment on the remaining patch.

Comment on attachment 5223 [details]
Patch #5

Endi, tridge and I discussed your patch. Basically is it right to look for all places where we perform a lookup for the SYSTEM control.
But then you shouldn't try to remove the control itself, but simply specify <control object>->critical = 0; (<control object> returned by "ldb_request_get_control" or after creation).

Created attachment 5270 [details]
A fix proposal (at least for the SYSTEM control)

I pushed my fix proposal after some testing to "master".
Dirk, could you retest the provision using a recent "master" source tree without Endi's patches?
If that works we are done. Otherwise we will have to fix more.

Hi Matthias,
checked out heads/master (which was 204e4b2 at that time) and recompiled as requested.
Unfortunately, I cannot provision then:

sudo ./setup/provision \
> --realm=test.LOCAL --domain=test \
> --server-role='domain controller' \
> --ldap-backend-type=openldap \
> --username=samba-admin \
> --password=PWChanged \
> --adminpass=PWChanged \
> --ldapadminpass=PWChanged \
> --slapd-path='/usr/local/libexec/slapd' 
hdb_db_open: database "cn=Schema,cn=Configuration,dc=test,dc=local": db_o
pen(/usr/local/samba/private/ldap/db/schema/id2entry.bdb) failed: No such file o
r directory (2).
backend_startup_one (type=hdb, suffix="cn=Schema,cn=Configuration,dc=test
,dc=local"): bi_db_open failed! (2)
slap_startup failed (test would succeed using the -u switch)
Failed to bind - LDAP client internal error: NT_STATUS_UNEXPECTED_NETWORK_ERROR
Failed to connect to 'ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi'
Setting up share.ldb
Setting up secrets.ldb
Setting up the registry
Setting up the privileges database
Setting up idmap db
Setting up SAM db
Setting up sam.ldb partitions and settings
Setting up sam.ldb rootDSE
Pre-loading the Samba 4 and AD schema
Adding DomainDN: DC=test,DC=local
pdc_fsmo_init: no domain object present: (skip loading of domain details)

Traceback (most recent call last):
  File "./setup/provision", line 222, in <module>
    nosync=opts.nosync,ldap_dryrun_mode=opts.ldap_dryrun_mode)
  File "bin/python/samba/provision.py", line 1240, in provision
    dom_for_fun_level=dom_for_fun_level)
  File "bin/python/samba/provision.py", line 927, in setup_samdb
    "SAMBA_VERSION_STRING": version
  File "bin/python/samba/provision.py", line 265, in setup_modify_ldif
    ldb.modify_ldif(data)
  File "bin/python/samba/__init__.py", line 261, in modify_ldif
    self.modify(msg, controls)
_ldb.LdbError: (1, 'LDAP client internal error: NT_STATUS_INTERNAL_ERROR')
A transaction is still active in ldb context [0xafa53d8] on /usr/local/samba/pri
vate/secrets.ldb

Just for the record, this is Andrew Bartlett's that was posted on
samba-technical on Jan 22, 2010:

> We should not have a network implementation of LDB_CONTROL_AS_SYSTEM_OID
> - for security this should never be accepted over LDAP.  

> On further reflection:  A patch would be accepted that ensures this
> remains true.  To fix the original bug, the ACL modules need to be
> modified to swallow the control, like I discuss here:

> We should also figure out what is causing
> DSDB_CONTROL_DN_STORAGE_FORMAT_OID to get to the backend, without being
> intercepted and interpreted by the extended_dn_out module. 

I think setting the control to not critical is insufficient. Please take a look at ldap_encode_control() in libcli/ldap/ldap_message.c:

// check all known controls
for (i = 0; handlers[i].oid != NULL; i++) {

    // if the control is registered
    if (strcmp(handlers[i].oid, ctrl->oid) == 0) {
        
        // if no encoder function is defined for the control
        if (!handlers[i].encode) {

            // if the control is critical return false (error)
            if (ctrl->critical) {
                return false;

            } else { // if not critical don't encode the control (skip)
                return true;
            }
        }

        ... encode the control ...

        break;
    }
}

// if the control is not registered return false (error)
if (handlers[i].oid == NULL) {
    return false;
}

So for this to work, the control would have to be registered as in patch #1
which was rejected.

So, where are we at with regard to swallowing the internal controls?  What internal-only controls are still being sent to the backend?

It seems reasonable to allow the LDAP client code to ignore non-critical controls it does not know how to parse, but it still does not fill me with delight.  (As I really don't like silent discards, particularly on the client which we control). 

Hi Andrew, I believe we are still trying to remove LDB_CONTROL_AS_SYSTEM_OID and
DSDB_CONTROL_DN_STORAGE_FORMAT_OID controls. Could you take a look at patch #5? Is that what you meant by "swallowing the internal controls"?

Yes, patch 5 is the approach I was expecting. 

Operating LDB in 'trace mode' (difficult in provision due to silly global varaible issues) is a good way to figure out what is going wrong.  I suggest you hack the source to enable it unconditionally, and see why the control is not stripped. 

Hi Andrew, I have traced and looked at the code, these controls are only used in the acl and extended_dn_out modules. Currently there is nothing in the code that will remove the controls. So in patch #5 I'm doing that by by calling save_controls() in those modules. Do you mean that the controls should have been removed somewhere else? Please note that after applying patch #5 the problem no longer appears.

My view is that patch #5 is the correct approach.  I'll talk to tridge about his objections and the options. 

Hi, do we have a solution for this bug? Thanks.

OK, I've finally talked to tridge, who has good reasons not to like save_controls().  Therefore, the right way to deal with this is to make the ldap client code ignore non-critical controls.

We should, before we add parsers for as_system in particular, add code to the Samba4 LDAP server to ensure that all unadvertised controls are stripped when in the incoming request (and denied if critical)

I'd like to resubmit Patch #1. I have applied this patch against revision 1933214108d1a71bc6473a696ce35020a427d8f4 and I was able to complete the quick tests with the default backend, FDS, and OpenLDAP. It also has been tested by Dirk in comment #8.

I think Patch #1 should be sufficient to close this bug because it fixed the reported problem. As mentioned in comment #23, the LDAP client code can already ignore non-critical controls as long as the controls are registered with NULL handlers, which is what Patch #1 is doing. Any other changes would be addressed separately from this bug.

I've merged Endi's patches, including patch #1.

I do wish to apologise for the length of time it has taken to resolve this issue. 

Hi,
sorry to say that, BUT:
- synced to head (=release-4-0-0alpha11-66-g204e4b2), so Endi's patches all should be included here
- recompiled, reinstalled
- provision still / again (?) fails:
sudo ./setup/provision \
> --realm=TEST.LOCAL --domain=TEST \
> --server-role='domain controller' \
> --ldap-backend-type=openldap \
> --username=samba-admin \
> --password=PWChanged \
> --adminpass=PWChanged \
> --ldapadminpass=PWChanged \
> --slapd-path='/usr/local/libexec/slapd' 
hdb_db_open: database "cn=Schema,cn=Configuration,dc=TEST,dc=local": db_open(/usr/local/samba/private/ldap/db/schema/id2entry.bdb) failed: No such file or directory (2).
backend_startup_one (type=hdb, suffix="cn=Schema,cn=Configuration,dc=TEST,dc=local"): bi_db_open failed! (2)
slap_startup failed (test would succeed using the -u switch)
Failed to bind - LDAP client internal error: NT_STATUS_UNEXPECTED_NETWORK_ERROR
Failed to connect to 'ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi'
Setting up share.ldb
Setting up secrets.ldb
Setting up the registry
Setting up the privileges database
Setting up idmap db
Setting up SAM db
Setting up sam.ldb partitions and settings
Setting up sam.ldb rootDSE
Pre-loading the Samba 4 and AD schema
Adding DomainDN: DC=TEST,DC=local
pdc_fsmo_init: no domain object present: (skip loading of domain details)

Traceback (most recent call last):
  File "./setup/provision", line 222, in <module>
    nosync=opts.nosync,ldap_dryrun_mode=opts.ldap_dryrun_mode)
  File "bin/python/samba/provision.py", line 1240, in provision
    dom_for_fun_level=dom_for_fun_level)
  File "bin/python/samba/provision.py", line 927, in setup_samdb
    "SAMBA_VERSION_STRING": version
  File "bin/python/samba/provision.py", line 265, in setup_modify_ldif
    ldb.modify_ldif(data)
  File "bin/python/samba/__init__.py", line 261, in modify_ldif
    self.modify(msg, controls)
_ldb.LdbError: (1, 'LDAP client internal error: NT_STATUS_INTERNAL_ERROR')
A transaction is still active in ldb context [0xa1a23d8] on /usr/local/samba/private/secrets.ldb

Regards,
  Dirk

Hey Guys, is there anything I can do to help you finding the difference between Endies patch against alpha 11 which weorked and the current state of the mainline branch where the fix seem not to show its salvation?
From my view, we are a tiny step before the final solution - and I love things to be closed finally.

Regards,
  Dirk

I ran into this using either alpha11 or tp2:

Administrator password will be set randomly!
Traceback (most recent call last):
  File "setup/provision", line 222, in <module>
    nosync=opts.nosync,ldap_dryrun_mode=opts.ldap_dryrun_mode)
  File "bin/python/samba/provision.py", line 1201, in provision
    provision_backend.init()
  File "bin/python/samba/provisionbackend.py", line 190, in init
    raise ProvisioningError("Warning: LDAP-Backend must be setup with path to slapd, e.g. --slapd-path=\"/usr/local/libexec/slapd\"!")
samba.provisionexceptions.ProvisioningError: Warning: LDAP-Backend must be setup with path to slapd, e.g. --slapd-path="/usr/local/libexec/slapd"!

The instructions in the wiki (http://wiki.samba.org/index.php/Samba4/LDAP_Backend/OpenLDAP) point to using:

setup/provision-backend --realm=ldap.samba.example.com --ldap-admin-pass=penguin --ldap-backend-type=openldap 

To provision the backend, but provision-backend is not compiled.

I was trying to compile Samba4 to use an OpenLDAP directory that is an instance of OpenDirectory running on Apple SnowLeopard Server.

Mike: 

This bug isn't about your wanting to use Samba4's LDAP backend against an existing directory.  

Please raise on samba-technical (where I will try and explain the limitations).  In short, against an existing OpenDirectory just isn't possible at the moment. 

As far as I can tell, this is fixed.

I've tested with 6de83ef6277d8506478ce5ff43d33e39541b310c and OpenLDAP CVS HEAD (from this week). 

Please open any new regressions or issues in a new bug.