Dot Net Admin and DLL Security Levels

By | February 5, 2015

Today I will discuss one of the least discussed topic on Sage CRM communities. It has been a long time we are developing our customizations in .NET API. This API methodology is well into our blood now and over the time we have learned all Pro’s and Con’s of using it.

New Stuff : Download GUMU Sage ERP X3 integration compatible with the new Sage CRM v7.3

All the time we just create our API DLL’s and dump them in the CustomDotNet folder. It does start working. However did you ever wonder what does Security Level mean when we look at these DLL’s under .Net Admin? See below screen where the Security Level has been set to “Run in Sandbox”.

1

Now first of all let us understand what exactly this Security level is. This is nothing but the .Net trust level that has been assigned to your API DLL.

The level of trust that you assign to any assembly determines what system resources the assembly has access to. By default, trust is assigned to Managed assemblies based on the zone where the assembly is located. You can also assign trust to assemblies based on the URL, the publisher, the strong name, and many other factors. By using the Trust An Assembly wizard, you can change the trust level of an individual assembly.

The Trust levels that can be defined for your Dot net assembly are as follows.
1. Full
2. High
3. Low
4. None

 .Net Assembly trust levels can be changed using “.Net framework Configuration” or “caspol.exe” tool.  Follow below video to understand how you can change the trust level for your dot net assemblies.

Click Here to watch Video

The values that you will see in CRM are.
1. Run In Sandbox:

Using Sandbox running programs can be separated as Testing, Production versions. Sandbox is often used to execute untested code, or untrusted programs from unverified third-parties, suppliers and untrusted users. The sandbox typically provides a tightly-controlled set of resources for guest programs to run in, such as scratch space on disk and memory. Network access, the ability to inspect the host system or read from input devices are usually disallowed or heavily restricted. In this sense, sandboxes are a specific example of virtualization.

2. Fully trusted:

 If this trust level is assigned, your code is allowed to do anything in the framework, meaning that all (.Net) permissions are granted. “Full-trust” is a .NET term used to indicate that it’s not running in a reduced-privilege .NET sandbox. In .NET prior to 3.5 SP1, this included running from a network share (in the default configuration). It also includes running as a ClickOnce application that has not requested additional permissions, or in some other browser-based sandbox. Full-trust means it can do anything the user it is running as can do, not that is running as an administrator.

 So if you are very much sure that the code you are writing will not have any security impact, go ahead and add it to Full Trust level. This will save you from the permission errors on dot net assemblies.

Also Read:
1. Restrict access to Sage ERP X3 Integrated data using Security Matrix feature
2. Restrict Sage CRM user access to your Sage 100 ERP data with GUMU Security Matrix
3. IIS Security in Sage CRM v7.2
4. Inherit parent entity security settings on child
5. Enhanced Data Security – Restriction on Custom entity screen buttons