Best Practices for the FIM Portal Administrator Account

Best Practices for the FIM Portal Administrator Account

The FIM Portal includes a built-in administrator account which is created at installation time. This account needs to be treated with extra care, and in particular must never be deleted. This article outlines a number of best practices which, while not requirements, will help with the smooth running of your Portal.

1. Use a dedicated account for the installation of the Portal

The account you are logged in as when you install the Portal becomes the built-in Administrator, so which account you choose is a subject worth considering ahead of time.

In a lab environment, where you'll only have one Portal server, there's no problem with using local Administrator. In production however this would be a mistake as there could be issues down the track if the Portal is moved to another server, with it's own local Administator SSID.

It may be tempting to use the Domain Administrator for the installation - however this may also cause problems down the track. The administration of FIM should be a separate task to the administration of AD, even if it's the AD administrator doing the install today. The FIM Portal can contain data that concerns systems other than AD, so there may be compliance and access concerns with the AD administrator having full access to it.

So consider creating another FIM service account in the domain to be the "FIM Portal Administrator". Make this account a member of the local Administrators group on the Portal server and then run the install as this account. And finally, protect the account from accidental deletion!

2. Block it in the FIM MA with a Connector Filter

Directly after creating the FIM MA, set Connector Filters using the GUIDs of the built-in Administrator and Sync accounts. This blocks them from getting into the Metaverse, and prevents any deprovisioning accidents befalling them. Anyone who has accidentally deleted their administrator account this way, and then been told they have to restore the Portal from backup, should know how important this is!

For reference the GUIDs are as follows:

Administrator: 7fb2b853-24f0-4498-9534-4e10589723c4
Sync Account: fb89aefa-5ea1-47f1-8890-abe7797d6497

3. Don't use the administrator account

Once the initial configuration is done you should get your own account into the Portal and make it a member of the Administrators Set. Then use that account for your configuration work. The built-in administrator account should only be used in particular circumstances.

4. The administrator account should not directly trigger Workflows

Avoid using the Administrators Set as the Requestor in MPRs which trigger workflows.

The main reason is that the administrator account is extremely useful in custom workflows where you can set it as the Actor and make changes without the danger of a) a permission denied error, and b) a workflow loop. Its predictable GUID means your code is transferrable between different Portal instances, making it preferable to a custom "Workflow Actor" account..

Additionally, the administrator account is a useful override when you need to go in and fix some data without worrying about firing off emails and other processes.

5. Disable the filter validation

The final point is about the built-in MPR "General workflow: Filter attribute validation for administrator".

This is the MPR that prevents you using certain attributes in the rules for a Set unless you first add them to the "Administrator Filter Permission" object. If you would like administrators to be able to makes Sets using any attribute, without first having to update the filter, then just disable this MPR.


Leave a Comment
  • Please add 3 and 1 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Sort by: Published Date | Most Recent | Most Useful
  • Carsten Siemens edited Revision 2. Comment: typo fixed

  • Ed Price - MSFT edited Original. Comment: Great article! Updated title and added TOC

Page 1 of 1 (2 items)
Wikis - Comment List
Sort by: Published Date | Most Recent | Most Useful
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
  • Great article. In section 3, you might include a note about being able to create your own account directly instead to waiting until you can sync it in. The PS script for adding an account SID to portal accounts is perfect for this.

    There are more benefits also to making this a non-user, especially when the role of maintaining FIM changes hands.

  • Ed Price - MSFT edited Original. Comment: Great article! Updated title and added TOC

  • Carsten Siemens edited Revision 2. Comment: typo fixed

Page 1 of 1 (3 items)