Issue 5768 - [enhancement] add support for Dereference Control
Summary: [enhancement] add support for Dereference Control
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-22 20:18 UTC by ando@openldap.org
Modified: 2021-03-05 21:13 UTC (History)
0 users

See Also:


Attachments
control (931 bytes, application/octet-stream)
2008-12-11 01:22 UTC, abartlet@samba.org
Details
request (3.39 KB, application/octet-stream)
2008-12-11 01:22 UTC, abartlet@samba.org
Details
response (4.86 KB, application/octet-stream)
2008-12-11 01:22 UTC, abartlet@samba.org
Details

Note You need to log in before you can comment on or make changes to this issue.
Description ando@openldap.org 2008-10-22 20:18:19 UTC
Full_Name: Pierangelo Masarati
Version: HEAD
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.72.89.40)
Submitted by: ando


See <http://www.openldap.org/lists/openldap-devel/200810/msg00105.html> and
<https://www.redhat.com/archives/fedora-directory-devel/2008-October/msg00003.html>
for discussion.

p.

Comment 1 ando@openldap.org 2008-10-22 20:20:50 UTC
changed notes
changed state Open to Test
moved from Incoming to Software Enhancements
Comment 2 ando@openldap.org 2008-10-22 22:15:50 UTC
A tentative implementation is in HEAD, please test.  You need to:

- configure as --enable-deref

- enable the "deref" overlay in slapd, with "overlay deref" (doesn't
work as global overlay yet, sorry).

- run searches like

$ ldapsearch -x -b dc=example,dc=com -E 'deref=member:entryUUID'

you'll see results like

# Alumni Assoc Staff, Groups, example.com
dn: cn=Alumni Assoc Staff,ou=Groups,dc=example,dc=com
control: 1.3.6.1.4.1.4203.666.5.16 false MIIDgjBdBAZtZW1iZXIEHGNuPU1hbmFnZXIsZ
  GM9ZXhhbXBsZSxkYz1jb22gNTAzBAllbnRyeVVVSUQxJgQkMjlkNTNiZjQtMzRhYi0xMDJkLThhNz
  MtYWI0MTM2OTEyOTExMIGFBAZtZW1iZXIERGNuPURvcm90aHkgU3RldmVucyxvdT1BbHVtbmkgQXN
  zb2NpYXRpb24sb3U9UGVvcGxlLGRjPWV4YW1wbGUsZGM9Y29toDUwMwQJZW50cnlVVUlEMSYEJDI5
  ZDNhNzQ0LTM0YWItMTAyZC04YTZjLWFiNDEzNjkxMjkxMTCBhQQGbWVtYmVyBERjbj1KYW1lcyBBI
  EpvbmVzIDEsb3U9QWx1bW5pIEFzc29jaWF0aW9uLG91PVBlb3BsZSxkYz1leGFtcGxlLGRjPWNvba
  A1MDMECWVudHJ5VVVJRDEmBCQyOWQ0MTM5Ni0zNGFiLTEwMmQtOGE2ZS1hYjQxMzY5MTI5MTEwfgQ
  GbWVtYmVyBD1jbj1KYW5lIERvZSxvdT1BbHVtbmkgQXNzb2NpYXRpb24sb3U9UGVvcGxlLGRjPWV4
  YW1wbGUsZGM9Y29toDUwMwQJZW50cnlVVUlEMSYEJDI5ZDQ4ZTQ4LTM0YWItMTAyZC04YTcwLWFiN
  DEzNjkxMjkxMTCBhAQGbWVtYmVyBENjbj1KZW5uaWZlciBTbWl0aCxvdT1BbHVtbmkgQXNzb2NpYX
  Rpb24sb3U9UGVvcGxlLGRjPWV4YW1wbGUsZGM9Y29toDUwMwQJZW50cnlVVUlEMSYEJDI5ZDRhNjR
  lLTM0YWItMTAyZC04YTcxLWFiNDEzNjkxMjkxMTCBgQQGbWVtYmVyBEBjbj1NYXJrIEVsbGlvdCxv
  dT1BbHVtbmkgQXNzb2NpYXRpb24sb3U9UGVvcGxlLGRjPWV4YW1wbGUsZGM9Y29toDUwMwQJZW50c
  nlVVUlEMSYEJDI5ZDU1NGY0LTM0YWItMTAyZC04YTc0LWFiNDEzNjkxMjkxMTCBhQQGbWVtYmVyBE
  Rjbj1VcnN1bGEgSGFtcHN0ZXIsb3U9QWx1bW5pIEFzc29jaWF0aW9uLG91PVBlb3BsZSxkYz1leGF
  tcGxlLGRjPWNvbaA1MDMECWVudHJ5VVVJRDEmBCQyOWQ1OGVkOC0zNGFiLTEwMmQtOGE3NS1hYjQx
  MzY5MTI5MTE=
