Free without warranty


This tool is a GUI for changing all the users in an OU with a particular password policy to another policy. It is primarily designed for cases where the policy is not associated with the OU but instead assigned to individual users. It is particularly helpful because iManager does not always seem to clear the user’s npsmPasswordPolicyDN attribute correctly and changing dozens of users by hand is a pain.

Requirements and Technical Notes:

.NET or Mono 2.0. The tool does not use LDAP certificates for simplicity and speed, so just go ahead and use it on an LDAP server that accepts straight 389 port connections without requiring SSL/TLS (i.e. use it from a workstation that has an almost straight link to the server). Also note that this is basically a shell script with a GUI bolted on — exception handling is minimal. I regard it as polished enough to publish, and it works well in my environment, but this is not a sterling example of best software engineering practice. It is written in C# using WinForms and the ADSI frameworks. It _does_ handle wacky policy names with spaces, slashes, etc.

Instructions for use:

  1. Enter your short novell admin username (the tool will find your context), password, and the LDAP server you want to query (see requirements above) and push the “Authenticate to eDirectory” button.
  2. Step one populates the Container, and Policy drop boxes. In order to avoid exceptions use the drop-box entries instead of just typing in your desired entries. Select the container you want to change (the tool handles only one container at a time and does not drill down into subcontainers), the password policy that the users are now assigned to, and the new policy to which they are being migrated. Then press the “Change Password Policy Button”
  3. When the process is finished, a log of results will be displayed in the big box at bottom.

Algorithm (For debugging):

  1. The program creates an admin connection to the LDAP server and checks that it is a valid connection. It does not check rights.
  2. All the containers in the tree are found and are displayed by short name in the container drop-down box. The values are the actual contexts (so a bit of OU “junk” does end up there — Tomcat roles, etc.). Password policy names are found in the Security object.
  3. When the Change Password Policy button is pressed, the program does a filtered search and grabs every user in the specified container whose npsmPasswordPolicyDN attribute is set to the name of the old policy. It then loops user by user to change npsmPasswordPolicyDN to the new policy, removes the user from the nsimAssignments list of the old policy, and adds the user to the nsimAssignments list of the new policy (if not present already).
  4. It is supposed to update the results box for every user handled with a log of what it did for that user, but in practice the box doesn’t seem to update until every user has been handled.

Source code available upon request. This was an internal project that I made universal enough to publish here, but you can probably improve its feature set and exception handling with a minimum of effort.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.

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.

Leave a Reply

Leave a Comment

  • jwilleke says:

    Good job!

    It would be great if you would first allow displaying the users who match the policy before having to commit to change to a new policy.

  • 6423241 says:

    For security reasons, all of my LDAP servers require SSL/TLS, making this tool unusable in my environment. That’s a shame, because it looks great otherwise.

  • jlodom says:

    I’m currently working on another internal tool, this one concerning Radius, and the code is quite a bit better. Given that, it looks like once that one is finished I will be able to revisit this tool with lessons learned and clean it up a bit. Specifically, I’ll be happy to add the following requested features:

    1. A “test” mode to see who will be affected per jwilleke.
    2. SSL/TLS support per 6423241.
    3. Source code with the app.
By: jlodom
May 29, 2009
12:07 pm
Active Directory Authentication Automation Cloud Computing Cloud Security Configuration Customizing Data Breach DirXML Drivers End User Management Identity Manager Importing-Exporting / ICE/ LDIF Intelligent Workload Management IT Security Knowledge Depot LDAP Monitoring Open Enterprise Server Passwords Reporting Secure Access Supported Troubleshooting Workflow