I don't know how I can succinctly express my problem other than I've got all
the latest bits for SQL Server 2000, Reporting Services, service packs,
etc... installed. I have Share Point Portal / IIS 6 / Windows 2003 / SQL
Server 2000 all installed on same box.
I followed all directions to install Reporting Services correctly under this
configuration and, lo and behold, everything worked as advertised.
After I got the above stack working under a non SSL mode, I proceeded to
setup an SSL only option for IIS. No biggie. Everything works just fine! I
created a CA key using OpenSSL and signed my IIS cert request and installed
into IIS and Share Point and SQL Reporting Services are all very cool with
this. Of course, I installed the CA cert in my Trusted Root Authorities on
the server and my client.
So what's the problem, right? Well I want to do the unthinkable. I want to
expose my Reporting Server on the Internet behind an ISA server (in the DMZ).
So to make this work, of course, everyone on the planet needs to use an FQDN
rather than my local machine name.
There's lots of advice on the net and in various technet articles from MS
about how to do this. Just update the ReportServerUrl in the ReportManager
app config file. I did that. Some people believe you should update the
UrlRoot in the ReportServer config file. I've tried that and all
combinations to no avail.
So the deal is if come into the ReportManager virtual using anything other
than the local host name of the machine I get one of two errors (after a long
timeout):
1. Underlying connection was closed: could not establish trust relationship
with remote server.
-or-
2. Underlying connection was closed: unable to connect to the remote server.
I think I've tried everything I can think of. I don't think it could be SSL
related because SSL works if I setup the Reporting server config files to be
based upon the local host name of the machine. My virtual directories in IIS
only permit SSL connectivity to both Reports and ReportServer virtuals.
I also have played around with the SecureConnectionLevel parameter in both
config files (making it something like "2" in each to no avail).
I'm beat! I've tried any and all combinations and just cannot seem to
change the name by which I can access the report server.
Oh, in case you are curious, the FQDN of the internal server is something
like "server1.edc.local". If I setup the config files to come in either via
"server1" or "server1.edc.local" (hey, that's a FQDN, right?) then all works
fine.
The FQDN for the server on the internet will be something like
"www.edc.mycompany.com" which has no relation to the Active Directory domain
name (which ends in .local). Of course, this FQDN gives me serious fits.
Any ideas on what to try next?
JohnWhat's the name on the Certificate used for SSL? Sounds like this
http://support.microsoft.com/default.aspx?scid=kb;en-us;823177 from the
error you are seeing.
--
HTH
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"John" <John@.discussions.microsoft.com> wrote in message
news:B6A8E286-2598-44AC-9E82-49C219ADACC0@.microsoft.com...
>I don't know how I can succinctly express my problem other than I've got
>all
> the latest bits for SQL Server 2000, Reporting Services, service packs,
> etc... installed. I have Share Point Portal / IIS 6 / Windows 2003 / SQL
> Server 2000 all installed on same box.
> I followed all directions to install Reporting Services correctly under
> this
> configuration and, lo and behold, everything worked as advertised.
> After I got the above stack working under a non SSL mode, I proceeded to
> setup an SSL only option for IIS. No biggie. Everything works just fine!
> I
> created a CA key using OpenSSL and signed my IIS cert request and
> installed
> into IIS and Share Point and SQL Reporting Services are all very cool with
> this. Of course, I installed the CA cert in my Trusted Root Authorities
> on
> the server and my client.
> So what's the problem, right? Well I want to do the unthinkable. I want
> to
> expose my Reporting Server on the Internet behind an ISA server (in the
> DMZ).
> So to make this work, of course, everyone on the planet needs to use an
> FQDN
> rather than my local machine name.
> There's lots of advice on the net and in various technet articles from MS
> about how to do this. Just update the ReportServerUrl in the
> ReportManager
> app config file. I did that. Some people believe you should update the
> UrlRoot in the ReportServer config file. I've tried that and all
> combinations to no avail.
> So the deal is if come into the ReportManager virtual using anything other
> than the local host name of the machine I get one of two errors (after a
> long
> timeout):
> 1. Underlying connection was closed: could not establish trust
> relationship
> with remote server.
> -or-
> 2. Underlying connection was closed: unable to connect to the remote
> server.
> I think I've tried everything I can think of. I don't think it could be
> SSL
> related because SSL works if I setup the Reporting server config files to
> be
> based upon the local host name of the machine. My virtual directories in
> IIS
> only permit SSL connectivity to both Reports and ReportServer virtuals.
> I also have played around with the SecureConnectionLevel parameter in both
> config files (making it something like "2" in each to no avail).
> I'm beat! I've tried any and all combinations and just cannot seem to
> change the name by which I can access the report server.
> Oh, in case you are curious, the FQDN of the internal server is something
> like "server1.edc.local". If I setup the config files to come in either
> via
> "server1" or "server1.edc.local" (hey, that's a FQDN, right?) then all
> works
> fine.
> The FQDN for the server on the internet will be something like
> "www.edc.mycompany.com" which has no relation to the Active Directory
> domain
> name (which ends in .local). Of course, this FQDN gives me serious fits.
> Any ideas on what to try next?
> John|||"Jasper Smith" wrote:
> What's the name on the Certificate used for SSL? Sounds like this
> http://support.microsoft.com/default.aspx?scid=kb;en-us;823177 from the
> error you are seeing.
I neglected to mention (somehow) that as I've tried both the inside and
outside FQDN attempts I do have two certs. I have a cert for the inside
(local) FQDN -- this one works as I said. When I flip all the configs around
to be using the outside FQDN, I use a cert for IIS that exactly matches (case
and all) the outside FQDN. No go. I even restart IIS and the Reporting
service thinking this might be it, but nothing.
Any other tricks to try?
John|||Is it just Report Manager giving the error, can you access the Report Server
web service ok (i.e. just go to https://externalname/ReportServer) and run a
report from there or do you get the same error?
--
HTH
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"John" <John@.discussions.microsoft.com> wrote in message
news:9FEE56AF-913A-4496-9D6A-C0FFCDA2C143@.microsoft.com...
> "Jasper Smith" wrote:
>> What's the name on the Certificate used for SSL? Sounds like this
>> http://support.microsoft.com/default.aspx?scid=kb;en-us;823177 from the
>> error you are seeing.
> I neglected to mention (somehow) that as I've tried both the inside and
> outside FQDN attempts I do have two certs. I have a cert for the inside
> (local) FQDN -- this one works as I said. When I flip all the configs
> around
> to be using the outside FQDN, I use a cert for IIS that exactly matches
> (case
> and all) the outside FQDN. No go. I even restart IIS and the Reporting
> service thinking this might be it, but nothing.
> Any other tricks to try?
> John|||"Jasper Smith" wrote:
> What's the name on the Certificate used for SSL? Sounds like this
> http://support.microsoft.com/default.aspx?scid=kb;en-us;823177 from the
> error you are seeing.
So the kb article talks about two scenarios. My certs match the URL I am
coming in on (as previously stated in a prior post), but the other scenario
seems more like what I have.
From the kb article:
"Other scenarios exist also. For example, some networks use a different
name-resolution scheme for internal versus external clients. In cases where
the certificate is issued to a server with a public URL (such as
www.adatum.com) and with intranet applications, the internal Domain Name
System (DNS) Server provides a different name for the same server (such as
www.internal.corporate.adatum.com). Requests for this Web service over SSL
may fail. This change is made to enhance the security of Web services that
use SSL."
The kb article subsequently states a possible remedy in unclear terms, as
follows:
"You can change the name-resolution scheme so that DNS provides the same
name for a server. The same name for the server must be used whether the
server is referred to from in the company or from outside the company.
For example, assume that a certificate has been issued to the URL
www.adatum.com. Any Web service application that is referred from outside the
organization is called by using the external DNS resolution schema
(www.adatum.com). When an intranet Web service application is called, the
internal DNS translates the name of the site as
www.internal.corporate.adatum.com. Therefore, any request for the Web Service
over SSL may fail unless you change the name-resolution scheme. "
So what does this really mean? Does it mean I can fix it somehow in DNS
(which I run out of my local AD) or does it mean I must rename my AD domain
(which is edc.local right now) to something that permits me to put the server
in the proper DNS zone (in this case mycompany.com).
What I am looking for right now is a quick fix without having to forklift my
AD into a new domain name. Any thoughts on what it means to change the
name-resolution scheme and what that translates to?
Regards,
John|||"Jasper Smith" wrote:
> Is it just Report Manager giving the error, can you access the Report Server
> web service ok (i.e. just go to https://externalname/ReportServer) and run a
> report from there or do you get the same error?
Yes, you can access the report server directly using either scheme (internal
or external FQDN scheme). This has always seemed to work so the problem is
limited to the ReportManager only as it is using the .NET Web service
technoloy that is really really mad about something.
Geesh -- I hope this gets easier with reporting services because I'm no
script kiddie and I feel like setting up reporting services to work in a real
internet setting is daunting to say the least!
John|||Anyone have any thoughts on the following I posted late last week to this
group? Specifically, the kb article (823177) states the following:
"You can change the name-resolution scheme so that DNS provides the same
name for a server. The same name for the server must be used whether the
server is referred to from in the company or from outside the company"
So I have done essential what this kb article suggest. The internal FQDN
host name on my box is server1.edc.local. Outsiders access this server via
my DMZ ISA server using the URL https://www.edc.mycompany.com.
So in addition to my outside DNS resolving www.edc.mycompany.com to my
front-end ISA server, I setup a split-DNS on the inside that resolves
www.edc.mycompany.com to the same IP address as server1.edc.local.
This *does not work* though. I still get the same error the KB article
describes. So what I am looking for is, do I have to renamed my local AD
domain to something like edc.mycompany.com and then rename server1 to www to
get this to work? Is that what the article's plan of action entails or is
there something else I can try?
John
"John" wrote:
> "Jasper Smith" wrote:
> > What's the name on the Certificate used for SSL? Sounds like this
> > http://support.microsoft.com/default.aspx?scid=kb;en-us;823177 from the
> > error you are seeing.
> So the kb article talks about two scenarios. My certs match the URL I am
> coming in on (as previously stated in a prior post), but the other scenario
> seems more like what I have.
> From the kb article:
> "Other scenarios exist also. For example, some networks use a different
> name-resolution scheme for internal versus external clients. In cases where
> the certificate is issued to a server with a public URL (such as
> www.adatum.com) and with intranet applications, the internal Domain Name
> System (DNS) Server provides a different name for the same server (such as
> www.internal.corporate.adatum.com). Requests for this Web service over SSL
> may fail. This change is made to enhance the security of Web services that
> use SSL."
> The kb article subsequently states a possible remedy in unclear terms, as
> follows:
> "You can change the name-resolution scheme so that DNS provides the same
> name for a server. The same name for the server must be used whether the
> server is referred to from in the company or from outside the company.
> For example, assume that a certificate has been issued to the URL
> www.adatum.com. Any Web service application that is referred from outside the
> organization is called by using the external DNS resolution schema
> (www.adatum.com). When an intranet Web service application is called, the
> internal DNS translates the name of the site as
> www.internal.corporate.adatum.com. Therefore, any request for the Web Service
> over SSL may fail unless you change the name-resolution scheme. "
> So what does this really mean? Does it mean I can fix it somehow in DNS
> (which I run out of my local AD) or does it mean I must rename my AD domain
> (which is edc.local right now) to something that permits me to put the server
> in the proper DNS zone (in this case mycompany.com).
> What I am looking for right now is a quick fix without having to forklift my
> AD into a new domain name. Any thoughts on what it means to change the
> name-resolution scheme and what that translates to?
> Regards,
> John|||John,
I am hoping this message will find you. Basically, you need to change the
links in the Reporting Services configuration file to match that of your
external link. There are 2 folders under C:\Program Files\Microsoft SQL
Server\MSSQL\Reporting Services\ReportManager and C:\Program Files\Microsoft
SQL Server\MSSQL\Reporting Services\ReportManager and ReportServer, look for
RSWebApplication.config and RSReportServer.config respectively and change to
(ie https://www.mydomain.com/Reports). Just have to make sure that
www.mydomain.com on the internal network resolves to the INTERNAL ip address
of the web server hosting Reporting Services and sounds like you may have
done that. Basically, INTERNAL clients pings www.mydomain.com will get
10.0.0.5 and EXTERNAL ping www.mydomain.com will get 208.11.111.111. Gluck.
"John" wrote:
> Anyone have any thoughts on the following I posted late last week to this
> group? Specifically, the kb article (823177) states the following:
> "You can change the name-resolution scheme so that DNS provides the same
> name for a server. The same name for the server must be used whether the
> server is referred to from in the company or from outside the company"
> So I have done essential what this kb article suggest. The internal FQDN
> host name on my box is server1.edc.local. Outsiders access this server via
> my DMZ ISA server using the URL https://www.edc.mycompany.com.
> So in addition to my outside DNS resolving www.edc.mycompany.com to my
> front-end ISA server, I setup a split-DNS on the inside that resolves
> www.edc.mycompany.com to the same IP address as server1.edc.local.
> This *does not work* though. I still get the same error the KB article
> describes. So what I am looking for is, do I have to renamed my local AD
> domain to something like edc.mycompany.com and then rename server1 to www to
> get this to work? Is that what the article's plan of action entails or is
> there something else I can try?
> John
> "John" wrote:
> > "Jasper Smith" wrote:
> >
> > > What's the name on the Certificate used for SSL? Sounds like this
> > > http://support.microsoft.com/default.aspx?scid=kb;en-us;823177 from the
> > > error you are seeing.
> >
> > So the kb article talks about two scenarios. My certs match the URL I am
> > coming in on (as previously stated in a prior post), but the other scenario
> > seems more like what I have.
> >
> > From the kb article:
> >
> > "Other scenarios exist also. For example, some networks use a different
> > name-resolution scheme for internal versus external clients. In cases where
> > the certificate is issued to a server with a public URL (such as
> > www.adatum.com) and with intranet applications, the internal Domain Name
> > System (DNS) Server provides a different name for the same server (such as
> > www.internal.corporate.adatum.com). Requests for this Web service over SSL
> > may fail. This change is made to enhance the security of Web services that
> > use SSL."
> >
> > The kb article subsequently states a possible remedy in unclear terms, as
> > follows:
> >
> > "You can change the name-resolution scheme so that DNS provides the same
> > name for a server. The same name for the server must be used whether the
> > server is referred to from in the company or from outside the company.
> >
> > For example, assume that a certificate has been issued to the URL
> > www.adatum.com. Any Web service application that is referred from outside the
> > organization is called by using the external DNS resolution schema
> > (www.adatum.com). When an intranet Web service application is called, the
> > internal DNS translates the name of the site as
> > www.internal.corporate.adatum.com. Therefore, any request for the Web Service
> > over SSL may fail unless you change the name-resolution scheme. "
> >
> > So what does this really mean? Does it mean I can fix it somehow in DNS
> > (which I run out of my local AD) or does it mean I must rename my AD domain
> > (which is edc.local right now) to something that permits me to put the server
> > in the proper DNS zone (in this case mycompany.com).
> >
> > What I am looking for right now is a quick fix without having to forklift my
> > AD into a new domain name. Any thoughts on what it means to change the
> > name-resolution scheme and what that translates to?
> >
> > Regards,
> >
> > John
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment