On 14/3/06 3:15, Gergely Sánta <[EMAIL PROTECTED]> wrote:
> Gergely Sánta wrote:
>
>> Chris Ridd wrote:
>>
>>> On 14/3/06 11:09, Gergely Sánta <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>> Hi!
>>>>
>>>> I'm working on a method, which should get access rights for users on
>>>> defined dn (Sun Directory Server 5.2).
>>>> I found, that the next command returns to me the access rights to an
>>>> entry:
>>>> ldapsearch -D <binddn> -b <basedn> -c "dn:<userdn>" <filter>
>>>> aclrights
>>>> I need this form, because I need to bind to LDAP as admin (<binddn>),
>>>> and need to get rights on an entry (<basedn>) for a user (<userdn>).
>>>> This command should be the same, as
>>>> ldapsearch -D <binddn> -b <basedn> -J
>>>> "1.3.6.1.4.1.42.2.27.9.5.2:true:dn:<userdn>" <filter> aclrights
>>>> which should be fit for me, as it's the same, as perl ldap search with
>>>> control hash:
>>>> { type => "1.3.6.1.4.1.42.2.27.9.5.2", critical => true, value =>
>>>> "dn:<userdn> }
>>>>
>>>> My problem is, that the second one do not works (with attribute -J). I
>>>> examined the packet, which is sent in both cases, and it seems,
>>>> ldapsearch with switch -c prepends some hexa info to it's value, but I
>>>> can't figure it out, what this data is. This is not done, when -J is
>>>> used. As perl support for control getEffectiveRights is the same, as -J
>>>> switch, it returns an error to me.
>>>>
>>>> Is there some way for gaining effective rights, as does ldapsearch with
>>>> argument "-c"?
>>>>
>>>
>>>
>>> Whose version of ldapsearch is this? It isn't the one supplied with
>>> Solaris
>>> 10, and it isn't the OpenLDAP one...
>>>
>>> My guess is that whatever-it-is is using the ProxyAuth control, but
>>> that's
>>> just a wild guess...
>>>
>>>
>> It's ldapsearch packaged in sun-directory-server-5.2-25.i386.rpm
>> The OpenLDAP ldapsearch as I figured out from it's manual have no
>> control support by "-J" nor by "-c"
>> ldapsearch supplied with Solaris 10 have no control support by "-c"
>> OID getEffectiveRights as I figured out, was added to Sun Directory
>> Server 5.2
>>
>> It seems to me, the server needs DN with that strange hexa-prefix for
>> getting effective rights, and "-c" is only a workaround for that "-J"
>> argument, because the packages sent are nearly the same, but that
>> prefix of DN.
>>
>> Both these packets contain the OID of getEffectiveRights
>> "1.3.6.1.4.1.42.2.27.9.5.2" as string, then hexa sequence "01 01 ff",
>> which represents "Control Critical: True", then the hexa prefix, and
>> at last the DN as string.
>> The hexa value in case of "-J" is only "04 35", in case of "-c" is "04
>> 3b 30 39 04 35"..
>> I understand, that these values may be dependent on data sent, I can
>> send the hexa dump of packets sent, if you need it..
>>
>> EdE
>
> Ok, I got the "04 35", it's quite simple.. 0x04 will be some message
> code, 0x35 is the length of the following string (dn)..
> Remains the "04 3b 30 39" part.. I've no opinion yet, what it should be..
The control's value must be ASN.1. There's an ASN.1 definition of a
"getEffectiveRights" control in section 9.1 of:
<http://www3.ietf.org/proceedings/01aug/I-D/draft-ietf-ldapext-acl-model-08.
txt>
But be warned that the draft expired 5 years ago (yow!) and it may bear
little or no resemblance to what your server's implementing.
You will need to use Convert::ASN to construct the control correctly. (Well
strictly you don't, but you might as well.)
Cheers,
Chris
