CREATE ASSEMBLY for assembly 'MyProject' failed because assembly 'MyProject' is not authorized for PERMISSION_SET = EXTERNAL_ACCESS.
The assembly is authorized when either of the following is true:
the database owner (DBO) has EXTERNAL ACCESS ASSEMBLY permission and the database has the TRUSTWORTHY database property on;
or the assembly is signed with a certificate or an asymmetric key that has a corresponding login with EXTERNAL ACCESS ASSEMBLY permission.
If you have restored or attached this database, make sure the database owner is mapped to the correct login on this server. If not, use sp_changedbowner to fix the problem.

Before I go futher, let me redefine the different permissions sets for SQL CLR

• SAFE: This permissions set is applied by default if not specified otherwise, and SAFE is the most restrictive permission set. Code executed by an assembly with SAFE permissions cannot access external system resources such as files, the network, environment variables, or the registry.
• EXTERNAL_ACCESS: This permissions set enables assemblies to access certain external system resources such as files, networks, environmental variables, and the registry.
• UNSAFE: enables assemblies unrestricted access to resources, both within and outside an instance of SQL Server. Code running from within an UNSAFE assembly can call unmanaged code as well.

SAFE is highly recommended by Microsoft.

So basically you are getting the error because using EXTERNAL or UNSAFE allows code to do something outside the scope of what SQL can normally do, and therefore for security measures SQL blocks you from just going ahead and loading this onto the server.

There are two fixes to this. The first is to go to the database you will be deploying the CLR function to and running the command

ALTER DATABASE Databasename SET TRUSTWORTHY ON;

While this works, it also is not the right solution as this will enable your database to run any CLR that is deployed to it, making it easier for bad or unreviewed code to get onto the SQL Server (again – this is bad).

The correct solution is to make an Asymmetric Key for your CLR Function, create a user to use the key, and then Grant the permission set access for that user. To do this you do the following:

USE master
GO 
-- First Create the Asymmetric Key from the Assembly
CREATE ASYMMETRIC KEY SQLCLRUserKey
FROM EXECUTABLE FILE = 'C:\SQL CLR Functions\SQLCLR\bin\Release\SQLCLR.dll'
GO

You can change “SQLCLRUserKey” to whatever you would like the key name to be, and the path to the dll must be the path to your CLR functions output dll.

-- Create the Login from the Asymmetric Key
CREATE LOGIN SQLCLRUser FROM ASYMMETRIC KEY SQLCLRUserKey
GO

This creates the user based off the key we made in step 1. Again, “SQLCLRUser” can be whatever user name you want to use, and you just need to make sure “SQLCLRUserKey” matches whatever name you used for Step 1.

-- Grant the External Access Priviledge to the Login
GRANT EXTERNAL ACCESS ASSEMBLY TO SQLCLRUser
GO

This grants the permissions for this user to deploy SQL CLR Projects with EXTERNAL permission sets. In order to do UNSAFE just change the words “EXTERNAL ACCESS” to “UNSAFE”.

Last is

USE [MyDatabase]
GO
-- Add a database user in the SQLCLR_Net Database for the Login
CREATE USER SQLCLRUser FOR LOGIN SQLCLRUser
GO

Where “MyDatabase” is the name of the database where your CLR Project will be deployed. This creates the user mapping in that database.

After this, you should be able to deploy your project as normal, and by doing these steps you will just be granting permissions for the specified CLR Project instead of ANY CLR Project (much better don’t you think?)

Step 1: Creating a Key Container

In order to secure your web.config, you will first need to create a key container in order to hold the private keys for the encrypted material. This is done with the following command line

c:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -pc "MyConnectionStrings" -exp

where “MyConnectionStrings” is the name of the key container you wish to create. After creating a key container, you can now modify your web.config to support the encrypted sections.

Removing a key collection

At any point you can also remove a key collection, however doing this will mean that your web application will not be able to decrypt your connection strings anymore, and you will not be able to decrypt the connection strings file yourself for changes (see section 4.1).

The command to remove a key collection is

c:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -pz "MyConnectionStrings"

Step 2: Setting up the web.config

In order to let ASP.NET know about the encryption provider (a.k.a. – which private keys to use to read the encrypted data), you must add the following section into your web.config under the section.

<configProtectedData defaultProvider="MyProvider">
	<providers>
		<add name="MyDBProvider"
		type="System.Configuration.RsaProtectedConfigurationProvider, System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
		keyContainerName="MyConnectionStrings" cspProviderName=""
		useMachineContainer="true" useOAEP="false" />
	</providers>
</configProtectedData>

The key things to note are the defaultProvider=”MyProvider”, the name=”MyDBProvider” and the keyContainerName=”MyConnectionStrings”. The Provider name can be whatever you wish, and you may have multiple providers if you wish. The provider can be set in code on the ConnectionManager.ConnectionStrings().Provider, but if a default one is specified via the “defaultProvider” attribute, this does not need to be specified. Normally you would only use multiple providers if you want to have your connection strings split into multiple documents. Just as a note – other things can be encrypted in the web.config besides the connection strings section, in which case multiple providers may be useful as well. The keyContainerName MUST be the same name as the key container name you used in Step 1.

