Setting the password for an Active Directory account through the NetWeaver Identity Center.
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.