MA property not supported message to be improved or fixed

Moved to v4

This check takes place after the export has succeeded, and checks the returned value. It would be much more sensible to check what type of DN Identity Broker would generate prior to the export, if possible. Moreover, in the cases where this has been a problem, the confirming import has still pulled in the entry with the mismatched DN. Further investigation should be carried out as to the impact of the DN not being checked on export (which the above essentially has the effect of doing). I believe this would cause transient errors to occur.

After reviewing the code for saving entities, I believe that it may be worthwhile testing the removal of this check completely. Essentially this is what users currently do to move past this issue, as FIM has already pulled in the new DN from the import file, and the join rule maps the user. I do not believe the <dn> field can be used in a join rule, but this is something I will need to confirm.

Considerations were made to move this check to the server side and calculate the "new DN" based on the provided adapter entity, and prevent the connector from performing the save if this was the case. However, in scenarios involving anchor modification or container field changes, a modified DN from Identity Broker may be exactly the result we expect.

Some things that will need to be confirmed in testing the removal of the check:

• Transient objects are not created due to a failure to resolve a changed entity, although I believe this will not be the case as the configured join rule should be all that is used
• The behaviour of reference value types in response to a distinguished name change
• The ramifications of a solution provisioning new connector space objects with distinguished names that do not match those generated by the Identity Broker DN generators - this may turn out to be superfluous, except in the above reference value scenarios (such as manager or account name flows)

Was this really estimated to take 1h 10m?

No, there was no initial estimate so the issue has taken the first worklog as the estimate. Updating the remaining estimate to allow for testing of the adapter without this check, further discussion, and analysis of results.

Test was set up to provision new users with a different DN to that generated by Identity Broker. Testing revealed the following:

• Transient objects do not occur - only one object is retrieved on the confirming import, which the join rule does indeed resolve
• DNs and reference value changes are protected by container restrictions, and as such this behaviour does not have an adverse affect on other reference types during a rename (only the entity in question)
• The provisioned user was successfully created, and a confirming delta import delta sync resulted in a new user (with the Identity Broker DN) being added to the connector space, and joining to the same metaverse object, ie. both the provisioned and the saved connector met the join criteria. This did not break the solution - attribute flows continued to succeed, as the provisioned object was essentially ignored (although it would still be updated in the connector space). The connector space would sit in this state until a full import deleted the originally provisioned user from the connector space, removing this "confused" state.

In other words, removing this check does not stop the solution from working correctly, but does leave the connector space in an aesthetically incorrect state (as expected, the solution has mismatching distinguished name generation in cases where this error appears, even if the end result is the same). On discussion with the team, it has been decided that Identity Broker should check for differences in DNs prior to saving or renaming in order to prevent this confused state from occurring.

Added an error message to prevent users from provisioning users with an incorrect DN, before saving occurs. Other DN modifications are triggered by Identity Broker in response to DN source attributes changing and should be allowed to run unhindered.

Marked as resolved, to be closed on confirmation of functionality during engine testing.

Tested and confirmed with engine. The add is successfully blocked. See screenshot. Issue closed.