Hi,
Just guessing by the error message, but your DNS Server does have a
valid service record for that Base DN? As the error message suggests
otherwise, but I may as well be completely off here.
Otherwise, but I am sure you know that, with only two "/" you can alway
use the hostname, in case the DNS serive record is missing:
ldapsearch -H ldap://server.example.net -b dc=example,dc=net" 'cn=foo'
Am 10.02.23 um 17:51 schrieb Norman Gray:
Greetings.
This command fails in an unexpected way:
% ldapsearch -x -H 'ldap:///dc=example,dc=net' '(cn=foo)'
Could not parse LDAP URI(s)=ldap:///dc=example,dc=net (3)
It appears that ldapsearch wants me to escape the '=' and ',' in that URI:
% ldapsearch -x -H 'ldap:///dc%3dexample%2cdc%3dnet' '(cn=foo)'
DNS SRV: Could not turn domain=example.net into a hostlist
But why? The manpage for ldapsearch says
-HÂ ldapuri
Specify URI(s) referring to the ldap server(s); a list of URI,
separated by whitespace or commas is expected; only the
protocol/host/port fields are allowed. As an exception, if no
host/port is specified, but a DN is, the DN is used to look up
the corresponding host(s) using the DNS SRV records, according
to RFC 2782. The DN must be a non-empty sequence of AVAs whose
attribute type is "dc" (domain component), and must be escaped
according to RFC 2396.
I read that as clearly saying (via the 'exception' branch of that paragraph)
that the first -H argument is correct.
RFC digression:
According to RFC 2396, the /dc... is `"/" path_segments`, segments are composed
of *pchar, and
pchar = unreserved | escaped |
":" | "@" | "&" | "=" | "+" | "$" | ","
...which includes both '=' and ','. Thus those characters don't need to be
escaped, by RFC 2396. Or, put another way, 'ldap:///dc=example,dc=net' _is_
escaped according to RFC2396, in the sense that nothing in it needs to be
escaped.
Looking instead at RFC 4516, the 'dn' in the 'ldapurl' is a 'distinguishedName' from RFC 4514 which
(Sect.3) permits '=' and ',' to be included. Sect.2.1 of 4516 requires that the URI must include
<reserved>, <unreserved> or <pct-encoded> of RFC 3986, but if we look at that, then
Sect.2.2 indicates that <reserved> includes both '=' and ','.
Thus the behaviour of ldapsearch, when parsing the -H option, doesn't appear to
match the documentation.
Explanation:
Looking at common.c:tool_args and common.c line 1199, I see that it calls
ldap_url_parselist to break the -H argument into a list of URIs, and this will
separate dc=example,dc=net at the comma. And sure enough, in practice it's
only the ',' that has to be escaped by %2c.
I believe this behaviour doesn't match the manpage, which (clearly in my
reading of it) requires either a list of protocol/host/port URIs OR (the
exception) a single URI containing no host/port but only a DN. That suggests
that common.c:tool_args has to detect that exception/second case. Apart from
the documentation issue, having to escape commas is both repeatedly surprising
and a pain in the neck on the occasions when I want to use the dc=... syntax
with ldapsearch.
Re detecting that exception, searching for "///" in the ldapuri string would seem to be
sufficient, and calling ldap_url_parselist_int in that case (instead of ldap_url_parselist) with a
sep argument of " " looks like it would do the job with a minimal change to the code.
Best wishes,
Norman
