0
Answered

The target principal name is incorrect when accessing via IIS

Ben Parkinson 9 months ago • updated 5 days ago 11

I am receiving an error on the standalone web component when trying to access it.

  • The site is installed and configured on IIS 7.5 per the instructions. 
  • Identity Broker is a base install also following the instructions.  
  • I can access the endpoints hosted on the Identity Broker server from the IIS server. 
  • The website is on port 8200 and shares the server with SharePoint and MIM Service & Portal. 
  • Identity Broker is on a separate server with just MIM Sync. 
  • The server also uses .NET4.6 (only mentioned here as I had issues with SharePoint).
  • I have tried enabling Anonymous Authentication over Windows Authentication and have also tried using the Identity Broker service account in the application pool. 
  • I've disabled Custom Errors to view the error, but have attached  Event Log item with the stack trace. 

It appears to be an authentication error, but I can't for the life of me work out where in the scheme of things it's coming from.

Broker Web Error.evtx

Event code: 3005 
Event message: An unhandled exception has occurred. 
Event time: 14/08/2017 9:20:14 AM 
Event time (UTC): 13/08/2017 11:20:14 PM 
Event ID: 7a9e61eff31a4fedbcdbc46027dff770 
Event sequence: 2 
Event occurrence: 1 
Event detail code: 0 
 
Application information: 
    Application domain: /LM/W3SVC/3/ROOT-1-131471400119122652 
    Trust level: Full 
    Application Virtual Path: / 
    Application Path: C:\inetpub\wwwroot\UnifyIdentityBroker\Identity Broker\StandaloneWeb\ 
    Machine name: IAM-DEV1-MIM2 
 
Process information: 
    Process ID: 5584 
    Process name: w3wp.exe 
    Account name: IIS APPPOOL\UNIFYIdentityBroker 
 
Exception information: 
    Exception type: HttpException 
    Exception message: The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate oXIwcKADCgEBomkEZ2BlBgkqhkiG9xIBAgIDAH5WMFSgAwIBBaEDAgEepBEYDzIwMTcwODEzMjMyMDE0WqUFAgMNka+mAwIBKakOGwxERVYuQ1NJUk8uQVWqGTAXoAMCAQGhEDAOGwxzYS11bmlmeS1pZGI='.
   at System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app)
   at System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)
   at System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)
   at System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)
   at System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)
The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate oXIwcKADCgEBomkEZ2BlBgkqhkiG9xIBAgIDAH5WMFSgAwIBBaEDAgEepBEYDzIwMTcwODEzMjMyMDE0WqUFAgMNka+mAwIBKakOGwxERVYuQ1NJUk8uQVWqGTAXoAMCAQGhEDAOGwxzYS11bmlmeS1pZGI='.
Server stack trace: 
   at System.ServiceModel.Channels.HttpChannelUtilities.ValidateAuthentication(HttpWebRequest request, HttpWebResponse response, WebException responseException, HttpChannelFactory`1 factory)
   at System.ServiceModel.Channels.HttpChannelUtilities.ValidateRequestReplyResponse(HttpWebRequest request, HttpWebResponse response, HttpChannelFactory`1 factory, WebException responseException, ChannelBinding channelBinding)
   at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   at System.ServiceModel.Channels.RequestChannel.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Dispatcher.RequestChannelBinder.Request(Message message, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at Unify.Framework.IStandardPostEngineCollector.RequiredSystemTypes()
   at Unify.Product.IdentityBroker.IdentityServiceClient.RequiredSystemTypes()
   at Unify.Connect.Web.ProfiledIdentityServiceClient.RequiredSystemTypes()
   at Unify.Connect.Web.MvcApplication.Application_Start()
The remote server returned an error: (401) Unauthorized.
   at System.Net.HttpWebRequest.GetResponse()
   at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
The target principal name is incorrect
   at System.Net.NTAuthentication.GetOutgoingBlob(Byte[] incomingBlob, Boolean throwOnError, SecurityStatus& statusCode)
   at System.Net.NTAuthentication.GetOutgoingBlob(String incomingBlob)
   at System.Net.NegotiateClient.DoAuthenticate(String challenge, WebRequest webRequest, ICredentials credentials, Boolean preAuthenticate)
   at System.Net.NegotiateClient.Authenticate(String challenge, WebRequest webRequest, ICredentials credentials)
   at System.Net.AuthenticationManagerDefault.Authenticate(String challenge, WebRequest request, ICredentials credentials)
   at System.Net.AuthenticationState.AttemptAuthenticate(HttpWebRequest httpWebRequest, ICredentials authInfo)
   at System.Net.HttpWebRequest.CheckResubmitForAuth()
   at System.Net.HttpWebRequest.CheckResubmit(Exception& e, Boolean& disableUpload)
 
 
Request information: 
    Request URL: http://localhost:8200/ 
    Request path: / 
    User host address: ::1 
    User:  
    Is authenticated: False 
    Authentication Type:  
    Thread account name: IIS APPPOOL\UNIFYIdentityBroker 
 
Thread information: 
    Thread ID: 12 
    Thread account name: IIS APPPOOL\UNIFYIdentityBroker 
    Is impersonating: False 
    Stack trace:    at System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app)
   at System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)
   at System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)
   at System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)
   at System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)
 
 
