There is a process that we go through to help people debug their LDAP issues. You can do it on your own (of course, if you get stuck you can always contact technical support). We recommend using the JXplorer LDAP browser for this task because it's a Java tool and as such it uses the same underlying LDAP library that CodeCollaborator will use. Here's the process:
- Download and install JXplorer, following the recommended installation guidelines.
- Start up JXplorer.
- From the File menu, choose Connect.
- In the connect dialog ("Open LDAP/DSML Connection"), specify the following:
- Host: the hostname portion of the connectionURL attribute from the Realm declaration in ROOT.xml.
- Port: the port portion of the connectionURL attribute from the Realm declaration in ROOT.xml.
Usually this is 389, which is the default if unspecified. Some Active
Directory configurations require connecting to the "Global Catalog"
which is port 3268 (you may see errors that say "DomainDnsZones.foo.bar.com" which means you need to use this port).
- Base DN: The value of the userBase attribute from from the Realm declaration in ROOT.xml.
- Security Level: User + Password
- Security User: The value of the connectionName attribute from the Realm declaration in ROOT.xml.
This should be a name that looks like an email address (jason@…) or
something that looks like an LDAP distinguished name
(uid=jason,ou=people,dc=mycompany,dc=com)
- Security Password: The value of the connectionPassword attribute from the Realm declaration in ROOT.xml.
- Click Ok to connect to establish the connection.
- If the connection establishes normally, you
should see the Explore tree populate with some nodes that represent
entities in your directory. Note: You may see a Error that
"Search partially failed!" This seems to be normal and is a consequence
of the way Active Directory does its searching.
- If the connection fails to establish normally, check the error message that explains the failure.
- Is it a network issue? This could mean that
the hostname or port number is wrong or that a firewall (local or on the
network somewhere) is preventing the connection to the LDAP
server. It could also mean that the LDAP server is simply offline.
Double check your connection information and firewalls and if you still
cannot connect, contact your LDAP administrator. (This error looks like:
"Error opening connection: 192.168.10.441:389")
- Is it a login issue? The specific error messages that come back will depend on the LDAP
server in question, but if it is a "security" related message it
probably means the user DN or password is wrong. Double check those and
try to reestablish the connection. If that fails, perhaps the LDAP
account does not exist or does not have query permissions on the
directory. Consult your LDAP administrator for help getting the
appropriate access. An example of an error message from an Active
Directory server is as follows:
Error opening connection:
[LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece
- If it is neither of those issues, send the error message
verbatim to Smart Bear technical support (the JXplorer error dialog
accepts Ctrl-C to copy the message to the clipboard), or consult Google or your LDAP administrator.
- Once the connection is established, it is time to verify the search parameters. From the Search meanu, select "Search Dialog".
- In the Search dialog, confirm that the "Start Searching From" is set to the value of the userBase attribute from the Realm declaration in ROOT.xml.
- Search Level should be set to "Search Full Subtree".
- Select the "Text Filter" tab at the bottom of the search dialog.
- Copy and paste the userSearch attribute from the Realm declaration in ROOT.xml into the text filter box (e.g., (sAMAccountName={0})).
- Replace the {0} with the value of a user that you expect to be able to login. For example, if the user would use the login jason and the filter is (sAMAccountName={0}), change this value to (sAMAccountName=jason).
- Press the Search button. Exactly one result should be returned. If zero results are returned, then the query is at fault. Some possible causes:
- The user name as substituted into the filter is incorrect.
- The user does not exist or does not exist within the subtree rooted at userBase.
- The filter itself is too restrictive. Filters can be arbitrarily complex with AND and OR
clauses. If the filter is complex, we recommend simplifying the query
down to only the username portion (the place where the {0} occurs) and
verifying that portion and then building up the query to the ultimate
query, verifying that at each step the user account is still findable.
- If the user is returned and you know that user's
password (for example, if it is the Code Collaborator administrator
account), verify that the account can login using JXplorer.
- Select the user from the results tree.
- Select the Table Editor tab.
- Copy the distinguishedName attribute to the clipboard.
- From the File menu, select Connect. Follow the login procedure
as above, substituting the user's distinguished name (on the clipboard)
for User DN and that user's password for Password.
- If that login fails, it's possible that the password is
incorrect or has been changed or that the account has been disabled or
locked. Consult with your LDAP administrator to confirm that the account has "bind access" as necessary.
