April 9, 2013 at 7:36 am
I have two identical SSRS 2008 servers, which are behaving differently when users attempt to access SSRS. On the first (QA) users can access reports without needing to enter a user / password. On the 2nd server (Prod) the users are asked for their domain login, and if they are not added into an SSRS role, denied access.
The *ONLY* differences I have found are the following:
On Prod, IIS is configured for Windows Authentication (both servers have IIS installed and running)
On Prod, the certificate used for SSRS is the server self-signed, while QA has a cert (likely from the domain authority)
*ALL* configuration settings between the two instances of SSRS (with the obvious exceptions of the DBs, and the service accounts {which are domain accounts for just this purpose}) are the same. I've even looked in the rsconfig.xml files on both and checked the authentication settings (WindowsNTLM)
Any help would be appreciated on getting this resolved (I need both to behave like QA)
Thanks,
Jason A.
April 9, 2013 at 9:25 am
I believe that the users need to add the prod site to the trusted sites in IE.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
April 9, 2013 at 12:34 pm
The security policies of the workplace don't allow users to add / remove entries from their Trusted Sites list. Also, the domain that the servers (both QA and prod are on the same domain) is already in the trusted sites.
The ONLY other difference I'm seeing is that on QA the SSL Certificate being used is:
A) Good for "ALL IPs" while on Prod it's only for one IP (both servers have 3 IPs)
B) The FQDN on QA does NOT have the domain, only the server name, Prod has the FQDN with domain name
I'm stumped at this point...
Thanks,
Jason
April 15, 2013 at 8:33 am
Jack, I must apologize, as your answer was on the right track...
Turns out there's a few things I didn't know about the network here...
1. While *.domain.com is in the Trusted sites, it apparently doesn't work too well...
2. Adding the servername.domain.com to the Local Intranet via GPOs did resolve the problem...
So, thank you!
It looks like the reason the QA server worked, is it doesn't use the FQDN. While a solution was briefly considered to get a new SSL Cert for Prod without the FQDN, turns out policy says NO to this.
A week of banging my head against this, and I had the answer on Tuesday...
Really, eye R schmart!
:rolleyes:
Jason
April 24, 2013 at 6:21 am
Jason,
It's not like we all haven't been there before. Just glad you got the issue sorted out.
-Jack
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply