How can I figure out what my LDAP settings should be?

Question

This is a frequently asked technical support question. When setting up a new CodeCollaborator instance with LDAP authentication, figuring out what the settings need to be to make everything work can be tricky -- especially since the administrators often don't have a lot of LDAP knowledge. Is there a process for determining or verifying the settings?

Answer

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.

djohns · Answer

Most 6.0 releases of Code Collaborator will provide a very non-intuitive error message if LDAP settings are not correct:Name jdbc is not bound in this ContextIf this error appears in your logs or on screen, you should probably follow the steps above.

john_maccario · Answer

Here's some helpful information that a user of ours, Mark Pettigrew, shared with us. &nbsp;1.) For Windows users that need to obtain their LDAP User Pattern or Active Directory User Base, run the following command: &nbsp; whoami /FQDN &nbsp; This will display the fully qualified domain name for the user that's currently logged in. &nbsp;This information is entered when running the Collaborator installation for LDAP or AD authentication and is stored in the "&lt;INSTALL_DIR&gt;	omcat\conf\Catalina\localhost\ROOT.xml" file. &nbsp; http://technet.microsoft.com/en-us/library/cc771299.aspx  2.) If you're configuring LDAPS, use InstallCert.java to obtain the public certificates from the server to which you're establishing a secure connection. &nbsp;Please refer to http://stackoverflow.com/questions/3685548/java-keytool-easy-way-to-add-server-cert-from-url-port&nbsp;for more details. &nbsp;If you have trouble compiling the Java file, you may download the binaries for InstallCert from http://miteff.com/install-cert. &nbsp; Once it's installed, run the following command to kick it off: &nbsp; java InstallCert &lt;HOST:PORT&gt; &nbsp; &nbsp; We hope this information assists you with your installation. &nbsp; Thanks, John &nbsp;

Forum Discussion

How can I figure out what my LDAP settings should be?

3 Replies

Recent Discussions

Add Git commits fails with 'partial entry'

Does anyone know if we can archive Collaborator data and import/migrate it to GitLab(Triage-ops)?

Oracle database supported character sets

Related Content

Trying to figure out how to do this Load Test

A prompt: Could u please show figure next to the folders?

AutoSave setting?