Friday, December 16, 2011

Administrator Locked Out of FIM Portal


I’ve been coming up to speed on MIIS/ILM/FIM lately reading the documentation and walking through the evaluation guides in a small lab forest.  I was walking through the FIM 2010 procedure Introduction to Publishing To Active Directory from Two Authoritative Data Sources using FIM 2010 R2.  I had completed the main sync of HR into FIM and back to the Metaverse.  When I switched back to the portal to check on the results I was greeted with an error screen.

Unable to process your request. The requester of this operation is invalid. The requestor's identity was not found.

I’m not sure what caused the problem.  I didn’t have a backup to roll back to, and I didn’t want to give up and just reinstall.  From experience I know that you seldom learn more about a program than when it’s broken.  So I dove in to the problem.

I know FIM is mostly a large SQL application.  I understand the sync database pretty well.  It has two main tables.  The mms_metaverse table stores each object in a row and each attribute in a column.  This allows for indexing the attributes for fast joins and searching the metaverse.  The mms_connectorspace is more opaque.  The data from the connector space is stored as XML blobs in the hologram.

My first glance at the FIMService database showed me it didn’t look anything like the sync database.

To get started I profiled my attempt to open the portal.  You see a call retrieve the default page from SharePoint, then you see the call to figure out who I am.


This is a stored procedure call to GetUserFromSecurityIdentifier where the parameter appears to be my SID in binary form.

Since SQL Server Profiler doesn’t show the return value of the query, I ran that query myself.

exec [FIMService].[fim].GetUserFromSecurityIdentifier @SecurityID=0x0010500000000000515000000467CC6805E2AB86508CBF18EF4010000,@UserID=@p2 output

Sure enough, no rows returned.  Looking at the stored procedure, it references the tables UserSecurityIdentifiers and Objects.  UserSecurityIdentifiers was completely empty.  UserSecurityIdentifiers is a simple table with only two columns: UserObjectKey and SecurityIdentifier.

There’s also a stored procedure called GetUserFromName.  When I ran that, it returned my name, so I was pretty sure I was just missing the row that tied my AD SID to the admin user in FIM.

To find my admin user in FIM I ran a query against the Objects table to find the FIM builtin administrator account '7FB2B853-24F0-4498-9534-4E10589723C4'

select * from [FIMService].[fim].[Objects] where objectid='7FB2B853-24F0-4498-9534-4E10589723C4'

For my instance it returned a value of 2340.

I issued one more query to insert my SID into the UserSecurityIdentifiers table.

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

The value successfully added.  I opened the portal and was treated to the normal administrative view!

I still don’t know what I changed to cause the SID to be deleted, but now at least I know how to get back in without a backup.  Perhaps some more testing in the future will reveal a repeatable pattern that causes the lockout.

1 comment:

  1. absolutely stunning coooool.
    using this you can make AD accouns FIM admins without having to sync them!!!