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."
What do you use for your DIT that's not defined following X.500 or this IETF
RFC, since you imply you're not following X.500 or IETF standards ?
Can you give specific examples of your 'slapd.conf', your 'rootdn' and your
TOP organization ? We'll see if your interpretation is implementable and
follows
the Internet Standards.
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.
I've read this RFC 3663 a few times before. I just read it again.
And once again it specifies that in Internet based LDAP
implementations when your domain is 'example.com' then
you have 'dc=example,dc=com' as your suffix. If any
organization does not respect this standard, there is a risk
that the implementation will have some errors.
So, doing another way will not prevent anyone but at the
risk of having errors. This is what had happen to the OP
without realising it. I tried to make him realise.
Now, to your example that in ldap.conf of the client he'll
have 'ldap.megasearch.com' even when his/her suffix is
'dc=example,dc=com', again the client will not be stopped
but risking the possibility of errors. It will work if
'example.com' domain had arranged for it's LDAP
server with suffix 'dc=example,dc=com' to be housed
in 'ldap.megasearch.com'. I must add that in the 'slapd.conf'
at 'ldap.megasearch.com' there must be a line that says,
rootdn "cn=Manager,dc=example,dc=com" or
something similar.
Since this debate has come about as result of the original
post, the implied intent is that his domain is 'example.com'
because his suffix 'dc=example,dc=com'.
This is what I'd think. I realised this a problem using 'example.com'
some time back in the past that's why I use 'example.com.ex' in my testings.
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
