MIM 2016: On Approvals, SPNs, NLBs, DNS and Browser settings

I just spent a whole day trying to figure out why approvals were not working. If you are in a really locked down environment then your “it works in my lab” can be thrown out the window. First let me mention, there is insightful blogpost from Carol which explained the root cause quite well.

Alright let’s get down to brass, for me I faced 4 things

  1. All web traffic passes through a proxy server.
  2. The browser settings are locked down and you cannot add a site as local internal site or trusted site. On the MIM servers only the server names are in the trusted site.
  3. There is a NLB present for the portal which is its own dangle to unravel.
  4. In the Portal resource config file I put the Network Load balancer (NLB) FQDN address as the base address.

The situation in MIM Portal is two fold.

  1. Form pages do not load well, especially when new custom attributes are added to the form. Works fine if I point to the MIM server, not the NLB address.
  2. With approvals I get the “Unable to process your request”.

The cause

Item One

Regarding the form pages. See this blogpost on NLB and css.

Item two

Approvals are heavily dependent on Spns/Kerberos. I noticed that when I do http://tlkidm that is the NLB hostname, spns work well, when I do http://tlkidm.tlkenterprise.net the spns do not work at all. Same thing if I use the MIM server name Spns work if I use the FQDN spns do not work. Now in the MIM config file I put the base address as tlkidm.tlkenterprise.net which is the NLB FQDN so it was stamping all approvals with this address and they were failing on approval attempt. I changed it back yesterday night to the hostname not FQDN. Unfortunately, once an approval is stamped, that kind of seals it, and if spns is not working for that address then it must be discarded. The users will have to resubmit their requests.

Why isn’t spns working for FQDN in this network? It’s the way the DNS (this configuration is known as Split-DNS) is configured as well as the network settings. I have configured spns in environments where the FQDN and hostname works well. But Split-DNS is where DNS completes your address to the FQDN when the hostname is used but when the FQDN is used it regards it as an outside address and that routes to the proxy and bypasses the SPN process.

Solution

Item One

  1. You can spend sometime with your NLB engineer and try and figure out a good setting on the NLB to make it work. Needs a good NLB engineer to figure out the correct setting.
  2. Point the NLB address to each local MIM Portal ip. The core purpose of the NLB is to act as a gateway to the MIM Portal and split the traffic intelligently. Once the traffic comes to MIM Portal, the MIM Portal can handle its business, does not need to go back to the NLB. Now I assume you have your MIM Portal and MIM service on the same server. I have seen a split architecture and it was a very unpleasant user experience. I don’t use it and I highly do not recommend it. Okay, back to the topic, use a host file on each MIM Portal server and put the local ip of the MIM Portal as the NLB address. Now is there any point placing the NLB address in the resource config as base address? We will see in item two.

Item two

  1. In my situation of a split DNS and the local server address is the only address in the trusted site list, my approvals must be stamped with the MIM server host name else the Spns will not work and approvals will fail. So in the resource config file I put the host name of the MIM server.
  2. In the SharePoint alternate access setting I pointed the NLB addresses and all other address to the host name of the local MIM server, http://tlkmimserver.
  3. Add the NLB url to the local internal site list of IE.

Result

  1. Form pages load fine.
  2. Approvals work fine.

3 thoughts on “MIM 2016: On Approvals, SPNs, NLBs, DNS and Browser settings

  1. Greetings Ike – I’m battling an approval issue ATM and wanted to validate which service account/SPN is responsible for the approval process. Is it the FIMService account or the SharePoint AppPool account?

    TIA,

    -Terry

    Like

  2. Good point. Probably the FIM service account. I build ALL my MIM deployments using the same account for FIM Service and Sharepoint AppPool. From my experience its the most stable and less hassle config. May not be inline with the Msft playbook but gives Day2 team less stress.

    Like

  3. Ike, thank you for the follow-up. 15 minutes after posting, I realized the answer to my previous Q as the request /approval object EndpointAddress attribute clearly states: “http://somehostname:5726”. This environment has been utilizing FIMService aliases for years and most approvals would work. A recent policy change now requires all SGs that control elevated rights assets to be Owned/Approved by a user’s elevated account. When these users were “Signing in as a Different User”, the Approval process would end in the typical non-informative error. Even though there were SPN and DNS host names for the aliases utilized, everything started working as expected when the FIMService config was updated to the machine’s actual hostname. Problem solved, on to the list of other issues…

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s