MSFTRSProdSamples Wiki & Documentation Rss Feed

Updated Wiki: SS2008R2!Security Extension Sample

sabottaca — Thu, 28 Feb 2013 23:52:49 GMT

Readme_Security Extension Sample

8/22/2011

This sample works only with SQL Server 2008 R2. It will not work with any version of SQL Server earlier than SQL Server 2008 R2.
The CustomSecurity sample security extension uses Forms Authentication along with SQL Server to provide a custom security model that works with Reporting Services. This sample is not supported on Itanium-based operating systems.

Before you begin:
If you plan to build the sample in Debug mode, you must comment out the following line of code. If you don't, the sample compiles without error, but the Report Manager page does not appear when you use the sample. System.Diagnostics.Debug.Assert(false, "Warning: userIdentity is null! Modify your code if you wish to support anonymous logon."); The line of code is in the GetUserInfo function in AuthenticationExtension.cs. public void GetUserInfo(out IIdentity userIdentity, out IntPtr userId) { if (HttpContext.Current != null && HttpContext.Current.User != null) { userIdentity = HttpContext.Current.User.Identity; } else { userIdentity = null; System.Diagnostics.Debug.Assert(false, "Warning: userIdentity is null! Modify your code if you wish to support anonymous logon."); throw new NullReferenceException("Anonymous logon is not configured. userIdentity should not be null!"); } userId = IntPtr.Zero; } This happens only when you build in Debug mode, you do not need to make this change if you build in Release mode. 02/28/2012 If you have more than one instance of reporting service, then the below code change is mandatory. Comment out the existing function "internal static string GetReportServerUrl(string machineName, string instanceName)" in the file "AuthenticationUtilities.cs". Next, copy and paste the below function code just below the commented out section in the "AuthenticationUtilities.cs**" file. This code will ensure that the correctly configured FBA instance URL's are picked up when performing a WMI lookup. internal static string GetReportServerUrl(string machineName, string instanceName) { string reportServerVirtualDirectory = String.Empty; string fullWmiNamespace = @"\\" + machineName + string.Format(wmiNamespace, instanceName); ManagementScope scope = null; ConnectionOptions connOptions = new ConnectionOptions(); connOptions.Authentication = AuthenticationLevel.PacketPrivacy; //Get management scope try { scope = new ManagementScope(fullWmiNamespace, connOptions); scope.Connect(); //Get management class ManagementPath path = new ManagementPath("MSReportServer_Instance"); ObjectGetOptions options = new ObjectGetOptions(); ManagementClass serverClass = new ManagementClass(scope, path, options); serverClass.Get(); if (serverClass == null) throw new Exception(string.Format(CultureInfo.InvariantCulture, CustomSecurity.WMIClassError)); //Get instances ManagementObjectCollection instances = serverClass.GetInstances(); foreach (ManagementObject instance in instances) { instance.Get(); //We're doing this comparison just to make sure we're validating the right instance. //This comparison is more reliable as we do the comparison on the instance name rather //than on any other property. if(instanceName.ToUpper().Equals("RS_" + instance.GetPropertyValue("InstanceName").ToString().ToUpper())) { ManagementBaseObject outParams = (ManagementBaseObject)instance.InvokeMethod("GetReportServerUrls", null, null); string[] appNames = (string[])outParams["ApplicationName"]; string[] urls = (string[])outParams["URLs"]; for (int i = 0; i < appNames.Length; i++) { if (appNames[i] == "ReportServerWebService") { reportServerVirtualDirectory = urls[i]; //Since we only look for ReportServer URL we can safely break here as it would save one more iteration. break; } } break; } } } catch (Exception ex) { throw new Exception(string.Format(CultureInfo.InvariantCulture, CustomSecurity.RSUrlError + ex.Message), ex); } if (reportServerVirtualDirectory == string.Empty) throw new Exception(string.Format(CultureInfo.InvariantCulture, CustomSecurity.MissingUrlReservation)); return reportServerVirtualDirectory + rsAsmx; }
Security Note:
The security extension sample should not be deployed and tested in a production environment. Reverting back to Windows Authentication after migrating to a different security extension is generally not recommended. If you do, you may experience errors when you attempt to access items in the report server database that have custom security descriptors, but no Windows Authentication security descriptors. To revert, you will have to reinstall Reporting Services and manually re-apply any role-based security for your Windows users. Before using this sample, you should back up your configuration files.

Important:
Samples are provided for educational purposes only. They are not intended to be used in a production environment and have not been tested in a production environment. Microsoft does not provide technical support for these samples. Sample applications and assemblies should not be connected to or used with your production SQL Server database or your report server without the permission of the system administrator. Microsoft does not provide technical support for these samples. Sample applications and assemblies should not be connected to or used with your production SQL Server database or your report server without the permission of the system administrator.

Important:

Samples are provided for educational purposes only. They are not intended to be used in a production environment and have not been tested in a production environment. Microsoft does not provide technical support for these samples. Sample applications and assemblies should not be connected to or used with your production SQL Server database or your report server without the permission of the system administrator. Microsoft does not provide technical support for these samples. Sample applications and assemblies should not be connected to or used with your production SQL Server database or your report server without the permission of the system administrator.

Requirements

You should be familiar with Visual Studio and either Visual C# or Visual Basic and you must have the following applications installed to run the CustomSecurity sample:

Microsoft Visual Studio 2008 or later.
Microsoft .NET Framework 2.0.
SQL Server 2008 R2 including Reporting Services and with SQL Server 2008 R2 CU3 or later applied.
Reporting Services samples.
A report server that you have permission to access on your network, if you plan to use the sample extension to add additional data processing functionality to your server.

Important:
SQL Server samples and sample databases must be downloaded and installed before you can view or work with them. For more information, see Considerations for Installing SQL Server Samples and Sample Databases.

Location

This sample is located by default at:
C:\Program Files\Microsoft SQL Server\100\Samples\Reporting Services\ Extension Samples\FormsAuthentication Sample

Building the Sample

You must first compile and install the extension. The procedure assumes that you have installed Reporting Services to the default location: C:\Program Files\Microsoft SQL Server\MSRS1050.MSSQLSERVER\Reporting Services. This location will be referred to throughout the remainder of this topic as <install_>.
If you have not already created a strong name key file, generate the key file using the following instructions.

To generate a strong name key file

Open a Microsoft Visual Studio prompt. Click Start, point to All Programs, point to Microsoft .NET Framework SDK 2.0, and then click SDK Command Prompt.-- or --Open a Microsoft .NET Framework command prompt. Click Start, point to All Programs, point to Microsoft .NET Framework SDK 2.0, and then click SDK Command Prompt.
Use the change directory command (CD) to change the current directory of the command prompt window to the folder where the samples are installed. Note: To determine the folder where samples are located, click the Start* button, point to All Programs, point to Microsoft SQL Server, point to Documentation and Tutorials, and then click Samples Directory. If the default installation location was used, the samples are located in <system_drive>:\Program Files\Microsoft SQL Server\100\Samples.*
At the command prompt, run the following command to generate the key file: sn -k SampleKey.snk Important: For more information about the strong-name key pair, see "Security Briefs: Strong Names and Security in the .NET Framework" in the .NET Development Center on MSDN.

To compile the sample using Visual Studio

Open CustomSecurity.sln in Microsoft Visual Studio. If you installed the sample to the default location, you can access it at C:\Program Files\Microsoft SQL Server\100\Samples\Reporting Services\Extensions.
In Solution Explorer, select the CustomSecurity project.
Look at the CustomSecurity project's references. If you do not see Microsoft.ReportingServices.Interfaces.dll, complete steps the following steps:
1. On the Project menu, click Add Reference. The Add References dialog box opens.
2. Click the .NET tab.
3. Click Browse, and find Microsoft.ReportingServices.Interfaces on your local drive. By default, the assembly is located in the <install>\ReportServer\bin directory. Click OK. The selected reference is added to your project.
On the Build menu, click Build Solution.

Deploying the Sample

After the sample is compiled, you must copy the DLLs and the ASPX pages to the appropriate subdirectories for your Report Server installation.

To deploy the sample

Copy Microsoft.Samples.ReportingServices.CustomSecurity.dll and Microsoft.Samples.ReportingServices.CustomSecurity.pdb to the <install>\ReportServer\bin directory.
Copy Microsoft.Samples.ReportingServices.CustomSecurity.dll and Microsoft.Samples.ReportingServices.CustomSecurity.pdb to the <install>\ReportManager\bin directory. If a PDB file is Not present, it was Not created by the Build step provided above. Ensure that the Project Properties for Debug/Build is set to generate PDB files.
Copy the Logon.aspx page to the <install>\ReportServer directory.
Copy the UILogon.aspx page to the <install>\ReportManager\Pages directory. After the assembly and logon pages are copied to the server, you need to make some modifications to the Report Server configuration file.

Important:
Make backup copies of all of your configuration files before making any changes. Backup and Restore Operations for a Reporting Services Installation can be looked up from MSDN. http://msdn.microsoft.com/en-us/library/ms155814.aspx is its current URL. Configuration Files (Reporting Services) can be reviewed to get detailed information about the various settings mentioned. Its current URL is http://msdn.microsoft.com/en-us/library/ms155866.aspx.

Important:

Make backup copies of all of your configuration files before making any changes. Backup and Restore Operations for a Reporting Services Installation can be looked up from MSDN. http://msdn.microsoft.com/en-us/library/ms155814.aspx is its current URL. Configuration Files (Reporting Services) can be reviewed to get detailed information about the various settings mentioned. Its current URL is http://msdn.microsoft.com/en-us/library/ms155866.aspx.

To modify the RSReportServer.config file

Open the RSReportServer.config file with Visual Studio or a simple text editor such as Notepad. RSReportServer.config is located in the <install>\ReportServer directory.
Locate the <AuthenticationTypes> element and modify the settings as follows:

Locate the <Security> and <Authentication> elements, within the <Extensions> element, and modify the settings as follows:

<Security>
<Extension Name="Forms"
Type="Microsoft.Samples.ReportingServices.CustomSecurity.Authorization,
Microsoft.Samples.ReportingServices.CustomSecurity" >
<Configuration>
<AdminConfiguration>
<UserName>username</UserName>
</AdminConfiguration>
</Configuration>
</Extension>
</Security>
<Authentication>
<Extension Name="Forms"
Type="Microsoft.Samples.ReportingServices.CustomSecurity.AuthenticationExtension,
Microsoft.Samples.ReportingServices.CustomSecurity" />
</Authentication> . For more information regarding .NET Framework security and Reporting Services, see Secure Development (Reporting Services).

Locate the <UI> element and update it as follows:

<UI>
<CustomAuthenticationUI>
<loginUrl>/Pages/UILogon.aspx</loginUrl>
<UseSSL>True</UseSSL>
</CustomAuthenticationUI>
<ReportServerUrl>http://<server>/ReportServer</ReportServerUrl>
</UI>

Note:
If you are running the sample security extension in a development environment that does not have a Secure Sockets Layer (SSL) certificate installed, you must change the value of the <UseSSL> element to False in the previous configuration entry. We recommend that you always use SSL when combining Reporting Services with Forms Authentication.

You will need to add a code group for your custom security extension that grants FullTrust permission for your extension. You do this by adding the code group to the RSSrvPolicy.config file.

To modify the RSSrvPolicy.config file

Open the RSSrvPolicy.config file located in the <install>\ReportServer directory.
Add the following <CodeGroup> element after the existing code group in the security policy file that has a URL membership of $CodeGen as indicated below and then add an entry as follows to RSSrvPolicy.config:

Note:
For simplicity, the Forms Authentication Sample is weak-named and requires a simple URL membership entry in the security policy files. In your production security extension implementation, you should create strong-named assemblies and use the strong name membership condition when adding security policies for your assembly. For more information about strong-named assemblies, see the Creating and Using Strong-Named Assemblies topic on MSDN.

Note:

For simplicity, the Forms Authentication Sample is weak-named and requires a simple URL membership entry in the security policy files. In your production security extension implementation, you should create strong-named assemblies and use the strong name membership condition when adding security policies for your assembly. For more information about strong-named assemblies, see the Creating and Using Strong-Named Assemblies topic on MSDN.

Next, you will need to increase the permissions for the "My Computer" code group in the Report Manager policy file.

To modify the RSMgrPolicy.config file

Open the Report Manager policy file, RSMgrPolicy.config, located in the <install>\ReportManager directory.
Locate the following code group in RSMgrPolicy.config and change the PermissionSetName attribute from Execution to FullTrust as follows:

<CodeGroup
class="FirstMatchCodeGroup"
version="1"
PermissionSetName="FullTrust"
Description="This code group grants MyComputer code Execution permission. ">
<IMembershipCondition
class="ZoneMembershipCondition"
version="1"
Zone="MyComputer" /> "}*To use Forms Authentication, you need to modify the Web.config files for Report Manager and Report Server.

To modify the Web.config file for Report Server

Open the Web.config file in a text editor. By default, the file is located in the <install>\ReportServer directory.
Locate the <identity> element and set the Impersonate attribute to false. * <identity impersonate="false" /> *
Locate the <authentication> element and change the Mode attribute to Forms.
Add the following <forms> element as a child of the <authentication> element and set the loginUrl, name, timeout, and path attributes as follows:

Add the following <authorization> element directly after the <authentication> element.

<authorization>
<deny users="?" />
</authorization>.

This will deny unauthenticated users the right to access the report server. The previously established loginUrl attribute of the <authentication> element will redirect unauthenticated requests to the Logon.aspx page.

To modify the Web.config file for Report Manager

Open the Web.config for Report Manager. It is located in the <install>\ReportManager directory.
Disable impersonation by locating the section <identity impersonate= "true" /> and changing it to the following: <identity impersonate="false" />.
Locate the <authentication> element and change the Mode attribute to Forms.
Add the following keys to the <appSettings> element.

Change the <Server Name> value to the name of the report server and the <Instance Name> value to the name of the instance the report server is associated with.

Note:
The <Instance Name> for a default instance is RS_MSSQLSERVER.

Creating the UserAccounts Database

The sample includes a database script, Createuserstore.sql, that enables you to set up a user store for the Forms sample in a SQL Server database.

To create the UserAccounts database

Open SQL Server Management Studio, and then connect to your local instance of SQL Server.
Locate the Createuserstore.sql SQL script file. The script file is contained within the sample project files.
Run the query to create the UserAccounts database.
Exit SQL Server Management Studio.

Testing the Sample

The following procedure tests the sample extension. You will register an administrator user, which adds the user name, password hash, and salt value to the users table in the UserAccounts database. It also will require you to enter that user name in the Report Server configuration file. You will then log on the same user to ensure the correct operation of the password verification routines as well as the proper loading of the extension assembly by the report server.

To test the sample

Restart the Reporting Services service by running the following commands at the command prompt: * net stop "SQL Server Reporting Services (<Instance Name>)"
net start "SQL Server Reporting Services (<Instance Name>)" *

Open Report Manager. You can do this from the Reporting Services program menu or by accessing the Reports virtual directory from your browser.
Enter a user name and password and click Register User to add the user to the accounts database.
Open the RSReportServer.config file. Locate the <Security> element and add the previously registered user name as follows:

Return to the UILogon.aspx page, re-enter the user name and password, and then click Logon. You should have access to Report Manager and the report server with no restrictions. The administrator user that you create has equivalent permissions on the report server to those of a built-in administrator account on the local computer. For the purpose of this sample, you can only have one user designated as an administrator. After you have a built-in administrator account, you can register additional users and assign them roles on the report server.

Note:
You should add your administrator user to the official System Administrator and Content Manager (root folder) roles of your report server. This prevents empty security descriptors from existing in the report server database. For more information about the System Administrator and Content Manager roles, see Using Predefined Roles.

Using the Web Service with Custom Security

You can use the Web service API with Forms Authentication just as you would with Windows Authentication. However, you must call LogonUser in your Web service code and pass the credentials of the current user. In addition, your Web service client will not have the benefit of automatic cookie management, which is provided by Internet Explorer or other Web browsers. You will have to extend the ReportingService2005 proxy class to include cookie management. This can be done by overriding the GetWebRequest and GetWebResponse methods of the Web service class.

Debugging the Sample Extension

Running the sample extension in the debugger is not only a great way to troubleshoot difficulties you may have, but it is also an effective way to step through the code and see the report server authentication and authorization process as it is happening.
The Microsoft .NET Framework provides several debugging tools that can help you analyze the sample code. The following procedure uses Visual Studio to debug the previous sample.

To debug the Forms Authentication sample code

Start Visual Studio and open CustomSecurity.sln on your test report server.
Open Internet Explorer and navigate to Report Manager while leaving the sample code open in Visual Studio.
Switch to Visual Studio and set some break points in the custom security extension project code.
With the extension project still the active window, from the Debug menu, click Process.The Processes dialog opens.
From the list of processes, select the Aspnet_wp.exe process (or W3wp.exe, if your application is deployed on IIS), and click Attach.
In the Attach to Process dialog, select the Common Language Runtime program type, and then click OK. For improved debugging performance, make sure that Native is not a selected program type.
When the sample runs, a logon form appears. Type the user credentials into the logon form and click the Logon button. Whenever your break points are encountered during processing, the debugger should stop execution at that point.
Step through your code using the F11 key. For more information about using Visual Studio for debugging, see your Visual Studio documentation.

Note:
Debugging this way requires a lot of resources and processor time. If you run into difficulties, close Visual Studio, reset IIS, and begin again by attaching the CustomSecurity solution to the ASP.NET worker process and logging on to Report Manager.

Removing the Sample Extension

While not generally recommended, it is possible to revert back to Windows Authentication after you have tried out the sample.

To revert to Windows security

Restore the following files from your backup copies: Web.config and RSReportServer.config. This should set the authentication and authorization methods for the report server to the default Windows security. This should also remove any entries you made for your extension in the Report Server configuration file.
After the configuration information is removed, your security extension is no longer available to the report server. You should not have to remove any security descriptors that were created while you were running the report server under the sample security extension. The report server automatically assigns the System Administrator role to the BUILTIN\Administrators group on the computer hosting the report server when Windows Authentication is enabled. However, you will have to manually re-apply any role-based security for your Windows users.

Note that reverting back to Windows Authentication after migrating to a different security extension is generally not recommended. If you do, you may experience errors when you attempt to access items in the report server database that have custom security descriptors, but no Windows Authentication security descriptors.

New Comment on "SS2008R2!Security Extension Sample"

SNTKAVIN — Thu, 17 Jan 2013 16:54:34 GMT

I am using SSRS R2 Ent edition I faced two issues but able to resolve them luckly, Issue 1: after implementing all changes as described in the readme documentaion, I tried to access both report manager and report server webservice... but I got blank pages Solution : <<Wookash comments helps here >> ================================================== When setting the <AuthenticationTypes> in rsreportserver.config, you must ensure that the RSWindowsExtendedProtectionLevel and RSWindowsExtendedProtectionScenario elements are preserved, or else you will see an error. Here's what the final <AuthenticationTypes> element should look like: <Authentication> <AuthenticationTypes> <Custom/> </AuthenticationTypes> <EnableAuthPersistence>true</EnableAuthPersistence> <RSWindowsExtendedProtectionLevel>Off</RSWindowsExtendedProtectionLevel> <RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario> </Authentication> ================================================== Issue 2: a) Report server webservice URL -- working fine with no issue b) Report Manager -- <Register> button works, but <Logon> button did not work.. Error : Invalid NameSpace , An error occurred while attempting to get the ReportServer Url Solution : "Dave Sell - msft"'s answer from the below forum, Thanks to "Dave Sell" http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/e90c853b-6018-41b0-9dd1-abd2ac872f16/ Steps ================================================== Steps to modify the MOF file to fix this issue: 1. Locate the existing MOF file (example: %ProgamFiles%\Microsoft SQL Server\MSRS10.SQL2008\Reporting Services\ReportServer\bin\reportingservices.mof would be the default location for a Reporting Services instance named SQL2008). 2. Copy this reportingservices.mof to reportingservicesalt.mof (or some other unique name). 3. Notepad reportingservicealt.mof 4. Choose edit->replace… 5. In the dialog, in the Find What: text box enter the modified instance name (for an RS instance named SQL2008, the modified instance name is RS_SQL2008), in the Replace with: text box enter the instance name unmodified (so for an RS instance named SQL2008, just enter SQL2008). 6. Press the Replace All button. 7. Save and close notepad. 8. From a command window at the same location as the results of step 1, type MOFCOMP REPORTINSERVICESALT.MOF (or whatever the name from step 2 was). Now the configuration tool should work with the following exception, if the RS instance name contains an underscore (_), a dollar sign ($) or a hash (#), then step 8 will fail and the user will need to re-install the Reporting Services instance with a name that does not include any of these three characters. ================================================== Thanks to contributors

New Comment on "SS2008R2!Security Extension Sample"

rajeshkumar1976 — Fri, 28 Dec 2012 05:47:47 GMT

I am getting this error, and I couldn't understand the method GetReportServerUrl. An error occurred while attempting to get the ReportServer Url. Invalid parameter . Could you provide any help?

New Comment on "SS2008!Security Extension Sample"

jeremainejohnson — Thu, 04 Oct 2012 15:29:22 GMT

I followed the steps and got to "Testing the Sample" and got stuck, when I access my report via thr URL i get "Service UnavailableHTTP Error 503. The service is unavailable." Any help will be appreciated. Thank you, Jeremaine

New Comment on "SS2008!Security Extension Sample"

SkylerTodd — Thu, 30 Aug 2012 15:55:54 GMT

When I attempted to install this sample on SSRS2008 NOT SSRS2008R2 I kept running into an issue... "Authorization ticket not received by LogonUser" and "Client found response content type of 'text/html; charset=utf-8', but expected 'text/xml'" To fix this I had to add a web reference to "http://<Server Name>/ReportServer/ReportService2005.asmx" and change proxy class in UILogon to extend my newly created web reference. "public class ReportServerProxy: ReportingServices2005.ReportingService2005" Also changed this line in AuthenticationUtiliteis private const string rsAsmx = @"/ReportService2010.asmx"; to private const string rsAsmx = @"/ReportService2005.asmx";. The issue is microsoft/codeplex has labeled the 2008r2 example as 2008... Hope this helps those who are still using 2008 instead of 2008r2

New Comment on "SS2008!AdventureWorks Sample Reports"

mshankar — Sun, 15 Jul 2012 12:53:02 GMT

Good Exmples

New Comment on "SS2008R2!Security Extension Sample"

wookash — Sun, 27 May 2012 00:42:47 GMT

If you'd like the sample to work with SQL Server 2012 Reporting Services, you will need to change the "v10" in the following line in AuthenticationUtilities.cs file to "v11" private const string wmiNamespace = @"\root\Microsoft\SqlServer\ReportServer\{0}\v10"; Final line will look like: private const string wmiNamespace = @"\root\Microsoft\SqlServer\ReportServer\{0}\v11";

New Comment on "SS2008R2!Security Extension Sample"

wookash — Sat, 26 May 2012 23:46:47 GMT

When setting the <AuthenticationTypes> in rsreportserver.config, you must ensure that the RSWindowsExtendedProtectionLevel and RSWindowsExtendedProtectionScenario elements are preserved, or else you will see an error. Here's what the final <AuthenticationTypes> element should look like: <Authentication> <AuthenticationTypes> <Custom/> </AuthenticationTypes> <EnableAuthPersistence>true</EnableAuthPersistence> <RSWindowsExtendedProtectionLevel>Off</RSWindowsExtendedProtectionLevel> <RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario> </Authentication>

New Comment on "SS2008R2!Security Extension Sample"

wookash — Sat, 26 May 2012 23:46:03 GMT

When setting the <AuthenticationTypes> in rsreportserver.config, you must ensure that the RSWindowsExtendedProtectionLevel and RSWindowsExtendedProtectionScenario elements are preserved, or else you will see an error. Here's what the final <AuthenticationTypes> element should look like: <Authentication> <AuthenticationTypes> <Custom/> </AuthenticationTypes> <EnableAuthPersistence>true</EnableAuthPersistence> </Authentication> <RSWindowsExtendedProtectionLevel>Off</RSWindowsExtendedProtectionLevel> <RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>

New Comment on "SS2005!Script Samples (Reporting Services)"

dg_to — Wed, 09 May 2012 21:18:44 GMT

The script samples did not install.

New Comment on "SS2008R2!AdventureWorks2008R2 Report Samples"

codeulike — Thu, 15 Mar 2012 01:11:28 GMT

SQL Server 2008 R2 Express with Advanced Services - I could not deploy the sample reports because Shared Datasets are not supported in SQL Server Reporting Services 2008 R2 Express edition. Got a series of errors like this when deploying from Bids: Deploying data set '/Datasets/EmployeeSalesDetail2008R2'. Error rsOperationNotSupported : The feature: "Shared dataset" is not supported in this edition of Reporting Services. Some of the reports did deploy however; presumably the ones that dont need shared datasets.

New Comment on "SS2008!AdventureWorks Sample Reports"

jdhin — Tue, 06 Mar 2012 01:02:20 GMT

Hi, I'm getting the following error on some tables when I try to deploy. Please advise on a fix. Error: [rsInvalidReportDefinition] The report definition is not valid. Details: The report definition has an invalid target namespace 'http://schemas.microsoft.com/sqlserver/reporting/2010/01/reportdefinition' which cannot be upgraded. C:\Program Files\Microsoft SQL Server\100\Samples\Reporting Services\Report Samples\AdventureWorks 2008R2 Sample Reports\AdventureWorks 2008R2\Employee_Sales_Summary_2008R2.rdl

New Comment on "SS2008R2!Security Extension Sample"

wly168 — Wed, 08 Feb 2012 15:57:53 GMT

The custom module may not be necessary as I suspect the already registered FormsAuthenticationModule may do the same thing.

New Comment on "SS2008R2!Security Extension Sample"

wly168 — Wed, 08 Feb 2012 12:18:39 GMT

The implementation is not capable of injecting a meaningful Identity into Http Context. This results in the throttle as governed by MaxActiveReqForOneUser being ineffectual. I fixed this problem in my implementation by creating a FormsAuthenticationTicket from the logon page. The following method is called by the code behind of the forms logon page on successful authentication. /// <summary> /// Generates the forms authentication ticket and put it in the response. /// </summary> /// <param name="userName">Name of the user.</param> private void GenerateFormsAuthenticationTicket(string userName) { FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket( 1, // version userName, // user name DateTime.Now, // creation DateTime.Now.AddMinutes(60), // Expiration true, // persistent ""); // User data // Now encrypt the ticket. string encryptedTicket = FormsAuthentication.Encrypt(authTicket); // Create a cookie and add the encrypted ticket to the cookie as data. HttpCookie authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket); //authCookie.Domain = FormsAuthentication.CookieDomain; // Add the cookie to the outgoing cookies collection. HttpContext.Current.Response.Cookies.Add(authCookie); } The second step is create a register an implementation of IHttpModule with the report manager. (You register the module in the web.config of the report manager.) This extracts the identity from the cookie and injects it into http context. The following code public class IdentityModule : IHttpModule { private static readonly ILog _log = LogManager.GetLogger(typeof(IdentityModule)); /// <summary> /// Gets the logger. /// </summary> /// <value>The log.</value> private static ILog Log { get { return _log; } } /// <summary> /// Initializes a module and prepares it to handle requests. /// </summary> /// <param name="context">An <see cref="T:System.Web.HttpApplication"/> that provides access to the methods, properties, and events common to all application objects within an ASP.NET application</param> public void Init(HttpApplication context) { context.AuthenticateRequest += new EventHandler(ExtractIdentity); } /// <summary> /// Disposes of the resources (other than memory) used by the module that implements <see cref="T:System.Web.IHttpModule"/>. /// </summary> public void Dispose() { } /// <summary> /// Extracts the identity from the cookie and asserts it into context. The identity cookie is generated at /// authentication time. Every successive call to the report manager results in this delegate beging called. /// </summary> /// <param name="sender">The sender.</param> /// <param name="args">The <see cref="System.EventArgs"/> instance containing the event data.</param> public void ExtractIdentity(object sender, EventArgs args) { // Extract the forms authentication cookie string cookieName = FormsAuthentication.FormsCookieName; HttpCookie authCookie = HttpContext.Current.Request.Cookies[cookieName]; if (null == authCookie) { Log.Debug("There is no authentication cookie."); return; } FormsAuthenticationTicket authTicket = null; try { authTicket = FormsAuthentication.Decrypt(authCookie.Value); } catch (Exception ex) { Log.Error("Problems decrypting authentication cookie.", ex); return; } if (null == authTicket) { Log.Debug("Cookie failed to decrypt.."); return; } FormsIdentity id = new FormsIdentity(authTicket); Log.Debug("Extracted forms identity : " + id.Name); // This principal will flow throughout the request lifecycle. GenericPrincipal principal = new GenericPrincipal(id, new string[0]); // Attach the new principal object to the current HttpContext object HttpContext.Current.User = principal; } }

New Comment on "Server Management Sample Reports"

DavidLean — Wed, 02 Nov 2011 00:33:39 GMT

As I can't change the text above. "Microsoft SQL Server "Katmai" Reporting Services" refers to SQL 2008. Katmai was its code name when in development.

New Comment on "SS2008!AdventureWorksOffline Report Samples"

xnasser — Sun, 09 Oct 2011 18:50:16 GMT

the file is missing Data_AddingCalculatedSeries

New Comment on "SS2008!Security Extension Sample"

bshaik — Tue, 04 Oct 2011 15:31:25 GMT

Hi , I have implemented Forms authentication for SSRS R2, i can get the users and assign permissions to site manager, then when i log in through with the normal user i get this message ui!ReportManager_0-1!1a44!10/04/2011-16:21:54:: e ERROR: System.Threading.ThreadAbortException: Thread was being aborted. at System.Threading.Thread.AbortInternal() at System.Threading.Thread.Abort(Object stateInfo) at System.Web.HttpResponse.End() at System.Web.HttpServerUtility.Transfer(String path, Boolean preserveForm) at Microsoft.ReportingServices.UI.ReportingPage.ShowErrorPage(String errMsg) webserver!ReportServer_0-2!1230!10/04/2011-16:22:16:: e ERROR: System.Exception: An error occurred while attempting to verify the user.Invalid attempt to read when no data is present. at Microsoft.Samples.ReportingServices.CustomSecurity.AuthenticationUtilities.VerifyPassword(String suppliedUserName, String suppliedPassword) at Microsoft.Samples.ReportingServices.CustomSecurity.AuthenticationExtension.LogonUser(String userName, String password, String authority) at Microsoft.ReportingServices.WebServer.RSCustomAuthentication.LogonUser(String userName, String password, String authority) at Microsoft.ReportingServices.WebServer.ReportingService2005Impl.LogonUser(String userName, String password, String authority) at Microsoft.ReportingServices.WebServer.ReportingService2010.LogonUser(String userName, String password, String authority) library!ReportServer_0-2!225c!10/04/2011-16:22:24:: Call to GetPermissionsAction(/). ui!ReportManager_0-1!23f0!10/04/2011-16:22:24:: e ERROR: Microsoft.ReportingServices.UI.FolderPage+InsufficientPermissionsToRoot: User '' does not have required permissions. Verify that sufficient permissions have been granted and Windows User Account Control (UAC) restrictions have been addressed. at Microsoft.ReportingServices.UI.FolderPage.Page_Init(Object sender, EventArgs e) at System.EventHandler.Invoke(Object sender, EventArgs e) at System.Web.UI.Control.OnInit(EventArgs e) at System.Web.UI.Page.OnInit(EventArgs e) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) library!ReportServer_0-2!225c!10/04/2011-16:22:24:: Call to GetSystemPermissionsAction(). ui!ReportManager_0-1!23f0!10/04/2011-16:22:24:: e ERROR: HTTP status code --> 500 can any one of you help please.

New Comment on "SS2008R2!Custom Report Item Sample"

Ucodia — Thu, 29 Sep 2011 16:00:14 GMT

Hello, I got it working properly in Visual Studio 2010 and on the report server. The problem is that I have no idea how to deploy this custom report item to make it available in Report Builder 3.0. I know we can also add custom report item to the Report Builde toolbox but I did not found any guidance for that. Any clue? Thanks.

Updated Wiki: SS2008R2!Security Extension Sample

mariwill — Thu, 22 Sep 2011 20:01:23 GMT

Readme_Security Extension Sample

Before you begin:
If you plan to build the sample in Debug mode, you must comment the following line of code. If you don't, the sample compiles without error, but the Report Manager page does not show when you use the sample. System.Diagnostics.Debug.Assert(false, "Warning: userIdentity is null! Modify your code if you wish to support anonymous logon."); The code is in GetUserInfo function in AuthenticationExtension.cs. public void GetUserInfo(out IIdentity userIdentity, out IntPtr userId) { if (HttpContext.Current != null && HttpContext.Current.User != null) { userIdentity = HttpContext.Current.User.Identity; } else { userIdentity = null; System.Diagnostics.Debug.Assert(false, "Warning: userIdentity is null! Modify your code if you wish to support anonymous logon."); throw new NullReferenceException("Anonymous logon is not configured. userIdentity should not be null!"); } userId = IntPtr.Zero; } This happens only when you build in Debug mode, you do not need to make this change if you build in Release mode.
Security Note:
The security extension sample should not be deployed and tested in a production environment. Reverting back to Windows Authentication after migrating to a different security extension is generally not recommended. If you do, you may experience errors when you attempt to access items in the report server database that have custom security descriptors, but no Windows Authentication security descriptors. To revert, you will have to reinstall Reporting Services and manually re-apply any role-based security for your Windows users. Before using this sample, you should back up your configuration files.

Important:
Samples are provided for educational purposes only. They are not intended to be used in a production environment and have not been tested in a production environment. Microsoft does not provide technical support for these samples. Sample applications and assemblies should not be connected to or used with your production SQL Server database or your report server without the permission of the system administrator. Microsoft does not provide technical support for these samples. Sample applications and assemblies should not be connected to or used with your production SQL Server database or your report server without the permission of the system administrator.

Important:

Requirements

You should be familiar with Visual Studio and either Visual C# or Visual Basic and you must have the following applications installed to run the CustomSecurity sample:

Microsoft Visual Studio 2008 or later.
Microsoft .NET Framework 2.0.
SQL Server 2008 R2 including Reporting Services and with SQL Server 2008 R2 CU3 or later applied.
Reporting Services samples.
A report server that you have permission to access on your network, if you plan to use the sample extension to add additional data processing functionality to your server.

Important:
SQL Server samples and sample databases must be downloaded and installed before you can view or work with them. For more information, see Considerations for Installing SQL Server Samples and Sample Databases.

Location

This sample is located by default at:
C:\Program Files\Microsoft SQL Server\100\Samples\Reporting Services\ Extension Samples\FormsAuthentication Sample

Building the Sample

To generate a strong name key file

Open a Microsoft Visual Studio prompt. Click Start, point to All Programs, point to Microsoft .NET Framework SDK 2.0, and then click SDK Command Prompt.-- or --Open a Microsoft .NET Framework command prompt. Click Start, point to All Programs, point to Microsoft .NET Framework SDK 2.0, and then click SDK Command Prompt.
Use the change directory command (CD) to change the current directory of the command prompt window to the folder where the samples are installed. Note: To determine the folder where samples are located, click the Start* button, point to All Programs, point to Microsoft SQL Server, point to Documentation and Tutorials, and then click Samples Directory. If the default installation location was used, the samples are located in <system_drive>:\Program Files\Microsoft SQL Server\100\Samples.*
At the command prompt, run the following command to generate the key file: sn -k SampleKey.snk Important: For more information about the strong-name key pair, see "Security Briefs: Strong Names and Security in the .NET Framework" in the .NET Development Center on MSDN.

To compile the sample using Visual Studio

Open CustomSecurity.sln in Microsoft Visual Studio. If you installed the sample to the default location, you can access it at C:\Program Files\Microsoft SQL Server\100\Samples\Reporting Services\Extensions.
In Solution Explorer, select the CustomSecurity project.
Look at the CustomSecurity project's references. If you do not see Microsoft.ReportingServices.Interfaces.dll, complete steps the following steps:
1. On the Project menu, click Add Reference. The Add References dialog box opens.
2. Click the .NET tab.
3. Click Browse, and find Microsoft.ReportingServices.Interfaces on your local drive. By default, the assembly is located in the <install>\ReportServer\bin directory. Click OK. The selected reference is added to your project.
On the Build menu, click Build Solution.

Deploying the Sample

After the sample is compiled, you must copy the DLLs and the ASPX pages to the appropriate subdirectories for your Report Server installation.

To deploy the sample

Copy Microsoft.Samples.ReportingServices.CustomSecurity.dll and Microsoft.Samples.ReportingServices.CustomSecurity.pdb to the <install>\ReportServer\bin directory.
Copy Microsoft.Samples.ReportingServices.CustomSecurity.dll and Microsoft.Samples.ReportingServices.CustomSecurity.pdb to the <install>\ReportManager\bin directory. If a PDB file is Not present, it was Not created by the Build step provided above. Ensure that the Project Properties for Debug/Build is set to generate PDB files.
Copy the Logon.aspx page to the <install>\ReportServer directory.
Copy the UILogon.aspx page to the <install>\ReportManager\Pages directory. After the assembly and logon pages are copied to the server, you need to make some modifications to the Report Server configuration file.

Important:
Make backup copies of all of your configuration files before making any changes. Backup and Restore Operations for a Reporting Services Installation can be looked up from MSDN. http://msdn.microsoft.com/en-us/library/ms155814.aspx is its current URL. Configuration Files (Reporting Services) can be reviewed to get detailed information about the various settings mentioned. Its current URL is http://msdn.microsoft.com/en-us/library/ms155866.aspx.

Important:

To modify the RSReportServer.config file

Open the RSReportServer.config file with Visual Studio or a simple text editor such as Notepad. RSReportServer.config is located in the <install>\ReportServer directory.
Locate the <AuthenticationTypes> element and modify the settings as follows:

Locate the <Security> and <Authentication> elements, within the <Extensions> element, and modify the settings as follows:

Locate the <UI> element and update it as follows:

<UI>
<CustomAuthenticationUI>
<loginUrl>/Pages/UILogon.aspx</loginUrl>
<UseSSL>True</UseSSL>
</CustomAuthenticationUI>
<ReportServerUrl>http://<server>/ReportServer</ReportServerUrl>
</UI>

Note:
If you are running the sample security extension in a development environment that does not have a Secure Sockets Layer (SSL) certificate installed, you must change the value of the <UseSSL> element to False in the previous configuration entry. We recommend that you always use SSL when combining Reporting Services with Forms Authentication.

You will need to add a code group for your custom security extension that grants FullTrust permission for your extension. You do this by adding the code group to the RSSrvPolicy.config file.

To modify the RSSrvPolicy.config file

Open the RSSrvPolicy.config file located in the <install>\ReportServer directory.
Add the following <CodeGroup> element after the existing code group in the security policy file that has a URL membership of $CodeGen as indicated below and then add an entry as follows to RSSrvPolicy.config:

Note:
For simplicity, the Forms Authentication Sample is weak-named and requires a simple URL membership entry in the security policy files. In your production security extension implementation, you should create strong-named assemblies and use the strong name membership condition when adding security policies for your assembly. For more information about strong-named assemblies, see the Creating and Using Strong-Named Assemblies topic on MSDN.

Note:

Next, you will need to increase the permissions for the "My Computer" code group in the Report Manager policy file.

To modify the RSMgrPolicy.config file

Open the Report Manager policy file, RSMgrPolicy.config, located in the <install>\ReportManager directory.
Locate the following code group in RSMgrPolicy.config and change the PermissionSetName attribute from Execution to FullTrust as follows:

To modify the Web.config file for Report Server

Open the Web.config file in a text editor. By default, the file is located in the <install>\ReportServer directory.
Locate the <identity> element and set the Impersonate attribute to false. * <identity impersonate="false" /> *
Locate the <authentication> element and change the Mode attribute to Forms.
Add the following <forms> element as a child of the <authentication> element and set the loginUrl, name, timeout, and path attributes as follows:

Add the following <authorization> element directly after the <authentication> element.

To modify the Web.config file for Report Manager

Open the Web.config for Report Manager. It is located in the <install>\ReportManager directory.
Disable impersonation by locating the section <identity impersonate= "true" /> and changing it to the following: <identity impersonate="false" />.
Locate the <authentication> element and change the Mode attribute to Forms.
Add the following keys to the <appSettings> element.

Change the <Server Name> value to the name of the report server and the <Instance Name> value to the name of the instance the report server is associated with.

Note:
The <Instance Name> for a default instance is RS_MSSQLSERVER.

Creating the UserAccounts Database

The sample includes a database script, Createuserstore.sql, that enables you to set up a user store for the Forms sample in a SQL Server database.

To create the UserAccounts database

Open SQL Server Management Studio, and then connect to your local instance of SQL Server.
Locate the Createuserstore.sql SQL script file. The script file is contained within the sample project files.
Run the query to create the UserAccounts database.
Exit SQL Server Management Studio.

Testing the Sample

To test the sample

Open Report Manager. You can do this from the Reporting Services program menu or by accessing the Reports virtual directory from your browser.
Enter a user name and password and click Register User to add the user to the accounts database.
Open the RSReportServer.config file. Locate the <Security> element and add the previously registered user name as follows:

Return to the UILogon.aspx page, re-enter the user name and password, and then click Logon. You should have access to Report Manager and the report server with no restrictions. The administrator user that you create has equivalent permissions on the report server to those of a built-in administrator account on the local computer. For the purpose of this sample, you can only have one user designated as an administrator. After you have a built-in administrator account, you can register additional users and assign them roles on the report server.

Note:
You should add your administrator user to the official System Administrator and Content Manager (root folder) roles of your report server. This prevents empty security descriptors from existing in the report server database. For more information about the System Administrator and Content Manager roles, see Using Predefined Roles.

Using the Web Service with Custom Security

Debugging the Sample Extension

To debug the Forms Authentication sample code

Start Visual Studio and open CustomSecurity.sln on your test report server.
Open Internet Explorer and navigate to Report Manager while leaving the sample code open in Visual Studio.
Switch to Visual Studio and set some break points in the custom security extension project code.
With the extension project still the active window, from the Debug menu, click Process.The Processes dialog opens.
From the list of processes, select the Aspnet_wp.exe process (or W3wp.exe, if your application is deployed on IIS), and click Attach.
In the Attach to Process dialog, select the Common Language Runtime program type, and then click OK. For improved debugging performance, make sure that Native is not a selected program type.
When the sample runs, a logon form appears. Type the user credentials into the logon form and click the Logon button. Whenever your break points are encountered during processing, the debugger should stop execution at that point.
Step through your code using the F11 key. For more information about using Visual Studio for debugging, see your Visual Studio documentation.

Note:
Debugging this way requires a lot of resources and processor time. If you run into difficulties, close Visual Studio, reset IIS, and begin again by attaching the CustomSecurity solution to the ASP.NET worker process and logging on to Report Manager.

Removing the Sample Extension

While not generally recommended, it is possible to revert back to Windows Authentication after you have tried out the sample.

To revert to Windows security

Restore the following files from your backup copies: Web.config and RSReportServer.config. This should set the authentication and authorization methods for the report server to the default Windows security. This should also remove any entries you made for your extension in the Report Server configuration file.
After the configuration information is removed, your security extension is no longer available to the report server. You should not have to remove any security descriptors that were created while you were running the report server under the sample security extension. The report server automatically assigns the System Administrator role to the BUILTIN\Administrators group on the computer hosting the report server when Windows Authentication is enabled. However, you will have to manually re-apply any role-based security for your Windows users.

Updated Wiki: SS2008R2!Security Extension Sample

mariwill — Thu, 22 Sep 2011 19:55:18 GMT

Readme_Security Extension Sample

Before you begin:
If you plan to build the sample in Debug mode, you must comment the following line of code. If you don't, the sample compiles without error, but the Report Manager page does not show when you use the sample. System.Diagnostics.Debug.Assert(false, "Warning: userIdentity is null! Modify your code if you wish to support anonymous logon."); The code is in GetUserInfo function in AuthenticationExtension.cs. public void GetUserInfo(out IIdentity userIdentity, out IntPtr userId) { if (HttpContext.Current != null && HttpContext.Current.User != null) { userIdentity = HttpContext.Current.User.Identity; } else { userIdentity = null; System.Diagnostics.Debug.Assert(false, "Warning: userIdentity is null! Modify your code if you wish to support anonymous logon."); throw new NullReferenceException("Anonymous logon is not configured. userIdentity should not be null!"); } userId = IntPtr.Zero; } This happens only when you build in Debug mode, you do not need to make this change if you build in Release mode. \|
Security Note:
The security extension sample should not be deployed and tested in a production environment. Reverting back to Windows Authentication after migrating to a different security extension is generally not recommended. If you do, you may experience errors when you attempt to access items in the report server database that have custom security descriptors, but no Windows Authentication security descriptors. To revert, you will have to reinstall Reporting Services and manually re-apply any role-based security for your Windows users. Before using this sample, you should back up your configuration files.

Important:
Samples are provided for educational purposes only. They are not intended to be used in a production environment and have not been tested in a production environment. Microsoft does not provide technical support for these samples. Sample applications and assemblies should not be connected to or used with your production SQL Server database or your report server without the permission of the system administrator. Microsoft does not provide technical support for these samples. Sample applications and assemblies should not be connected to or used with your production SQL Server database or your report server without the permission of the system administrator.

Important:

Requirements

You should be familiar with Visual Studio and either Visual C# or Visual Basic and you must have the following applications installed to run the CustomSecurity sample:

Microsoft Visual Studio 2008 or later.
Microsoft .NET Framework 2.0.
SQL Server 2008 R2 including Reporting Services and with SQL Server 2008 R2 CU3 or later applied.
Reporting Services samples.
A report server that you have permission to access on your network, if you plan to use the sample extension to add additional data processing functionality to your server.

Important:
SQL Server samples and sample databases must be downloaded and installed before you can view or work with them. For more information, see Considerations for Installing SQL Server Samples and Sample Databases.

Location

This sample is located by default at:
C:\Program Files\Microsoft SQL Server\100\Samples\Reporting Services\ Extension Samples\FormsAuthentication Sample

Building the Sample

To generate a strong name key file

Open a Microsoft Visual Studio prompt. Click Start, point to All Programs, point to Microsoft .NET Framework SDK 2.0, and then click SDK Command Prompt.-- or --Open a Microsoft .NET Framework command prompt. Click Start, point to All Programs, point to Microsoft .NET Framework SDK 2.0, and then click SDK Command Prompt.
Use the change directory command (CD) to change the current directory of the command prompt window to the folder where the samples are installed. Note: To determine the folder where samples are located, click the Start* button, point to All Programs, point to Microsoft SQL Server, point to Documentation and Tutorials, and then click Samples Directory. If the default installation location was used, the samples are located in <system_drive>:\Program Files\Microsoft SQL Server\100\Samples.*
At the command prompt, run the following command to generate the key file: sn -k SampleKey.snk Important: For more information about the strong-name key pair, see "Security Briefs: Strong Names and Security in the .NET Framework" in the .NET Development Center on MSDN.

To compile the sample using Visual Studio

Open CustomSecurity.sln in Microsoft Visual Studio. If you installed the sample to the default location, you can access it at C:\Program Files\Microsoft SQL Server\100\Samples\Reporting Services\Extensions.
In Solution Explorer, select the CustomSecurity project.
Look at the CustomSecurity project's references. If you do not see Microsoft.ReportingServices.Interfaces.dll, complete steps the following steps:
1. On the Project menu, click Add Reference. The Add References dialog box opens.
2. Click the .NET tab.
3. Click Browse, and find Microsoft.ReportingServices.Interfaces on your local drive. By default, the assembly is located in the <install>\ReportServer\bin directory. Click OK. The selected reference is added to your project.
On the Build menu, click Build Solution.

Deploying the Sample

After the sample is compiled, you must copy the DLLs and the ASPX pages to the appropriate subdirectories for your Report Server installation.

To deploy the sample

Copy Microsoft.Samples.ReportingServices.CustomSecurity.dll and Microsoft.Samples.ReportingServices.CustomSecurity.pdb to the <install>\ReportServer\bin directory.
Copy Microsoft.Samples.ReportingServices.CustomSecurity.dll and Microsoft.Samples.ReportingServices.CustomSecurity.pdb to the <install>\ReportManager\bin directory. If a PDB file is Not present, it was Not created by the Build step provided above. Ensure that the Project Properties for Debug/Build is set to generate PDB files.
Copy the Logon.aspx page to the <install>\ReportServer directory.
Copy the UILogon.aspx page to the <install>\ReportManager\Pages directory. After the assembly and logon pages are copied to the server, you need to make some modifications to the Report Server configuration file.

Important:
Make backup copies of all of your configuration files before making any changes. Backup and Restore Operations for a Reporting Services Installation can be looked up from MSDN. http://msdn.microsoft.com/en-us/library/ms155814.aspx is its current URL. Configuration Files (Reporting Services) can be reviewed to get detailed information about the various settings mentioned. Its current URL is http://msdn.microsoft.com/en-us/library/ms155866.aspx.

Important:

To modify the RSReportServer.config file

Open the RSReportServer.config file with Visual Studio or a simple text editor such as Notepad. RSReportServer.config is located in the <install>\ReportServer directory.
Locate the <AuthenticationTypes> element and modify the settings as follows:

Locate the <Security> and <Authentication> elements, within the <Extensions> element, and modify the settings as follows:

Locate the <UI> element and update it as follows:

<UI>
<CustomAuthenticationUI>
<loginUrl>/Pages/UILogon.aspx</loginUrl>
<UseSSL>True</UseSSL>
</CustomAuthenticationUI>
<ReportServerUrl>http://<server>/ReportServer</ReportServerUrl>
</UI>

Note:
If you are running the sample security extension in a development environment that does not have a Secure Sockets Layer (SSL) certificate installed, you must change the value of the <UseSSL> element to False in the previous configuration entry. We recommend that you always use SSL when combining Reporting Services with Forms Authentication.

You will need to add a code group for your custom security extension that grants FullTrust permission for your extension. You do this by adding the code group to the RSSrvPolicy.config file.

To modify the RSSrvPolicy.config file

Open the RSSrvPolicy.config file located in the <install>\ReportServer directory.
Add the following <CodeGroup> element after the existing code group in the security policy file that has a URL membership of $CodeGen as indicated below and then add an entry as follows to RSSrvPolicy.config:

Note:
For simplicity, the Forms Authentication Sample is weak-named and requires a simple URL membership entry in the security policy files. In your production security extension implementation, you should create strong-named assemblies and use the strong name membership condition when adding security policies for your assembly. For more information about strong-named assemblies, see the Creating and Using Strong-Named Assemblies topic on MSDN.

Note:

Next, you will need to increase the permissions for the "My Computer" code group in the Report Manager policy file.

To modify the RSMgrPolicy.config file

Open the Report Manager policy file, RSMgrPolicy.config, located in the <install>\ReportManager directory.
Locate the following code group in RSMgrPolicy.config and change the PermissionSetName attribute from Execution to FullTrust as follows:

To modify the Web.config file for Report Server

Open the Web.config file in a text editor. By default, the file is located in the <install>\ReportServer directory.
Locate the <identity> element and set the Impersonate attribute to false. * <identity impersonate="false" /> *
Locate the <authentication> element and change the Mode attribute to Forms.
Add the following <forms> element as a child of the <authentication> element and set the loginUrl, name, timeout, and path attributes as follows:

Add the following <authorization> element directly after the <authentication> element.

To modify the Web.config file for Report Manager

Open the Web.config for Report Manager. It is located in the <install>\ReportManager directory.
Disable impersonation by locating the section <identity impersonate= "true" /> and changing it to the following: <identity impersonate="false" />.
Locate the <authentication> element and change the Mode attribute to Forms.
Add the following keys to the <appSettings> element.

Change the <Server Name> value to the name of the report server and the <Instance Name> value to the name of the instance the report server is associated with.

Note:
The <Instance Name> for a default instance is RS_MSSQLSERVER.

Creating the UserAccounts Database

The sample includes a database script, Createuserstore.sql, that enables you to set up a user store for the Forms sample in a SQL Server database.

To create the UserAccounts database

Open SQL Server Management Studio, and then connect to your local instance of SQL Server.
Locate the Createuserstore.sql SQL script file. The script file is contained within the sample project files.
Run the query to create the UserAccounts database.
Exit SQL Server Management Studio.

Testing the Sample

To test the sample

Open Report Manager. You can do this from the Reporting Services program menu or by accessing the Reports virtual directory from your browser.
Enter a user name and password and click Register User to add the user to the accounts database.
Open the RSReportServer.config file. Locate the <Security> element and add the previously registered user name as follows:

Return to the UILogon.aspx page, re-enter the user name and password, and then click Logon. You should have access to Report Manager and the report server with no restrictions. The administrator user that you create has equivalent permissions on the report server to those of a built-in administrator account on the local computer. For the purpose of this sample, you can only have one user designated as an administrator. After you have a built-in administrator account, you can register additional users and assign them roles on the report server.

Note:
You should add your administrator user to the official System Administrator and Content Manager (root folder) roles of your report server. This prevents empty security descriptors from existing in the report server database. For more information about the System Administrator and Content Manager roles, see Using Predefined Roles.

Using the Web Service with Custom Security

Debugging the Sample Extension

To debug the Forms Authentication sample code

Start Visual Studio and open CustomSecurity.sln on your test report server.
Open Internet Explorer and navigate to Report Manager while leaving the sample code open in Visual Studio.
Switch to Visual Studio and set some break points in the custom security extension project code.
With the extension project still the active window, from the Debug menu, click Process.The Processes dialog opens.
From the list of processes, select the Aspnet_wp.exe process (or W3wp.exe, if your application is deployed on IIS), and click Attach.
In the Attach to Process dialog, select the Common Language Runtime program type, and then click OK. For improved debugging performance, make sure that Native is not a selected program type.
When the sample runs, a logon form appears. Type the user credentials into the logon form and click the Logon button. Whenever your break points are encountered during processing, the debugger should stop execution at that point.
Step through your code using the F11 key. For more information about using Visual Studio for debugging, see your Visual Studio documentation.

Note:
Debugging this way requires a lot of resources and processor time. If you run into difficulties, close Visual Studio, reset IIS, and begin again by attaching the CustomSecurity solution to the ASP.NET worker process and logging on to Report Manager.

Removing the Sample Extension

While not generally recommended, it is possible to revert back to Windows Authentication after you have tried out the sample.

To revert to Windows security

Restore the following files from your backup copies: Web.config and RSReportServer.config. This should set the authentication and authorization methods for the report server to the default Windows security. This should also remove any entries you made for your extension in the Report Server configuration file.
After the configuration information is removed, your security extension is no longer available to the report server. You should not have to remove any security descriptors that were created while you were running the report server under the sample security extension. The report server automatically assigns the System Administrator role to the BUILTIN\Administrators group on the computer hosting the report server when Windows Authentication is enabled. However, you will have to manually re-apply any role-based security for your Windows users.

MSFTRSProdSamples Wiki & Documentation Rss Feed

Updated Wiki: SS2008R2!Security Extension Sample

Readme_Security Extension Sample

Requirements

Location

Building the Sample

To generate a strong name key file

To compile the sample using Visual Studio

Deploying the Sample

To deploy the sample

To modify the RSReportServer.config file

To modify the RSSrvPolicy.config file

To modify the RSMgrPolicy.config file

To modify the Web.config file for Report Server

To modify the Web.config file for Report Manager

Creating the UserAccounts Database

To create the UserAccounts database

Testing the Sample

To test the sample

Using the Web Service with Custom Security

Debugging the Sample Extension

To debug the Forms Authentication sample code

Removing the Sample Extension

To revert to Windows security

See Also

Tasks

Other Resources

Help and Information

New Comment on "SS2008R2!Security Extension Sample"

New Comment on "SS2008R2!Security Extension Sample"

New Comment on "SS2008!Security Extension Sample"

New Comment on "SS2008!Security Extension Sample"

New Comment on "SS2008!AdventureWorks Sample Reports"

New Comment on "SS2008R2!Security Extension Sample"

New Comment on "SS2008R2!Security Extension Sample"

New Comment on "SS2008R2!Security Extension Sample"

New Comment on "SS2005!Script Samples (Reporting Services)"

New Comment on "SS2008R2!AdventureWorks2008R2 Report Samples"

New Comment on "SS2008!AdventureWorks Sample Reports"

New Comment on "SS2008R2!Security Extension Sample"

New Comment on "SS2008R2!Security Extension Sample"

New Comment on "Server Management Sample Reports"

New Comment on "SS2008!AdventureWorksOffline Report Samples"

New Comment on "SS2008!Security Extension Sample"

New Comment on "SS2008R2!Custom Report Item Sample"

Updated Wiki: SS2008R2!Security Extension Sample

Readme_Security Extension Sample

Requirements

Location

Building the Sample

To generate a strong name key file

To compile the sample using Visual Studio

Deploying the Sample

To deploy the sample

To modify the RSReportServer.config file

To modify the RSSrvPolicy.config file

To modify the RSMgrPolicy.config file

To modify the Web.config file for Report Server

To modify the Web.config file for Report Manager

Creating the UserAccounts Database

To create the UserAccounts database

Testing the Sample

To test the sample

Using the Web Service with Custom Security

Debugging the Sample Extension

To debug the Forms Authentication sample code

Removing the Sample Extension

To revert to Windows security

See Also

Tasks

Other Resources

Help and Information

Updated Wiki: SS2008R2!Security Extension Sample

Readme_Security Extension Sample

Requirements

Location

Building the Sample

To generate a strong name key file

To compile the sample using Visual Studio

Deploying the Sample