1

I'm getting this error from Content Porter 2013:

The HTTP request is unauthorized with client authentication schema 'Anonymous'. The authentication header received from the server was 'Negotiate, NTLM'.

CP works in our environment, but we installed a new sandbox 2013 CM & we can't import any CP packages to it because of this error. Any ideas?

Improve this question
6
  • Which authentication schema is used in the Tridion? Ldap/SSO/Windows? Does issue occur just on connection to the server ?
    – Syav4eg
    Commented Jul 1, 2015 at 7:37
  • Windows. I can get to the CM & access it when browsing to it while logged in with my network account. How can I verify that CP is actually running correctly? The sandbox is a VM. can this be a network quick?
    – Mr Smith
    Commented Jul 1, 2015 at 16:57
  • @MrSmith I added additional details to verify CP
    – Vipin Kothari
    Commented Jul 1, 2015 at 20:31
  • Check authentication on the webservices level it has to be "Windows Authentication"
    – Syav4eg
    Commented Jul 2, 2015 at 6:47
  • I checked. it is set to Windows Authentication.
    – Mr Smith
    Commented Jul 2, 2015 at 18:22

3 Answers 3

Reset to default
2

After a couple of days of analysis I found the problem and the solution. The problem was occurring only at the time of uploading the package, where the anonymous authentication kicks in (in IIS) and it delegates the authentication process to WCF. In theory only NTFS will interfere with the WCF authentication if a user doesn't have the right access level to a folder, for example, the service might be trying to access (Temp, Packages, etc...).

So I confirmed that the folder permissions were right. Then I tried fiddler and the only think I could confirm was that the error was happening when hitting the stream upload binding in the ImportExport service.

What I did to resolve the issue is to use procmon.exe in windows and filter the results to only see the operations done by the w3p service, which turned out to be very helpful, since I started to see "Paths" with the text Rejected-By-UrlSca it, and a bunch of 404 errors on fiddler again.

After some research I came accross this post regarding the URL scan ISAPI filter, which indeed was the cause of the error:

Rejected by URL Scan 404 Errors

After following the steps in such post, I removed the ISAPI filter with URLScan in IIS for the SDL Tridion web application.

Improve this answer
0
3

This error occurs mostly because you haven't set IIS authentication appropriately for CP/ImportExport. Did you executed the steps mentioned in the installation document for IIS settings? Also, the authentication mode has to be Windows which isn't currently the case because of which you are getting this error.

Please also check the web.config under TridionHome\webservices and check the bindings and make sure it is set as windows for credentials.

Here are a couple of helpful links https://stackoverflow.com/questions/1044034/wcftestclient-the-http-request-is-unauthorized-with-client-authentication-scheme

https://stackoverflow.com/questions/13704720/the-http-request-is-unauthorized-with-client-authentication-scheme-ntlm-the-a

Edit 1:

To test if CP is working fine or installed properly, you can try the below:

  1. Try hitting the ImportExport Service endpoint @ http://localhost/webservices/ImportExportService2013.svc and see if it comes up fine after providing the username and password. If the authentication mode on the virtual directory for webservices is set appropriately, this will come up
  2. Write a simple program to use ImportExport service and try package export and check if you are able to export packages from the newly setup server. You might encounter errors on this if it isn't setup appropriately which will help resolve the issue
Improve this answer
3

For the all content porter errors, the first thing that you should check for is Tridion event log on CM server. It provides detailed information on what is the exact.

Most of the times, I have seen that authentication related error are shown in content porter however actual error could be something totally different. Can you please check the event log and if you are able to figure out from event log then paste it here so that we can provide you the right direction.

Additionally, you can use fiddler to monitor the traffic and compare working vs non-working server (in your case sandbox vs working server)

Update 1: You should perform following steps in order to find out more details.

  1. Compare web.config in webservices folder for working CM server vs non-working CM servers. Both should be same.
  2. Compare the authentication mode on IIS for webservices for working CM server vs non-working server.
  3. If above two are fine, then use fiddler to monitor the traffic. There is separate call for uploading package and starting import so you can easily identify if uploading package is giving 200 (OK status) or not. If the problem is with uploading package then mostly it will be permission on folder.

By performing above steps, you would have drilled down to the problem then there are better chances of fixing it.

Improve this answer
3
  • Nothing in the event log. Everything works, except for import (which makes me think the issue has something to do with uploading the package...)
    – Jaime Santos Alcón
    Commented Jul 8, 2015 at 14:08
  • @JaimeSantosAlcón - Updated my answer to include more debugging step details. Please check and let us know.
    – Hiren Kaku
    Commented Jul 8, 2015 at 15:17
  • I did all that already, I get a 401 when hitting the Upload Stream endpoint for content porter. It might be file systems permissions or a network policy security setting all along, but I can't tell. I am a bit frustrated. I don't know where else to look.
    – Jaime Santos Alcón
    Commented Jul 10, 2015 at 11:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.