Full_Name: Philippe EYCHART Version: 2.4.13 OS: slack12 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.82.141) Hi, The "tool_conn_setup" function (in common.c) autorise the Url synthaxe "ldap:///dc=my%2cdc=domaine" which produce a SRV request to find the best server to request (not yet according the rfc 2782 - I've made dnssrv.c patch to implement priorities and I try to implement weight before submit this work). So, the client tools - ldapsearch, ldapadd, ... permit this syntaxe (via "ldap_dn2domain" and "ldap_domain2hostlist" functions). Unfortunately, ldap_initialize() doesn't use these functions (but only ldap_url_parselist_ext()) and doesn't allow this synthaxe. So, other packages (like SAMBA) doesn't enjoy this capability : "passdb backend = ldapsam:ldap:///dc=my%2cdc=domain" according a SRV definition "_ldap._tcp.my.domain. IN SRV ..." Is there any reason for that ? Can we envisage to increase this possibility ? Regards
My first work ... -----Message d'origine----- De : openldap-its@OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] Envoyé : mardi 3 février 2009 11:02 À : Philippe.eychart@informatique.gov.pf Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#5919. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its@openldap.org with (ITS#5919) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#5919) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=5919 Please remember to retain your issue tracking number (ITS#5919) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.
Philippe.eychart@informatique.gov.pf wrote: > The "tool_conn_setup" function (in common.c) autorise the Url synthaxe > "ldap:///dc=my%2cdc=domaine" which produce a SRV request to find the best server > to request (not yet according the rfc 2782 - I've made dnssrv.c patch to > implement priorities and I try to implement weight before submit this work). So, > the client tools - ldapsearch, ldapadd, ... permit this syntaxe (via > "ldap_dn2domain" and "ldap_domain2hostlist" functions). This was done to allow testing client-side the DNS SRV feature. > Unfortunately, ldap_initialize() doesn't use these functions (but only > ldap_url_parselist_ext()) and doesn't allow this synthaxe. So, other packages > (like SAMBA) doesn't enjoy this capability : "passdb backend = > ldapsam:ldap:///dc=my%2cdc=domain" according a SRV definition > "_ldap._tcp.my.domain. IN SRV ..." > > Is there any reason for that ? Can we envisage to increase this possibility ? None that I'm aware of. Feel free to move that code from tools to libldap. Patches are welcome, as usual. 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 -----------------------------------
ando@sys-net.it wrote: > Philippe.eychart@informatique.gov.pf wrote: > >> The "tool_conn_setup" function (in common.c) autorise the Url synthaxe >> "ldap:///dc=my%2cdc=domaine" which produce a SRV request to find the best server >> to request (not yet according the rfc 2782 - I've made dnssrv.c patch to >> implement priorities and I try to implement weight before submit this work). So, >> the client tools - ldapsearch, ldapadd, ... permit this syntaxe (via >> "ldap_dn2domain" and "ldap_domain2hostlist" functions). > > This was done to allow testing client-side the DNS SRV feature. > >> Unfortunately, ldap_initialize() doesn't use these functions (but only >> ldap_url_parselist_ext()) and doesn't allow this synthaxe. So, other packages >> (like SAMBA) doesn't enjoy this capability : "passdb backend = >> ldapsam:ldap:///dc=my%2cdc=domain" according a SRV definition >> "_ldap._tcp.my.domain. IN SRV ..." >> >> Is there any reason for that ? Can we envisage to increase this possibility ? > > None that I'm aware of. Feel free to move that code from tools to > libldap. Patches are welcome, as usual. But please put a note into the accompanying man-page with a strong recommendation not to use it without further security mechs. I wouldn't configure Samba like this. (Similar problems like DNS lookups in Kerberos implementations for realm- and KDC-discovery.) I've implemented something like this in web2ldap but the SRV mech causes an user interaction on the UI. So the user has a vague chance to determine whether he's tricked to another DSA by DNS spoofing. Ciao, Michael.
I'm not quite sure if it's a good idea to move ldap SRV lookup into ldap_initialize(), since ldap:/// is also means "this LDAP server" in referral objects and some slapd backends. Possibly some other syntax should be used to say "use SRV record", e.g. "ldap://./", or another function could work like ldap_initialize() but be more clever. Though a helper function which copies clients/tools/common.c:tool_conn_setup() functionality could in any case be useful. Also note that _ldap._tcp.domain is of limited utility outside Windows-land, because Microsoft annexed it for Active Directory: On a site which has Windows and Active Directory, _ldap._tcp.domain is normally required to refer to Active Directory. Thus if such a site uses another LDAP server for their public LDAP data, they can't _ldap._tcp.domain for that. -- Hallvard
h.b.furuseth@usit.uio.no wrote: > Also note that _ldap._tcp.domain is of limited utility outside > Windows-land, because Microsoft annexed it for Active Directory: I don't see why. > On a site which has Windows and Active Directory, _ldap._tcp.domain > is normally required to refer to Active Directory. Thus if such > a site uses another LDAP server for their public LDAP data, they > can't _ldap._tcp.domain for that. Off course you should use distinct "domains" (better say dc-style naming contexts for MS AD and other OpenLDAP DSAs). But then it won't collide. Ciao, Michael.
----- "h b furuseth" <h.b.furuseth@usit.uio.no> wrote: > I'm not quite sure if it's a good idea to move ldap SRV lookup into > ldap_initialize(), since ldap:/// is also means "this LDAP server" in > referral objects and some slapd backends. Possibly some other syntax > should be used to say "use SRV record", e.g. "ldap://./", or another > function could work like ldap_initialize() but be more clever. Though > a > helper function which copies clients/tools/common.c:tool_conn_setup() > functionality could in any case be useful. Probably the cleanest solution is to use extensions. 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 -----------------------------------
h.b.furuseth@usit.uio.no wrote: > Also note that _ldap._tcp.domain is of limited utility outside > Windows-land, because Microsoft annexed it for Active Directory: Most of system définitions may also be centralized without any used of Active Directory. Redundance notions are nevertheless necessary, also inside Linux-land ... ;-) Used of SRV rr is a good reponse, (in particular in case of large Intranet with many remote sites -islands in pacific- and poor communication ressources - satellite) but require to be performed in all client applications : nssldap, samba, ldap client tools for rsync/mail/DNS/proxy/supervision definitions, ... or openldap.
changed notes moved from Incoming to Software Enhancements
And what do you think about : ldap://.nameOfSrvDomainSearch/ ('.' at begining of the hostname to say "use SRV record" of this domain - search domain(s) if only '.') ?... -- pe -----Message d'origine----- De : Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] Envoye : mercredi 4 fevrier 2009 05:02 A : Philippe.eychart@informatique.gov.pf Cc : openldap-its@openldap.org Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) I'm not quite sure if it's a good idea to move ldap SRV lookup into ldap_initialize(), since ldap:/// is also means "this LDAP server" in referral objects and some slapd backends. Possibly some other syntax should be used to say "use SRV record", e.g. "ldap://./", or another function could work like ldap_initialize() but be more clever. Though a helper function which copies clients/tools/common.c:tool_conn_setup() functionality could in any case be useful. Also note that _ldap._tcp.domain is of limited utility outside Windows-land, because Microsoft annexed it for Active Directory: On a site which has Windows and Active Directory, _ldap._tcp.domain is normally required to refer to Active Directory. Thus if such a site uses another LDAP server for their public LDAP data, they can't _ldap._tcp.domain for that. -- Hallvard
and patch could be something like that ... -- pe -----Message d'origine----- De : Philippe EYCHART [mailto:philippe.eychart@informatique.gov.pf] Envoye : jeudi 5 fevrier 2009 11:33 A : h.b.furuseth@usit.uio.no; ando@sys-net.it Cc : openldap-its@openldap.org Objet : RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) And what do you think about : ldap://.nameOfSrvDomainSearch/ ('.' at begining of the hostname to say "use SRV record" of this domain - search domain(s) if only '.') ?... -- pe -----Message d'origine----- De : Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] Envoye : mercredi 4 fevrier 2009 05:02 A : Philippe.eychart@informatique.gov.pf Cc : openldap-its@openldap.org Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) I'm not quite sure if it's a good idea to move ldap SRV lookup into ldap_initialize(), since ldap:/// is also means "this LDAP server" in referral objects and some slapd backends. Possibly some other syntax should be used to say "use SRV record", e.g. "ldap://./", or another function could work like ldap_initialize() but be more clever. Though a helper function which copies clients/tools/common.c:tool_conn_setup() functionality could in any case be useful. Also note that _ldap._tcp.domain is of limited utility outside Windows-land, because Microsoft annexed it for Active Directory: On a site which has Windows and Active Directory, _ldap._tcp.domain is normally required to refer to Active Directory. Thus if such a site uses another LDAP server for their public LDAP data, they can't _ldap._tcp.domain for that. -- Hallvard
Sorry : -ldap_initialize( LDAP **ldp, LDAP_CONST char *url ) +ldap_initialize( LDAP **ldp, LDAP_CONST char *url_in ) -- PE
philippe.eychart@informatique.gov.pf wrote: > And what do you think about : ldap://.nameOfSrvDomainSearch/ ('.' at > begining of the hostname to say "use SRV record" of this domain - search > domain(s) if only '.') ?... I'd recommend not to mess around with the hostport portion of the LDAP URL. In opposite to Hallvard I'm not even sure whether a distinction is really needed when invoking ldap_initialize(). Ciao, Michael.
michael@stroeder.com wrote: > I'd recommend not to mess around with the hostport portion of the LDAP > URL. In opposite to Hallvard I'm not even sure whether a distinction is > really needed when invoking ldap_initialize(). ok ... The rfc 2255 defined the LDAP URL syntaxe as : scheme "://" [hostport] ["/" [dn etc... where host (rfc1738) must be a fully qualified domain name of a network host or IP address. (a fully qualified domain name cannot effectiely begin with a '.' ;-) Therefore, transforming a fully qualified domain name in a IP adress remains to be a DNS job. But, "My.domain.[:port]" is actually a fully qualified domain name and produce effectively one (at least) IP address of a network host when a SRV rr is defined and an authoritative answer can be obtained from a DNS. Of course I admit it could be not very efficient to try systematically a SRV resolution on every domain name of a LDAP URLS chain ... So I propose to add an extension (something like "forceSrvSearch") which will indicate that the library must perform a SRV request on this URL to find the IP address from the hostname (or hostport) parameter specified. It'll be a bit more complex to patch up ... :( -- PE
michael@stroeder.com wrote: > Such an extension would be feasible. But still I'm not sure whether this > distinction is needed. Although LDAP URL with empty hostport portion are > used internally (e.g. in ACLs) this IMHO does not affect > ldap_initialize(). Maybe I missed something. But before implementing a > patch this should be clarified. Do you suggest that an empty hostport (as ldap_initialize() arg) could mean that a SRV search is needed ? But this will reduce the search in the default domain name, won't it ? So, how to produce a search in another specific domain name when wished ? Where (in the URI) to appoint the root ("dc=my,dc=domain") or the explicit domain name ("my.domain") for the search domain ?... Secondarily, how to specify the present meaning "this LDAP server" if we use this empty hostport syntaxe for SRV seach ? (A SRV search could respond when the user think to request his local LDAP server ...) --- PE
philippe.eychart@informatique.gov.pf wrote: > michael@stroeder.com wrote: >> Such an extension would be feasible. But still I'm not sure whether this >> distinction is needed. Although LDAP URL with empty hostport portion are >> used internally (e.g. in ACLs) this IMHO does not affect >> ldap_initialize(). Maybe I missed something. But before implementing a >> patch this should be clarified. > > Do you suggest that an empty hostport (as ldap_initialize() arg) could mean > that a SRV search is needed ? > But this will reduce the search in the default domain name, won't it ? > So, how to produce a search in another specific domain name when wished ? > Where (in the URI) to appoint the root ("dc=my,dc=domain") or the explicit > domain name ("my.domain") for the search domain ?... > > Secondarily, how to specify the present meaning "this LDAP server" if we use > this empty hostport syntaxe for SRV seach ? (A SRV search could respond when > the user think to request his local LDAP server ...) OpenLDAP clients do the following: empty hostport, empty DN: localhost, default port empty hostport, non-empty DN: SRV what might be missing IMHO is: use domain to specify SRV however, I don't see any special need for it, as domain can always be put in DN form. I don't know if there's need for a form that asks to use SRV to discover the server for the default SUFFIX. In order to avoid issues, I recommend using something like x-dnssrv={<domain>|<DN>} where <DN> is restricted to the domain component sequence form. 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 -----------------------------------
Michael Ströder wrote: > As said I'm really concerned about security aspects: Because if the > hostname in the LDAP URL is absent there's absolutely no possibility to > check for DNS spoofing and the LDAP client would possibly happily send > its credentials to a rogue server, even with TLS or Kerberos. Think > twice before implementing this. > > Frankly I'd vote against stuffing this into standard function > ldap_initialize(). Using this without further pre-caution (like > user-interaction) is broken in a similar way like chasing LDAPv3 > referrals at the client side. But stuffing this in ldap_initialize(3) has the great advance of allowing to inject this feature in clients without the need to modify them, just reconfiguring. The use of a URL extension should make it clear that one intends to use the feature, and avoid unintentional (e.g. misconfiguration) uses. 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 -----------------------------------
Pierangelo Masarati [mailto:ando@sys-net.it] wrote: > OpenLDAP clients do the following: > empty hostport, empty DN: localhost, default port > empty hostport, non-empty DN: SRV > what might be missing IMHO is: > use domain to specify SRV > however, I don't see any special need for it, as domain can always be > put in DN form. > I don't know if there's need for a form that asks to use SRV to discover > the server for the default SUFFIX. > In order to avoid issues, I recommend using something like > x-dnssrv={<domain>|<DN>} > where <DN> is restricted to the domain component sequence form. Ok, I start on this agreement ... So, is it a Good Thing (IYHO ;) to introduce this patch according the "followup 9" ?... One other possible solution could be (for example) to patch the ldap_connect_to_host() function in os-ip.c (around getaddrinfo() and ldap_pvt_gethostbyname_a() calls). However, samba (as an example) seems not to use it ... I think that the first solution remains the one who will have a minimal impact on the existing sources ... Michael Str.der wrote: > Frankly I'd vote against stuffing this into standard function > ldap_initialize(). Using this without further pre-caution (like > user-interaction) is broken in a similar way like chasing LDAPv3 > referrals at the client side. I also think myself that security aspects are important ; but in other hand, IMHO : it is of the responsibility of the DNS administrator to configure cleanly and to protect its systems of any corruption (and maybe also to the project BIND to improve tools allowing it). Although it is there, the advantage of the suggested solution ("followup 9") is as well as this patch can be located as well within the function ldap_initialize() as within another frontal function (according to what will be finally decided ;). --- PE
philippe.eychart@informatique.gov.pf wrote: > Used of SRV rr is a good reponse, (in particular in case of large Intranet > with many > remote sites -islands in pacific- and poor communication ressources - > satellite) but require > to be performed in all client applications : nssldap, samba, ldap client > tools > for rsync/mail/DNS/proxy/supervision definitions, ... or openldap. We are in this case : I work in Tahiti, for the french polynesian gouvernment, IT departement. Our intranet take in a big geographic area recovering several islands. I'm in charge to transfer of the totality of our management systems (and network config) in a centralized base (of course: openldap). But, in one hand, distant servers (and users) can't be submit to communication links quality, in particular concerning local services (authentifications, local messaging, samba service, etc ...) and in other hand, we can't multipy the number of ldap servers assuming redundence (quite services merged, we already manage more than 100 servers - and about 4000 pc). So, one local server in every remote site must assume ldap service for the other local servers (which assume different services for different administrative departements) to guarantee acceptable performances (and also to insure a certain insensitivity in break of communication links, at least for local provided services) ; so, in case of an ldap server failure, the redundance must be assumed by the central servers group, with the help of SRV resolutions that (will) allow the ... excellent openldap library ;) It seems to me that SRV RRs definition is actually a quite good answer (easy to deploy and, why not, standardized) to this problematic. -----Message d'origine----- De : Michael Ströder [mailto:michael@stroeder.com] Envoyé : mercredi 11 février 2009 06:44 À : philippe.eychart@informatique.gov.pf Cc : openldap-its@openldap.org Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) philippe.eychart@informatique.gov.pf wrote: > Michael Ströder wrote: >> Frankly I'd vote against stuffing this into standard function >> ldap_initialize(). Using this without further pre-caution (like >> user-interaction) is broken in a similar way like chasing LDAPv3 >> referrals at the client side. > > I also think myself that security aspects are important ; but in other hand, > IMHO : it is of the responsibility of the DNS administrator to configure > cleanly and to protect its systems of any corruption (and maybe also to the > project BIND to improve tools allowing it). DNSSEC would be a solution. But my question is which problem to solve at first with SRV RRs? Ciao, Michael.
In fact, none of the LDAP clients need (can) write the directory servers. They (remote servers) only read informations needed to make (or upgrade) their own config files and to authenticate their own users. Client interfaces (web/php) allow the users to upgrade (or, according their profile, simply consult) the informations needed. Some of them (authorized "administrators" on remote sites) can to upgrade some more sensible informations (create/delete new users in their department, change them from groups, affect profile application softwares, create new emails/alias or proxy acces, upgrade departement informations or sometime, why not, administrate some new samba shares, ...) On central site, technicians of the hot-line or system administrators make the rest ... (of course, everything is not totally ended and work remains to be done ... What, as matter of fact, remains a good think concerning my remuneration ;-) --- PE -----Message d'origine----- De : Michael Ströder [mailto:michael@stroeder.com] Envoyé : jeudi 12 février 2009 00:29 À : Philippe EYCHART Cc : openldap-its@openldap.org Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) Philippe EYCHART wrote: > philippe.eychart@informatique.gov.pf wrote: >> Used of SRV rr is a good reponse, (in particular in case of large Intranet >> with many >> remote sites -islands in pacific- and poor communication ressources - >> satellite) but require >> to be performed in all client applications : nssldap, samba, ldap client >> tools >> for rsync/mail/DNS/proxy/supervision definitions, ... or openldap. > > We are in this case : I work in Tahiti, for the french polynesian > gouvernment, IT departement. > Our intranet take in a big geographic area recovering several islands. > I'm in charge to transfer of the totality of our management systems (and > network config) in a centralized base (of course: openldap). > But, in one hand, distant servers (and users) can't be submit to > communication links quality, in particular concerning local services > (authentifications, local messaging, samba service, etc ...) and in other > hand, we can't multipy the number of ldap servers assuming redundence (quite > services merged, we already manage more than 100 servers - and about 4000 > pc). > So, one local server in every remote site must assume ldap service for the > other local servers (which assume different services for different > administrative departements) to guarantee acceptable performances (and also > to insure a certain insensitivity in break of communication links, at least > for local provided services) ; so, in case of an ldap server failure, the > redundance must be assumed by the central servers group, with the help of > SRV resolutions that (will) allow the ... excellent openldap library ;) > It seems to me that SRV RRs definition is actually a quite good answer (easy > to deploy and, why not, standardized) to this problematic. IMHO DNS RRs are not a good failover mechanism. The LDAP clients would have to be quite smart to do the right thing. Especially if LDAP clients are writing to the directory servers. Ciao, Michael.
Here is a first result (patch integration) ... It doen't more remains to write the actual SRV search ... (coming soon) Here is a running log : root@testldap0:/var/log# >syslog root@testldap0:/var/log# grep "^[^#].*ldapsam:" /etc/samba/smb.conf passdb backend = ldapsam:"ldap://ns0 ldap://ns0/ou=profile%2cdc=gov%2cdc=pf??sub?(objectClass=*)?x-dnssrv=dc=gov% 2cdc=pf ldap://newldap/dc=srv%2cdc=gov%2cdc=pf??sub?(objectClass=*)?toto ldap:///dc=srv%2cdc=gov%2cdc=pf??sub??toto" root@testldap0:/var/log# /etc/rc.d/rc.samba restart Starting Samba: /usr/local/samba/sbin/smbd -D /usr/local/samba/sbin/nmbd -D root@testldap0:/var/log# cat syslog Feb 13 01:38:25 testldap0 smbd: the final url is: "ldap://ns0 ldap://ldap1.gov.pf ldap://ldap2.gov.pf ldap://ldap3.gov.pf ldap://newldap/dc=srv%2cdc=gov%2cdc=pf??sub?(objectClass=*)?toto ldap://ldap1.gov.pf ldap://ldap2.gov.pf ldap://ldap3.gov.pf-" -- PE
As I leave one week for a security formation ISO 27001 (and in case it would persuade me to make never more programming ;), here is the current state (not finished) of the patch (only the modified function - cf "Followup 19"). In fact, 2 more options must be validated there : 1/- ... // if (x-dnssrv == ".") then $hostname is (must be) the search SRV-domain (or the default domain, if $hostname=="") ... 2/- // in all cases, if (*port != '\0') then : result = $(grep "$port" $(the result of the SRV search)) ... -- PE
philippe.eychart@informatique.gov.pf wrote: > This is a multi-part message in MIME format. > > ------=_NextPart_000_00C2_01C98DEA.AA80EF10 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > > As I leave one week for a security formation ISO 27001 (and in case it would > persuade me to make never more programming ;), here is the current state > (not finished) of the patch You should upload patches to ftp.openldap.org and post a link to them, otherwise mailers screw them up as below. Please follow instructions at <http://www.openldap.org/devel/contributing.html#submitting>. p. (only the modified function - cf "Followup 19"). > In fact, 2 more options must be validated there : > 1/- ... // if (x-dnssrv == ".") then $hostname is (must be) the search > SRV-domain (or the default domain, if $hostname=="") ... > 2/- // in all cases, if (*port != '\0') then : result = $(grep "$port" $(the > result of the SRV search)) ... > -- > PE > > ------=_NextPart_000_00C2_01C98DEA.AA80EF10 > Content-Type: application/octet-stream; > name="open.c.url_expand.patch" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: attachment; > filename="open.c.url_expand.patch" > > --- openldap-2.4.13/libraries/libldap/open.c 2008-10-31 = > 23:23:58.000000000 +0000=0A= > +++ openldap-2.4.13/libraries/libldap/open.c 2009-02-14 = > 00:31:27.000000000 +0000=0A= > @@ -212,19 +212,164 @@=0A= > return( ld );=0A= > }=0A= > =0A= > +int=0A= > +url_expand_on_srv_search ( char ***result, LDAP_CONST char *url_in, = > char *domain )=0A= > +{ int rc =3D 0;=0A= > + char *scheme, *hostname, *port, *opt;=0A= > +=0A= > + // Syntax validation ...=0A= > + if ( (scheme =3D (char *)LDAP_STRDUP( url_in )) =3D=3D NULL )=0A= > + return -1; // memory error ...=0A= > +=0A= > + hostname =3D (char *)strchrnul( scheme, '/' ); *hostname++ =3D '\0';=0A= > + if ( *hostname++ !=3D '/' )=0A= > + return -1; // syntax error ...=0A= > + =0A= > + opt =3D (char *)strchrnul( hostname, '/' ); if ( *opt ) *opt++ =3D = > '\0';=0A= > + port =3D (char *)strchrnul( hostname, ':' ); if ( *port ) *port++ =3D = > '\0';=0A= > +=0A= > + if ( *hostname && !strcmp ( domain, "." )=3D=3D0 ) // if (x-dnssrv = > =3D=3D ".") then $hostname is the search SRV-domain (or default domain, = > if $hostname=3D=3D"") ...=0A= > + return -1; // syntax error ...=0A= > +=0A= > + // So now, we can search the server name(s) of the _ldap._tcp.$domain = > service ...=0A= > + // if ( *port !=3D '\0') then : grep the result of SRV RR search with = > $port ...=0A= > +=0A= > + // Coming soon ...=0A= > +if ( (*result =3D ldap_str2charray( "ldap1.gov.pf ldap2.gov.pf = > ldap3.gov.pf", " " )) !=3D NULL ) rc =3D 3; // line to delete ...=0A= > +=0A= > + // Search is finished : so now, add initial scheme and opt to result = > hostport(s) ...=0A= > + if ( *result !=3D NULL ) {=0A= > + size_t plus =3D strlen( scheme ) + strlen ( opt ) + 4;=0A= > + for ( rc=3D0; (char *)((*result)[rc]) !=3D NULL; ) {=0A= > + (*result)[rc] =3D (char *)LDAP_REALLOC ( (char *)((*result)[rc]), = > strlen ( (char *)((*result)[rc]) ) + plus ); =0A= > + { // do a : memcpy ( &((char *)((*result)[rc]))[strlen( scheme ) + = > 2], *result[rc], strlen( (char *)((*result)[rc]) ) + 1 );=0A= > + char *n =3D &((char *)((*result)[rc]))[strlen( scheme ) + 2];=0A= > + char *s =3D (char *)((*result)[rc]);=0A= > + char *e =3D s + (strlen( (char *)((*result)[rc]) ) + 1);=0A= > + for ( n +=3D e - s; e >=3D s; ) *n-- =3D *e--;=0A= > + }=0A= > + memcpy ( &((char *)((*result)[rc]))[strlen( scheme )], "//", 2 );=0A= > + memcpy ( (char *)((*result)[rc]), scheme, strlen( scheme ) );=0A= > + strcat ( (char *)((*result)[rc]), "?" ); strcat ( (char = > *)((*result)[rc]), opt );=0A= > + rc++;=0A= > + }=0A= > + } else rc =3D 0;=0A= > +=0A= > + LDAP_FREE ( scheme );=0A= > + return rc;=0A= > +}=0A= > +=0A= > +char *=0A= > +expand_dnssrv_definitions ( LDAP_CONST char *url_in )=0A= > +{=0A= > ...=0A= > =0A= > > ------=_NextPart_000_00C2_01C98DEA.AA80EF10-- > > 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 -----------------------------------
Hi, Here is the description of use of the current version of the "x-dnssrv" extension through some examples: CONTEXT OF EXAMPLE : /etc/resolv.conf: search gov.pf nameserver localhost /var/named/pz/gov.pf: $ORIGIN gov.pf. ... _ldap._tcp IN SRV 0 1 389 ldap IN SRV 1 1 389 ldap1.backup.gov.pf. IN SRV 1 1 390 ldap2.backup.gov.pf. ... and /var/named/pz/backup.gov.pf: $ORIGIN backup.gov.pf. ... _ldap._tcp IN SRV 0 1 389 ldap0 IN SRV 0 1 389 ldap1 ... LDAP URI EXAMPLES FOR THE "x-dnssrv" EXTENSION: For: "ldap:///ou=person,dc=gov,dc=pf??sub??x-dnssrv=dc=gov%2cdc=pf" -> the result URI will be: "ldap://ldap.gov.pf.:389/ou=person,dc=gov,dc=pf??sub \ ldap://ldap1.backup.gov.pf.:389/ou=person,dc=gov,dc=pf??sub \ ldap://ldap2.backup.gov.pf.:390/ou=person,dc=gov,dc=pf??sub" For: "ldap:///????x-dnsSRV=gov.pf." -> the result URI will be: "ldap://ldap.gov.pf.:389 ldap://ldap2.backup.gov.pf.:390 / ldap://ldap1.backup.gov.pf.:389" For: "ldap:///dc=gov%2cdc=pf????x-dnssrv" -> the result URI will be: "ldap://ldap.gov.pf.:389/dc=gov%2cdc=pf \ ldap://ldap1.backup.gov.pf.:389/dc=gov%2cdc=pf \ ldap://ldap2.backup.gov.pf.:390/dc=gov%2cdc=pf" For: "ldap://gov.pf.:389/????x-dnssrv" -> the result URI will be: "ldap://ldap.gov.pf.:389 ldap://ldap1.backup.gov.pf.:389" For: "ldap:///????x-dnssrv[,extension]*" -> because of resolv.conf, the result URI will be: "ldap://ldap.gov.pf.:389/????[extension[,extension]*]* \ ldap://ldap1.backup.gov.pf.:389/????[extension[,extension]*]* \ ldap://ldap2.backup.gov.pf.:390/????[extension[,extension]*]*" WARNING: "ldap://goov.pf./????x-dnssrv" -> give: "" "ldap://gov.pf./????x-dnssrv,x-dnssrv=dc=backup%2cdc=gov%2cdc=pf" -> give: "ldap://ldap.gov.pf.:389/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf \ ldap://ldap2.backup.gov.pf.:389/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf \ ldap://ldap1.backup.gov.pf.:390/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf" "ldap:///dc=gov%2cdc=pf???sub?x-dnssrv=dc=backup%2cdc=gov%2cdc=pf" -> give: "ldap://ldap0.backup.gov.pf.:389/dc=gov,dc=pf???sub \ ldap://ldap1.backup.gov.pf.:389/dc=gov,dc=pf???sub" "ldap://ldap.gov.pf/dc=backup%2cdc=gov%2cdc=pf????x-dnssrv" -> give: "ldap://ldap.gov.pf.:389/dc=backup%2cdc=gov%2cdc=pf \ ldap://ldap2.backup.gov.pf.:389/dc=backup%2cdc=gov%2cdc=pf \ ldap://ldap1.backup.gov.pf.:390/dc=backup%2cdc=gov%2cdc=pf" "ldap:///o=gov%2cc=pf????x-dnssrv" correct, but because of default the domain research ... -> give: "ldap://ldap.gov.pf.:389/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf \ ldap://ldap1.backup.gov.pf.:390/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf \ ldap://ldap2.backup.gov.pf.:389/????x-dnssrv=dc=backup%2cdc=gov%2cdc=pf" SYNTAX ERROR (the resultant URI will remain unchanged): "ldap://ldap.gov.pf/dc=gov%2cdc=pf????x-dnssrv=dc=gov%2cdc=pf" "ldap://ldap.gov.pf/????x-dnssrv=dc=gov%2cdc=pf" "ldap://ldap.gov.pf/????x-dnssrv=gov.pf." "ldap://dc=gov%2cdc=pf/????x-dnssrv" "ldap://gov.pf[/[?[?[?[?]]]]]" etc ... I proceed in the last check of sources and I post patchs (open.c & dnssrv.c) ... -- PE
Sorry : error in the last warning example !... "ldap:///o=gov%2cc=pf????x-dnssrv" correct, but because of the default domain search (cf. resolv.conf) - not because of "o=gov,c=pf" (which isn't the dn of a domaine) ... -> give (of course): "ldap://ldap.gov.pf.:389/o=gov%2cc=pf \ ldap://ldap1.backup.gov.pf.:390/o=gov%2cdc=pf \ ldap://ldap2.backup.gov.pf.:389/o=gov%2cdc=pf" -- PE
I must be tired !... ;) The good result is ... : "ldap://ldap.gov.pf.:389/o=gov%2cc=pf \ ldap://ldap2.backup.gov.pf.:390/o=gov%2cc=pf \ ldap://ldap1.backup.gov.pf.:389/o=gov%2cc=pf" yes!!! -----Message d'origine----- De : Philippe EYCHART [mailto:philippe.eychart@informatique.gov.pf] Envoyé : vendredi 27 février 2009 13:39 À : openldap-its@openldap.org Objet : RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) Sorry : error in the last warning example !... "ldap:///o=gov%2cc=pf????x-dnssrv" correct, but because of the default domain search (cf. resolv.conf) - not because of "o=gov,c=pf" (which isn't the dn of a domaine) ... -> give (of course): "ldap://ldap.gov.pf:389/o=gov%2cc=pf \ ldap://ldap1.backup.gov.pf:390/o=gov%2cdc=pf \ ldap://ldap2.backup.gov.pf:389/o=gov%2cdc=pf" -- PE
Name of the tarball posted on ftp.openldap.org : philippe_eychart_openldap_x-dnssrv_20090227.tgz. Content: - file1 : openldap-2.4.13-i486-1.x-dnssrv.open.c.20090227.patch (8918 bytes) - file2 : openldap-2.4.13-i486-1.rfc2782-priOnly.dnssrv.c.20090227.patch (5437 bytes) (necessary to patch1 because of the possible empty domain argument option - and, of course, to implement the priority notion ...) Regards
I would like to end the patch of dnssrv.c by implementing the weighty notion in SRV searchs (according to the rfc2782); but the use of a file disk to store the previous answers does seem to me a very successful solution. Would anybody have better one idea?...
Hi, So, no idea about how to save the result of a previous SRV request in the implementation of the weight notion according to the rfc 2782?... From my part either :-( (perhaps, somewhere in the kernel?...) PE PS: About the patch, I use it for several weeks now and everything seems good : no bugg, functioning and result waited ;-)
"result waited" : sorry, I wanted to say "result such as hoped" ;-)
libldap require x-dnssrv=TRUE? patch welcome
Created attachment 601 [details] philippe_eychart_openldap_x-dnssrv_20090227.tgz From the FTP server
has serious security issues, no real use case.