Request for the permission of type ‘SecurityPermission’ failed

When you get the following exception while executing a report on the SSRS or within Ax:

System.Security.SecurityException was unhandled
Message="Request for the permission of type
‘System.Security.Permissions.SecurityPermission, mscorlib, Version=,
Culture=neutral, PublicKeyToken=b77a5c561934e089′ failed.”

this is probably because the permission set in the config file of the SSRS – which you can normally find here (SQL 2005):

C:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportServer

is not configured correctly. The exception might be thrown for example because of the following line:


To resolve that problem you have to look for the PermissionSet that is defined for the assembly that caused the exception. In this case this is System.Security-assembly.

In the web.config you can find the link to the rssrvpolicy.config file

   1:      <securityPolicy>
   2:        <trustLevel name="RosettaSrv" policyFile="rssrvpolicy.config" />
   3:      </securityPolicy>

and in the rssrvpolicy.config the definition of the PermissionSets:

   1:            <NamedPermissionSets>
   2:              <PermissionSet class="NamedPermissionSet" version="1" Unrestricted="true" Name="FullTrust" Description="Allows full access to all resources" />
   3:              <PermissionSet class="NamedPermissionSet" version="1" Name="Nothing" Description="Denies all resources, including the right to execute" />
   4:              <PermissionSet class="NamedPermissionSet" version="1" Name="Execution">
   5:                <IPermission class="SecurityPermission" version="1" Flags="Execution" />
   6:              </PermissionSet>
   7:              <PermissionSet class="NamedPermissionSet" version="1" Name="AxSessionPermissionSet">
   8:                <IPermission class="AxSessionPermission" version="1" Unrestricted="true" />
   9:                <IPermission class="SecurityPermission" version="1" Flags="Assertion" />
  10:              </PermissionSet>
  11:            </NamedPermissionSets>

In the CodeGroup-section are defined:

   1:              <CodeGroup class="FirstMatchCodeGroup" version="1" PermissionSetName="Execution" Description="This code group grants MyComputer code Execution permission. ">
   2:                <IMembershipCondition class="ZoneMembershipCondition" version="1" Zone="MyComputer" />
   3:                <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust" Name="Microsoft_Strong_Name" Description="This code group grants code signed with the Microsoft strong name full trust. ">
   4:                  <IMembershipCondition class="StrongNameMembershipCondition" version="1" PublicKeyBlob="002400000480000094000000060200000024000052534131000400000100010007D1FA57C4AED9F0A32E84AA0FAEFD0DE9E8FD6AEC8F87FB03766C834C99921EB23BE79AD9D5DCC1DD9AD236132102900B723CF980957FC4E177108FC607774F29E8320E92EA05ECE4E821C0A5EFE8F1645C4C0C93C1AB99285D622CAA652C1DFAD63D745D6F2DE5F17E5EAF0FC4963D261C8A12436518206DC093344D5AD293" />
   5:                </CodeGroup>
   6:                <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust" Name="Ecma_Strong_Name" Description="This code group grants code signed with the ECMA strong name full trust. ">
   7:                  <IMembershipCondition class="StrongNameMembershipCondition" version="1" PublicKeyBlob="00000000000000000400000000000000" />
   8:                </CodeGroup>

The tool CasPol.exe (part of the .Net SDK) will help you to identify the CodeGroup that the System.Security assembly belongs to. In the GAC folder of this assembly I did a CasPol –rsg (resolvesGroup) on this assembly:


Now we can see that this assembly belongs to the Microsoft_Strong_Name (line 3 in the CodeGroup excerpt) and is configured for FullTrust. With the –rsp (resolvesPermissions) you can visualize all permissions that are granted to this assembly (as defined in the FullTrust named PermissionSet):


When the exception was raised, this assembly was configured to ‘Nothing’ (line 3 of the NamedPermissionSets excerpt). The problem was resolved by granting this assembly FullTrust.

You can find a good article about CAS (Code Access Security) for the SSRS on msdn here.

Comments (3)

  1. Hi ,

    Is it a good Idea to set the Full Trust for the assembly to run the reports, I too had a similar problem and I did FullTrust to my assembly?

    However, when we consider client scenarios, we dont have a control on the Installation done by them.

    I want to add some more to your inputs here, Setting FullTrust to the assembly enables you to achieve more out of SSRS and SSAS, for example here what I noticed:

    You can dynamically call MDX queries from you Business Logic of SSRS, thereby having more control over them to manipulate the data. We had a scenario in which we had to manipulate data in a matrix, and this approach helped me greatly.

    However, the solution was denied since it was playing around with the configuration.


  2. Michael says:

    How are you able to determine that the assembly belongs to "Microsoft_Strong_Name"?

    Also, how do you know the assembly was configured to "Nothing" when the exception was raised?

    Also, how do you go about granting an assembly "FullTrust"?

  3. John Hardin says:

    I agree with Michael – there at the end you go all hand-wavy.

    How do you determine that the assembly was configured to "nothing"? Line 3 in NamedPermissionSets just *defines* the "nothing" set. What indicates System.Security.dll is (or was) in _that_ set? Did caspol report something you haven't shown to us?

    All of my caspol output exactly matches your examples. It looks like the assembly is already granted FullTrust. Yet I am getting this error when I try to preview a report in VS2008.

Skip to main content