Hello,
I have an openldap using dynlist to get some attributes of the entries.
When I manually performs search, I can get these attributes (obtained through the dynlist overlay) without any problem, but when an application (a CAS server to be precise) tries to do the same search, with the same bind dn, I can't see those attributes.
I have used wireshark to check any difference and I have found that the only difference between my search and the one made by the application is that this one use a control parameter in the search, to be precise the control 2.16.840.1.113730.3.4.2..
Then I have checked and I have realized that if I used the -M option then I get the same behaviour and I can't get the attributes from the dynlist overlay.
As far as I know I can't configure this behaviour in my application (although I'm also looking for any way to configure CAS not to use that control), so, why openldap does not use the dynlist overlay when this dsa it control is used? Is there any way to change this behaviour?
Any help?
On 02/07/2012 11:33 AM, Angel L. Mateo wrote:
Hello,
I have an openldap using dynlist to get some attributes of the entries.
When I manually performs search, I can get these attributes (obtained through the dynlist overlay) without any problem, but when an application (a CAS server to be precise) tries to do the same search, with the same bind dn, I can't see those attributes.
I have used wireshark to check any difference and I have found that the only difference between my search and the one made by the application is that this one use a control parameter in the search, to be precise the control 2.16.840.1.113730.3.4.2..
Then I have checked and I have realized that if I used the -M option then I get the same behaviour and I can't get the attributes from the dynlist overlay.
As far as I know I can't configure this behaviour in my application (although I'm also looking for any way to configure CAS not to use that control), so, why openldap does not use the dynlist overlay when this dsa it control is used? Is there any way to change this behaviour?
man slapo-dynlist:
... The above described behavior is disabled when the man‐ ageDSAit control (RFC 3296) is used. In that case, the contents of the dynamic group entry is returned; namely, the URLs are returned instead of being expanded.
p.
El 07/02/12 12:34, Pierangelo Masarati escribió:
On 02/07/2012 11:33 AM, Angel L. Mateo wrote:
Hello,
I have an openldap using dynlist to get some attributes of the entries.
When I manually performs search, I can get these attributes (obtained through the dynlist overlay) without any problem, but when an application (a CAS server to be precise) tries to do the same search, with the same bind dn, I can't see those attributes.
I have used wireshark to check any difference and I have found that the only difference between my search and the one made by the application is that this one use a control parameter in the search, to be precise the control 2.16.840.1.113730.3.4.2..
Then I have checked and I have realized that if I used the -M option then I get the same behaviour and I can't get the attributes from the dynlist overlay.
As far as I know I can't configure this behaviour in my application (although I'm also looking for any way to configure CAS not to use that control), so, why openldap does not use the dynlist overlay when this dsa it control is used? Is there any way to change this behaviour?
man slapo-dynlist:
... The above described behavior is disabled when the man‐ ageDSAit control (RFC 3296) is used. In that case, the contents of the dynamic group entry is returned; namely, the URLs are returned instead of being expanded.
I haven't seen this (and I swear I had looking it for :-( Sorry and thank you.
openldap-technical@openldap.org
-
Angel L. Mateo -
Pierangelo Masarati