Unable to run IT Analytics reports after upgrading or installing IT Analytics 7.1 SP2
|Article:TECH175120|||||Created: 2011-11-22|||||Updated: 2012-09-24|||||Article URL http://www.symantec.com/docs/TECH175120|
|NOTE: If you are experiencing this particular known issue, we recommend that you Subscribe to receive email notification each time this article is updated. Subscribers will be the first to learn about any releases, status changes, workarounds or decisions made.|
When a user accesses any IT Analytics report they receive the following message:
The authenticated user cannot access the requested cube. Please verify that the authenticated user has proper privileges to the requested cube on the SQL Server Analysis Services instance on which it is hosted, and that the client machine has the Microsoft SQL Server 2005 Analysis Services 9.0 OLE DB Provider installed. Additionally check the browser settings for the internet zone this site shows up in and verify that the setting called "Access data sources across domains" under Miscellaneous is set to "Enable" or "Prompt".
This issue is isolated to the following environment:
- IT Analytics SP2 build number 7.1.2060
- Symantec Management Platform is installed on a different host than SQL Analysis and Reporting Services
- User is able to access cubes from the Reports > IT Analytics > Cubes, but is unable to run reports.
- User has already been given access to Reporting Services.
To verify that the user has correct permissions in Reporting Services, you can navigate to IT Analytics Settings > Reports > Security tab. Make sure that the user’s credentials or a windows group the user belongs to is displayed in the text area.
- Reporting Server Authentication Type is set to Windows Integrated Authentication
To check this setting, please go to IT Analytics Settings > Configuration and verify that under Reporting Server the Authentication Type is set to Windows Integrated Authentication.
When the Symantec Management Platform and SQL Server Analysis Services and SQL Server Reporting Services are hosted on two different computers and the Reporting Services IT Analytics data source is set to use Windows Integrated Authentication, Kerberos is required to pass the credentials of the user from the Symantec Management Platform to the Reporting Server. Without enabling Kerberos, the connection to Reporting Services is attempted as an anonymous user, which fails authentication in a typical configuration.
There are two ways you can resolve this issue. Option 1 allows you to bypass enabling Kerberos by setting the Reporting Server’s Authentication Type to Stored Credentials. Doing this will mean that all user requests to run IT Analytics reports will impersonate the user specified in the Stored Credentials and you will not be able to utilize any of the cube security features. This is the best option if you are not concerned with restricting which cubes users can access or which data users can see inside of cubes. If you would like to continue using Windows Integrated Authentication you will need to configure Kerberos as described in Option 2.
Option 1 - Setting Reporting Server to use Stored Credentials:
To set the Reporting Server to use Stored Credentials, you can use the instructions below. If you’d like to continue to use Windows Integrated Authentication, you will need to configure Kerberos as described in Option 2.
- In the Symantec Management Console, on the Settings menu, click Notification Server > IT Analytics Settings.
- In the left pane, click Configuration.
- Under Authentication Type, click the edit pencil:
- Select Stored Credentials and enter a domain username and password to use for authentication. Access to Reporting Services is always authenticated with the same rights for all users.
- Click Save Security Settings.
Note: The username and password for a workstation's user may need to be added to Internet Explorer's Local Intranet Zones, otherwise the user will be prompted to enter their network credentials when drilling down into an IT Analytics report. This is done by going to the browser's Tools menu > Internet Options > Security tab, click on Local intranet, and then add in the FQDN for the Symantec Management Platform server and then click on the OK button.
Option 2 - Configuring Kerberos for the SMP and Reporting Services:
To complete the two-step delegation process from the user’s computer to the Symantec Management Platform and then to Reporting Services, follow the instructions below:
- From Active Directory set the computer that the Symantec Management Platform is hosted on to “Trust this computer for delegation to any server (Kerberos only).
- If the Application Pool that the Symantec Management Platform is using in IIS is a domain account you will also need to enable that account to be trusted for delegation as described in the previous step. If the App Pool is using the Default value "ApplicationPoolIdentity" you may skip this step.
- Add the following Service Principal Names to the Symantec Management Platform:
Setspn –S http/<netbiosName> <netbiosName>
Setspn –S http/<Fully Qualified Domain Name> <netbiosName>
Setspn –S http/computer1 computer1
Setspn –S http/computer1.domain.com computer1
Note: if the Application Pool that the Symantec Management Platform is using in IIS uses a domain account you may need to set the SPN’s for that account instead of computer1. For example:
Setspn –S http/computer1 <domain\username>
Setspn –S http/computer1.domain.com <domain\username>
- (SQL 2008 Only) On the Reporting Services server edit the ReportServer.config file so that <RSWindowsNegotiate/> is listed at the top of the <AuthenticationTypes> node. This file can be located at <SQL Server Install Directory>\ MSRS10.MSSQLSERVER\Reporting Services\ReportServer
- Add the following Service Principal Names for the account that the SQL Reporting Services service is running as. This is only required if it’s running as a Domain account:
Setspn -S http/<netbiosName> <domain\username>
Setspn -S http/<fqdn> <domain\username>
- All affected systems must be restarted before the changes can take effect. It may also be necessary to restart the client system you are testing from as well.
Article URL http://www.symantec.com/docs/TECH175120