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.
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:
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
This configuration was causing calls from the FIM Portal to the FIMSErvice to travel off-box, thus requiring the use of Kerberos Delegation.
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.
Peter Geelen - MSFT edited Revision 5. Comment: Consolidated layout
Is this a case of a scaled-out deployment where the FIM Portal is connecting to another server running the FIM Service even though there is also a FIM Service instance on the same box?