I'm working on an Alchemy plugin, and I'm having trouble using the importexport service to export a simple package. I'm getting an access denied error, which is baffling me because I don't see any NETWORK SERVICE user anywhere on the system, and also because my code attempts to explicitly set the user to something else.

    var selection = new Selection[] { new ItemsSelection(tcms) };

    var endpointIdentity = EndpointIdentity.CreateUpnIdentity("WIN-DFMAJQHT95L\\Administrator");

    var endpointAddress = new EndpointAddress(new Uri("http://localhost:81/webservices/ImportExportService2013.svc/basicHttp"),
                                                  new AddressHeader[0]{});

    var binding = new BasicHttpBinding();
    binding.Name = "ImportExport_basicHttpBinding";
    binding.Security.Mode = BasicHttpSecurityMode.TransportCredentialOnly;
    binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Windows;

    var importExportClient = new ImportExportServiceClient(binding, endpointAddress);

    var exportInstruction = new ExportInstruction()
        LogLevel = LogLevel.Normal,
        BluePrintMode = BluePrintMode.ExportSharedItemsFromOwningPublication,
        //ExpandDependenciesOfTypes = IncludeDependencyTypes

    var processId = importExportClient.StartExport(selection, exportInstruction);

The error I'm getting is:

System.ServiceModel.FaultException`1[Tridion.ContentManager.ImportExport.Client.ImportExportServiceFault]: Access is denied for the user NT AUTHORITY\NETWORK SERVICE. (Fault Detail is equal to Tridion.ContentManager.ImportExport.Client.ImportExportServiceFault).

Any suggestions?

Server stack trace: at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc) 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 Tridion.ContentManager.ImportExport.Client.IImportExportService.StartExport(Selection[] selections, ExportInstruction instruction) at LatestItems.Controllers.LatestItemsServiceController.GetExportConfig(ExportConfigRequest request)

  • 1
    This message is what I would expect if the client credentials are not being sent (seems to be the case). At a guess, the line where you're getting the windows credentials is running server-side, and is getting the ID under which the process is running (NETWORK SERVICE) instead of the logged in user.
    – Nuno Linhares
    Jun 13 '16 at 18:23
  • Which line are you referring to? When I create my endpointIdentitty, I've tested explicitly setting the username to an Admin or current windows user - and in all cases, I've confirmed by writing out to a log that the user is NOT the NETWORK SERVICE user. Jun 13 '16 at 21:54
  • I suspect I have a similar issue and/or require a similar solution as this: stackoverflow.com/questions/12044338/… Jun 13 '16 at 22:30
  • Adding this code seems promising. However, I don't want to have to deal with any passwords: ------------- var credentials = new NetworkCredential("Administrator", "<password>"); importExportClient.ChannelFactory.Credentials.Windows.ClientCredential = credentials; Jun 13 '16 at 23:02

Adding this code seems to be the best solution:

var credentials = new NetworkCredential("Administrator", "<password>"); 
importExportClient.ChannelFactory.Credentials.Windows.ClientCredential = credentials;

Continuing with the export and then writing the code to download the package, there were a few other issues that I eventually managed to resolve by comparing my code to the Tridion.ContentManager.ImportExport.Common.dll.config file. Basically all pertinent information in that config file needed to be replicated in the C# code, because as an Alchemy plugin there is no .config file to merge that information into.

  • 1
    Agree that this is not optimal, you should be able to use the current user. Keep on searching, there must be a way to get it correctly. At least, this confirms that the issue is you're not getting/passing the correct credentials.
    – Nuno Linhares
    Jun 14 '16 at 11:30
  • I don't think it's possible. With the core service, this is normally done using client.Impersonate(), but with the importExportClient, there is no Impersonate() method, or anything similar, that I am aware of. I guess that makes sense, since Content Porter asks for credentials separately from the CME. However, this is a major blocker for my plugin and it means I have no nice way to interact securely with the importExport service from the client side in my plugin. Jun 21 '16 at 4:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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