Here are some notes I took during my attempt to install the Permission Collection and Reconciliation Service (PCRS) on a new AD driver at a client.
The PCRS requires a user that has some specific rights in User Application, the rights are documented. Lets call the user the “resource administrator”.
A special job is installed on the AD driver, called the PermissionOnboarding job. Unfortunately you are not responsible for configuring that job, instead there are special policies that try to configure the job automatically when the driver starts.
There are some gotchas there.
First the driver must be security equivalent to a User that has a nspmDistributionPassword set and the driver must have rights to retrieve the nspmDistributionPassword. If you are running the driver as security equivalent to a organizational role or group this won’t work. You must create a user, assign the correct password policy and rights to the user. If you are not using Universal Password for your administrative users, well you are out of luck.
When the policies are running they retrieve the Security Equals attribute from the driver and then try to read nspmDistributionPassword from the user it points to.
Next they try to get nspmDistributionPassword from your UA resource administrator, so the driver must have rights to read that users password and the user must have a nspmDistributionPassword set.
What happens next is also interesting, the policies attempt to configure the PermissionOnboard job using a Java call to dxcmd.
In that call they use the security equivalent user and its password to run the command.
So if the driver can’t read the password it won’t work but you will not get any notice of it not working.
In another call to dxcmd the policy is trying to set a named password on the job, it is trying to set the password of the UA resource administrator as the named password. Of course if it can’t read the password of the UA resource administrator or the drivers security equivalent user it won’t work.
If you have configured everything correctly then it may still not work!
If you are running eDirectory as a non-root user you are out of luck, the dxcmd commands called by the driver policies assume that you are running on port 524, the the actual command won’t do you any good.
You must edit the three startup policies where the JOBCMD variable is set and add a -host and -port parameter, in my case I added ” -host idm1 -port 1524″ to the beginning of the JOBCMD variables. After that I could the job to work correctly.
I would have rather seen that I as the developer was responsible for setting all the correct named passwords when importing the package instead of the automatic attempts that are done in policy, even if they are nice when they work. I also don’t like the need to have Universal Password active on accounts that have such high privileges.
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.