When developing IDM solutions, usually there is a need for synchronizing passwords between eDirectory and other directories, such as another eDirectory, Active Directory or any other LDAP vendor.
I needed a way to quickly see if the password was synced when testing password changes, and to find out to which directories the password was synced correctly and where it wasn’t synced correctly.
For this purpose I developed a function I call “Multiple Tree Check” in my application Console2.
With this function I can test a username and password against up to five LDAP servers at once and directly see if I can logon to those server or not. This also helps me when troubleshooting password sync issues.
This article will explain how it works.
First, you need to download and start the Console2 application from this page: http://www.novell.com/communities/node/12387/console2
You also need to have Java 1.6.21 or newer installed.
After downloading and unzipping the file start the ldapmu_upc.jar file by doubleclicking on it or from the command line with the “java -jar ldapmu_upc.jar” command.
Enter the information needed in the fields marked on the picture below (IP, username, password, port) and click Connect.
Click on the File menu and then on “Multiple Tree Logon Check”.
This will bring up the main window where all the work is done.
The interface can be confusing since it’s crammed with many buttons and other GUI elements.
On the bottom you have five rows, each row represents an LDAP server.
There you can enter the logon information for each server that will be tested, you can enter it manually or you can double click the field where is says “Doubleclick here…”.
This will bring up a dialog with a drop down where you can load a saved server profile. The profiles here have nothing to do with the profile buttons in this window, they are managed from the main application window.
For each row you have the following options you must fill in:
Server X: The IP address or hostname of the LDAP server.
Port X: The ports the server is listening on, you must enter both the SSL and clear text port in the following format, SSL Port:Clear text port, for example: 636:389. Default is 636:389
AdminDN X: The DN of a user that will be used for searching through the directory for the user login you want to test. This is optional if your directory supports anonymous connections, then you must use the “Try anonymous search if AdminDN is missing” checkbox.
AdminPass X: The password for the user DN entered in the previous field.
Use checkbox, If you want to test the logon against this server or not. You can uncheck it if you don’t want a particular LDAP server to be used for testing.
Info textlabel, A RESULT label with the “i” icon, the result will be displayed here. Usually SUCCESS or FAILURE. The result will be also be displayed in the “Error/information log” area.
SSL button, If you want to connect on the SSL port or on the clear text port. This tells “Multiple Tree Check” if you want to use SSL when connecting or not. It also decides which port the application will connect to. Remember the 636:389 field?
An empty textfield allowing you to specify another attribute name to search for in the LDAP directory you are connecting to. Currently you can choose to search between cn and uid attributes via a drop down in the upper left corner, if you are connecting to a directory such as Active Directory, the username might not be stored in those attributes and you may want to enter another attribute to search for, in that case you would enter sAMAccountName in that field.
System type, currently you can only choose between eDirectory and AD.
A viewing glass button at the end, opens up an LDAP browser for the object you tested displaying some attributes such as loginDisabled etc.
After loading the server profiles you want or after entering the information manually you must enter the logon information for testing.
To test a username and password you enter the username in the top text field next to the drop down where you can choose between cn and uid.
The password you want to test should be entered below in the field “Password to try:”
Then you can click on the “Try to logon to the following LDAP server” button.
It will connect to each of the five LDAP server defined with the username and password in the AdminDN and AdminPass fields.
After connecting it will try to find the username you have entered for testing. The username must be the same in all directories for this to work.
If the search succeeds and it finds only one object with that name it will try to logon as that user against that LDAP server with the password you have provided.
The “Multiple Tree Check” works like this, it connects to each LDAP server you specify in the Server 1 – Server 5 fields on the bottom of the window. Depending on the LDAP server settings you can connect anonymously if the server allows it or as a user who has the rights to perform an LDAP search. After connecting to each LDAP server it tries to locate the username you have typed in using an LDAP filter such as (cn=johndoe) or (uid=johndoe).
The username you are searching for must exist only once in each directory, i.e. it must be unique, otherwise the application won’t know which DN it should bind as.
After the username is found the application attempts to bind using the DN it found and the password you have specified.
By default the checkbox “Try anonymous search if AdminDN is missing” is not checked. If you check it and leave the AdminDN field blank for an LDAP server then an anonymous search will be performed.
Depending on the outcome the “info” label will change from RESULT to SUCCESS or FAILURE or some other message. You can the click on the viewing glass icon to look at the user attributes.
The entire operation will also be logged to the “Error/information log” text area of the window.
Below the “Try to logon to the following LDAP server” button there are some more options.
“Try anonymous search if AdminDN is missing”
If you check this box the application will try to bind anonymously to any server you have specified that is missing the AdminDN information.
The bind method performs a simple bind, the compare tries to compare the userPassword attribute with the password you have entered.
The end result is the same as far as I have noticed, so actually I never use compare, only bind.
“Ignore aliasObject” checkbox
The search for the user is performed using a simple filter such as (cn=johndoe), in case you have created aliases in your tree this will confuse the application since it will find two objects with the same name and it won’t proceed then, this checkbox tells it to use a search filter such as (&(cn=johndoe)(!(objectClass=aliasObject))) instead, which means it won’t care about the alias.
The current profile buttons in Multiple Tree Check are a remnant of the time when you could not double click on the server field and load a profile. So I have left them there for backward compability in those cases where I still have some old profiles, but you really shouldn’t use them as I will probably remove them sometime in the future.
Test it with other LDAP servers than eDirectory and AD and add them to the system type drop down list.
I have plans to clean up the GUI a bit and make it easier to use.
I might also make it possible to test more than five LDAP servers at once but since I’ve never had a need for that that is low priority.
Enter the username and password.
Enter the required information for each LDAP server.
Click the “Try to logon to the following LDAP server” button.
Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.