# member: <entryUUID=29d53bf4-34ab-102d-8a73-ab4136912911>;cn=Manager,dc=exam
  ple,dc=com
# member: <entryUUID=29d3a744-34ab-102d-8a6c-ab4136912911>;cn=Dorothy Stevens
  ,ou=Alumni Association,ou=People,dc=example,dc=com
# member: <entryUUID=29d41396-34ab-102d-8a6e-ab4136912911>;cn=James A Jones 1
  ,ou=Alumni Association,ou=People,dc=example,dc=com
# member: <entryUUID=29d48e48-34ab-102d-8a70-ab4136912911>;cn=Jane Doe,ou=Alu
  mni Association,ou=People,dc=example,dc=com
# member: <entryUUID=29d4a64e-34ab-102d-8a71-ab4136912911>;cn=Jennifer Smith,
  ou=Alumni Association,ou=People,dc=example,dc=com
# member: <entryUUID=29d554f4-34ab-102d-8a74-ab4136912911>;cn=Mark Elliot,ou=
  Alumni Association,ou=People,dc=example,dc=com
# member: <entryUUID=29d58ed8-34ab-102d-8a75-ab4136912911>;cn=Ursula Hampster
  ,ou=Alumni Association,ou=People,dc=example,dc=com
member: cn=Manager,dc=example,dc=com
member: cn=Dorothy Stevens,ou=Alumni Association,ou=People,dc=example,dc=com
member: cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,dc=com
member: cn=Jane Doe,ou=Alumni Association,ou=People,dc=example,dc=com
member: cn=Jennifer Smith,ou=Alumni Association,ou=People,dc=example,dc=com
member: cn=Mark Elliot,ou=Alumni Association,ou=People,dc=example,dc=com
member: cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,dc=com
owner: cn=Manager,dc=example,dc=com
description: All Alumni Assoc Staff
cn: Alumni Assoc Staff
objectClass: groupOfNames


The related C API is in libraries/libldap/deref.c; as a guideline, you can look
at clients/ttols/ldapsearch.c, which creates the control and parses the response
in order to print it in extended DN style.

The current specification is formalized in a comment in overlays/deref.c; I intend
to improve it and post it at <http://www.openldap.org/faq/data/cache/1469.html>.

Please report through the ITS.

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
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------

Comment 3 ando@openldap.org 2008-10-24 12:35:12 UTC
ando@OpenLDAP.org wrote:

> Log Message:
> forgot access control...


Probably the current implementation is far from optimal, since it makes 
use of over_entry_get_rw() and thus:

- requires to apply ACLs within the overlay
- prevents other overlays from interoperating
- prevents the overlay from being instantiated as global

Probably, an internal search with scope "base" would be better.

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
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------

Comment 4 Hallvard Furuseth 2008-10-24 12:56:16 UTC
ando@sys-net.it writes:
> The current specification is formalized in a comment in
> overlays/deref.c; I intend to improve it and post it at
> <http://www.openldap.org/faq/data/cache/1469.html>.

