I have setup SSRS 2017 Scaleout environment with two nodes and a load balancer. Users can login fine with both IE and Chrome but editing Data Sources works in IE but not in Chrome. Details below.
Here are the high level Installation/Configuration steps.
lets say Nodes are N1, N2. Load balancer vip/name is reports.root3i.com
Kerberos
Created AD user domain\ssrs_svc
setspn for ssrs_svc with
http/N1.root3i.com
http/N2.root3i.com
http/N1, http/N2
http/reports.root3i.com
http/reports
Enabled Kerberos delegation for N1, N2 and ssrs_svc accounts to trust any service
Install and Setup
Setup SSRS on N1 with domain\ssrs_svc
Created new Report Database on a remote server
Defaults for Web Service/Report manager url. No Https
Backed up Encryption Key
Setup SSRS on N2 with domain\ssrs_svc
Defaults for Web Service/Report manager url. No Https
Used existing database on a remote server
Restored encryption key from N1
At this time, N1, N2 were already present in the scale-out tab.
RsReportServer.config
Added same machinekey for N1 and N2 with AES Decryption and HMACSHA256 validation.
Set UrlRoot https://reports.root3i.com
Hostname to reports.root3i.com
AuthenticationTypes
<AuthenticationTypes>
<RSWindowsKerberos/>
<RSWindowsNegotiate/>
</AuthenticationTypes>
Permissions
Created an AD Group SSRS_Admins
Assigned System Administrator and User role to the above group under Site Settings -> Security
Assigned all the roles for Folder level permissions(Browser, Content Manager, My Reports, Publisher, Report Builder
Issue
Editing Data Sources works fine in IE from a Workstation for users that are member of SSRS_Admins group but using Chrome, we get this generic error "Error has occurred"
RSPortal logs has this error. "ERROR: OData exception occurred: System.Net.WebException: The request failed with HTTP status 401: Unauthorized"
Is this known issue with Chrome? Did I miss any steps in Config? We would really like it to work on Chrome.
Versions:
Workstation Windows 10 1803
Chrome 68
Helpful Links:
https://www.sqlshack.com/scaling-out-reporting-services-changes-in-sql-server-2016/
https://learn.microsoft.com/en-us/sql/reporting-services/report-server/configure-a-report-server-on-a-network-load-balancing-cluster?view=sql-server-2017
Related
SQL Server/SSRS 2016 Developer, installed on my local laptop, Windows 10 Pro.
My login is an admin to SQL Server, I'm able to do everything. For SSRS, when I try to connect to my web portal url I'm told "You are not allowed to view this folder. Contact your administrator to obtain the necessary permissions." Connecting to the web service url I get this message, "The permissions granted to user are insufficient for performing this operation. (rsAccessDenied)". When I connect to Reporting Services with my login in SSMS it connects but I'm not able to do anything - when I right-click on anything the Properties options are not available.
I have run IE as administrator and added the web portal url to trusted sites. I've run SSMS as administrator and connected to Reporting Services, same problems. I can run Reporting Services Configuration Manager as administrator and have no problems there. It seems like somehow when I setup SSRS my account didn't get added to the list of administrators for Reporting Services.
I did select * from ReportServer.dbo.Users and see these three:
Everyone
NT AUTHORITY\SYSTEM
BUILTIN\Administrators
I have tried Chrome, IE, Edge, all as regular user and administrator.
Any suggestions? Thanks!
I have installed SSRS 2016 developer locally on my machine.
I can't get the report manager page to load and in the log files I get this error:
Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ServerConfigurationErrorException: AuthzInitializeContextFromSid: Win32 error: 1355
I have search and seem to get back to this article each time:
https://support.microsoft.com/en-gb/kb/842423
But how would I do this or apply these on my local machine?
I have tried changing the service user to Network Service and Local Service/System, and also my domain login I use which has local admin rights but always get this same error.
Can anyone suggest anything else I can try?
This is fixed in SQL 2016 SP1 update
this appears very similar to a known issue with SQL 2016. A patch is due soon with Cumulative Update #1. If you are on a domain joined machine, and the server does not have access to the domain controller (e.g. you aren't VPN'd, don't have wifi, etc...) this AuthZ call will fail.
I am currently using SSIS to connect to and transfer data from a Microsoft Project Online (Cloud-based) database to an on-prem SQL Server db. The issue is that the SSIS package executes as expected when not running Fiddler4.
While troubleshooting with MS techs, it has been requested we capture a Fiddler trace and decrypt HTTPS traffic. We were able to do this in months past, but as of late, it will cause the SSIS package to fail with the following error:
"Cannot acquire a managed connection from the run-time connection manager."
I have followed the instructions to remove certificates a few times, as well as a few other net suggestions, but still having the issue. We are at a point where MS cannot troubleshoot further unless I can capture a trace.
Full error:
Information: 0x4004300A at TimeSet, SSIS.Pipeline: Validation phase is beginning.
Error: 0xC020801F at TimeSet, OData Source [2]: Cannot acquire a managed connection from the run-time connection manager.
Error: 0xC0047017 at TimeSet, SSIS.Pipeline: OData Source failed validation and returned error code 0xC020801F.
Error: 0xC004700C at TimeSet, SSIS.Pipeline: One or more component failed validation.
Error: 0xC0024107 at TimeSet: There were errors during task validation.
Thanks for any and all help!
Edit: Went through my CA store and saw that the FiddlerRoot was not part of the Trusted CA list. Attempted to explicitly import the CA certificate in my security store, but the cert is still not showing in the trusted list. The Cert is named (for some reason) DO_NOT_TRUST_FiddlerRoot. Could this be part of what I have been seeing if the CA is marked to not be trusted?
Stepping back a bit: The Fiddler root certificate is always called DO_NOT_TRUST_FiddlerRoot and its name has no impact on anything (other than what is shown in the UI).
Does Fiddler properly collect HTTPS traffic from your web browsers?
If so, there are several possible explanations for what's going on here, but the most likely is that the Fiddler root certificate isn't trusted by the process that is using the connection; by default, for instance, Fiddler only tries to trust the root certificate in the per-user certificate store, but sometimes things run in a different user account (e.g. a service account) and thus the root must be placed in the per-machine certificate store.
You can try the following:
In Fiddler’s Tools > Fiddler Options > HTTPS tab, click Export Root Certificate to Desktop.
Launch mmc.exe.
Click File > Add/Remove Snap-In.
Select the Certificates snap-in and press Add.
When prompted This snap-in will always manage certificates for: choose Computer Account
Click Local Computer, then Finish, then OK.
Open the Certificates (Local Computer) node.
Right-click the Trusted Root Certificate Authorities folder and choose All Tasks > Import.
Choose the file you exported in step #1 and import it.
After a fresh install of SQL Server 2012 Developer on my Windows 7 machine, I configure SSRS. Then, in IE (version 11), I try to access the SSRS server at http://(servername)/Reports. Windows asks for my username and password. Odd, because I'm an administrator. So I enter my username and password and I get this reply:
User '' does not have required permissions. Verify that sufficient permissions have been granted and Windows User Account Control (UAC) restrictions have been addressed.
Researching the issue, I come across a number of answers, including:
Reporting Services permissions on SQL Server R2 SSRS
SSRS 2008: User Does Not Have Required Permissions
The answers to these questions are similar:
Run IE as an administrator
Add the SSRS URL to Trusted Sites in Security tab of Internet Options
Retry SSRS URL
On success, add your user to Site Settings and Folder Settings with the appropriate permissions.
You should then be able to access SSRS without running IE as administrator
Additional workarounds include disabling UAC and repeating the steps above.
Running IE as an administrator did not work. At step 3. I got the same response as above and was never able to get to the SSRS home page.
Before disabling UAC, are there any other workarounds?
The workaround I found is from Peter O’Gorman's blog entry.
The steps above are the same, except add the URL to Local Intranet, not Trusted Sites:
Run IE as an administrator
Add the SSRS URL to Local Intranet in Security tab of Internet Options
Retry SSRS URL
On success, add your user to Site Settings and Folder Settings with the appropriate permissions.
You should then be able to access SSRS without running IE as administrator
To my pleasant surprise, this worked like a charm. Thanks Peter!
Run IE as an administrator - not Chrome. I swear I tried this before with no joy.
I don't understand why not Chrome and why administrator. Maybe Chrome somehow dismisses the elevated permissions. How does the rsManager know at what level the browser is running anyway?
Microsoft SQL Server Management Studio 12.0.2000.8
Microsoft Analysis Services Client Tools 12.0.2000.8
Microsoft Data Access Components (MDAC) 6.3.9600.16384
Microsoft MSXML 3.0 5.0 6.0
Microsoft Internet Explorer 9.11.9600.17498
Microsoft .NET Framework 4.0.30319.34209
Operating System 6.3.9600
Chrome Version 39.0.2171.95 m
Same steps as Glenn mentioned previously. I also had to add user to role in two different spots once I was able to access SQL Server Reporting Services - Home. In Folder setting -> security -> new role assignment and site settings -> security -> new role assignment. I added my user as well.
http://techasp.blogspot.com/2013/06/how-to-fix-reporting-services.html
This works for Reporting Services 2008 onwards
This one has been bugging me for a while, some users have access to the report server others get this error message. While trying to resolve it with a system administrator I came across this post from microsoft support
For users to navigate to a particular folder, they must have Browser role on
all folders starting at the root folder (the folder named "/" in the
item path or "Home" in Report Manager). So you will need to grant
those permissions explicitly. By default, permissions are inherited
from the parent folder. If there are any breaks in the inheritance,
you will need to set those permission explicitly.
What we did as a administrator users, was to navigate to Reports page, then folder settings and grant the user that does not have permissions Browser rights to the folder. Use could then navigate to the home page and work their way down the tree. the sys admin hadn't granted access to the user at the home level just on the folders and reports that have access to.
I am building custom reports in Microsoft CRM and am using the CRM_URL parameter to created drill downs.
However, the URL coming in is ***http://**myserver.com/org/CRMReports...* but it should be **https://**myserver.com/org/CRMReports...
My understanding is that this value is dynamically passed in by MS CRM. How/where can I update this URL to use https?
you need to use the SRSS config tool. =>
Configuring a Report Server for Secure Sockets Layer (SSL) Connections (2005)
Configuring a Report Server for Secure Sockets Layer (SSL) Connections (2008)
"Edit UrlRoot in the RSReportServer.config File
If you are using the report server e-mail delivery extension, you can create subscriptions that included a report URL in the e-mail message. To construct the report URL, the report server uses the UrlRoot configuration setting in the RSReportServer.config file. If the report runs on a report server that is accessed through an SSL connection, you must manually edit the UrlRoot to use the https:// prefix.
If you are using a server certificate, the format of the URL is as follows:
<UrlRoot>https://certificatename/reportservervirtualdirectoryname</UrlRoot>
The answer to my issue was #4 & #5 from this link:
http://rc.crm.dynamics.com/rc/regcont/en_us/op/articles/secure_comm.aspx#ID0EFD
For deployments that will not be used
by external clients, which connect
over the Internet, follow these steps:
Obtain a certificate from a CA. To use certificates you will have set
up a public key infrastructure (PKI),
which consists of one or more CAs that
are linked in a hierarchy. These CAs
and the PKI are required to manage
certificate issuance, validation,
renewal, and revocation in one or more
organizations. You can use a
third-party PKI with Microsoft Windows
Server 2003, or you can establish your
own PKI, based on Windows Server 2003
Certificate Services.
Make sure that there are no users accessing Internet Information
Services (IIS) where the Microsoft
Dynamics CRM Web application is
installed. To do this, stop the
Microsoft Dynamics CRM Web site:
right-click the Web site, and then
click Stop.
Configure the Microsoft Dynamics CRM Web site to use SSL. To do this,
perform the following steps on the
server running IIS where the Microsoft
Dynamics CRM Web application is
installed:
1. Start Internet Information Services (IIS) Manager
2. Right-click the Microsoft Dynamics CRM Web site, and then click
Properties.
3. Click the Directory Security tab, click Server
Certificate, and then follow the
instructions in the Web Server
Certificate Wizard.
4. If you want clients to only use SSL when they connect to the
Microsoft Dynamics CRM application, on
the Directory Security tab in the
Secure communications area, click
Edit.
5. On the Secure Communications dialog box, click the
Require secure channel (SSL) check
box.
6. Close Internet Information Services (IIS) Manager.
Important: You can apply only a single certificate to the Microsoft
Dynamics CRM Web site. Therefore, you
if you have configured Microsoft
Dynamics CRM Server for both internal
and Internet-facing (external) access,
you cannot configure SSL for both
internal and external connections to
the Microsoft Dynamics CRM Web site.
You must manually modify the following values in the configuration
database.
Warning: Incorrectly modifying the configuration database
(MSCRM_CONFIG) can cause unexpected
behavior in the Microsoft Dynamics CRM
system or cause the system to stop
working. We recommend that you back up
the Microsoft Dynamics CRM system
before you complete these steps. For
information about how to back up the
Microsoft Dynamics CRM system, see the
Operating and Maintaining Guide that
is part of the Microsoft Dynamics CRM
4.0 Implementation Guide document set.
1. On the computer running Microsoft SQL Server, start SQL Server
Management Studio.
2. Expand Databases, expand MSCRM_CONFIG, expand Tables,
right-click dbo.DeploymentProperties,
and then click Open Table.
3. In the dbo.DeploymentProperties table under
the ColumnName column, in the
ADRootDomainScheme row, change the
NVarCharColumn column value from http
to https. Note that this value must be
in lower-case letters.
4. In the dbo.DeploymentProperties table, under
the ColumnName column, in the
ADSdkRootDomain row, change the
NVarCharColumn column value by using
the name of the certificate configured
for the Microsoft Dynamics CRM Web
site. The name of the certificate can
be found, in Internet Information
Services (IIS) Manager, on the
Directory Security tab of the
Microsoft Dynamics CRM Web site
properties page.
5. Click View Certificate.
6. On the Certificate dialog box, click Details.
7. Click the Friendly Name field to locate the certificate name.
If the certificate name is the same as
the computer name, you can use the
format ServerName:SSLPortNumber. By
default, the TCP port for SSL
connections is 443.
8. In the dbo.DeploymentProperties table, under
the ColumnName column, in the
ADWebApplicationRootDomain row, change
the NVarCharColumn column value by
using the name of the certificate
configured for the Microsoft Dynamics
CRM Web site. If the certificate name
is the same as the computer name, you
can use the format
ServerName:SSLPortNumber. By default,
the TCP port for SSL connections is
443.
9. Make sure your modifications are saved and then close
SQL Server Management Studio.
Modify the LocalSDKPort Windows registry subkey value. To do this,
complete the following steps.
Warning: Serious problems might occur if you modify the registry
incorrectly by using Registry Editor
or by using another method. These
problems might require that you
reinstall the operating system and
Microsoft Dynamics CRM. We cannot
guarantee that these problems can be
solved. Modify the registry at your
own risk.
1. Start Registry Editor, and locate the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM
subkey.
2. Right-click LocalSdkPort, click Modify, and then click OK.
3. In the Base area, click Decimal, and then type the TCP port.
4. Click OK.
5. Close Registry Editor.
Restart IIS. To do this, at the command line, run the iisreset
command.
Start the Microsoft Dynamics CRM Web site. To do this, right-click the
Microsoft Dynamics CRM Web site, and
then click Start.
Restart the Microsoft Dynamics CRM Asynchronous Processing Service.
To do this, click Start, point to
Administrative Tools, and then click
Services. In the list of services,
right-click Microsoft Dynamics CRM
Asynchronous Processing Service, and
then click Restart.
Verify that you can successfully connect to the Microsoft Dynamics CRM
Web site. To do this, you must use a
URL that begins with https. For
example, in Internet Explorer the URL
will appear similar to the following
address:
https://ServerName/OrganizationName/loader.aspx
If the Microsoft Dynamics CRM Web site is not configured to require
SSL connections, verify that you can
successfully connect to the site by
using an http connection, for example,
http://ServerName/OrganizationName/loader.aspx.