Impersonation Level problem using .NET calls

[ferencr]

I am trying to connect to Zemax OpticStudio API using their .NET interface. Identical .NET calls from C# work, but they fail from LabVIEW.

I get the following error as I try to open a connection from LabVIEW:

Invoke Node System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
Inner Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
Inner Exception: System.Runtime.Remoting.RemotingException: An error occurred while processing the request on the server: System.Security.SecurityException: Cannot open an anonymous level security token.

at System.Security.Principal.WindowsIdentity.GetCurrentInternal(TokenAccessLevels desiredAccess, Boolean threadOnly)
at System.Security.Principal.WindowsIdentity.GetCurrent()
at System.Runtime.Remoting.Channels.Ipc.IpcServerTransportSink.ServiceRequest(Object state)
The Zone of the assembly that failed was:
MyComputer <append><b>System.Runtime.Remoting.RemotingException</b> in ZOS-API test.vi

The connection is denied because impersonation is at a level of anonymous.

Default DCOM settings for the computer were already at Authentication: Connect and Impersonation: Identify. For some reason LabVIEW (or some part of LabVIEW that is involved in .NET calls) is trying to connect using a lower authentication level than default.

How would I go about setting the impersonation level from anonymous to identify?

[the_mitten]

Hi ferencr,

I've found two common reasons that this can occur:

• Sometimes LabVIEW is not running with administrative privileges, which can cause the security exception error. Try running LabVIEW as an administrator. 
• Sometimes there can be a difference in permissions between different drives, specifically on network drives. Is the LabVIEW installation and the Zemax installation located on the same drive?

Regards,

[ferencr]

Hi Michael,

Thank you for taking the time to answer.

Launching LabVIEW Development as administrator and then running the vi makes no difference. I still get the same error: System.Security.SecurityException: Cannot open an anonymous level security token

LabVIEW and Zemax are both installed locally on C:

Do you have any other leads?

Thanks,

Ferenc

[ferencr]

Drawing from the following links I was able to replicate the issue in a controlled manner.

C# source code used:

http://stackoverflow.com/questions/850427/why-does-an-ipcchannel-tell-me-cannot-open-an-anonymous-le...

Fix that worked in this example:

https://social.msdn.microsoft.com/Forums/Windowsserver/en-US/78d0a414-fd09-4769-a87a-a61a9424dff5/ca...

See the attached image for an easy to understand summary. Basically if LabVIEW is the application, the RegisterChannel (https://msdn.microsoft.com/en-us/library/ms223155(v=vs.110).aspx) method fails if ensureSecurity = TRUE.

It seems that the operating system is unable to open a secure Remoting Channel with a LabVIEW application when it has no problem doing so with a C# application.

[the_mitten]

Hi Ferenc,

I just got an email that you replied to this thread, so this step may no longer be relevant, but I was just about to click post so I'll continue with submitting!

Can we ensure that the DCOM security settings and authentication level for LabVIEW are consistent with the rest of the computer in the Component Services? 

It sounds like you're familiar with the DCOM configuration settings, but as a reference, steps 1-4 on page 5 of this guide demonstrate how to find the DCOM security settings. 

One thing to note - if you're using 32-bit LabVIEW on a 64-bit machine, you'll have to load the 32-bit DCOM configuration settings by running 

mmc comexp.msc /32

from the command line.Otherwise, the steps are the same in the guide above.

What are the security settings for LabVIEW set to? What about the authentication level? Does anything happen if you change them? What about compared to the settings for Visual Studio?

[ferencr]

DCOM settings are consistent with the link, default: connect and identify. Both Visual Studio and LabVIEW are set to use default for all values with some small differences. I have set LabVIEW from default to connect and explicitly allowed every user to access to be able to do anything with LabVIEW.

I went ahead and followed all other applicable steps in the manual, but without any luck.

Running the command mmc comexp.msc /32 made no difference. 2 days ago I also installed a second, 64-bit copy of LabVIEW on my computer to try, but it didn't make any difference.

One person on a forum reported that uninstalling a re-installing LabVIEW helped, do you think there is value in trying that?

[the_mitten]

Hi ferencr,

I wouldn't imagine that there would be any advantage in re-installing LabVIEW, unless it somehow elevated the application's security level; can you point me to what forum you were looking at? 

What about implementing something like this in LabVIEW? Basically, use the DLL from this example (or create your own) to impersonate a user security level, and then make the .NET calls. I don't know if this would address your issue, but might be worth digging into.

Regards,

[ferencr]

Hi Michael,

I don't remember where that was, and the page didn't contain much substance, so I did not save it.

I had already tried explicit impersation, yes, something like that. To make it easier for myself I created a C# DLL that impersonates before making calls to the Zemax API (setup c) below).

As I mentioned earlier, even if all DLL calls in a), b), and c) are identical:

a) C# application --> Zemax: no error

b) LabVIEW application --> Zemax: Cannot open anonymous level security token

c) LabVIEW application --> C# DLL --> Zemax: Cannot open anonymous level security token

Impersonation did not help. But I'll post the resulting exception printout, maybe you see something valuable in it.

Thank you,

Ferenc

windows identify before impersonation: _CENSORED_COMPUTER_NAME_\Ferenc
The impersonation level for the current user is : None
the user account is authenticated by the system