You've specified the syntax, but not the semantics.  I don't see
any mention there of what this control does, though I suppose the
examples help if one knows what a GUID and a SID are.

BTW, possibly "deref(erence)" is a confusing name for the control,
since it is apparently not related to aliases.

-- 
Hallvard

Comment 5 Howard Chu 2008-10-24 13:14:32 UTC
h.b.furuseth@usit.uio.no wrote:
> ando@sys-net.it writes:
>> The current specification is formalized in a comment in
>> overlays/deref.c; I intend to improve it and post it at
>> <http://www.openldap.org/faq/data/cache/1469.html>.
>
> You've specified the syntax, but not the semantics.  I don't see
> any mention there of what this control does, though I suppose the
> examples help if one knows what a GUID and a SID are.

It doesn't matter what a GUID or SID, aside from being attributes of an entry 
that was referenced by a search response entry.

> BTW, possibly "deref(erence)" is a confusing name for the control,
> since it is apparently not related to aliases.

Oh please. Nor is it related to referrals or search references, and yet these 
are all references, and "dereference" applies to them equally.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

Comment 6 ando@openldap.org 2008-10-24 13:32:28 UTC
h.b.furuseth@usit.uio.no wrote:
> ando@sys-net.it writes:
>> The current specification is formalized in a comment in
>> overlays/deref.c; I intend to improve it and post it at
>> <http://www.openldap.org/faq/data/cache/1469.html>.
> 
> You've specified the syntax, but not the semantics.  I don't see
> any mention there of what this control does, though I suppose the
> examples help if one knows what a GUID and a SID are.

I will, in a more detailed document.

> BTW, possibly "deref(erence)" is a confusing name for the control,
> since it is apparently not related to aliases.

"Dereference" means take DN-valued attributes, lookup the requested 
attributes from their entry and present the whole thing (name + attrs) 
as the control value.  So

ldapsearch -E deref=member:cn,sn

will return a control value consisting in sequences of member values 
contained in the search, plus the corresponding values of cn and sn.

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
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------

Comment 7 Hallvard Furuseth 2008-10-24 13:43:31 UTC
Howard Chu writes:
>> BTW, possibly "deref(erence)" is a confusing name for the control,
>> since it is apparently not related to aliases.
> 
> Oh please. Nor is it related to referrals or search references, and yet
> these are all references, and "dereference" applies to them equally.

Actually the docs do use different names for that - "follow"/"chase"
referrals, or "chain" on the server side, vs. "deref"erence aliases.
So if this is a new operation, I figured it wouldn't hurt to look for
another word for whatever it is doing.  But sure, it's no big thing.
And in that regard it can already be a bit confusing that it's aliases
and not referrals & search references which are "deref"erenced.

-- 
Hallvard

Comment 8 ando@openldap.org 2008-11-06 19:00:30 UTC
moved from Software Enhancements to Development
Comment 9 Quanah Gibson-Mount 2008-11-10 19:15:28 UTC
changed notes
changed state Test to Release
Comment 10 abartlet@samba.org 2008-11-11 03:52:30 UTC
On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote:
> A tentative implementation is in HEAD, please test.  You need to:

I just wanted to say thankyou very much for doing this.  The Samba side
of things has taken far longer than I ever imagined, but I hope to look
at the OpenLDAP integration this or next week.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com

Comment 11 Quanah Gibson-Mount 2008-11-11 04:18:08 UTC
--On Tuesday, November 11, 2008 3:52 AM +0000 abartlet@samba.org wrote:

>
> --=-nSmbtQnR20QHrM5OsFp5
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
>
> On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote:
>> A tentative implementation is in HEAD, please test.  You need to:
>
> I just wanted to say thankyou very much for doing this.  The Samba side
> of things has taken far longer than I ever imagined, but I hope to look
> at the OpenLDAP integration this or next week.

It was added to RE24 today, for inclusion in 2.4.13, so getting feedback 
would be great.

--Quanah


--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration

