I’m moving off the SCOM world a bit as I’ve been tasked with learning a new product. My cyber mentor told me that this is one that I’ll find myself redoing multiple times and unfortunately, he wasn’t kidding. I did some looking around and didn’t find much in terms of good step by steps on this, so I decided to create my own. For the most part, I’m working off of the documentation found here, but there are some gaps in it along with a few lessons learned that aren’t clearly documented. Hopefully, someone will find this useful.
First, let’s talk about what it is.
It’s main purpose is to synchronize your corporate identities off of a master copy. Let’s say for instance, that your authoritative identity store is an HR database. MIM can be used to take the data entered in the HR database and push it to Active Directory, Exchange, a 3rd party ticketing tool, and well, just about anything if you take the time to install the connectors and (if necessary) write the scripts. It’s pretty powerful and automates a lot of manual processes that are often filled with user error. It can also used to synchronize identities between your on premise infrastructure and your Azure infrastructure. Likewise, it comes with really cool features such as the ability to enable self service password resets via a registration and reset portal. This allows users to quickly reset their own passwords instead of waiting on hold for a help desk representative to do it for them. It’s quicker and it takes a load off of your call center since password resets are one of the higher volume calls. As a security person, I think there are better solutions to passwords in general (Microsoft is going 2 factor and password free for the record), and I think that’s an attainable goal, but organizations aren’t often changing that fast, and something like MIM can help them transition to that.
If you want to read more, this is a good starting point. This is basically the next evolution of ForeFront Identity Manager (FIM), so you’ll see a lot of these terms used interchangeably.
Ok, so I’m done with the sales pitch. Sorry about all of that. I’m guessing if you’re reading this, you’re already interested in it. From a pre-requisite standpoint, the product is somewhat complicated. You need active directory, which to be fair everyone has. The web portals sit on top of a SharePoint infrastructure, and of course there’s a SQL database involved as well. So lots of setup. We break our documentation into the domain setup, server setup, Exchange, SharePoint, and SQL setup. I’m not going to step by step all of these, but I am going to highlight the basic needs. First of note, I don’t have Exchange in my lab presently, so I’m not doing that at all.
- First step, figure out your URLs. For my demo purposes, I’m using mim.ctm.contoso.com as the main portal. I’m using passwordregistration.ctm.contoso.com and passwordreset.ctm.contoso.com for registering and resetting passwords. I’m going to house all of that one one SharePoint Front end server, which also double as my MIM server. You can distribute which is highly recommended for a non-lab environment, but for the purposes of my lab, SQL, SharePoint, and MIM will all be housed on the same server. Since this is web based, https is highly recommended. I don’t have the certificate infrastructure to do that, so I’m going to stick with http in my lab, but I think the average reader understands that this is not ideally a good answer. You can however, start with http and change it to https later on since this is all using IIS and SharePoint. I do highly recommend that you involve your SharePoint admin for this stage of planning so they can carve off the site collection and what not.
- Second step, figure out your accounts. I would note that the scripts here are for the most part good. There is, however, a typo in the account creation scripts with both the MIMInstall account and the MIMMA account having MIMMA as the name. You’ll want to correct that if you’re just going to use our scripts. It’s wroth noting that our scripts assume a different URL than what I’m using, so you’ll probably want to drop these into an ISE window and edit them to fit your needs, and you’ll probably not want to use the same password for all of these accounts either. It’s also worth noting that this is heavily dependent on Kerberos, and as such you’ll need to setup those SPNs. Your SQL and SharePoint admins may have different means of configuring all of this. If for instance, you aren’t using a SQL service account to manage SQL, than the SPN information will need to be tied to the SQL server machine name and what not. This one will cost you time troubleshooting if you’re not careful about it, so pay attention to all of that.
- Third step, install SQL server. I’m not a fan of the instructions found here. It’s a simple script. There’s nothing wrong with that, but it really doesn’t tell you much. You need the database engine obviously. You need SQL agent set to auto start. You also need Full Text Search installed. The MIM install will fail if you don’t do that. Your MIM Install account will need to be an SA over the instance. Our script assumes that the account you used in step 2 is being used as the SQL server service account. Don’t forget that though if you install using the wizard, as there are Kerberos settings tied to it.
- Fourth step, install SharePoint. These scripts all work, but you’ll need to modify the URLs to suit your needs.
- Fifth step, Exchange. I don’t have anything to add here because I didn’t do it. You’re on your own here.
- Sixth step, MIM server setup. The server setup documentation is relatively straight forward. Your MIMInstall account will need to be a local admin, and as the guide notes, your service accounts need the logon as a service right. You may need to set this part via GPO depending on your environment, and of course the SQL and SharePoint accounts will need that too, but if you’re been working with your SharePoint admin and SQL DBA, that’s been addressed. The server install piece is straight forward, but the scripts were written for older versions of windows, so they won’t work on a Server 2016 deployment (there is no application server role anymore). I’ve modified it slightly:
Install-WindowsFeature Web-WebServer,Net-Framework-Features,rsat-ad-powershell,Web-Mgmt-Tools,Windows-Identity-Foundation,Server-Media-Foundation,Xps-Viewer –includeallsubfeature -restart -source d:\sources\SxS
Note also the source location, as not all of these are on a standard server build, especially if you’re deploying in the cloud.
Anyways, that’s it for the setup. Next step will cover the sync service as well as the portal installs.