When you try to use an external component on client side (RunOnClient = Yes), then it can happen that get the following message “The Microsoft Dynamics NAV client needs permission to run xyz – an external component”:
The problem here is, that it is not possible to allow it for all future sessions. It is limited to the current client session, and will come up every time the user has restarted the client. This can be annoying for the end user.
There is a quick solution for this: set the key ServicePrincipleNameRequired in the ClientUserSettings.config to true:
<add key="ServicePrincipalNameRequired" value="True" />
The description of this key from the MSDN site http://msdn.microsoft.com/en-us/library/dd301077(v=nav.70).aspx:
If this parameter is set to true, then the client can only connect to a Microsoft Dynamics NAV Server instance that has been associated with a service principal name (SPN).
If this parameter is set to false, then the client attempts to connect to the configured Microsoft Dynamics NAV Server instance, regardless of whether that instance is associated with an SPN.
Default: false
You might wonder what this has to do with running an external component. The reason is that a NAV Server instance that has an associated SPN is considered to be trustworthy, and therefore external components are safe to use. At the other hand, the client will not be able to contact to a server that has no associated SPN. That might not be a problem in live situations when every part of the installation and configuration is done correctly, including SPN’s. But when SPN’s are missing you will not be able to use this option.
Remember that there are at two locations of the ClientUserSettings.config file:
During installation a default ClientUserSettings.config is installed in the location ‘C:\ProgramData\Microsoft\Microsoft Dynamics NAV\70’. This config file is used as a default config for any user that starts the client for the first time. At first time starting, a copy of this config file is made to the location ‘C:\Users\<username>\AppData\Roaming\Microsoft\Microsoft Dynamics NAV\70’.
If you want to configure the setting for all future users, then change the config file in the ProgramData folder. Otherwise change the config file in the Users Roaming folder.
By the way and not on topic: for Terminal Servers / Citrix Servers it is a good idea to change the default config file in the ProgramData folder before any user starts the NAV client. That will save a lot of time.
Great post! It was on my to-do list for a while to blog about this, because for some things I’ve been working on this became quite a pain. I hope to get time to post about a workaround I came up with, which has some limitations, but doesn’t require you to work with SPNs.
On another hand, I personally believe this setting to be a misdesign by Microsoft in solution of this problem. The primary reason why not allowing future sessions to benefit from your choice whether to trust a component or not is because of how .NET works – you declare a .NET variable by referencing an assembly and the version – both of which can be easily faked by a malicious developer who can later substitute your assembly with their own, which does whatever it might be that you don’t want to execute while thinking you are executing something else.
Now – while trusting the server instance through SPN is a good thing, whoever wants to infect your assembly (or replace it altogether with their own) can still do so – because there is no guarantee that the assembly at the run-time will match the one at design time, except for the namespace and class structure to be the same. Therefore, this only gives an impression of better security, but keeps a large security hole still open for potential attacks.
The only true solution to this issue would be to require strongly-signed assemblies, just as the client control add-ins do. Then, nobody can either tamper with, or substitute, your assemblies, and then a one-time-valid-for-the-future choice would be correct.
Hi Vjeko,
You are definitely right: NAV should not trust an assembly because of the server having an SPN, but because of being signed.
Luckily, NAV uses the public key token in the variable declaration. If available… Which makes it a choice of the developer to use it or not. En because NAV does not enforce the use of a signed assembly, it is still vulnerable, no matter if the server has an SPN or not.
So the conclusion is that developers always should use a signed assembly. And it would even be better if NAV enforces the use of it or, alternatively, only offer the always allow option for signed assemblies.
By the way: the software test in the CfMD process checks for external assemblies. If they are not strongly named and signed, then the CfMD test will fail. That’s a good step of course.
To be accurate you don’t need to set that flag to reject connections to the server if the SPN is broken. What you need is a line like this:
Notice the =Spn at the end rather that =NoSpn.
Once this line is in the config it’ll stop whining about the DotNET components (as long as the Spn is okay).
Of course the easiest way to add that line is to use the ServicePrincipleNameRequired item you described. But once the “Hint” is there you can remove the requirement tag.
(BTW: I agree this is a stupid way to authenticate the NAV server to the client)
GRRRRRRR,
Try this ….
>add key=”UnknownSpnHint” value=”(net.tcp://localhost:7046/dynamicsnav70/Service)=Spn;” /<
Pingback: NAV Client needs permission to run external component | Pardaan.com
Have you tested this when the service has the cerdential type set to username? I have the following keys set in the clientusersettings.config, but I still never get the option to always allow:
key=”ClientServicesCredentialType” value=”Username”
key=”AllowNtlm” value=”False”
key=”ServicePrincipalNameRequired” value=”True”
key=”UnknownSpnHint” value=”(net.tcp://localhost:7046/DynamicsNAV70/Service)=Spn;”
Seems to me like this only happens for local NAV server instances. I tested this with remote NAV server instances and the permission request never occurs. Furthermore, for local NAV server instances only the config needs to be true but the client doesn’t actually check if an SPN is set or not
Note that this only applies when the ClientServicesCredentialType is Windows. For the other ClientServicesCredentialTypes there no way to skip this message.
In NAV 2013 R2 there is nothing changed regarding this logic.
Pingback: ArcherPoint Dynamics Developer Digest - vol 136 - Microsoft Dynamics NAV Community
We still have a client on NAV2013R2 and this has bitten us. Now changing the value to true does fix it for the client sessions. But does anyone know how to fix it for the NAV web service calls? Meaning: something calls a NAV webservice which wants to use an external component which triggers the question. Which makes the webservice call error out.
Hi Alain,
This is a client side setting, to control the execution of controls on the NAV client rather than the server. That’s not possible with web services, because there is no NAV client involved at all.
I would redesign your code to not run any client side components during web service calls as this is simply not supported.
AJ
Not exactly what I wanted to hear. But I was afraid it wouldn’t have been possible. Thanks.