A long time after writing an earlier blog post on this error, I’ve seen it again. You try to approve in the Portal, and right after clicking Sumbit you get the dreaded FIM “Unable to process” error page
I had been working through all the usual Kerberos issues but was pretty sure I had all the SPNs, names in config files and Alternate Access Mappings lined up. Plus there was no sign of that “cannot connect to the middle tier” error in the FIM event log that always sets off Kerberos alarm bells in my mind.
Eventually I did manage to get an error – this one in the Applications log, and only when I logged in to the Portal as the approving user on the FIM server itself:
Log Name: Application Source: ASP.NET 2.0.50727.0 Date: 9/02/2014 09:59:16 Event ID: 1309 Task Category: Web Event Level: Warning Keywords: Classic User: N/A Computer: FIMServer.mydomain.com Description: Event code: 3005 Event message: An unhandled exception has occurred. Event time: 2/9/2014 9:59:16 AM Event time (UTC): 2/8/2014 10:59:16 PM Event ID: 941b508e7d764e89a77c1c5a57cad942 Event sequence: 293 Event occurrence: 6 Event detail code: 0 Application information: Application domain: /LM/W3SVC/1069363774/ROOT-1-130363694884026945 Trust level: WSS_Minimal Application Virtual Path: / Application Path: C:\inetpub\wwwroot\wss\VirtualDirectories\80\ Machine name: FIMSERVER Process information: Process ID: 8780 Process name: w3wp.exe Account name: MYDOMAIN\SharepointAppPoolServiceAccount Exception information: Exception type: SecurityNegotiationException Exception message: The caller was not authenticated by the service. Request information: Request URL: http://fimportal/identitymanagement/aspx/Requests/ApproveRequests.aspx?CacheID=18eab583-73a2-4bbd-991d-80e16f60a646 Request path: /identitymanagement/aspx/Requests/ApproveRequests.aspx User host address: xxx.xxx.xxx.xxx User: MYDOMAIN\ApproverUser Is authenticated: True Authentication Type: NTLM Thread account name: MYDOMAIN\SharepointAppPoolServiceAccount
I’ve highlighted the bit that jumped out at me – NTLM. It should have been using Kerberos.
When you approve you are actually hitting a published endpoint which is stamped on the Approval object itself and based on the externalHostAddress of the FIM Service instance where the Approval object was initially created. It must be possible to authenticate to this endpoint using Kerberos, and if anything gets in the way of that, the approval will fail.
So I went and checked the Windows Authentication settings on the “Sharepoint – 80” site in IIS and, for some reason that I have yet to get to the bottom of, only “NTLM” was listed as a provider. We must have “Negotiate” and it must be first.
I also followed the step to “Turn off NTLM authentication in the Portal” in the FIM post-installation steps: http://technet.microsoft.com/en-us/library/gg637904(v=ws.10).aspx
After a FIM Service restart and iisreset it is now possible to approve!