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.

MIM LAB7: Testing Run profiles and populating data

This post is part of a series. The chapter index is located here.

In this post we will create run profiles and initialize the MAs.

Continue reading “MIM LAB7: Testing Run profiles and populating data”

MIM LAB6: The AD MA and Run profiles

This post is part of a series. The chapter index is located here.

In this lab we will configure the firs AD management agent and set up run profiles.

Continue reading “MIM LAB6: The AD MA and Run profiles”

MIM LAB5: The MIM Service / Portal Management Agent

This post is part of a series. The chapter index is located here.

In this post we will install and configure the MIM Portal / Service management agent.

Continue reading “MIM LAB5: The MIM Service / Portal Management Agent”

MIM LAB 4: Installing the MIM Portal / MIM Service

This post is part of a series. The chapter index is located here.

In this post we install and configure the MIM Portal / Service.

Be aware that I had to make some changes to things I did in previous labs to make this work. I hope I have included all the details, but I have yet to re-run a complete install to test it. Continue reading “MIM LAB 4: Installing the MIM Portal / MIM Service”

MIM LAB 2: Preparing the first MIM server

This post is part of a series. The chapter index is located here.

In this post we:

  • Create the first MIM VM and join it to AD
  • Install prerequisites
  • Set Local security policies
  • Change IIS authentication mode
  • Install SQL Server
  • Install and configure Sharepoint Foundation Services 2013

Continue reading “MIM LAB 2: Preparing the first MIM server”

MIM LAB 1: Prepare a domain controller

This post is a part of a series. The chapter index is located here.

We will look at:

  • Installing ADDS
  • Creating a domain
  • Configuring DNS
  • Creating a basic OU structure
  • Creating users and groups required for the MIM installation

Continue reading “MIM LAB 1: Prepare a domain controller”

MIM 2016 Lab series

Introduction

 

These are the notes from my adventures installing a MIM 2016 SP1 lab/dev environment. I am using https://docs.microsoft.com/en-us/microsoft-identity-manager/microsoft-identity-manager-deploy as a guide, so make sure you read it as well. A certain proficiency with Windows 2016 and AD is a prerequisite to understand this series. All servers in this lab are running Windows 2016 Datacenter with GUI, and I am using SQL Server 2016. Thus, I deviate from the guide mentioned above which is based on Win 2012 R2 and SQL 2014.

 

My plan is to use three VMs:

  • DC01, the domain controller.
  • IM01: SQL Server, MIM Sync, MIM Service.
  • IM02: Exchange and other stuff that should not be co-located with the software on IM01. I considered naming it Exchange, but there may come a time when I will install other stuff on it related to MIM.

I am creating a separate domain in a new forest for this lab, aptly named mim.local, as I am going to test multi-forest MIM deployments. This will certainly add some spice to the process…

Be aware, this is a lab. Do not use this setup as-is in production. I have tried to add remarks for what I would do different in production along the way.

Chapters

The will be a series, and new chapters will be added as I get time. The chapters are listed below.

Event 20501 Hyper-V-VMMS

Problem

The following event is logged non-stop in the Hyper-V High Availability log:

Log Name:      Microsoft-Windows-Hyper-V-High-Availability-Admin
Source:        Microsoft-Windows-Hyper-V-VMMS
Date:          27.07.2017 12.59.35
Event ID:      20501
Task Category: None
Level:         Warning
Description:
Failed to register cluster name in the local user groups: A new member could not be added to a local group because the member has the wrong account type. (0x8007056C). Hyper-V will retry the operation.

image

Analysis

I got this in as an error report on a new Windows Server 2016 Hyper-V cluster that I had not built myself. I ran a full cluster validation report, and it returned this warning:

Validating network name resource Name: [Cluster resource] for Active Directory issues.

Validating create computer object permissions was not run because the Cluster network name is part of the local Administrators group. Ensure that the Cluster Network name has “Create Computer Object” permissions.

I then checked AD, and found that the cluster object did in fact have the Create Computer Object permissions mentioned in the message.

The event log error refers to the cluster computer object being a member of the local admins group. I checked, and found that it was the case. The nodes themselves were also added as local admins on all cluster nodes. That is, the computer objects for node 1, 2 and so on was a member of the local admins group on all nodes. My records show that this practice was necessary when using SOFS storage in 2012. It is not necessary for Hyper-V clusters using FC-based shared storage.

The permissions needed to create a cluster in AD

  • Local admin on all the cluster nodes
  • Create computer objects on the Computers container, the default container for new computers in AD. This could be changes, in which case you need permissions in the new container.
  • Read all properties permissions in the Computers container.
  • If you specify a specific OU for the cluster object, you need permissions in this OU in addition to the new objects container.
  • If your nodes are located in a specific OU, and not the Computers OU, you will also need permissions in the specific OU as the cluster object will be created in the OU where the nodes reside.

See Grant create computer object permissions to the cluster for more details.

Solution

As usual, a warning: If you do not understand these tasks and their possible ramifications, seek help from someone that does before you continue.

Solution 1, low impact

If it is difficult to destroy the cluster as it requires the VMs to be removed from the cluster temporarily, you can try this method. We do not know if there are other detrimental effects caused by not having the proper permissions when creating the cluster.

  • Remove the cluster object from the local admin on all cluster nodes.
  • Remove the cluster nodes from the local admin group on all nodes.
  • Make sure that the cluster object has create computer objects permissions on the OU in which the cluster object and nodes are located
  • Make sure that the cluster object and the cluster node computer objects are all located in the same OU.
  • Validate the cluster and make sure that it is all green.

Solution 2, high impact

Shotgun approach, removes any collateral damage from failed attempts at fixing the problem.

  • Migrate any VMs away from the cluster
  • Remove the cluster from VMM if it is a member.
  • Remove the “Create computer objects” permissions for the cluster object
  • Destroy the cluster.
  • Delete the cluster object from AD
  • Re-create the cluster with the same name and IP, using a domain admin account.
  • Add create computer objects and read all properties permissions to the new cluster object in the current OU. 
  • Validate the cluster and make sure it is all green.
  • Add the server to VMM if necessary.
  • Migrate the VMs back.