Just going into prod with a major FIM solution and we found that approvals weren’t working. The request was sent, the email arrived, but when the user went to the Portal to attempt to respond to the request they got “Unable to process your request” immediately after clicking “Submit”.
I actually guessed the cause straight away – but then spent three hours on fruitless troubleshooting because of something I didn’t know about Approval objects – more on that below.
The problem was an incorrect externalHostName in the Microsoft.ResourceManagement.Service.exe.config file.
Actually it wasn’t supposed to be incorrect – but it turned out a peculiarity in the customer’s network means that Kerberos only works using the cname instead of the full fqdn. So I figured the problem was that externalHostName was “fimservice.mydomain.com” instead of just “fimservice”.
I changed the config file, restarted the FIMService and IIS and … still could not approve.
Queue the aforementioned three hours of enabling and trawling log files, messing with service accounts and SPNs, and general hair tearing. After enabling verbose logging I could see this error: “The Portal cannot connect to the middle tier using the web service interface” – something that I know is often externalHostName. So why didn’t my first change fix it?
Well actually it had – just not for the existing Approval objects. And here’s the thing I didn’t know: Approval objects are stamped with the externalHostName from the config file. So change the config file and your existing Approvals are still broken. You need to trigger a new Approval before you can tell for sure if the problem still exists.
I would strongly recommend using A records and not cname records then creating spn’s for both the netbios and fully qualified names as a safe guard for Kerberos either way u got me checking my config tomorrow 🙂
http://technet.microsoft.com/en-us/library/gg502606.aspx
Maybe my terminology is not correct – it’s got something to do with split-brain DNS so their network appends the domain suffix for you if you use the short name, and if you append the domain suffix yourself then it’s assumed to be destined for the internet and has to go out through the firewall and back in again. Certainly the result seems to be that kerberos login only works on the portal if you go http://fim and not when you go http:/fim.fulldomain. FIM is not special here – it’s the same with all their services. Just another interesting variation to find at a customer site 🙂
Now you have me curious about what their DNS suffix Search list is….
I imagine the SPN request is being made with a different DNS suffix, when you use the short name, but they don’t have it defined with the full name perhaps?
If you care or are curious, enable Kerberos debugging to see if it detects a Kerb message in those 2 different scenarios. Or just connect up network monitor.
http://jeftek.com/226/directory-services-debugging/
(I wish they still kept lower level Kerberos debugging in Windows 2008/r2, but they removed it and you can’t get the same level of detail anymore without working with MS directly. If anyone knows of a way to interactively debug the OS for kerberos messages like we could before but attaching the debugger, I’d love to hear about it.)
Good Luck!
We had SPNs defined on every possible combination of full name, short name and server name. All are defined as alternate access mappings in Sharepoint. It’s really just down to something interventionist being done by their network hardware and the situation is not isolated to FIM. Eg., when you want to talk to their load-balanced CAS you also have to use the short name.