Main() windows identify after impersonation: _CENSORED_COMPUTER_NAME_\Ferenc
The impersonation level for the current user is : Impersonation
the user account is authenticated by the system
Found OpticStudio at: c:\program files\zemax opticstudio
Exception impersonating user: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Runtime.Remoting.RemotingException: An error occurred while processing the request on the server: System.Security.SecurityException: Cannot open an anonymous level security token.

   at System.Security.Principal.WindowsIdentity.GetCurrentInternal(TokenAccessLevels desiredAccess, Boolean threadOnly)
   at System.Security.Principal.WindowsIdentity.GetCurrent()
   at System.Runtime.Remoting.Channels.Ipc.IpcServerTransportSink.ServiceRequest(Object state)
The Zone of the assembly that failed was:
MyComputer

Server stack trace:
   at System.Runtime.Remoting.Channels.Ipc.IpcServerHandler.ReadToEndOfHeaders(BaseTransportHeaders headers)
   at System.Runtime.Remoting.Channels.Ipc.IpcClientHandler.ReadHeaders()
   at System.Runtime.Remoting.Channels.Ipc.IpcClientTransportSink.ProcessMessage(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream, ITransportHeaders& responseHeaders, Stream& responseStream)
   at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)

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 System.Runtime.Remoting.Activation.IActivator.Activate(IConstructionCallMessage msg)
   at System.Runtime.Remoting.Activation.LocalActivator.DoRemoteActivation(IConstructionCallMessage ctorMsg)
   at System.Runtime.Remoting.Activation.LocalActivator.Activate(IConstructionCallMessage ctorMsg)
   at System.Runtime.Remoting.Activation.AppDomainLevelActivator.Activate(IConstructionCallMessage ctorMsg)
   at System.Runtime.Remoting.Messaging.ClientContextTerminatorSink.SyncProcessMessage(IMessage reqMsg)
   at System.Runtime.Remoting.Activation.ActivationServices.Activate(RemotingProxy remProxy, IConstructionCallMessage ctorMsg)
   at System.Runtime.Remoting.Proxies.RemotingProxy.InternalActivate(IConstructionCallMessage ctorMsg)
   at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke(IMessage reqMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at ZemaxUI.Common.ViewModels.ZOSAPI_Application..ctor()
   --- End of inner exception stack trace ---
   at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)
   at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
   at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
   at System.Activator.CreateInstance(Type type, Boolean nonPublic)
   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes, StackCrawlMark& stackMark)
   at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at System.Activator.CreateInstance(Type type, Object[] args, Object[] activationAttributes)
   at ZOSAPI.ZOSAPI_Connection.CreateApp(ZOSAPI_Connection connection, Int32 processId, Boolean wrap, Object[] args)
   at ZOSAPI.ZOSAPI_Connection.ConnectToAppByProcess(Int32 processId, Boolean wrap)
   at ZOSAPI.ZOSAPI_Connection.CreateConnection(String exeName, Boolean wrap, String applicationName)
   at ZOSAPI.ZOSAPI_Connection.CreateNewApplication()
   at ImpersonatorZOSAPI.ImpersonatorZOSAPI.ZosApiOpenZemax() in C:\LV Dev\LVP3 - Lens Design\Zemax Interface test\ImpersonatorZOSAPI\ImpersonatorZOSAPI\ImpersonatorZOSAPI.cs:line 245
   at ImpersonatorZOSAPI.ImpersonatorZOSAPI.DoWorkUnderImpersonation() in C:\LV Dev\LVP3 - Lens Design\Zemax Interface test\ImpersonatorZOSAPI\ImpersonatorZOSAPI\ImpersonatorZOSAPI.cs:line 191

[the_mitten]

Hi Ferenc,

Interesting. Does this occur when trying to call any other .NET assemblies on the computer? 

Additionally, have you contacted Zemax about this issue? I don't mean to suggest that it is an issue with their software, but it would be helpful if we could get some perspective from their team about what the DLL is expecting, if they are knowledgeable of this occurring with any other program, etc. Especially if there is an issue with LabVIEW, we would need to be able to access the Zemax DLL in order to do testing to verify the behavior.

I will continue to check with my colleagues on my end to see what information I can gather, but due to the holidays any update will likely be a slower than usual.

Regards,

[ferencr]

Hi Michael,

Yes, I did contact Zemax at about the same time I started this thread.

From the API developer: "I can’t imagine why the security level would make a difference – we haven’t run in to a similar issue with any other environment.  Are they able to get their C# DLL working if it doesn’t call the API?  If so then I suspect the actual exception below is a red herring."

I agree with him that the actual description of the exception may be misleading. What I know from my experimentation is that when RegisterChannel (Channel, true) changes to RegisterChannel (Channel, false), the exception goes away and Windows allows LabVIEW to communicate through the remoting channel. For some reason LabVIEW (or even a C# dll called by LabVIEW) is unable to connect to the server with a secure remoting channel, but only with an unsecure one.

I haven't had any issues with other .NET assemblies on my computer, but then again maybe the ones I used don't require secure remoting channels.

I'll try on another computer as well, also on Windows 7 vs 10, and let you know how it goes.

Thank you,

Ferenc