While this may probably be an uncommon event, it does occur and you may see it more frequent today when customers are upgrading their FIM to MIM 2016 on brand new servers (Windows 2012 R2 or Windows 2016) and they may want completely separate accounts but of course expect you are going to carry over the same database and the exact same settings. I am going to look at it from the perspective of you are changing the service account of any existing FIM/MIM installation, it is slightly different from when you are installing new, which is actually a bit easier. But the guidelines work for both.
Before I talk about the steps, I want to talk about some tech info concerning MIM accounts. MIM takes the service account and encrypts the service account info and some other data (like MA passwords) in the database. That is very good operation to meet audit requirements, passwords or key account info should not be stored in clear format in your DB that is a security risk. MIM will pull the account (like MA) password from within the DB when it runs. The Sid of the supplied service account that is used in this encryption process represents the authoritative owner to MIM and is the only one allowed to decrypt the data.
Now you understand what that Key you are asked to store at the end of the MIM install is used for. It is the decryption key, created with the Sid of the Service account. In the event of a restore or the re-use of an existing MIM DB, MIM will ask for that key and the id and password and it will pull the Sid of the account you supply from the DC or authoritative security system for that account, compare it with the Sid it has in the Key as the authoritative owner allowed to decrypt, it there is a match then it’s all good. If there isn’t a match then that process fails.
So you will understand why I have some steps below
- Go to AD and create the new MIM Sync Service account. Give similar group membership and server rights as the old service account.
- Give the new account SA rights in SQL.
- If you made any changes to the Miisserver.config file, backup that file.
- Stop the Sync service
- Open Key management tool. Abandon the old key. When prompted add the new account to re-encrypt the data
- Go to the MIM software and run setup, select change and go through the process. Enter the new service account info.
- Apply post hot-fix you had before
- Your MIM Sync should start. Copy back the miisserver.config if you backed it up. Go to each MA and re-enter the MA account to reset the connections.
- Remove the SQL SA rights of the new account.
Changing the Portal account is a bit different. I had a very interesting experience when I wanted to change my Portal service account. I kept getting “Identity unknown” when I tried to access the Portal via the browser. I even installed a brand new FIM Service DB but pointing to the same MIM Sync server and I saw that MIM was grabbing the old MIM Portal service account Sid and placing it in its User identity table. I was baffled, where was it getting this account info when I enter the new account during setup? Well, from the MIM Sync server. And so some steps I will do in here will be direct to the FIM Service DB, which comes with the usual warning etc.
- Go to AD and create the new MIM Portal Service account. Give similar group membership and server rights as the old service account.
- Go to IIS Admin in the Portal, go to application pool, for each one that uses the Portal account, re-enter the id and password. Restart IIS.
- Give the new account Sharepoint Admin rights. Go to a command prompt
cd C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\BIN
STSADM.EXE -o updatefarmcredentials -userlogin mydomain\mynewportalaccount -password Welcome1
- On the MIM Portal, go to control panel, services and change the Portal service password. Restart the service.
- Change the Service account Sid in the FIM Service DB
- Go to AD, go to properties of the new service account, go to the ObjectSid attribute, select Hexadecimal, copy the Hexadecimal value to a text file, remove the spaces, start it with 0x0, so an example it should look like this “0x0105000000000005150000006ACBAE7878A2767273FF9B6B50040000”
- Go to the FIMService DB, go to the UserIdentifier table, click edit the table, change the UserObjectKey 2340 to 2341
- run the following SQL query
insert into [FIMService].[fim].UserSecurityIdentifiers values (2340, 0x0105000000000005150000006ACBAE7878A2767273FF9B6B50040000)
- Delete the 2341 row in the table
- Log into your Portal with the new account
Change any SPNs registered with the previous service account.