MA property not supported message to be improved or fixed
Matthew Clark 12 years ago in UNIFYBroker/Microsoft Identity Manager • updated by anonymous 7 years ago • 8
Refer to https://unifysolutions.jira.com/wiki/display/IDBFIM300/An+export+to+Identity+Broker+fails+with+an+ma-extension-error+and+the+Windows+Application+Event+Log+cites+an+InvalidOperationException+as+the+reason. In the cases where this error occurs, the error message should be improved to state that the generated distinguished name on the Identity Broker side is not matching the provisioning logic (or is not present).
Cannot provision incorrect DN.png
Customer support service by UserEcho
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:
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:
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.