Share via

Best Practices for the FIM Portal Administrator Account

  • Article

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 FIM Portal.

 

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

The account you are logged in as when you install the FIM 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 FIM 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 FIM Portal is moved to another server, with its own local Administrator SSID.

It may be tempting to use the Domain Administrator account 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 an 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 FIM Portal server and then run the install as this account. And finally, protect the account from accidental deletion with Active Directory!

 

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 FIM 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

More info: http://aka.ms/FIMwellknownguids

 

3. Don't use the administrator account

Once the initial configuration is done you should get your own account into the FIM 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 transferable between different FIM 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 make Sets using any attribute, without first having to update the filter, then just disable this MPR.

See also