Why does the LDAP/AD RA convert adds to modifies. How do I prevent this!

Question

hellos.
I have noticed that if I attempt to add an LDAP entry which has the same DN as an existing entry, then the default Provisioning workflow SILENTLY converts this add to a modify.
template: cn=$fullname$,ou=people,dc=company1,dc=com
so if 2 different persons with same first and lastnames are entered into IdM first one gets added Ok but then gets hijacked by the second 'addition'.
ok. I understand that I have to cater for this eventuality, but isnt the whole point of using an intelligent system like IdM to trap these events automatically.
I would rather see an error message like "error code 68: object already exists" on the screen after screen entry + save than end up with 2 different Idm entities pointing to the same LDAP entry!!
Is it possible to set a switch (waveset property?) allowing/denying the convert add to modify when the target already exists?
Must I have to either rewrite the provisioning workflow or plug in some fullname validation on the form?

Answer 1

It does not matter what you intend to do or not: the identity template is there to tell IDM how the resource account should be identified. The software has no "knowledge" of your intentions. It uses the configuration you gave it to create the account you are requesting. If that should not happen in all cases then you will have to handle that.
The fact that you provision to the resource also shows that you do not see the resource as the authoritive source of data.
IDM does not assume or preempt that the account already exists on the resource. If it finds that the account already exists when it checks the resource it has to follow what you have configured it to do. In this case that is create the account you wanted it to create. To make sure that the account contains the information you want it to contain it will modify/add the values which are missing and or different.
The fact that the resource account is already there is not an error situation and will never be one. It is considered as being a normal case with a normal solution: IDM takes hold of the account. If it would be an error case there would be no need for reconciliation or active sync. You can even go a step further and state that the account on LDAP should not have existed if you try to create the user this way, reconcile or active sync should take care of these kinds of accounts.
For the sharing part: IDM understands that resources can contain shared accounts, it even has a state for them in the reconciliation. But when you create an user in IDM and assign resources the accounts on the resources automatically belong to the user in IDM. This has to be enforced otherwise there would never be a guarantee that an user whom has a resource assigned also really has the account.
If you want IDM to fail in situations like this then you have to code that yourself and customise the workflow or forms used for the provisioning process. By doing that you will create a huge amount of manual intervention to create the accounts in a later stage unless you can make the work flow smart enough to cycle through a number of possible resource account Id values if the account already exists on the resource.
This will almost certainly also kill any possibilities to run a reconcile against that resource because you can not catch this in correlation rules or confirmation rules.
Then a user form does not go out and see if the account already exists. The form provides logic and a display template for information. The provisioner and the userviewer will do al the processing.
If you really want to leave the existing account alone then there are two options you can set as form properties, only one can be used at anytime:
"NoLinking"
"InteractiveLinking"
like this:
<Form .....>
<Properties>
<Property name='InteractiveLinking' value='true'/>
</Properties>
If you specify "NoLinking" the provisioning will go ahead and the user will get accounts on all resources where there were no conflicts, no intercation possible.
If you specify "InteractiveLinking" your checkin of the userview will fail and you will be returned to the GUI. At that point you will have to fix the issues that were found before any provisioning will take place. This requires custom forms and all handling needs to be done by the user. Have a look for DiscoveredAccountFields in the libraries
This was build into the product after a push from one customer and has never been documented outside of one release note. It will become part of the standard docs from version 7 onwards. However it is still considered as a bad solution but if you want it you can use it.
WilfredS