Comment 12 Quanah Gibson-Mount 2008-11-24 17:02:57 UTC
changed notes
changed state Release to Closed
Comment 13 abartlet@samba.org 2008-12-11 01:22:07 UTC
On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote:
> A tentative implementation is in HEAD, please test.  You need to:

Thankyou very much.  I downloaded CVS HEAD and tested it out (finally -
the Samba4 side of the implementation took far longer than I expected).

> - configure as --enable-deref
> 
> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't
> work as global overlay yet, sorry).

This is something Samba4 will need, as many of our links are
cross-database.  But fixing this for a single DB is a big help in any
case.

> - run searches like
>
> $ ldapsearch -x -b dc=example,dc=com -E 'deref=member:entryUUID'
> 
> you'll see results like

When using Samba4's client, it seems to work, but it is as if it extends
the control to the full expected length, but not the data.  Ie, attached
this is the control response I got back from the 'make testenv'
environment in Samba4.  I've also attached the full LDAP request.

The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4
parsing bug).

I can make the Samba4 tree that reproduces this available as a GIT
repository if you like.  

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
Comment 14 abartlet@samba.org 2008-12-11 04:42:20 UTC
On Thu, 2008-12-11 at 12:22 +1100, Andrew Bartlett wrote:
> On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote:
> > A tentative implementation is in HEAD, please test.  You need to:
> 
> Thankyou very much.  I downloaded CVS HEAD and tested it out (finally -
> the Samba4 side of the implementation took far longer than I expected).
> 
> > - configure as --enable-deref
> > 
> > - enable the "deref" overlay in slapd, with "overlay deref" (doesn't
> > work as global overlay yet, sorry).
> 
> This is something Samba4 will need, as many of our links are
> cross-database.  But fixing this for a single DB is a big help in any
> case.
> 
> > - run searches like
> >
> > $ ldapsearch -x -b dc=example,dc=com -E 'deref=member:entryUUID'
> > 
> > you'll see results like
> 
> When using Samba4's client, it seems to work, but it is as if it extends
> the control to the full expected length, but not the data.  Ie, attached
> this is the control response I got back from the 'make testenv'
> environment in Samba4.  I've also attached the full LDAP request.
> 
> The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4
> parsing bug).
> 
> I can make the Samba4 tree that reproduces this available as a GIT
> repository if you like.  

To reproduce:

In a checkout from git://git.samba.org/abartlet/samba.git master run:
OPENLDAP_ROOT=/usr/local/ TEST_LDAP=yes make testenv

Then in the xterm that pops up, run:

bin/ldbsearch -H ldap://localdc1 cn=administrator
--controls=extended_dn:1:1

This will not return the extended DN (compare with TEST_LDAP=no),
because it fails to parse the returned control in
libcli/ldap/ldap_controls.c (I suspect my parser also needs work)

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
Comment 15 ando@openldap.org 2008-12-11 22:17:44 UTC
Andrew Bartlett wrote:
> On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote:
>> A tentative implementation is in HEAD, please test.  You need to:
> 
> Thankyou very much.  I downloaded CVS HEAD and tested it out (finally -
> the Samba4 side of the implementation took far longer than I expected).
> 
>> - configure as --enable-deref
>>
>> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't
>> work as global overlay yet, sorry).
> 
> This is something Samba4 will need, as many of our links are
> cross-database.  But fixing this for a single DB is a big help in any
> case.
> 
>> - run searches like
>>
>> $ ldapsearch -x -b dc=example,dc=com -E 'deref=member:entryUUID'
>>
>> you'll see results like
> 
> When using Samba4's client, it seems to work, but it is as if it extends
> the control to the full expected length, but not the data.  Ie, attached
> this is the control response I got back from the 'make testenv'
> environment in Samba4.  I've also attached the full LDAP request.
> 
> The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4
> parsing bug).

I've found the bug (erroneous manipulation of octet strings containing 
'\0' octets).  The objectSid is octet string-valued.  Should be fixed 
now; 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
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------