Custom event details:
Affected Versions:
Fixed by Version:

Answer

Answer
Answered

Hi Ben

This issue is a little tricky to troubleshoot as we've not seen this before and isn't something that can be reproduce in a test environment, but have something for you to try.

In both the Unify.Service.Connect.exe.config and the web.config files, find the system.serviceModel element and nested within that find <transport clientCredentialType="Windows" /> and change the Windows value to Ntlm. Restart the website and the IdB service.

Let us know of the outcome.

Forgot to mention Broker version is 5.1 latest build.

Under review

That looks like it's related to the WCF endpoint. Make sure the changes that have been made to the WCF settings in the Identity Broker config files have also been made to the web.config. Not that it relates to your error, but you were correct in using the Windows auth settings in IIS.

Answer
Answered

Hi Ben

This issue is a little tricky to troubleshoot as we've not seen this before and isn't something that can be reproduce in a test environment, but have something for you to try.

In both the Unify.Service.Connect.exe.config and the web.config files, find the system.serviceModel element and nested within that find <transport clientCredentialType="Windows" /> and change the Windows value to Ntlm. Restart the website and the IdB service.

Let us know of the outcome.

That has fixed the problem, thanks.

That seems to suggest then that Kerberos is not working as expected within their Active Directory implementation doesn't it? In which case, I'd really like them to troubleshoot for that as opposed to forcing NTLM. 

Keen to hear your thoughts.

Kerberos and AD are not really our area of expertise, but it does seem like some environmental issue is involved since the default value has always been sufficient, as I mentioned before.

Thanks Beau. An AD environment issue was my initial thought when I saw the problem as I couldn't reproduce it on my lab with the same config.

Just providing a long overdue update on this. I proved it to be an environment issue some time ago; however, the suggested fix to their environment has only just gone in and the issue is sorted.

For my own information, is there a way we could configure Identity Broker to fall back to NTLM if so configured? (Should not be a recommended general approach  as it's a horrible idea from a security perspective)

Would the workaround that Beau provided in the answer be a suitable fall-back? I'd be happy to turn this into an article on the topic.

The change in the config files work, and is OK to use. The concern is more that if a customer fixes their issue, we should then update the configs and depending on the department, that might be a long, difficult process for two properties. If it performs an auto fallback then as the environment is fixed, Broker would just pick up the new authentication protocol.

For some of our implementations it might be better if we could add auto fall back as it's not a clear problem particularly from v5.2 onward as the connector data page produces a misleading JSON data table pop-up error (assuming from the third party table tool), which can easily be diagnosed, but I'm cognizant that some don't always dig deeper.

I'm also not sure how many customers we have actually had to set to NTLM. If we believe the issue is just for this customer, then definitely happy to leave as is and have the guys find this via the search and not waste any time on it.

Alternatively, I'd also be happy to reproduce the issue and get screen shots, etc. so we can place it into an article.

+1

There are no other clients that I'm aware of (and seems that way for the others considering the history of this ticket). I'm leaning towards leaving this as a documentation/configuration issue, as the WCF endpoints are deprecated in v5.3 and will be removed in a future version (in favour of Web API). Thoughts?

Definitely happy with that then.