Benno wrote:
On Sun Apr 23, 2006 at 17:54:40 +1000, Philip Greggs wrote:
On 4/23/06, Benno <[EMAIL PROTECTED]> wrote:
Now as it turned out 'example.com' is active domain and belongs to
someone else (#wohois example.com). So with 'HOST ldap.example.com'
in ldap.conf of the client, which is #lapdadd -x -D
"cn=Manager,cn=example,dc=com'
will ask the authoritative DNS where to find 'ldap.example.com'.
The client will be directed to an LDAP server 'ldap.example.com' if there
is such a server. Since that server is not the intended server, it will return
errors even when the DN and the password are right.
Why is the 'ldapsearch -x ' returning an error ? This was the question.
The fact that the client is directed to an LDAP server 'ldap.example.com' has
everything to do with
"HOST ldap.example.com"
in ldap.conf, (or -h/-H command line arguments) and *nothing* to do with the
query.
For example, with the same setup:
ldapdadd -x -D "cn=Manager,cn=foo,dc=com'
The client will still be directed to ldap.example.com to find records
about the domain foo.com. Alternatively it could be
ldap.megasearch.com, holds a lot of records about a bunch of different
domains. So in ldap.conf I'd have:
"HOST ldap.megasearch.com"
Then:
ldapdadd -x -D "cn=Manager,cn=example,dc=com'
Would try ldap.megasearch.com, and there is no reason that the ldap server
there wouldn't hold records for the DN dc=example,dc=com. There is nothing
All RFC2247 does is:
"defines an algorithm by which a name registered with
the Internet Domain Name Service [2] can be represented as an LDAP
distinguished name."
Now it would probably be nice if on:
$ ldapadd -x -D "cn=Manager,dc=example,dc=com"
ldapadd would parse the query string, and then work out that it should
automatically guess that the ldap server holding records for that DN was
at ldap.example.com, but, afaik, that is totally *not* how LDAP works.
In fact RFC2247 specifically does not:
"define the procedure to locate an enterprise's LDAP directory server,
given their domain name."
LDAP totally separates the data held in an ldap server and how to
contact an ldap server. If you think of an LDAP server as a database,
(which is more or less what it is), then I find things fall out and
become easier to understand.
In a database server the server doesn't treat the contents of the
database as having any type of semantics that the server itself
should care about.[1] In fact the user specifies the format of the
data in a schema. LDAP works in exactly the same way, except it is
optimised for storing hierarchical data. Just as a SQL client can't
tell which database to conect to based on the contents of the query
string, neither can an LDAP client tell which server to connect to
based on the contents of the query string.
Since you were talking about RFC3663 it is important to note that it:
"defines an Experimental Protocol for the Internet community. It does
not specify an Internet standard of any kind."
It is defining the layout of a *particular* set of LDAP data, specifcally
showing a way in which you *could* store some of the data currently in WHOIS
in an LDAP server. Specifically is talking about how a registry and registrar
databases could possibly interact. I can't find any version of RFC3663 that
actually supercedes it to suggest that it ever went past experimental
suggestion,
I'm sure one of the domain registrars on the list can probably tell us, but
given I'm still using whois, I can only imagine it hasn't gone forward.
Anyway, the point is RFC3663 doesn't say *anything* about how a person should
setup the data in their LDAP server.
The short answer to all these is, there are two LDAP standards, namely:
1. X.500
2. IETF
Use anything other than any of these standards, your LDAP implementation
is risking errors.
Clearly the original poster is using IETF. In RFC 3663 as one previous
post cited the original poster's domain is
example.com
Hope this helps.
O Plameras
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