Comment 16 ando@openldap.org 2008-12-11 22:22:46 UTC
Andrew Bartlett wrote:
> On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote:
>> A tentative implementation is in HEAD, please test.  You need to:
> 
> Thankyou very much.  I downloaded CVS HEAD and tested it out (finally -
> the Samba4 side of the implementation took far longer than I expected).
> 
>> - configure as --enable-deref
>>
>> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't
>> work as global overlay yet, sorry).
> 
> This is something Samba4 will need, as many of our links are
> cross-database.  But fixing this for a single DB is a big help in any
> case.

Apparently this was fixed during the overlay's shakedown, as it seems to 
work as expected when only instantiated as global.  In fact, nothing was 
preventing it from working this way by design, it only didn't work at 
some point of its evolution.  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
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------

Comment 17 abartlet@samba.org 2008-12-12 00:16:23 UTC
On Thu, 2008-12-11 at 23:17 +0100, Pierangelo Masarati wrote:
> Andrew Bartlett wrote:
> > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote:
> >> A tentative implementation is in HEAD, please test.  You need to:
> > 
> > Thankyou very much.  I downloaded CVS HEAD and tested it out (finally -
> > the Samba4 side of the implementation took far longer than I expected).
> > 
> >> - configure as --enable-deref
> >>
> >> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't
> >> work as global overlay yet, sorry).
> > 
> > This is something Samba4 will need, as many of our links are
> > cross-database.  But fixing this for a single DB is a big help in any
> > case.
> > 
> >> - run searches like
> >>
> >> $ ldapsearch -x -b dc=example,dc=com -E 'deref=member:entryUUID'
> >>
> >> you'll see results like
> > 
> > When using Samba4's client, it seems to work, but it is as if it extends
> > the control to the full expected length, but not the data.  Ie, attached
> > this is the control response I got back from the 'make testenv'
> > environment in Samba4.  I've also attached the full LDAP request.
> > 
> > The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4
> > parsing bug).
> 
> I've found the bug (erroneous manipulation of octet strings containing 
> '\0' octets).  The objectSid is octet string-valued.  Should be fixed 
> now; please test.

While I'm mostly at sea on ASN.1, I don't think the OpenLDAP's
implementation matches your IETF draft (if not, an education on subtle
details of ASN.1 will be appreciated)

draft-masarati-ldap-deref-00


> 2.3.  Control Response
> 
> 
> The control type is deref-oid (IANA assigned; see Section 6). The
> specification of the Dereference Control response is:
> 
> controlValue ::= SEQUENCE OF derefRes DerefRes
> 
> DerefRes ::= SEQUENCE {
> derefAttr AttributeDescription,
> derefVal LDAPDN,
> attrVals [0] PartialAttributeList OPTIONAL }
> 
> PartialAttributeList ::= SEQUENCE OF
> partialAttribute PartialAttribute
> 
> PartialAttribute is defined in [RFC4511]; the definition is reported
> here for clarity:
> 
> PartialAttribute ::= SEQUENCE {
> type AttributeDescription,
> vals SET OF value AttributeValue }
> 

the output of dumpasn1 on the control:

