Best practices for the FIM Portal Administrator account

The account you use to install the FIM Portal becomes its built-in administrator account. I believe this account should be treated with extra care, so here are a few of my personal best practices. Please do comment and add your own tips if you have a different perspective to share.

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

In a lab, when I know I’ll only have one Portal server, I tend to use local Administrator when installing. In production however I think this would be a mistake as there could be issues down the track if the Portal is moved to another server.

It may also be tempting to use the Domain Administrator for the installation – however I think this is a mistake as well. 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 it’s really not appropriate that the AD admin gets full access to it all

So my advice is to create yet another FIM service account, the “FIM Portal Administrator”. Make it a member of the local Administrators group on the Portal server and then run the install as this account.

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

The first thing I do after creating the FIM MA is to 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

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. Also it has a predictable GUID meaning your code is transferrable between different Portal instances.

And even without custom WFs, sometimes it’s just damn useful to be able to go in and fix some data without worrying about what will get fired off.

Note that by “directly” I mean through “Grant Permission” MPRs, as there’s not a lot I can do about indirectly triggering though “Set Transition” MPRs. Which is one of the reasons I generally prefer the “Grant Permission” type.

5. Disable the filter validation

This one is not strictly about the administrator account, as it applies to all members of the Administrators set, but I thought it worth mentioning…

I always disable the 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. I really find this a great annoyance and of no conceivable value, and it always gets disabled the first time it gets in my way.