Issues with setting an AD password thru Identity Center

The problem:
Setting the password for an Active Directory account through the NetWeaver Identity Center.

Possible Solutions:

Solution 1# IdM Template job to set AD password using VB script.
 
Issue 1.1: The most frequent error and by far the most vague was the “Error Object doesn’t support this property or method”. It never told us anything more than that; we never understood what the object was nor what property or method it didn’t support.

Issue 1.2: The other error we encountered was ” Error Failed to set password on user . Error no:-2147016654.”; this normally occurred only when running the script in TEST mode. Details about the error number pointed to it possibly being an error due to insufficient privileges.

Solution 2# A custom VB script to reset the AD password, called from a generic pass within Identity Center; we used Richard L. Mueller’s script, which can be found on his website @ http://www.rlmueller.net/Reset%20a%20Password.htm

Issue 2.1: This script worked perfectly from the command prompt on the APP server, but failed when we tried running it through a generic pass within the Identity Center. It failed with the same error mentioned in Issue 1.1.

Solution 3# Using a shell execute pass, run a ‘dsmod’ command to reset the AD password.

Issue 3.1: Like the script used in the previous solution, it worked perfectly fine from a command prompt, outside the Identity Center, but it failed to set the AD password when executed through a shell execute pass within the Identity Center. There was no real error in the job log; the job apparently ran successfully, but it probably just failed within the external command prompt with a ‘dsmod’ error.

Solution 4# Use the command prompt ‘runas’ command to run the ‘dsmod’ command as the domain admin.

Issue 4.1: Again, this worked perfectly on the system, outside the Identity Center, but it failed when executed through a shell execute pass within the Idenity Center.

Solution 5# At this point I thought it might’ve been the direct nature of executing the scripts or the dsmod command that might be preventing me from having the necessary privileges; thinking about it, being logged into the system as a domain admin, anything I run against the domain should ideally¬†work, but this was apparently not the case. I thought if I tried executing either the script or the dsmod command in a more indirect way, it might work; say, executing a batch file that in turn executed a vbscript file that was created on the fly, containing the ‘dsmod’ command which was being run using the ‘runas’ command through a wscript shell, all through an internal script from within the Identity Center. Yes, I know; that’s a terribly long and inefficient way of accomplishing the task, but I was pushed to the limits of frustration.

Issue 5.1: Even still, after all that nonsense, it ran perfectly within tne system, but it failed to actually set the password from within the Identity Center. Again, the job ran successfully, but just failed within the external command prompt with a ‘dsmod’ error.

Solution 6# THE ONE THAT FINALLY WORKED!
All this while, the common theme seemed to be that any solution would work on the base system, but would fail when run from within the Identity Center. Why? The security context is apparently different. Even with enforcing my admin privileges through the Identity Center it still failed. The only solution that would possibly work at this point would be to create a new dispatcher, that would be solely used for setting AD passwords, and use it with the existing set password template job (only with a minor change). Once it’s installed as a service, change this dispatcher service’s logon credentials from the local system account to your domain admin credentials and choose to run your password set job with this new dispatcher instead. Before running it, edit the pwdNext script to remove the line that changes the AD password. Not removing this line will result in an error; we need to simply SET the password and end there, rather than going on and changing the password also. This should now hopefully allow you to successfully set AD passwords. To fine tune this solution a little more, create a service account with only the ability to set passwords and use those credentials within the new dispatcher service. In an ideal environment you wouldn’t have waste all this time; the original template job should work well as is. But if you have to deal with an environment as picky as ours, and none of the previous five solutions work, this would be one solution that would possibly work.

Bug with md5 hashed security answers

When working with the recover password task in IdM we came across a bizarre bug with the security questions/answers used to authenticate a user so that they may change their password.

When a user sets up their security questions and answers, if they happen to use an uppercase letter in at least one of their answers, and if you’ve chosen to store the security answers as an MD5 hash in the identity store, your user will not be able to recover their password. Why? Because the php page for the “Recover Password” task has a line of code that goes ahead and impulsively converts your security answers to lowercase. This results in your answers never being able to match your security answers that were originally hashed with all uppercase letters intact.

This buggy line of code exists in the “changepassword.php” file of the workflow interface, on line 717:

$md5Value = md5(strtolower($outputArray[$key]));

removing the “strtolower” function from the above line of code makes it look like this:

$md5Value = md5($outputArray[$key]);

And, that should fix the bug. It’s quite a strange error and if you’re not aware of where it stems from you could waste many hours looking in the wrong place.

Queue runaround (tip)

Let’s say you have a couple of jobs/tasks sitting in your provisioning queue, but you’ve changed your mind and you don’t want them to run anymore; what do you do? Well, instead of wasting your time trying to create a job to ‘Clean (your) provisioning queue’, try this:

  1. Log on to your Monitoring module.
  2. Click on the ‘Provisioning queue’ link in your menu.
  3. Once there you should see all the jobs/tasks waiting to execute.
  4. Clicking on the ‘queue size’ link for each entry will bring up another window that should give you the option to ‘Cancel’ the job/task.
  5. Click ‘Cancel’‘ to remove the job/task.
  6. Repeat steps 4-5 so as to remove all the jobs/tasks or just specific ones.

Hopefully, this will save you some time and frustration.

Start up…

This is a new blog on SAP’s Netweaver Identity Manager, fka Maxware. from the practitioners of Secude Global Consulting. We will use our experiences installing, deploying and configuring this product to help you get the maximum benefit from this versatile piece of software. You may also see an occasional post on systems thinking and enterprise risk management.