>    0  983: SEQUENCE {
>    4  168:   SEQUENCE {
>    7    8:     OCTET STRING 'memberOf'
>   17   56:     OCTET STRING
>          :       'cn=Enterprise Admins,cn=Users,dc=samba,dc=exampl'
>          :       'e,dc=com'
>   75   98:     [0] {
>   77   51:       SEQUENCE {

Shouldn't there be another SEQUENCE { here?

>   79    9:         OCTET STRING 'entryUUID'
>   90   38:         SET {
>   92   36:           OCTET STRING
> '24476f18-5c24-102d-9945-7320c1040f54'
>          :           }
>          :         }
> 130   43:       SEQUENCE {
> 132    9:         OCTET STRING 'objectSid'
> 143   30:         SET {
> 145   28:           OCTET STRING
>          :             01 05 00 00 00 00 00 05 15 00 00 00 AB BE DB 7B
>          :             16 72 AE E6 53 BE 65 6F 07 02 00 00
>          :           }
>          :         }
>          :       }
>          :     }
> 

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
Comment 18 abartlet@samba.org 2008-12-12 03:23:37 UTC
On Thu, 2008-12-11 at 23:22 +0100, Pierangelo Masarati wrote:
> Andrew Bartlett wrote:
> > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote:
> >> A tentative implementation is in HEAD, please test.  You need to:
> > 
> > Thankyou very much.  I downloaded CVS HEAD and tested it out (finally -
> > the Samba4 side of the implementation took far longer than I expected).
> > 
> >> - configure as --enable-deref
> >>
> >> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't
> >> work as global overlay yet, sorry).
> > 
> > This is something Samba4 will need, as many of our links are
> > cross-database.  But fixing this for a single DB is a big help in any
> > case.
> 
> Apparently this was fixed during the overlay's shakedown, as it seems to 
> work as expected when only instantiated as global.  In fact, nothing was 
> preventing it from working this way by design, it only didn't work at 
> some point of its evolution.  Please test.

Indeed, it works well as a global.  Thanks!

