Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Two SSRS servers, different behaviors... Expand / Collapse
Author
Message
Posted Tuesday, April 9, 2013 7:36 AM


Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: 2 days ago @ 12:17 PM
Points: 737, Visits: 5,460
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.
Post #1440317
Posted Tuesday, April 9, 2013 9:25 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: 2 days ago @ 9:09 AM
Points: 10,342, Visits: 13,352
I believe that the users need to add the prod site to the trusted sites in IE.



Jack Corbett

Applications Developer

Don't let the good be the enemy of the best. -- Paul Fleming

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
How to Post Performance Problems
Crosstabs and Pivots or How to turn rows into columns Part 1
Crosstabs and Pivots or How to turn rows into columns Part 2
Post #1440422
Posted Tuesday, April 9, 2013 12:34 PM


Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: 2 days ago @ 12:17 PM
Points: 737, Visits: 5,460
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
Post #1440498
Posted Monday, April 15, 2013 8:33 AM


Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: 2 days ago @ 12:17 PM
Points: 737, Visits: 5,460
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!

Jason
Post #1442331
Posted Wednesday, April 24, 2013 6:20 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: 2 days ago @ 9:09 AM
Points: 10,342, Visits: 13,352
Jason,

It's not like we all haven't been there before. Just glad you got the issue sorted out.

-Jack




Jack Corbett

Applications Developer

Don't let the good be the enemy of the best. -- Paul Fleming

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
How to Post Performance Problems
Crosstabs and Pivots or How to turn rows into columns Part 1
Crosstabs and Pivots or How to turn rows into columns Part 2
Post #1445898
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse