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.