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. Cheers, Benno [1] Ok, well some databases store configuration in the database themself, but they don't care about the *users* data. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
