Novell Home

Custom Plug-in for iManager - Unique CN Checks

Novell Cool Solutions: Tip

Digg This - Slashdot This

Posted: 8 Dec 2004
 

A reader recently asked for advice on customizing plug-ins for iManager. The goal: to scan eDirectory trees to see if a given CN exists or is unique. Our thanks to readers John Lebahn and Rick Humelsine, who responded with their own custom plug-in code that solves the problem. Also thanks to Debra Gantz for setting the wheels in motion for this article.

John's Solution

The issue is how to check multiple trees before creating the user. We wanted to know before entering all of the user info that the username entered was not used in any eDirectory tree.

The solution is to create custom iManager tasks that will check for duplicate CN's in multiple eDirectory Trees. This required two tasks, one to collect the username and template and one for the additional user information after the CN is verified to be unique. This allows us to check for duplicates before we attempt to create the user.

"Create New User" Task

Here's an example of the Create New User task in iManager:

When this form is launched it does an LDAP search of the local eDirectory tree for all Templates (class=template) and populates the template listbox. After you enter the username and template (if desired) and click OK, the CN is checked for illegal charters. (We have DirXML drivers to NT systems that have different naming requirements). A second task is then launched. This task is labeled "Not Used" because it is also displayed in iManager, and it will display an error if launched directly. I would like this to be hidden but have not found a solution for that yet.

"Not Used" Task

Here's an example of the Not Used task in iManager:

The username is brought forward to the second form along with any template information (if selected). The username is also changed to lowercase for compatibility with UNIX systems. An LDAP search is performed on our local tree and the meta tree to verify the username is unique. If a match is found, an error message is displayed, and the user is brought back to the Create New User form. We have various list boxes on the form, some populated with static values and some populated from the values of multi-valued attributes returned from an LDAP search.

Code for the iManager Tasks

Note 1: We created an Alias for a server in our local tree and in one in our meta tree, as well as proxy user accounts that have rights to the needed attributes. These are set as variables near the top of each code sample.

Note 2: We use many custom attributes, so you probably won't be able to use all of this sample code. Still, there is a lot of content in it that may be helpful.

Note 3: You will need to run the tckeygen.ncf file to import the needed certificates into the Tomcat keystore.

Click here for the Create New User sample code:

Click here for the Not Used sample code:

Rick's Solution

Here's my solution to the problem of verifying the uniqueness of the CN for a new user.

First, modify the JSP page corresponding to the Create User form so that it checks for a parameter "CN" in its request. If the parameter is not present (null), we show only the text field for the user to enter a new CN, followed by a "Verify" button:

      <INPUT type="text" name="_CN" ...>
      <INPUT type="button" value="Verify" onClick=udlpVerifyUniqueCN()>

Here is the corresponding JavaScript function:

      function udlpVerifyUniqueCN()
      {
         var form=document.forms[0];
         form.udlpAction.value = "verifyCN";
         form.action="/nps/servlet/UdlpCustom?udlpAction=verifyCN";
         form.submit();
      }

Checking the LDAP directories for the new CN is done by a Servlet (UdlpCustom). If the CN already exists, the Servlet prints the full DN for each entry found. If the CN is not found, the Servlet redirects the client back to the Create User form with a CN=value parameter appended to the URL.

Click here for the modified section of the Create User Form (JSP).

Click here for the complete UdlpCustom Servlet.

Finally, note that the JndiClient object used to access the LDAP directories is just a "wrapper" for the JNDI methods that are used to connect, search, and format the results. Novell's LDAP API could also be used for the same purpose.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell