Getting started with the Permission Collection and Reconciliation Service

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.

Rights and passwords

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.

Job configuration

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.

 My thoughts

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.



How To-Best Practice
Comment List
  • Some of this is my fault. The guy who worked on this initially liked how the auto configure I described from Lothar's Password Notifier driver worked, and thought this would be a clever way to make life easier for implementing this.

    Where I disagree with his approach, is he should have gone one step further, and looked at how Lothar does it in his driver. I.e. Go back to source material. :) I was just explaining how clever Lothar was, but Lothar is in fact, more clever than that!

    In the Password Notifier driver, if you look, he lets you configure a user and password for the queries it needs to do. Then failing that, he tries to autoconfigure it via Sec Equals. A slightly more clever approach. That would answer your issues. Pick your user, and failing that, try to auto way. Failing that, still fail. But at least leave control where it should be.
Related Discussions