How to Test Whether LDAP is Working Properly
Articles and Tips: article
01 Jul 2002
Excerpts from Technical
Information Document (TID)
#10059954
This solution is designed to determine whether an LDAP-related problem is coming from a problem with NDS and the LDAP server, or from the client application that is making LDAP requests.
An excellent resource for the configuration, testing, and development of LDAP for NDS can be found in Novell's LDAP Developer's Guide by Roger G. Harrison, Jim Sermersheim, and Steve Trottier; published 2000 (ISBN 0-7645-4720-8).
Configure DSTRACE To View Results
Before continuing, make sure that DSTRACE is configured to view the back end of LDAP queries. This will make troubleshooting problems much easier. These instructions are for NetWare only; for NT and Linux/UNIX, the setup will be slightly different, but the process will be the same.
Type DSTRACE ON at the NetWare console to load the DSTRACE NLM.
Type DSTRACE again at the NetWare console to display a list of available options.
Type DSTRACE -ALL to turn off all other filters (you need the latest versions of DSTRACE for this feature to work; earlier versions may need the DSTRACE CLEAR ALL command).
Type DSTRACE +LDAP to turn on the LDAP filter which allows display of LDAP messages.
To turn on the tracing to a screen, type DSTRACE SCREEN ON. To trace to a file, type DSTRACE FILE ON.
Configure which options will be traced by launching ConsoleOne (preferably version 1.2d or later; the snapins are modified in these versions). Go to the LDAP server object and open the properties window. Switch to the tab labeled "Screen Options." This tab allows you to choose which items are traced once DSTRACE has been enabled.
For testing purposes, choose Critical Errors, Configuration Processing, Informational Messages, Search Response Summary, and Connection Information. This will enable DSTRACE to show the queried posed by the client, the authentication mechanism, and the results of the query.
Be aware that DSTrace causes the server to take a big hit in performance; turn off DSTRACE once testing is completed.
Configuring the Tree for Testing
The tests in this solution were performed on a single-server tree running eDirectory 8.5, although that should not be a determining factor in the process. To match the conditions of the tests below, make sure that user Admin has full rights to everything, and is a trustee at [Root] with explicit rights to all entry options and all attribute/property options. (This is not the default; by default, admin only has supervisor entry rights).
Next, make sure that an LDAP proxy user is assigned as a trustee (normally at [Root]) and that it has No rights. This is important so that LDAP will not return the whole tree as results when an anonymous query is performed. If this is not done, then the proxy user will inherit the rights of [Public], which means by default that it will have Browse rights to the whole tree. (You can do this by making sure that all the check boxes except for "inheritable" are unchecked, not grey.)
An LDAP proxy user is used so that anonymous queries are limited to certain information. By configuring a proxy user with specific (limited) rights, anonymous queries will return limited information. Otherwise, anonymous queries will return information according to inherited rights of [Public].
An LDAP proxy user is a standard NDS user object (with any name) that has a blank password. This is critical, since either No password or Any password will cause the object to fail when authenticating. If a proxy user does not have a password, then it has no public/private key pair, and thus will never be able to log in. If a proxy user has Any password (any combination of characters), then the object will not be able to log in generically. Therefore, it needs to have a password that is blank ; this will allow the object to log in generically without problems.
About Utilities for Testing
There are multiple products with which to test LDAP. The Netscape Web Browser (4.x) is an easy tool to use, and works pretty well for generic queries to test whether the LDAP server is working in general. However, there are a few known issues with it, and so it might be better to use a different utility that allows for more customization of queries.
The queries in the tests below were all performed with the "ldapsearch" utility from the Netscape SDK. This is a third-party tool and is not endorsed or supported by Novell. The "ldapsearch" utility can be found in the Netscape LDAP SDK.
Similar utilities can be found elsewhere, including one provided by Novell. This utility has the same name as the Netscape utility (ldapsearch), but uses a slightly different syntax. It can be found on the CDROM that accompanies the book mentioned above.
Testing LDAP
LDAP queries/actions can be classified by asking two questions: is the query secure (does it use SSL), and is the query authenticated (are you querying anonymously or as a specific user). The answers to these two questions provide for four types of LDAP queries:
Authenticated, non-secure query
Unauthenticated, non-secure query (proxy)
Authenticated, secure query (SSL)
Unauthenticated, secure query (SSL, proxy)
To test LDAP whether the server or the client is causing a problem, it is necessary to try each of these queries with a utility that is known to work properly. If queries for each of the above types work with this utility but not with another application, then the problem must lie within the application itself and not the NDS LDAP server. The NDS LDAP server is based on open LDAP standards, and thus will work with any LDAP client that is correctly wording queries.
The syntax of the Netscape ldapsearch utility is somewhat difficult. To learn more about the correct syntax go to http://developer.netscape.com/docs/manuals/directory/41/ag/find.htm and http://developer.netscape.com/docs/manuals/enterprise/mngserv/ldapsrch.htm .
There are a couple of items to be careful of for SSL queries. Since Netscape created the utility, they want you to use the certificate database from the Netscape browser. The syntax for the query shows that I was using "A:\CERT7.DB,"a certificate database file that I pulled out of Communicator after importing my trusted root certificate from NDS. The database is located in [ netscape root directory ]\users\[ name of profile , such as "default"].
Another file needs to accompany the certificate database. This is the security module KEY3.DB file. It should be copied from the Netscape profile directory to the same location as the certificate database used for the query. Together, the CERT7.DB and KEY3.DB files provide the information the utility requires for SSL connections. If you receive a -8174 error, it is likely that these files were not copied correctly, or that their contents are not correct.
Example of Test Results and Search Syntax
The results of each of the four types of tests is shown below, listing the syntax and the results from the dstrace screen with LDAP options turned on. The results are returned in LDIF format.
These queries can easily be created as batch files that can be edited in text editors like Notepad. Then, you can simply run the batch file from the command prompt to prevent retyping the whole query each time.
Conclusion
In short, unauthenticated connections returned information only for the proxy user, because he can only see himself. When a query is formed to log in as admin, who could see everything, results were returned for everything. The query could have been formed to request all attributes, but it limited the search results to show the CN and DN only (see the last part of the search string).
If you're still not convinced that the connection is being made over a secure port, try disabling port 389 so the system has no choice but to bind through the secure port 636. If it still works, then you are guaranteed to be making an SSL connection. If it works, but you are seeing more or less information than you think you should be seeing, make sure your rights assignments are set properly. Use the effective rights option in ConsoleOne to verify this.
Once you have verified that this is working properly, then any application that returns different information is a fault in that application. For example, the Netscape address book binds as "anonymous" even when you try to log in. This appears to be an issue with that product.
|
Authenticated, Non-secure Search
|
Results of the Authenticated, Non-secure Search
|
|
A:\>ldapsearch -b o=novell -h 10.10.10.1 -D cn=admin,o=novell -w novell -E -u "cn=*" cn version: 1 dn: cn=admin,o=novell ufn: admin,novell cn: admin dn: cn=Bulkload,o=novell ufn: Bulkload,novell cn: Bulkload Object cn: Bulkload dn: cn=CKLINE-51,o=novell ufn: CKLINE-51,novell cn: CKLINE-51 dn: cn=CKLINE-51_SYS,o=novell ufn: CKLINE-51_SYS,novell cn: CKLINE-51_SYS dn: cn=CKLINE-51_VOL1,o=novell ufn: CKLINE-51_VOL1,novell cn: CKLINE-51_VOL1 dn: cn=LDAP Group - CKLINE-51,o=novell ufn: LDAP Group - CKLINE-51,novell cn: LDAP Group - CKLINE-51 dn: cn=LDAP Server - CKLINE-51,o=novell ufn: LDAP Server - CKLINE-51,novell cn: LDAP Server - CKLINE-51 |
Created new monitor 0x0 Monitor 0x1dd started DoBind on connection 0xd044fac0 DoBind: name = 'cn=admin,o=novell', client version = 3, method = 0x80 send_ldap_result 0:"":""to connection 0xd044fac0 DoSearch on connection 0xd044fac0 get_filter: begin get_filter get_filter: PRESENT SRCH base "o=novell" scope 2 deref 0 sizelimit 0 timelimit 0 attrsonly 0 filter: (cn=*) attrs: cn nds_back_search: getOperationalAttrs is TRUE => send_search_entry (cn=admin,o=novell) => send_search_entry (cn=Bulkload,o=novell) => send_search_entry (cn=CKLINE-51,o=novell) => send_search_entry (cn=CKLINE-51_SYS,o=novell) => send_search_entry (cn=CKLINE-51_VOL1,o=novell) => send_search_entry (cn=LDAP Group - CKLINE-51,o=novell) => send_search_entry (cn=LDAP Server - CKLINE-51,o=novell) send_ldap_result 0:"":""to connection 0xd044fac0 DoUnbind on connection 0xd044fac0 |
|
Anonymous, Non-secure Search
|
Results of the Anonymous, Non-secure Search
|
|
A:\>ldapsearch -b o=novell -h 10.10.10.1 -E -u "cn=*" cn version: 1 dn: cn=proxy,o=novell ufn: proxy,novell cn: proxy |
DoSearch on connection 0xd044fac0 DoBind on connection 0xd044fac0 DoBind: name = 'anonymous', client version = 3, method = 0x80 get_filter: begin get_filter get_filter: PRESENT SRCH base "o=novell" scope 2 deref 0 sizelimit 0 timelimit 0 attrsonly 0 filter: (cn=*) attrs: cn nds_back_search: getOperationalAttrs is TRUE => send_search_entry (cn=proxy,o=novell) send_ldap_result 0:"":""to connection 0xd044fac0 DoUnbind on connection 0xd044fac0 |
|
Authenticated, Secure Search
|
Results of the Authenticated, Secure Search
|
|
A:\>ldapsearch -b "o=novell" -h 10.10.10.1 -p 636 -Z -P a:\cert7.db -D cn=admin,o=novell -w novell -E -u "cn=*" cn version: 1 dn: cn=admin,o=novell ufn: admin,novell cn: admin dn: cn=Bulkload,o=novell ufn: Bulkload,novell cn: Bulkload Object cn: Bulkload dn: cn=CKLINE-51,o=novell ufn: CKLINE-51,novell cn: CKLINE-51 dn: cn=CKLINE-51_SYS,o=novell ufn: CKLINE-51_SYS,novell cn: CKLINE-51_SYS dn: cn=CKLINE-51_VOL1,o=novell ufn: CKLINE-51_VOL1,novell cn: CKLINE-51_VOL1 dn: cn=LDAP Group - CKLINE-51,o=novell ufn: LDAP Group - CKLINE-51,novell cn: LDAP Group - CKLINE-51 dn: cn=LDAP Server - CKLINE-51,o=novell ufn: LDAP Server - CKLINE-51,novell cn: LDAP Server - CKLINE-51 |
DoBind on connection 0xd044fac0 DoBind: name = 'cn=admin,o=novell', client version = 3, method = 0x80 send_ldap_result 0:"":""to connection 0xd044fac0 DoSearch on connection 0xd044fac0 get_filter: begin get_filter get_filter: PRESENT SRCH base "o=novell" scope 2 deref 0 sizelimit 0 timelimit 0 attrsonly 0 filter: (cn=*) attrs: cn nds_back_search: getOperationalAttrs is TRUE => send_search_entry (cn=admin,o=novell) => send_search_entry (cn=Bulkload,o=novell) => send_search_entry (cn=CKLINE-51,o=novell) => send_search_entry (cn=CKLINE-51_SYS,o=novell) => send_search_entry (cn=CKLINE-51_VOL1,o=novell) => send_search_entry (cn=LDAP Group - CKLINE-51,o=novell) => send_search_entry (cn=LDAP Server - CKLINE-51,o=novell) send_ldap_result 0:"":""to connection 0xd044fac0 DoUnbind on connection 0xd044fac0 |
|
Anonymous, Secure Search
|
Results of the Anonymous, Secure Search
|
|
A:\>ldapsearch -b "o=novell" -h 10.10.10.1 -p 636 -Z -P a:\cert7.db -E -u "cn=*" cn version: 1 dn: cn=proxy,o=novell ufn: proxy,novell cn: proxy |
DoSearch on connection 0xd044fac0 DoBind on connection 0xd044fac0 DoBind: name = 'anonymous', client version = 3, method = 0x80 get_filter: begin get_filter get_filter: PRESENT SRCH base "o=novell" scope 2 deref 0 sizelimit 0 timelimit 0 attrsonly 0 filter: (cn=*) attrs: cn nds_back_search: getOperationalAttrs is TRUE => send_search_entry (cn=proxy,o=novell) send_ldap_result 0:"":""to connection 0xd044fac0 DoUnbind on connection 0xd044fac0 |
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.