FIM Troubleshooting: Accessing the FIM Portal using a Sensitive Account (cannot be delegated)

Article
2024-01-17

Here is an issue dealing with accessing the FIM Portal using a Sensitive (cannot be delegated) account.

Running FIM 2010 R2 RC in production and ran into this problem. As the cause seems to be external to FIM, I think the information is applicable to FIM 2010 as well.

REPRO STEPS

Running FIM 2010 R2 RC Portal and Service on SharePoint Foundation Server 2010
Use an alias to route directly to the Identity Management Portal (https://myalias routing to https://myservername/identitymanagement/default.aspx)
Configure the FIMService SPNs and delegation properly for both the machine name & alias
In the SharePoint - 80 web.config file, use the Alias for the resourceManagementServiceBaseAddress property

PROBLEM

When accessing the FIM Identity Management Portal using a restricted account (account is sensitive and cannot be delegated), a Kerberos delegation error was being returned through SharePoint:

ERROR RETURNED

An unexpected error has occurred.

Troubleshoot issues with Microsoft SharePoint Foundation. 

Correlation ID: ab2ca1bb-cd37-4197-bd44-9015a2b38c65

 

The correlation id results in the following : 

01/19/2012 13:07:25.21 w3wp.exe (0x2B54) 0x23EC SharePoint Foundation Runtime tkau Unexpected 

System.ServiceModel.FaultException: The request for security token could not be satisfied because authentication failed.    

at System.ServiceModel.Security.SecurityUtils.ThrowIfNegotiationFault(Message message, EndpointAddress target)     

at System.ServiceModel.Security.IssuanceTokenProviderBase`1.ThrowIfFault(Message message, EndpointAddress target)     

at System.ServiceModel.Security.SspiNegotiationTokenProvider.GetNextOutgoingMessageBody(Message incomingMessage, SspiNegotiationTokenProviderState sspiState) 

ab2ca1bb-cd37-4197-bd44-9015a2b38c65

CAUSE

This configuration was causing calls from the FIM Portal to the FIMSErvice to travel off-box, thus requiring the use of Kerberos Delegation.

RESOLUTION

Changed the resourceManagementServiceBaseAddress property in the web.config file to point to the machine name hosting the service & portal, and logging into the Portal as a sensitive (cannot be delegated) account no longer returns the exception.

Share via