8:49 p.m.
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 http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc. http://redhat.com
1:35 a.m.
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.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4:31 a.m.
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.
8:30 a.m.
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(a)sys-net.it
---------------------------------------
10:51 a.m.
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(a)sys-net.it
---------------------------------------
3:11 p.m.
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 http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc. http://redhat.com
3:59 p.m.
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(a)sys-net.it
---------------------------------------
7:06 a.m.
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(a)sys-net.it
---------------------------------------
10:49 p.m.
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 http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc. http://redhat.com
1:50 p.m.
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(a)sys-net.it
---------------------------------------
4:21 p.m.
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 http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc. http://redhat.com
2:45 a.m.
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(a)sys-net.it
---------------------------------------
2:35 p.m.
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
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc. http://redhat.com
5564
days inactive
5572
days old
12 comments
4 participants
participants (4)
-
Andrew Bartlett -
Howard Chu -
Michael Ströder -
Pierangelo Masarati