Administrator locked out of the MIM Portal after initial MA sync

Problem

After the first MIM Portal / Service management agent sync run the initial portal administrator account (the one used during portal installation) is locked out of the portal. The error message “Unable to process your request” and “The requestor of this operation is invalid” is displayed when you try to log in:

image

 

Analysis

For some reason, the User mapping is removed from the FIMService database. The query SELECT * FROM [FIMService].[fim].[UserSecurityIdentifiers] returns 0 rows. at this point, one row should be returned, lining the default admin UserObjectKey (2340 at time of writing) with the SID for the account used to install the MIM Service.

I found the solution with help from this post: http://dloder.blogspot.no/2011/12/administrator-locked-out-of-fim-portal.html.

In short, use Extended Events or SQL Profiler to find the ObjectID and corresponding ObjectKey.

SELECT *  FROM [FIMService].[fim].[Objects]
  WHERE ObjectKey = '2340'

ObjectKey	ObjectTypeKey	ObjectID
2340	24	7FB2B853-24F0-4498-9534-4E10589723C4

The ObjectKey and ObjectID for the first administrator account seems to be hard-coded into the FIMService database. This conclusion is based on the fact that I got the same values as those from a fresh MIM 2016 install as those listed in a post from 2011.

What remains is to re-establish the link between the FIMService Object and the AD SID (user).

Update 2017.09.20: Further analysis strongly indicates that the root cause of the problem is lack of a filter in the MIM/FIM Service MA during the initial sync run. There should be a filter in the MA preventing synchronization of the primary administrator account (the account used during installation) and the Built-in Synchronization account.

Solution

The usual warning: This solution details commands that should be understood before they are executed in a production environment. If the solution looks like gibberish, seek help before you continue. You may need a DBA to interpret the commands. And remember backups.

Get you SID in hexadecimal form. You can get it from AD Users and Computers in advanced mode. Open your user, look at the attribute list and find the ObjectSID attribute. View it in hexadecimal form. It should look something like 01 05 00 00 00 and so on. Remove the spaces using your favorite text editor, and add a 0x prefix to indicate that this is a hex value. Your result should look like this:

0x010500000000000512345234504560734063457AFCDEBB69EE0000

Execute the following SQL command against your FIMService database:

 
insert into [FIMService].[fim].UserSecurityIdentifiers 
values (2340, 0x010500000000000512345234504560734063457AFCDEBB69EE0000)

Then, perform an IISRESET. You should now be able to log in to the portal again.

Author: DizzyBadger

SQL Server DBA, Cluster expert, Principal Analyst

4 thoughts on “Administrator locked out of the MIM Portal after initial MA sync”

  1. Thanks for sharing this, this was very helpful. I did face the issue of MIMINSTALL getting locked out but the user was already there in the UserSecurityIdentifiers table. This is MIM 2016 SP1. So I ran these:
    delete from [FIMService].[fim].UserSecurityIdentifiers where UserObjectKey=3552 (key obtained by searching with the hexadecimal objectSID)
    insert into [FIMService].[fim].UserSecurityIdentifiers values (2340, 0x010500000000000515000000083CD20A5D5EA1CBDBACC3F94F040000)

  2. Sorry for the stupid question but am from a networking background ,Just wondering how to use SQL Profiler to find the ObjectID and corresponding ObjectKey. ??

    1. https://docs.microsoft.com/en-us/sql/tools/sql-server-profiler/start-sql-server-profiler?view=sql-server-ver15 is a nice starting point for learning how to use profiler. If I remember correctly, you just start a profiler sessions logging commands to the FIMService database while you try to log in. Searching the results for the login request should reveal the ObjectKey. I do not remember if it contains your username, but if you note the exact time for your login attempt there should not be to many requests occurring at that point in time.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.