This is the second part of my two part series on Reporting Services Encryption. The first part of the series can be read here.
This article will explain how we maintain the keys and various recovery scenarios.
What Data is Encrypted
First off let’s understand what data is encrypted in Reporting Services.
Reporting Services encrypts and stores in the ReportServer database the following:
· Data Source Connection Strings. This is the information required to connect to a data source in order to retrieve data for a report. The connection string could contain a username and password.
· Data Source Credentials (Username and Passwords). These are the stored credentials outside of the connection string used for connecting to a data source in order to retrieve data for a report.
· Subscriptions that store credentials, for example when using the File Share delivery mechanism. This is the credentials required to access the file share.
· Unattended User Account Credentials. This account is used for unattended report processing where you would not need an account to access a data source.
Encrypted data is held in the following tables in the ReportServer database:
· DataSource
· Subscriptions
What about the Credentials to Connect to the ReportServer Database
You may have noticed that there is some encrypted data in the ReportServer configuration file:
C:\Program Files\Microsoft SQL Server\MSSQL.n\Reporting Services\ReportServer\rsreportserver.config
Under the <Configuration> section is a <DSN> element with encrypted data. This holds the Connection String the ReportServer web service and Report Server Windows Service uses in order to connect to the ReportServer database. During Reporting Services Configuration when you went through the Database Setup, you had to select the credentials for connecting to the ReportServer database. By default the connection allows windows authenticated access however; you can change the connection string information using the command RSCONFIG.EXE
Also under the <UnattendedExecutionAccount> section is the encrypted account name used for Unattended Execution operations. This can be set using the Reporting Services Configuration Manager or using the command RSCONFIG.EXE.
The data is encrypted using CRYPTPROTECTDATA and CRYPTUNPROTECTDATA API’s using the machine key. A machine key is generated for a machine that any user can use to decrypt data. This is important because the account running the ReportServer application pool and the Reporting Services windows service account needs to be able to connect to the ReportServer database however; they do not need to be the same account name.
Maintaining the Encryption Keys
Maintaining the keys is about having a backup and restore strategy for the keys and the ability to recover from any situation.
Backing up the Symmetric Key
Once a symmetric key is created it remains the same for the life of the Reporting Services installation or until it is manually changed by a DBA. So theoretically we only need to backup a key once or after it is changed however; you would have to be very confident that the backup file is available if you ever need to recover it.
The backup of the symmetric key only takes seconds to complete so my advice would be to schedule it on a weekly basis or after a key change and ensure the backup file is written to tape. This way you do not run the risk where having one tape from being corrupt, lost or reused.
When you backup the Symmetric key you need to supply a password to the backup. This is to ensure the Symmetric key is not stored in the backup file in a decrypted format which can easily be feed into an app to decrypt the information in Reporting Services. So this means you need to manage a password for the backup files otherwise you will never be able to restore the key. How you do this will depend on the number of DBA’s you have, whether there are separate global teams and what systems you have in place to store passwords.
Note: The Asymmetric keys are not backed up because they can be regenerated automatically from the Reporting Services Windows Service. I will explain this in more detail in the coming sections.
There are two ways to backup the Symmetric key:
· Use the Backup option under Encryptions Keys in the Reporting Services Configuration Manager for the Reporting Services instance and supply a password and backup file.
· Use the command RSKeyMgmt.exe as shown below
For a default installation the RSKeyMgmt.exe command will be in the folder:
C:\Program Files\Microsoft SQL Server\90\Tools\binn
You run the command with the following parameters
RSKeyMgmt –e –f <backup file> -p <password> -i <instance>
-e means Extract to retrieve the Symmetric Key
-f is the file to contain the Symmetric key
-p is a password which is used to encrypt the Symmetric key before it is written to the backup file
-i is the local Instance of Reporting Services. The default is MSSQLSERVER which points to a default instance.
Note: There is no Server parameter in order to backup the keys remotely. You can manually back them up remotely using the Reporting Services Configuration Manager and connecting to the remote instance.
Restoring the Symmetric Key
I will now explain how restore the Symmetric key from a backup however; in later sections I will explain when to restore a key.
The restoration of the key only updates the Keys table in the ReportServer database. The key is extracted from the backup file, encrypted with the Public Asymmetric key for that instance and then written into the Keys table. If the restoration of the key is successful this does not mean any credentials can be decrypted, this can only be determined by running a report.
There are two ways to restore the Symmetric key:
· Use the Restore option under Encryptions Keys in the Reporting Services Configuration Manager for the Reporting Services instance and supply a password and backup file.
· Use the command RSKeyMgmt.exe as shown below
For a default installation the RSKeyMgmt.exe command will be in the folder:
C:\Program Files\Microsoft SQL Server\90\Tools\binn
You run the command with the following parameters
RSKeyMgmt –a –f <backup file> -p <password> -i <instance>
-a means Apply to restore the Symmetric Key
-f is the file to contain the Symmetric key
-p is a password which was used to encrypt the Symmetric key before it is written to the backup file
-i is the local Instance of Reporting Services. The default is MSSQLSERVER which points to a default instance.
Note: There is no Server parameter in order to restore the keys remotely. You can restore them remotely using the Reporting Services Configuration Manager and connecting to the remote instance.
How Do I Change the Symmetric Key
OK so now we are getting into the sections which deal with recovery and troubleshooting.
For security or auditing reasons you may be forced to periodically change the Symmetric key. This process is very straight forward however; there is one important point you must understand. You cannot change the Symmetric key if you cannot first decrypt the data with the original key. So this means if you lose the Symmetric key for any reason, you will not be able to decrypt the data and give it a new key. In this situation your only choice is to delete the encrypted data as described further on.
You have to make sure that there are no reports running or users accessing using Reporting Services when you do this. The length of time to complete the change will depend on the number of entries in the DataSource and Subscriptions tables. Also note in a Scale-Out environment when there are two or more Reporting Services, changing the Symmetric key will change it for all the Reporting Services installations and so you need to ensure neither one is being used.
You can prevent anyone from using Reporting Services as follows:
· Start the SQL Server Surface Area Configuration tool
· Click Surface Area Configuration for Features
· Select your Reporting Services Instance
· Click Web Service and HTTP Access
· Remove the check from Enable Web Service and HTTP access
There are two ways to change the Symmetric key:
· Use the Change option under Encryptions Keys in the Reporting Services Configuration Manager for the Reporting Services instance and supply a password and backup file.
· Use the command RSKeyMgmt.exe as shown below
For a default installation the RSKeyMgmt.exe command will be in the folder:
C:\Program Files\Microsoft SQL Server\90\Tools\binn
You run the command with the following parameters
RSKeyMgmt –s -i <instance>
-s means we are going to generate a new Symmetric key and re-encrypt all the encrypted data.
-i is the local Instance of Reporting Services. The default is MSSQLSERVER which points to a default instance.
Important: Now you have generated a new key make sure you make a backup straight away.
When do I Need to Restore the Symmetric Key
Firstly let’s discuss what changes to Reporting Services causes a need to restore the Symmetric key. As I have mentioned before the Symmetric key never changes otherwise you cannot decrypt the data. If you do change the key you would have to decrypt the data with the old key and then encrypt it again with the new key and described in the previous section.
There are occasions when you need to restore a Symmetric key even when it has not changed. This is when the Asymmetric key has changed and you need to encrypt the original Symmetric key with the new Public Asymmetric key.
The following list details when you should restore the Symmetric Key
· Changing the Service Account of the Reporting Services Windows Service
· Resetting the password for the Reporting Services Windows Service account
· Rebuilding a Reporting Services Machine
· Upgrading Reporting Services
Interestingly there are places in Books Online that says renaming the machine will require the symmetric key to be restored. When I tested renaming a machine it worked OK without requiring a restore. In fact the only thing I had to do after the rename is what is shown in books online under “Renaming a Report Server Computer”.
Changing the Service Account of the Reporting Services Windows Service
I explained in the first article that the Asymmetric keys are generated by the Windows Service. It generates keys based on what we call Machine Store and User Store values. The Machine Store is the name of the machine and the User Store is based on the User that generates the key i.e.; the Windows Service account. The reason for having two is so we are able to generate the original Private key if either the Machine name changes or we change the Windows Service account. This is so we can decrypt the Symmetric key with the original Private key and re-encrypt with the new Private key. Obviously what we cannot do is change both the machine name and the User account at the same time.
If you ever need to change the Windows account then use the Reporting Services Configuration Manager to complete the task. This is because it carries out various tasks under the covers to ensure it has the right access.
You can change the Service Account as follows:
· Start the Reporting Services Configuration Manager for the Instance you wish to change
· Click on Windows Service Identity on the left hand side
· Enter or Select the Account you wish to
· Click Apply at the bottom of the Screen
· You will be prompted to backup the Symmetric key. Enter a password and a file name
· Click OK
· When prompted for an Administrator account in order to carry out the changes, select and enter the appropriate credentials for your installation.
· The change will now take place and complete when the Task Status finishes with “Restoring Encryption Key”
Resetting the password for the Reporting Services Windows Service account
If you change the password of the windows service account by specifying the old password followed by the new password, the keys remain the same and everything is fine. If you have a system administrator reset your password by not specifying the old password, the keys become invalid.
If the Windows password is reset you will need to perform the following:
· Stop the Windows service
· Change the Password for the Windows Service using the services.msc snap in.
· Restart the Windows service
· Check the Windows Service Errorlog ReportServerService_<timestamp>.log in C:\Program Files\Microsoft SQL Server\MSSQL.n\Reporting Services\LogFiles and look for any Encryption errors.
· If the Windows service is unable to decrypt the Symmetric key, restore the Symmetric key from your backup.
· Stop and Start the Windows Service and repeat the above.
Rebuilding a Reporting Services Machine
When you rebuild a Reporting Services Installation, in order to use an existing encryption key you need to ensure the following are the same:
· The Installation ID is the same
· The Machine Name is the same
· The Instance Name is the same
· The Windows Service account and password are the same.
The first three are held in the Keys table in the ReportServer database and are used to identify the row containing the Symmetric Key. The Windows Service account and password are used to generate the Asymmetric keys.
The Installation ID is contained in the rsreportserver.config file in the ReportServer Virtual Directory under the element <InstallationID>.
Any changes in the above will require you to restore the Symmetric key from the backup.
Upgrading Reporting Services
Books Online describes the upgrade process which I will not cover here. I just wanted to add that depending on how you do the upgrade will depend on whether you need to restore the Symmetric key.
Troubleshooting Encryption Failures
What Errors Indicate an Encryption Problem
A good indication as to whether you have an encryption problem is to run a report that uses stored credentials. You may get the error
An error has occurred during report processing.
The report server cannot decrypt the symmetric key used to access sensitive or encrypted data in a report server database. You must either restore a backup key or delete all encrypted content and then restart the service.
Check the documentation for more information.
(rsReportServerDisabled) Bad Data.
You can also receive a similar message in the log file ReportServerService_<timestamp>.log when the Reporting Services Windows Service starts up and validates the key in the ReportServer database.
If you receive any errors that are related to decryption problems then just restore the Symmetric key. There are no side affects or issues restoring the key. It is also worth restarting the Windows service after you restore the key and ensure there are no error messages in the log file ReportServerService_<timestamp>.log
I mentioned that the credentials used by the Windows Services and Web Services are stored in the configuration file rsreportserver.config in the ReportServer Virtual Directory. If there is an issue decrypting this information then you will get the following error:
The encrypted value for configuration setting Dsn cannot be decrypted. (rsFailedToDecryptConfigInformation)
An internal error occurred on the report server. See the error log for more details. (rsInternalError)
You can use the RSCONFIG.EXE utility to specify and verify the account used for connecting to the ReportServer database.
What happens if I do Not have a Backup
If you do not have a backup then you will not be able to decrypt any encrypted data. This is very bad news and can result in a lot of effort to manually recreate all the data sources and subscription information.
When you delete the Symmetric key the Windows service will automatically create a new one. In a Scale-Out environment you will need to initialize each Report Server from the server where you originally deleted the key.
There are two ways to delete the encrypted content.
· Use the Delete option under Encryptions Keys in the Reporting Services Configuration Manager for the Reporting Services instance and supply a password and backup file.
· Use the command RSKeyMgmt.exe as shown below
For a default installation the RSKeyMgmt.exe command will be in the folder:
C:\Program Files\Microsoft SQL Server\90\Tools\binn
You run the command with the following parameters
RSKeyMgmt –d -i <instance>
-d means we are going to delete all the encrypted content
-i is the local Instance of Reporting Services. The default is MSSQLSERVER which points to a default instance.
After this command is run you need to manually add back in all the credential information.
You can list all the Data Sources by running the following in the ReportServer database and then try and determine what information need adding.
SELECT c.Path
FROM DataSource d
JOIN Catalog c ON d.ItemID = c.ItemID
WHERE c.Type = 5
ORDER BY 1
You can list all the Subscriptions by running the following in the ReportServer database and then you need to view each of them to determine which ones need credentials added.
SELECT c.Path,
s.Description
FROM Subscriptions s
JOIN Catalog c ON c.ItemID = s.Report_OID
ORDER BY 1,2
That brings me to the end of this article. I hope it was useful.
If you understand how Reporting Services uses encryption then you will understand how to manage the encryption keys, recover from any encryption failure and more importantly, not to get in an unrecoverable situation. Although Books Online has some information about encryption keys, I feel the information is not laid out in an intuitive way.
This is the first of two articles where I will first be explaining encryption and how Reporting Services creates the keys. The second article will explain how to maintain the keys and various recovery scenarios.
Overview of Encryption
The following paragraphs explain what encryption is in general.
What is Encryption?
Encryption is used to turn some human readable piece of data into something which is not human readable to ensure the information is not compromised. We refer to this process by saying we encrypt the data. A good example would be your password. In order to turn a non-human readable piece of data back in to something that is readable, we decrypt the data.
The process that encrypts and decrypts the data uses mathematical algorithms. The algorithm will generate a random number which becomes the Key. This key will be used by the algorithm to generate the encrypted data.
While I will be explaining encryption I will only be giving you sufficient information to understand the role it plays in Reporting Services. If you would like a better understanding of Cryptography I recommend watching the following webcast at IT’S Showtime
What types of Encryption Algorithms are there?
There are numerous encryption key algorithms used today so rather than explain all the different types, I will explain what Reporting Services uses.
Reporting Services uses two algorithms, a Symmetric Key algorithm and an Asymmetric Key algorithm.
· A Symmetric Key algorithm uses the same key to encrypt and decrypt the data.
· An Asymmetric Key algorithm uses one key to encrypt the data and another key to decrypt the data.
With a Symmetric Key algorithm all parties who are involved with encrypting and decrypting data have a copy of the same key. The algorithm used by Reporting Services is the 3DES or Triple DES as it is pronounced.
With Asymmetric Key algorithms firstly; each key has a name. One key is called the Public Key and the other key is called the Private key. The Private key is never shared out whilst the Public key on the other hand is given out to anyone involved with exchanging the encrypted data. Asymmetric algorithms only allow data to be encrypted with the Public key and decrypted using the Private key. Reporting Services uses the RSA algorithm.
Why are Multiple Algorithms used?
In Cryptography it is standard practise to use one key to encrypt the data and then a second key to encrypt the first key which was used to encrypt the data. The reason for this is to prevent a malicious user from getting hold of the first key which will allow them to decrypt the data.
When it comes to deciding which key to use, there is a simple rule you use. You always encrypt data using a Symmetric key and you always encrypt a key using an Asymmetric key. The reason for this is because encrypting data using a Symmetric key is 100’s of times faster than encrypting the same data using an Asymmetric key however; an Asymmetric key is harder to crack than a Symmetric key.
By the way, if you were wondering about Certificates, these are Asymmetric keys so whilst you could encrypt data with them, the same rules apply. Certificates are not used in the context of this article however; I will be discussing Certificates in a future article on using Reporting Services over SSL.
Encryption Summary
So to summarise; Reporting Services uses two algorithms for encryption, one is the 3DES Symmetric algorithm to encrypt data and the second is an RSA Asymmetric algorithm to encrypt the Symmetric key.
A side note here. If you are considering using encrypted columns in SQL Server, follow my advice here. Use a Symmetric key to encrypt the data and use an Asymmetric key or Certificate to encrypt the Symmetric key. That’s a quick tip just for you.
Generating the Encryption Keys
The following paragraphs go into detail on how the keys are created and where they are stored in Reporting Services.
In order to fully understand how keys are created I need to explain about Scale-Out Deployment because there are additional steps involving encryption that need to be followed in order to complete the installation.
In a basic configuration there is one Reporting Services server and one SQL Server containing the ReportServer and ReportServerTempdb database.
In a Scale-Out configuration there are two or more Reporting Services all pointing at the same SQL Server containing the ReportServer and ReportServerTempdb database. This enables multiple reports to be run simultaneously on different machines for performance reasons.
How are the Symmetric and Asymmetric Keys Created
It is important to realise that all keys are managed by the Reporting Services windows service. Any encrypting or decrypting is done by the windows service. If the Web Service requires some data decrypted, it sends an RPC request to the windows service to do it on its behalf.
So this means that the windows service has to be running at all times, something which was not required on Reporting Services 2000.
The Asymmetric keys are generated by the Cryptographic Services service during Reporting Services configuration based on the account name running the windows service. This means that if you change the account name, the asymmetric keys become invalid. Also a very important point to bear in mind is the account password. If you change the password of the windows service account by specifying the old password followed by the new password, the keys remain the same and everything is fine. If you have a system administrator reset your password by not specifying the old password, the keys become invalid. I will explain some recovery situations below. Every Reporting Services installation has a different Public key
The symmetric key is also generated by the Cryptographic Services service during Reporting Services configuration however; the key is not based on the account running the windows service and in fact no change of any sort will cause it to become invalid. The Symmetric key is generated by the first server configured in a Scale-Out deployment; the other servers simply get a copy. This ensures each server is able to decrypt the data.
Configuring the first Reporting Services Instance.
The first instance is always created regardless of whether you are deploying a standard configuration or a Scale-Out deployment.
Whether you install using a Default Configuration or you are doing a Files Only installation and configuring Reporting Services using the Reporting Services Configuration Manager, the result is the same.
During the Database Setup part of the configuration we enter what is known as the Activation Process that consists of two phases.
The first phase is called the Announce phase which connects to the ReportServer database and runs the stored procedure AnnounceOrGetKey. This checks a table called Keys for a row specific to this Reporting Services installation and if none is found the following information is added:
|
Column |
Description |
|
MachineName |
This is the host name of the Reporting Services machine |
|
InstanceName |
This is the Instance name of the Reporting Services installation. You can have multiple instances of Reporting Services on the same physical machine |
|
InstallationID |
Every Reporting Services installation has a unique ID stored in its rsreportserver.config file which is created in the ReportServer virtual directory. |
|
Client |
This is always 1 |
|
PublicKey |
This is the public key created by the Reporting Services windows service and is unique for each service. |
The second phase is called the Activation phase. This phase gets the Symmetric key from the Reporting Services windows service which will be used to encrypt the data and encrypts the symmetric key with the Public key. A stored procedure called SetKeysForInstallation is run which updates the Keys table and adds the encrypted symmetric key into the SymmetricKey column. At no time during any of this process is the Symmetric key ever shown decrypted.
Configuring a Second Server in a Scale-Out Deployment
When you configure a second server as part of a Scale-Out deployment you will need to do a Files Only installation. This will require you to run the Reporting Services Configuration Manager to complete the installation. I am not going to explain the exact steps since I will be doing this in a future blog however; you complete the installation just like the first server until you get to the Database Setup part.
Normally at this stage you would be connecting to a SQL Server that does not have a previously created ReportServer or reportServerTempdb database created however; in a Scale-Out deployment you will be connecting to a SQL Server where the databases were created when you configured the first server instance.
Again during the Database Setup we enter the Activation process which contains the two phases. In phase one which is the Announce phase, the actions are completed in the same way as it was done when configuring the first server however; the difference comes when we enter the Activation phase.
In order to complete the second phase we need the decrypted Symmetric key so we can encrypt it with the second instances public key and store it in the Keys table. The problem we face is that it can only be decrypted by the first instances private key so phase two has to be completed by the first server. You run the Reporting Services Configuration Manager and connect to the first server. When you run the initialization step in the Configuration Manager, the Symmetric key is decrypted using the first server’s private key and then encrypted using the second server’s public key then stored in the Keys table. This is why the Public key for each server is also stored in the Keys table.
At this stage we have a Keys table with two rows. One row is for the first server and the other row is for the second server. Both rows contain the same symmetric key but each has been encrypted with a different public key.
So now you understand how the keys are created, the next article will explain how to maintain the keys and various recovery scenarios.
One of the issues which crop up time and time again is the classic Double Hop Authentication problem. This article will explain what the issueis and how to configure your Reporting Services environment in order to use Double Hop Authentication. I will only be discussing the configuration for IIS6.0 on Windows 2003.
So what is Double Hop Authentication?
Imagine you are sitting at your laptop and you launch Internet Explorer. You enter http://<server>/Reports and this brings up Reporting Services Report Manager. In a real world environment your web server hosting Reporting Services will not be on your laptop but rather a different machine. Using the windows NTLM protocol, your windows credentials will be passed to the web server. This counts as one hop. As long as everything you require is located on the web server, your windows credentials will be used for accessing the resources. So far so good.
Here is the issue. You run a report which needs to connect to a SQL Server to get the data required for the report however; SQL Server is located on a third machine. So you have laptop to web server to SQL Server, a second hop or double hop. In this scenario NTLM is not able to forward your windows credentials to SQL Server, so you will not be able to get the data from SQL Server using your windows account. I mentioned SQL Server however; it does not matter what service you are trying to connect to on the third, the problem is that NTLM will never pass your credentials so it would also fail for Analysis Services as an example. In the situation the account used to access the third server will be the NT Authority\Anonymous Logon account. So if the third server is SQL Server then you need to add the Anonymous account as a SQL Server account with the necessary privileges.
The workaround mostly used is to create a generic account to access the data and store the credentials in the Reporting Services Catalog. This works great however; I will explain how you can configure your environment to use Double Hop Authentication in order for you to connect to the third server using your own credentials.
I have to say right now that I will provide as much information as I can in order for you to get this working however; I am sure there will be issues for some of you which will mean it still does not work. This is why I will be providing links to external resources to help.
Configuring Double Hop Authentication
I have already mentioned that NTLM does not support Double Hop Authentication so in order for this to work we need to configure Kerberos Authentication.
I am going to break this up into three sections:
· One for the Client configuration
· One for the Web Server configuration
· One for a SQL Server configuration. I will only be discussing SQL Server as the third hop since this is probably the most popular.
Before you start you need to be aware of the servers involved. In fact for this to work there are in fact more than three servers involved. There are the three servers I mentioned above and also one or more domain controllers. You will need to make a note of all the machines and the domains the machines reside in.
Client Configuration
Follow these steps on the client machine where you run Report Manager.
· Review the contents of the file C:\Windows\System32\Drivers\ETC\hosts and ensure there are no references to any of the machines which are used for your configuration including domain controller entries
· From a command prompt run NSLOOKUP on the Fully Qualified Domain Name (FQDN) of the web server and domain controller and ensure they are all visible.
· From a command prompt run NSLOOKUP on the IP Addresses of the web server and domain controller and ensure they are all visible.
· From a command prompt PING the web server and domain controller.
· From the Event Viewer within the System events locate the latest W32Time entry in the Source column and confirm the time is synchronized.
· In Active Directory your Windows Account must NOT have the option Account is sensitive and cannot be delegated enabled.
· Within Internet Explorer choose Tools -> Internet Options -> Advanced and ensure the option Enable Integrated Windows Authentication is enabled
· When you connect to Report Manager you need to make sure that the Internet Explorer Security Zone is not using Internet. Choose Tools -> Internet Options -> Security -> Local Intranet and then Click Sites and add the Web Server to the list of web sites.
So that is your client ready.
Web Server Configuration
Follow these steps on the web server where Reporting Services has been installed.
· Review the contents of the file C:\Windows\System32\Drivers\ETC\hosts and ensure there are no references to any of the machines which are used for your configuration including domain controller entries
· From a command prompt run NSLOOKUP on the Fully Qualified Domain Name (FQDN) of the client, SQL Server machine and domain controller and ensure they are all visible.
· From a command prompt run NSLOOKUP on the IP Addresses of the client, SQL Server machine and domain controller and ensure they are all visible.
· From a command prompt PING the client, SQL Server machine and domain controller
· From the Event Viewer within the System events locate the latest W32Time entry in the Source column and confirm the time is synchronized.
· We need to ensure the Web Site where the Reporting Services Virtual Directories are created is configured for Kerberos Authentication. Firstly, from IIS Manager click on the Web Sites folder on the left hand side and make a note of the Numeric Identifier for the Reporting Services Website.
· From a command prompt:
o Change to folder C:\Inetpub\Adminscripts.
o Run cscript adsutil.vbs set w2svc/NN/root/NTAuthenticationProviders “Negotiate,NTLM”
where NN is the Numeric Identifier from above.
· Make sure that the Reporting Services Virtual Directories has the Integrated Windows Authentication enabled only within Properties -> Directory Security -> Authentication and Access Control
· If the account specified in the Application Pool used by the Reportserver Virtual Directory is a local account, in Active Directory you need to Enable Delegation for the Web Server Machine. If the account is a domain account, you need to Enable Delegation for the Domain Account.
· Run SECPOL.MSC and under Security settings -> Local Pol