I've been working with current CVS OpenLDAP and the memberof plugin, for Samba4 integration.
Following your suggestion, I'm trying to load multiple memberof instances, but the syntax doesn't seem to work for me. Attached is how I'm currently configuring the overlay. It causes this when loading:
overlay_config(): overlay "memberof" already in list overlay_config(): overlay "memberof" already in list ...
It also only appears to work for the first entry (happily that is member/memberof, and this seems to have worked).
Is the syntax I'm using correct, or does the module need to be reworked for this operation?
Finally, I'm wondering if the error returns can be adjusted:
When I add invalid member to a group, OpenLDAP returns LDAP_CONSTRAINT_VIOLATION <adding non-existing object as group member>, but AD returns error 32, LDAP_NO_SUCH_OBJECT for this situation. Would it be reasonable to change this, or could it be made configurable. Having the LDAP server give me the error the client expects would avoid the need for a translation layer. (it might be nobody ever looks at this, but I don't like to make that assumption).
Thanks,
Andrew Bartlett
Andrew Bartlett wrote:
I've been working with current CVS OpenLDAP and the memberof plugin, for Samba4 integration.
Following your suggestion, I'm trying to load multiple memberof instances, but the syntax doesn't seem to work for me. Attached is how I'm currently configuring the overlay. It causes this when loading:
overlay_config(): overlay "memberof" already in list overlay_config(): overlay "memberof" already in list ...
(Sorry, I don't have any feedback on that point.)
defaultsearchbase DC=samba,DC=example,DC=com
backend hdb database hdb suffix CN=Schema,CN=Configuration,DC=samba,DC=example,DC=com
None of the backends in OpenLDAP have ever implemented any meaningful actions for the "backend" directive. You should just omit that.
Andrew Bartlett wrote:
When I add invalid member to a group, OpenLDAP returns LDAP_CONSTRAINT_VIOLATION <adding non-existing object as group member>, but AD returns error 32, LDAP_NO_SUCH_OBJECT for this situation.
Hmm, this is a result of a modify operation for which an additional constraint is enforced. So I think the error code returned by OpenLDAP is correct. Because the entry to be modified really exists it would be wrong to return LDAP_NO_SUCH_OBJECT.
Would it be reasonable to change this, or could it be made configurable.
I'd even recommend not to enable this by configuration.
(it might be nobody ever looks at this, but I don't like to make that assumption).
I'm nitpicking here because my web2ldap has a special exception handler for dealing with LDAP_NO_SUCH_OBJECT (automagically lookup SRV RR for dc-style DNs etc).
Ciao, Michael.
Andrew Bartlett wrote:
I've been working with current CVS OpenLDAP and the memberof plugin, for Samba4 integration.
Following your suggestion, I'm trying to load multiple memberof instances, but the syntax doesn't seem to work for me. Attached is how I'm currently configuring the overlay. It causes this when loading:
overlay_config(): overlay "memberof" already in list overlay_config(): overlay "memberof" already in list
That's harmless; It's like that because in principle there might be overlays that can only be instantiated once, but this now has to be declared by setting an appropriate flag, which is tested for right after that message. So I'm conditioning the message only in case a once-only overlay is being instantiated multiple times.
...
It also only appears to work for the first entry (happily that is member/memberof, and this seems to have worked).
AFAIR, it should work for all. However, with the combination of parameters you specified I've spotted an error: it seems to only work when __modifying__ a group, not when creating it with an already existing member. I'm looking at it, and I'll file an ITS as soon as I can single out what's the critical combination of parameters.
Is the syntax I'm using correct, or does the module need to be reworked for this operation?
Probably, the module should be reworked in many directions, but not for what you're trying to do (except fixing the bug I mentioned above).
Finally, I'm wondering if the error returns can be adjusted:
When I add invalid member to a group, OpenLDAP returns LDAP_CONSTRAINT_VIOLATION <adding non-existing object as group member>, but AD returns error 32, LDAP_NO_SUCH_OBJECT for this situation. Would it be reasonable to change this, or could it be made configurable. Having the LDAP server give me the error the client expects would avoid the need for a translation layer. (it might be nobody ever looks at this, but I don't like to make that assumption).
LDAP_CONSTRAINT_VIOLATION was chosen since it correctly expresses what is the real error: the overlay was configured to be picky on checking referential integrity, which, to me, is a constraint; LDAP would otherwise be happy to have broken referential integrity, since that's the responsibility of the application layer (the overlay in our case). Returning LDAP_NO_SUCH_OBJECT for an operation (add, modify) whose object (the request DN) is that of the group, and it exists, would be rather misleading. Of course, as the slapo-memberof is an aplication layer, I don't see a strong objection to making this error configurable, but I strongly recommend to use LDAP_CONSTRAINT_VIOLATION as default.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
It also only appears to work for the first entry (happily that is member/memberof, and this seems to have worked).
AFAIR, it should work for all. However, with the combination of parameters you specified I've spotted an error: it seems to only work when __modifying__ a group, not when creating it with an already existing member. I'm looking at it, and I'll file an ITS as soon as I can single out what's the critical combination of parameters.
All issues should be fixed in HEAD (ITS#5299); please test. p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
On Thu, 2007-12-27 at 17:30 +0100, Pierangelo Masarati wrote:
LDAP_CONSTRAINT_VIOLATION was chosen since it correctly expresses what is the real error: the overlay was configured to be picky on checking referential integrity, which, to me, is a constraint; LDAP would otherwise be happy to have broken referential integrity, since that's the responsibility of the application layer (the overlay in our case). Returning LDAP_NO_SUCH_OBJECT for an operation (add, modify) whose object (the request DN) is that of the group, and it exists, would be rather misleading. Of course, as the slapo-memberof is an aplication layer, I don't see a strong objection to making this error configurable, but I strongly recommend to use LDAP_CONSTRAINT_VIOLATION as default.
I certainly agree with regard to defaults. I just need to be able to configure it, as trying to pick out this error (I think i would have to parse the textual error return) and remap it for windows clients would be a real pain...
I do realise that the mission of OpenLDAP in general, and my hope to use it as a backend to Samba4 will diverge significantly. I would have OpenLDAP handling this area at all, except that hdb is handling the subtree renames, and linked attributes are fundamentally linked to that.
Andrew Bartlett
On Thu, 2007-12-27 at 19:51 +0100, Pierangelo Masarati wrote:
Pierangelo Masarati wrote:
It also only appears to work for the first entry (happily that is member/memberof, and this seems to have worked).
AFAIR, it should work for all. However, with the combination of parameters you specified I've spotted an error: it seems to only work when __modifying__ a group, not when creating it with an already existing member. I'm looking at it, and I'll file an ITS as soon as I can single out what's the critical combination of parameters.
All issues should be fixed in HEAD (ITS#5299); please test. p.
The warning is gone, but the link between masteredBy and hasMasterNCs still doesn't appear.
It is actually a special case, as it is between containers/databases/partitions (what is the right term?).
For example: dn: cn=NTDS Settings,cn=LOCALDC1,cn=Servers,cn=Default-First-Site-Name,cn=Sites,cn=Configuration,dc=samba,dc=example,dc=com hasMasterNCs: cn=Configuration,dc=samba,dc=example,dc=com hasMasterNCs: cn=Schema,cn=Configuration,dc=samba,dc=example,dc=com hasMasterNCs: dc=samba,dc=example,dc=com
This is record is created with an 'add', but none of those link targets have a masteredBy record.
overlay memberof memberof-dangling error memberof-refint TRUE memberof-group-oc top memberof-member-ad hasMasterNCs memberof-memberof-ad masteredBy
Perhaps there a restriction that the memberof-group-oc should be unique?
Thanks,
Andrew Bartlett
Andrew Bartlett wrote:
The warning is gone, but the link between masteredBy and hasMasterNCs still doesn't appear.
It is actually a special case, as it is between containers/databases/partitions (what is the right term?).
OK, the overlay, the way you're using it (stacking within a database) will only allow reverse links between entities that belong to that database. You can try making that instance of the overlay as global (i.e. placing it before the first database). I don't think I ever tested it that way, so there might be pending issues, but in principle it should work.
For example: dn: cn=NTDS Settings,cn=LOCALDC1,cn=Servers,cn=Default-First-Site-Name,cn=Sites,cn=Configuration,dc=samba,dc=example,dc=com hasMasterNCs: cn=Configuration,dc=samba,dc=example,dc=com hasMasterNCs: cn=Schema,cn=Configuration,dc=samba,dc=example,dc=com hasMasterNCs: dc=samba,dc=example,dc=com
This is record is created with an 'add', but none of those link targets have a masteredBy record.
overlay memberof memberof-dangling error memberof-refint TRUE memberof-group-oc top memberof-member-ad hasMasterNCs memberof-memberof-ad masteredBy
Perhaps there a restriction that the memberof-group-oc should be unique?
No, there shouldn't. You usage is quite different from what I envisaged, though, as using "top" for the group objectclass is definitely triggering consistency checks more often than I expected.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
Andrew Bartlett wrote:
The warning is gone, but the link between masteredBy and hasMasterNCs still doesn't appear.
It is actually a special case, as it is between containers/databases/partitions (what is the right term?).
OK, the overlay, the way you're using it (stacking within a database) will only allow reverse links between entities that belong to that database. You can try making that instance of the overlay as global (i.e. placing it before the first database). I don't think I ever tested it that way, so there might be pending issues, but in principle it should work.
I had to rework the frontend infrastructure a bit to allow the slapo-memberof to be used as global, but it seems to work now. I've filed ITS#5301 to take care of this issue.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
On Sat, 2007-12-29 at 16:06 +0100, Pierangelo Masarati wrote:
Pierangelo Masarati wrote:
Andrew Bartlett wrote:
The warning is gone, but the link between masteredBy and hasMasterNCs still doesn't appear.
It is actually a special case, as it is between containers/databases/partitions (what is the right term?).
OK, the overlay, the way you're using it (stacking within a database) will only allow reverse links between entities that belong to that database. You can try making that instance of the overlay as global (i.e. placing it before the first database). I don't think I ever tested it that way, so there might be pending issues, but in principle it should work.
I had to rework the frontend infrastructure a bit to allow the slapo-memberof to be used as global, but it seems to work now. I've filed ITS#5301 to take care of this issue.
Great. It seems to work!
However, my further tests (attempting to rename cn=ldaptestuser2,cn=users,DC=samba,DC=example,DC=com into cn=ldaptestuser3,cn=users,DC=samba,DC=example,DC=com)
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1170099088 (LWP 26101)] 0x0808a285 in slap_mods_obsolete_check () (gdb) bt full #0 0x0808a285 in slap_mods_obsolete_check () No symbol table info available. #1 0x0808a969 in fe_op_modify () No symbol table info available. #2 0x402e6cd0 in memberof_value_modify (op=0x9e42a68, rs=<value optimized out>, ndn=<value optimized out>, ad=0x9c06690, old_dn=0x9e42a7c, old_ndn=0x9e42a84, new_dn=0x45be36f4, new_ndn=0x45be36e4) at memberof.c:501 on = (slap_overinst *) 0x9c06520 mo = (memberof_t *) 0x9c06628 op2 = {o_hdr = 0x9e42b3c, o_tag = 102, o_time = 1198996875, o_tincr = 197, o_bd = 0x9c0a2d8, o_req_dn = {bv_len = 52, bv_val = 0x45be5b74 "cn=ldaptestgroup,cn=users,dc=samba,dc=example,dc=com"}, o_req_ndn = {bv_len = 52, bv_val = 0x45be5b74 "cn=ldaptestgroup,cn=users,dc=samba,dc=example,dc=com"}, o_request = {oq_add = {rs_modlist = 0x45be3490, rs_e = 0x0}, oq_bind = { rb_method = 1170093200, rb_cred = {bv_len = 0, bv_val = 0xffffffff <Address 0xffffffff out of bounds>}, rb_edn = { bv_len = 16, bv_val = 0x45be5394 "cn=ldaptestuser3"}, rb_ssf = 16, rb_mech = {bv_len = 1170101188, bv_val = 0x0}}, oq_compare = { rs_ava = 0x45be3490}, oq_modify = {rs_mods = {rs_modlist = 0x45be3490, rs_no_opattrs = 0 '\0'}, rs_increment = -1}, oq_modrdn = {rs_mods = { rs_modlist = 0x45be3490, rs_no_opattrs = 0 '\0'}, ---Type <return> to continue, or q <return> to quit--- rs_deleteoldrdn = -1, rs_newrdn = {bv_len = 16, bv_val = 0x45be5394 "cn=ldaptestuser3"}, rs_nnewrdn = {bv_len = 16, bv_val = 0x45be53c4 "cn=ldaptestuser3"}, rs_newSup = 0x0, rs_nnewSup = 0x45be407c}, oq_search = {rs_scope = 1170093200, rs_deref = 0, rs_slimit = -1, rs_tlimit = 16, rs_limit = 0x45be5394, rs_attrsonly = 16, rs_attrs = 0x45be53c4, rs_filter = 0x0, rs_filterstr = {bv_len = 1170096252, bv_val = 0x0}}, oq_abandon = { rs_msgid = 1170093200}, oq_cancel = {rs_msgid = 1170093200}, oq_extended = {rs_reqoid = {bv_len = 1170093200, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0x10}, oq_pwdexop = {rs_extended = { rs_reqoid = {bv_len = 1170093200, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0x10}, rs_old = {bv_len = 1170101140, bv_val = 0x10 <Address 0x10 out of bounds>}, rs_new = { bv_len = 1170101188, bv_val = 0x0}, rs_mods = 0x45be407c, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0x9e42c64, o_authz = { sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = { bv_len = 37, bv_val = 0x9c0a600 "cn=Manager,dc=samba,dc=example,dc=com"}, sai_ndn = { bv_len = 37, ---Type <return> to continue, or q <return> to quit--- bv_val = 0x9c0a660 "cn=manager,dc=samba,dc=example,dc=com"}, sai_ssf = 71, sai_transport_ssf = 71, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x9e33220, o_res_ber = 0x0, o_callback = 0x45be354c, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x45be57ec "20071230064115.762010Z#000000#000#000000"}, o_private = 0x0, o_next = {stqe_next = 0x0}} rs2 = {sr_type = REP_RESULT, sr_tag = 103, sr_msgid = 104, sr_err = 0, sr_matched = 0x0, sr_text = 0x45be2ce4 "modify/af\211�\aT<\210@\234��\t\005", sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x0}, sru_extended = { r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} cb = {sc_next = 0x0, sc_response = 0x8081b70 <slap_null_cb>, sc_cleanup = 0, sc_private = 0x0} mod = {{sml_mod = {sm_desc = 0x9c06690, sm_values = 0x45be353c, sm_nvalues = 0x45be351c, sm_numvals = 1, sm_op = 1, sm_flags = 1, sm_type = {bv_len = 6, bv_val = 0x9bcec38 "member"}}, sml_next = 0x9e2efe8}, {sml_mod = {sm_desc = 0x0, sm_values = 0x0, sm_nvalues = 0x0, sm_numvals = 0, sm_op = 0, sm_flags = 0, sm_type = { bv_len = 0, bv_val = 0x0}}, sml_next = 0x0}} ml = <value optimized out> values = {{bv_len = 165948008, bv_val = 0x45be3744 "�\177\031 \b"}, { ---Type <return> to continue, or q <return> to quit--- bv_len = 1170093812, bv_val = 0x45be3568 "\0307�E�\202.@\220f�\t|*�\t\204*�\t�6�E�6�E \005"}, { bv_len = 52, bv_val = 0x45be5234 "cn=ldaptestuser2,cn=users,dc=samba,dc=example,dc=com"}, {bv_len = 0, bv_val = 0x0}} nvalues = {{bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x9e436b8 "\bP�E(\�E\bP�E\001"}, {bv_len = 52, bv_val = 0x45be52d4 "cn=ldaptestuser2,cn=users,dc=samba,dc=example,dc=com"}, {bv_len = 0, bv_val = 0x0}} mcnt = 0 __PRETTY_FUNCTION__ = "memberof_value_modify" #3 0x402e82fc in memberof_response (op=0x9e42a68, rs=0x45be40f8) at memberof.c:1463 vals = <value optimized out>
Thank you very much for all your efforts on this so far!
Andrew Bartlett
Andrew Bartlett wrote:
Great. It seems to work!
However, my further tests (attempting to rename cn=ldaptestuser2,cn=users,DC=samba,DC=example,DC=com into cn=ldaptestuser3,cn=users,DC=samba,DC=example,DC=com)
Should be fixed now in HEAD. Please test.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
On Wed, 2008-01-02 at 22:50 +0100, Pierangelo Masarati wrote:
Andrew Bartlett wrote:
Great. It seems to work!
However, my further tests (attempting to rename cn=ldaptestuser2,cn=users,DC=samba,DC=example,DC=com into cn=ldaptestuser3,cn=users,DC=samba,DC=example,DC=com)
Should be fixed now in HEAD. Please test.
p.
This seems to work. I've found some more challenges (such as, should a rename onto an entry's own DN work), but I'll try and work on that next week. (I suspect this is an area where I can write a module to cause that to be a no-op, rather than ask for changes in OpenLDAP).
Andrew Bartlett
Andrew Bartlett wrote:
This seems to work.
Good; making progress, then, aren't we?
I've found some more challenges (such as, should a rename onto an entry's own DN work),
You mean
dn: cn=Foo,dc=example,dc=com changetype: modrdn newrdn: cn=Foo deleteoldrdn: 1
?
but I'll try and work on that next week. (I suspect this is an area where I can write a module to cause that to be a no-op, rather than ask for changes in OpenLDAP).
I note this is not directly related to slapo-memberof(5), but rather handled by the underlying backend. RFC 4511 states that a modify DN operation must fail with the entryAlreadyExists result code if there was already an entry with that name. However, a broad interpretation would recognize that such a modify DN operation is going to be a no-op and simply ignore it. The specific case doesn't seem to be explicitly dealt with in RFC 4511.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
-
Andrew Bartlett -
Howard Chu -
Michael Ströder -
Pierangelo Masarati