My only issue remaining is the clarification over the ASN.1 encoding of
the control.

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
Comment 19 ando@openldap.org 2008-12-12 07:50:50 UTC
Andrew Bartlett wrote:
> On Thu, 2008-12-11 at 23:17 +0100, Pierangelo Masarati wrote:
>> Andrew Bartlett wrote:
>>> On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote:
>>>> A tentative implementation is in HEAD, please test.  You need to:
>>> Thankyou very much.  I downloaded CVS HEAD and tested it out (finally -
>>> the Samba4 side of the implementation took far longer than I expected).
>>>
>>>> - configure as --enable-deref
>>>>
>>>> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't
>>>> work as global overlay yet, sorry).
>>> This is something Samba4 will need, as many of our links are
>>> cross-database.  But fixing this for a single DB is a big help in any
>>> case.
>>>
>>>> - run searches like
>>>>
>>>> $ ldapsearch -x -b dc=example,dc=com -E 'deref=member:entryUUID'
>>>>
>>>> you'll see results like
>>> When using Samba4's client, it seems to work, but it is as if it extends
>>> the control to the full expected length, but not the data.  Ie, attached
>>> this is the control response I got back from the 'make testenv'
>>> environment in Samba4.  I've also attached the full LDAP request.
>>>
>>> The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4
>>> parsing bug).
>> I've found the bug (erroneous manipulation of octet strings containing 
>> '\0' octets).  The objectSid is octet string-valued.  Should be fixed 
>> now; please test.
> 
> While I'm mostly at sea on ASN.1, I don't think the OpenLDAP's
> implementation matches your IETF draft (if not, an education on subtle
> details of ASN.1 will be appreciated)
> 
> draft-masarati-ldap-deref-00
> 
> 
>> 2.3.  Control Response
>>
>>
>> The control type is deref-oid (IANA assigned; see Section 6). The
>> specification of the Dereference Control response is:
>>
>> controlValue ::= SEQUENCE OF derefRes DerefRes
>>
>> DerefRes ::= SEQUENCE {
>> derefAttr AttributeDescription,
>> derefVal LDAPDN,
>> attrVals [0] PartialAttributeList OPTIONAL }
>>
>> PartialAttributeList ::= SEQUENCE OF
>> partialAttribute PartialAttribute
>>
>> PartialAttribute is defined in [RFC4511]; the definition is reported
>> here for clarity:
>>
>> PartialAttribute ::= SEQUENCE {
>> type AttributeDescription,
>> vals SET OF value AttributeValue }
>>
> 
> the output of dumpasn1 on the control:
> 
>>    0  983: SEQUENCE {
>>    4  168:   SEQUENCE {
>>    7    8:     OCTET STRING 'memberOf'
>>   17   56:     OCTET STRING
>>          :       'cn=Enterprise Admins,cn=Users,dc=samba,dc=exampl'
>>          :       'e,dc=com'
>>   75   98:     [0] {
>>   77   51:       SEQUENCE {
> 
> Shouldn't there be another SEQUENCE { here?

Well, that was my intention when I ber_printf("{{OOt{{O[W]}{O[W]}}}}"), 
which, AFAIK, means:
	"{"	SEQUENCE
	"{"	SEQUENCE
	"OO"	derefAttr, derefVal
	"t"	[0]
	"{"	SEQUENCE
	"{O[W]}"	SEQUENCE, type, SET OF vals

Am I missing anything?  Couldn't "[0] {" be a shortcut in dumpasn1 to 
indicate SEQUENCE OF and the presence of a context+constructed tag?

Looking at the raw data of an example, I see a sequence

240  126  060  063  004  011

which means:

240 context + constructed
126 (the length, 86 octets)
060 sequence
063 (the length, 51 octets)
004 octet string
011 (the length, 9 octets: "entryUUID")

I'm not an expert in ASN.1, but from what I infer by looking at LDAP 
specs and at OpenLDAP implementation, this is consistent with the way 
similar cases are dealt with (e.g. the "Controls" at the end of a 
request message).

p.

> 
>>   79    9:         OCTET STRING 'entryUUID'
>>   90   38:         SET {
>>   92   36:           OCTET STRING
>> '24476f18-5c24-102d-9945-7320c1040f54'
>>          :           }
>>          :         }
>> 130   43:       SEQUENCE {
>> 132    9:         OCTET STRING 'objectSid'
>> 143   30:         SET {
>> 145   28:           OCTET STRING
>>          :             01 05 00 00 00 00 00 05 15 00 00 00 AB BE DB 7B
>>          :             16 72 AE E6 53 BE 65 6F 07 02 00 00
>>          :           }
>>          :         }
>>          :       }
>>          :     }
>>
> 
> Thanks,
> 
> Andrew Bartlett
> 



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
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------

Comment 20 abartlet@samba.org 2009-01-06 04:49:49 UTC
On Fri, 2008-12-12 at 14:23 +1100, Andrew Bartlett wrote:
> On Thu, 2008-12-11 at 23:22 +0100, Pierangelo Masarati wrote:
> > Andrew Bartlett wrote:
> > > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote:
> > >> A tentative implementation is in HEAD, please test.  You need to:
> > > 
> > > Thankyou very much.  I downloaded CVS HEAD and tested it out (finally -
> > > the Samba4 side of the implementation took far longer than I expected).
> > > 
> > >> - configure as --enable-deref
> > >>
> > >> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't
> > >> work as global overlay yet, sorry).
> > > 
> > > This is something Samba4 will need, as many of our links are
> > > cross-database.  But fixing this for a single DB is a big help in any
> > > case.
> > 
> > Apparently this was fixed during the overlay's shakedown, as it seems to 
> > work as expected when only instantiated as global.  In fact, nothing was 
> > preventing it from working this way by design, it only didn't work at 
> > some point of its evolution.  Please test.
> 
> Indeed, it works well as a global.  Thanks!
> 
> My only issue remaining is the clarification over the ASN.1 encoding of
> the control.

While I'm still confused about the ASN.1, I've coded to match OpenLDAP's
current behaviour.

The deref overlay seems to be working well.  Many thanks!

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
Comment 21 ando@openldap.org 2009-01-24 14:55:20 UTC
Andrew Bartlett wrote:

> While I'm still confused about the ASN.1, I've coded to match OpenLDAP's
> current behaviour.
> 
> The deref overlay seems to be working well.  Many thanks!

Cool.  I'd appreciate some definitive review of the correspondence of 
the implementation with respect to the draft (draft-masarati-ldap-deref 
in docs/draft, or from the IETF ID interface).  That's the best I could 
put in place so far.

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
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------

Comment 22 OpenLDAP project 2014-08-01 21:04:59 UTC
applied to HEAD
applied to RE24