Showing posts with label dmz. Show all posts
Showing posts with label dmz. Show all posts

Friday, March 23, 2012

Reporting Services Over the Internet

Can anybody help.
I want to run reporting services on a web server (DMZ and Firewall) and use
NT authentication, but when i try to run a report and the data source falls
over saying it can not found the login.
I have created the login (test) on both the Domain and web server (same
password)
Regards
Gary
Direct e-mail gary.baker@.mentec.co.ukI assume you've tried SQL Login instead of NT Auth for your data source?
And the SQL box and web server are both in the same domain?
Jeff
"Gary Baker" <gary.baker@.mentec.co.uk> wrote in message
news:OpKj#IllEHA.2820@.TK2MSFTNGP15.phx.gbl...
> Can anybody help.
> I want to run reporting services on a web server (DMZ and Firewall) and
use
> NT authentication, but when i try to run a report and the data source
falls
> over saying it can not found the login.
> I have created the login (test) on both the Domain and web server (same
> password)
> Regards
>
> Gary
>
> Direct e-mail gary.baker@.mentec.co.uk
>

Wednesday, March 21, 2012

Reporting Services Login Issue

I have a client that has a unique situation. Here is the back ground
information:
A Reporting Services 2005 server in a DMZ. This server is not part of
any domain, only has local users.
A SQL Server with the Report Database and an Analysis Services Server
with the Cubes on which the reports are built are behind the
firewall. These servers are in a Windowss 2003 Domain using Domain
accounts for access.
The issue is getting the Report Server in the DMZ to successfully open
a report based on a Cube. Using a Standard SQL Server Login we can
successfully open a report from the Reporting Server in the DMZ that
uses a relational database behind the firewall. This works obviously
since we can use a Standard Login and not deal with the domain/no
domain issue.
When we try to setup a report that uses the CUBE, we can not get the
Domain Server to accept our "ghost" user we created. We create a
user, "reptusr" on the local server in the DMZ. We also created a
user, "reptusr" in the domain behind the firewall and gave that user
id access to the CUBE. This is not working.
I can't find a lot of information on this specific scenario so any
information anyone may have would be greatly appreciated!
Thanks in advance!
MartinDid you write full username (domain\reptusr)? Also, check Use as Windows
credentials when connecting to the data source in datasource properties.
Stjepan
<martinghale@.gmail.com> wrote in message
news:1170983260.446204.25060@.a75g2000cwd.googlegroups.com...
>I have a client that has a unique situation. Here is the back ground
> information:
> A Reporting Services 2005 server in a DMZ. This server is not part of
> any domain, only has local users.
> A SQL Server with the Report Database and an Analysis Services Server
> with the Cubes on which the reports are built are behind the
> firewall. These servers are in a Windowss 2003 Domain using Domain
> accounts for access.
> The issue is getting the Report Server in the DMZ to successfully open
> a report based on a Cube. Using a Standard SQL Server Login we can
> successfully open a report from the Reporting Server in the DMZ that
> uses a relational database behind the firewall. This works obviously
> since we can use a Standard Login and not deal with the domain/no
> domain issue.
> When we try to setup a report that uses the CUBE, we can not get the
> Domain Server to accept our "ghost" user we created. We create a
> user, "reptusr" on the local server in the DMZ. We also created a
> user, "reptusr" in the domain behind the firewall and gave that user
> id access to the CUBE. This is not working.
> I can't find a lot of information on this specific scenario so any
> information anyone may have would be greatly appreciated!
> Thanks in advance!
> Martin
>|||Thank you. Sorry for the delay in getting back. Was out sick.
We have tried that. Have tried everything it seems like. We simply
can not get the report or the Data Source to be able to use Windows
crendentials. Works perfect with SQL Server Login. Plus we are at a
disadvantage as our 'admins' won't actually give us access to the
servers to troubleshoot so we are currently building out a virtual
environment.
Thanks for the suggestion.
Martin