Hello,
I have two different LDAP servers containing different information about my users. In one of them, I'm trying to configure dynlist overlay to dinamically add attributes for users, so I have configured dynlist. I'm using the labeledURI attribute with a value like this:
labeledURI: ldap://<the_other_server>:389/dc=usuarios,dc=mydomain,dc=com?irisClassifCode,sn1,givenName?one?(irisPersonalUniqueID=<userID>)
Whenever I look for a user I get the error:
Jan 10 13:07:07 canis12 slapd[12689]: dynlist_prepare_entry("<userDN>"): illegal URI "ldap://<the_other_server>:389/dc=usuarios,dc=mydomain,dc=com?irisClassifCode,sn1,givenName?one?(irisPersonalUniqueID=<userID>)"
If I remove the server part of the URI, like:
labeledURI: ldap:///dc=usuarios,dc=mydomain,dc=com?irisClassifCode,sn1,givenName?one?(irisPersonalUniqueID=<userID>)
but, obviously, I'm not getting the additional attributes (because this LDAP directory doesn't have them).
What am I doing wrong? Could I use a LDAP URI directed to another LDAP server?
Angel L. Mateo wrote:
Hello,
I have two different LDAP servers containing different information about my users. In one of them, I'm trying to configure dynlist overlay to dinamically add attributes for users, so I have configured dynlist. I'm using the labeledURI attribute with a value like this:
labeledURI: ldap://<the_other_server>:389/dc=usuarios,dc=mydomain,dc=com?irisClassifCode,sn1,givenName?one?(irisPersonalUniqueID=<userID>)
Whenever I look for a user I get the error:
Jan 10 13:07:07 canis12 slapd[12689]: dynlist_prepare_entry("<userDN>"): illegal URI "ldap://<the_other_server>:389/dc=usuarios,dc=mydomain,dc=com?irisClassifCode,sn1,givenName?one?(irisPersonalUniqueID=<userID>)"
If I remove the server part of the URI, like:
labeledURI: ldap:///dc=usuarios,dc=mydomain,dc=com?irisClassifCode,sn1,givenName?one?(irisPersonalUniqueID=<userID>)
but, obviously, I'm not getting the additional attributes (because this LDAP directory doesn't have them).
What am I doing wrong? Could I use a LDAP URI directed to another LDAP server?
Read the slapo-dynlist(5) manpage. It says quite clearly:
The optional URI restricts expansion only to entries matching the DN, the scope and the filter portions of the URI.
Nothing else in the URI is valid.
El 10/01/11 14:06, Howard Chu escribió:
Read the slapo-dynlist(5) manpage. It says quite clearly:
The optional URI restricts expansion only to entries matching the DN, the scope and the filter portions of the URI.
Nothing else in the URI is valid.
Oh... I've read this manpage few times, but I missed that paragraph, sorry.
Angel L. Mateo wrote:
El 10/01/11 14:06, Howard Chu escribió:
Read the slapo-dynlist(5) manpage. It says quite clearly:
The optional URI restricts expansion only to entries matching the DN, the scope and the filter portions of the URI.
Nothing else in the URI is valid.
Oh... I've read this manpage few times, but I missed that paragraph,sorry.
Note that this is by design: the reason is that:
1) we don't want to allow arbitrary URLs
2) we don't want to duplicate all functionalities of other modules (in a moment users would ask for: arbitrary authentication mechanisms, detailed handling of errors, timeouts, etc.); if you need to that, you can configure an instance of back-ldap that handles requests for the remote database. Back-ldap, by design, already handles all these functionalities.
p.
El 10/01/11 15:22, Pierangelo Masarati escribió:
Angel L. Mateo wrote:
El 10/01/11 14:06, Howard Chu escribió:
Read the slapo-dynlist(5) manpage. It says quite clearly:
The optional URI restricts expansion only to entries matching the DN, the scope and the filter portions of the URI.
Nothing else in the URI is valid.
Oh... I've read this manpage few times, but I missed that paragraph, sorry.
Note that this is by design: the reason is that:
we don't want to allow arbitrary URLs
we don't want to duplicate all functionalities of other modules (in a
moment users would ask for: arbitrary authentication mechanisms, detailed handling of errors, timeouts, etc.); if you need to that, you can configure an instance of back-ldap that handles requests for the remote database. Back-ldap, by design, already handles all these functionalities.
So, could I use back-ldap to add attributes to an existing entry?
Or should I have to configure my two ldap servers (without back-ldap) and then a third ldap server with back-ldap that aggregates information from the two original ones?
Excuse for my ignorance about back-ldap :-(
El 10/01/11 17:20, Angel L. Mateo escribió:
El 10/01/11 15:22, Pierangelo Masarati escribió:
Angel L. Mateo wrote:
El 10/01/11 14:06, Howard Chu escribió:
Read the slapo-dynlist(5) manpage. It says quite clearly:
The optional URI restricts expansion only to entries matching the DN, the scope and the filter portions of the URI.
Nothing else in the URI is valid.
Oh... I've read this manpage few times, but I missed that paragraph, sorry.
Note that this is by design: the reason is that:
we don't want to allow arbitrary URLs
we don't want to duplicate all functionalities of other modules (in a
moment users would ask for: arbitrary authentication mechanisms, detailed handling of errors, timeouts, etc.); if you need to that, you can configure an instance of back-ldap that handles requests for the remote database. Back-ldap, by design, already handles all these functionalities.
So, could I use back-ldap to add attributes to an existing entry?
Or should I have to configure my two ldap servers (without back-ldap) and then a third ldap server with back-ldap that aggregates information from the two original ones?
Excuse for my ignorance about back-ldap :-(
Sorry, I was too obfuscated yesterday. I have configured my dc=usuarios,dc=mydomain,dc=com as a back-ldap database and then I can point labeledURI to ldap:///<the rest>.
openldap-technical@openldap.org
-
Angel L. Mateo -
Howard Chu -
Pierangelo Masarati