Step 3: Move connection strings into a different configuration file

Now that we have done this, we can encrypt our connection strings. Before we do this though, I would advise moving your connection strings out to an external file. The reason is a) All the connection strings will be kept separate from your web.config settings and b) The encryption tool parses and re-writes the web.config file, and if you have done any special formatting to make your web.config look nice, that formatting may be completely removed.

Doing this is rather simple, all you have to do is create another configuration file for your project (we will be using “ConnectionStrings.config” ) and moving your <connectionStrings> settings to that file. So before doing this you may have

Web.config

<configuration>
  ...
	<connectionStrings>
		<clear/>
		<add name="MyDBConn"
			connectionString="Data Source=MySQLSvr;Initial Catalog=AdventureWorks;User Id=MyUser;Password=MyPass;"
			providerName="System.Data.SqlClient" />
        </connectionStrings>
...
</configuration>

Now you will have
Web.config

<configuration>
...
        <connectionStrings configSource="ConnectionStrings.config"></connectionStrings>
...
</configuration>

ConnectionStrings.config

<connectionStrings>
	<clear/>
	<add name="MyDBConn"
		connectionString="Data Source=MySQLSvr;Initial Catalog=AdventureWorks;User Id=MyUser;Password=MyPass;"
		providerName="System.Data.SqlClient" />
        </connectionStrings>
</connectionStrings>

Step 4: Encrypting your connection strings

Next you need to encrypt the file where you are keeping the connection strings. This is done with the following command

c:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -pef "connectionStrings" "PATH"

Where “PATH” is the full path to the folder where your web.config is stored. i.e. “C:\inetpub\wwwroot”. It does not matter where the “connectionstrings.config” file is found as the web.config now has the file location of the connectionstrings.config in it, and the program will follow that path to the external file. The best idea is still to put the connectionstring.config file in the same directory as the web.config though. After doing this, you should be able to open the ConnectionStrings.config and see that the information has changed to some encrypted data.

Decrypting your connectionstrings.config

Should the need arise for some changes to come to your connectionstrings, you can simply decrypt the file by executing the command

c:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -pdf "connectionStrings" "PATH"

Step 5: Give ASP.NET access to the private key

The next command to run is to give the ASP.NET service access to the private key for it to be able to decipher the web.config file. By default the “NT Authority\Network Service” is the owner of the ASP.NET worker process, however this can be changed so you may need to grant the permissions to a different account instead. Giving access is done using the following commands:

c:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -pa "MyConnectionStrings" "NT Authority\Network Service"
c:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -pa "MyConnectionStrings" "ASPNET"

Again, the “MyConnectionStrings” MUST be the name of the key container that you named in Step 1. At this point your application should now have access to use the ConnectionStrings.config in it’s encrypted state.

Step 6: (Optional where applicable) Exporting the private keys to a different server

One final thing to note is that if you are running the application on some instance where the application will need to be run on multiple web servers with the same ConnectionStrings.config, you will need to export the private key container so that the same file can be used on different machines. This is accomplished via the following command

c:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -px "MyConnectionStrings" "C:\CustomKeys.xml" -pri

After copying the file over to the other server, you would run the command

c:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -pi "MyConnectionStrings" "C:\CustomKeys.xml"

to import the keys. I believe you will still need to redo Step 5 again in order to grant permissions.

Step 7: Accessing the connection strings within the web application

The first thing to do in order to access the connection strings is you will need to add a reference to the project to System.Configuration. Although you can access some classes and objects in System.Configuration without adding a reference, the ASP.NET 2.0 connection strings configuration manager (which we will need) is not part of them. Once you add the reference, you simply add

VB.NET

Dim MyConnStr As String = System.Configuration.ConfigurationManager.ConnectionStrings("MyDBConn").ConnectionString

C#

string MyConnStr = System.Configuration.ConfigurationManager.ConnectionStrings["MyDBConn"].ConnectionString

to access the connection string, where MyDBConn is the name you gave the connection string. Note that is you have multiple providers or the provider for the connection strings is not the same as the default provider, you will need to add

VB.NET

1
2
3

Dim DBConn As New System.Configuration.ConnectionStringSettings("MyDBConn")
DBConn.ProviderName = "MyProvider"
Dim MyConnStr As String = DBConn.ConnectionString

C#

1
2
3

System.Configuration.ConnectionStringSettings DBConn = new System.Configuration.ConnectionStringSettings["MyDBConn"];
DBConn.ProviderName = "MyProvider"
string MyConnStr = DBConn.ConnectionString

F.A.Q

Q: I would like to add/update/remove a connection string in the file and I’ve already encrypted the file, how do I do this? I have multiple web servers
A: If you just a single web server, all you need to do is , change it how you need, and then encrypt the file again. If you have multiple web servers, you will need to perform this on one of your servers, and then you can just copy that file to the other servers as the other servers will already have the key and know how to read the encrypted file.