If you have ever wondered or deleted “User Administrators” Set in MIM Portal, then read this
Background:
There is a set in MIM portal called “User Administrators”. Its criteria is simply all users resource=”user”.
The set has a well-known ObjectID = ‘77197b15-6f61-40ea-8d69-10f3f1fe4904’.
At first look, it looks like and afterthought or a placeholder to be used and customized for user management access and since it is not applied in any MPRs, you might think its useless and delete it.
This set is hard coded into MIM Service to grant view access to all users on “new” and “delete” buttons on User’s Set.
After deleting this set, no one, including administrators can see the buttons above on users, so you can’t delete nor create a user in Portal.
NOTE: Because your permissions are granted via MPRs, and this simply removes the buttons, you can always perform those actions via powershell as a workaround. Deleting the set has restricted your view of the buttons, not the ability to perform the actions via other means.
First thought is to create a new set with same criteria, but we know that the name is not the one hardcoded, but the ObjectID. So, this does not work. I know that we need to try to create the new set and apply the old ObjectID. Turns out, even after deleting the Set in the MIM Portal, there are several references of this object in the FIMService Database. We have to first delete old objects and update new object.
This object exists in several tables in the FIMService Database
- fim.objects ObjectID=’77197b15-6f61-40ea-8d69-10f3f1fe4904’
- fim.set – ForeingKey related to fim.objects
- fim.SetFilter – ForeingKey related to fim.objects
- fim.ObjectValueString – ForeingKey related to fim.objects
- fim.ObjectValueIdentifier – ForeingKey related to fim.objects
- fim.ObjectValueDateTime – ForeingKey related to fim.objects
- fim.SetMembershipCondition – ForeingKey related to fim.objects
CAUTION: Take a database backup before proceeding.
Fixing the issue:
- Look for the object in FIMService, starting in Objects table as the master table
SELECT *
FROM [FIMService].[fim].[Objects]
Where ObjectID =’77197b15-6f61-40ea-8d69-10f3f1fe4904′
Result: it returns one entry with the same ObjectID and objectKey = ‘2789’. Remember we need the ObjectKey because this is the foreign key on other tables
- Now we try to delete the object
Delete From [FIMService].[fim].[Objects]
Where ObjectID =’77197b15-6f61-40ea-8d69-10f3f1fe4904′
Result: We get a referential integrity error:
Msg 547, Level 16, State 0, Line 1
The DELETE statement conflicted with the REFERENCE constraint “FK_ObjectValueIdentifier_Objects”. The conflict occurred in database “FIMService”, table “fim.ObjectValueIdentifier”, column ‘ObjectKey’.
- So we go to fim.ObjectValueIdentifier and delete there
Delete FROM [FIMService].[fim].[ObjectValueIdentifier]
Where ObjectKey =’2789′
Result: Success
- We get back to try to delete it on the objects table
DELETE FROM [FIMService].[fim].[Objects]
Where ObjectID =’77197b15-6f61-40ea-8d69-10f3f1fe4904′
Result: Success
- Now we create a new set called “User Administrators” (NOTE: You can name it whatever you want, really).
- This set will have different ObjectID so we need to update this in the Database with the default ObjectID from original set
In my example, new ObjectID =‘4fac8002-fab7-49d3-88fd-e051156a5a54’
- Run this query to Update ObjectID in Objects Table
UPDATE [FIMService].[fim].[Objects]
Set ObjectID =’77197b15-6f61-40ea-8d69-10f3f1fe4904′
Where ObjectID =’4fac8002-fab7-49d3-88fd-e051156a5a54′
Result” Success
- Do an IISReset
- Go back and verify users set has the buttons back
Remaining issue:
After the restore process above, everything works fine, but the Set cannot be viewed nor edited anymore in the portal.
This is not an issue, as we should not be touching it anyways, but it is a cosmetic deficiency and needs to be mentioned.
Suggestion: If you are an implementer of MIM, you should know this by now if you read the article and you will not delete the set, but since you are most likely going to leave this to be handed by other people, Rename the SET to something that no one will delete it. Restrict access to delete the set via MPRs.