[THIN] Re: AW: Re: CSG and WI 2.0 - URGENT
- From: "Chris Lynch" <lynch00@xxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Thu, 25 Sep 2003 11:59:27 -0700
Well, it turned out that the DEFAULT.HTM was redirecting to HTTP, and not to
HTTPS. (this is the one within the METAFRAMEXP folder). Once I entered in
the full path: https://FQDN/citrix/metaframexp/default/logon.asp, the
client browser was able to connect to the website via HTTPS.
So, all is working now, thanks to Citrix, as they were of help for once.
Chris
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Carl Stalhood
Sent: Thursday, September 25, 2003 9:17 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: AW: Re: CSG and WI 2.0 - URGENT
To configure CSG and WI on the same server I do the following:
1. Change the port number of the Default Web Site to 88 or 8080 or
something like that. The Default Web Site does not need to be configured
with SSL.
2. Create another website called Redirect that listens on port 80.
3. Create default.htm to redirect to
https://csg.company.com/Citrix/MetaFrameXP/default.htm. Put this file in the
Redirect web site root folder.
4. Use the CSG web wizard (last page of the wizard) to point CSG to the
Web Interface (specify remote computer, type in IP address of CSG server and
the custom port of the Default Web Site).
Users access the CSG server on port 80. They get the Redirect web site which
redirects them to the CSG server on 443. The CSG server on 443 proxies the
traffic to the Default Web Site on the custom port. When Web Interface is
installed it is installed to the Default Web Site.
Here is a default.htm file that redirects:
<html>
<head>
<META HTTP-EQUIV="Refresh" CONTENT="0;
URL=https://csg.company.com/citrix/MetaFrameXP/default.htm";>
</head>
<body></body>
</html>
Carl Stalhood
Choice Solutions
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of Chris Lynch
Sent: Thursday, September 25, 2003 11:01 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: AW: Re: CSG and WI 2.0 - URGENT
Importance: High
I hate to be picky on this subject, as it is quite old, but CSG DOES NOT
PROXY for the client when you have CSG and WI on the same server. I have
just gone through an installation with this scenario, and the CSG service
REDIRECTS the client to port 80, and does not proxy.
I am only using one server, with one IP address, one SSL certificate, IIS is
listening on TCP 80 and 444, and CSG is configured with WI on the local host
(which CSG is listening on 443).
How do I get the CSG service to either PROXY the client requests, or
redirect to 443 for the WI without using another IP address/server?
Thanks,
Chris
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
Of KOETZING Thomas
Sent: Wednesday, September 10, 2003 1:39 PM
To: 'thin@xxxxxxxxxxxxx'
Subject: [THIN] AW: Re: CSG and WI 2.0
Secure Gateway 2.0 acts as an SSL Proxy for IIS. When you connect using
https to the CSG server, your browser is sending data to the Secure Gateway
service, not IIS. The Secure Gateway service decrypts the request and relays
it to IIS on localhost:80
>but I want to secure my WI login page with HTTPS
There are two ways to deal with this.
1) Restrict access to IIS by IP address
This would be the preferred method in my opinion. Remove the "Require SSL"
checkbox in IIS, but turn on IP address restrictions so that IIS will only
serve pages to the localhost address, 127.0.0.1.
- Right-click Default Web Site, view Properties
- Directory Security tab
- Edit IP address or domain name restrictions
- By default, all computers should be Denied access
- Add an exception for a single computer, 127.0.0.1
This works because the gateway service is the HTTP "client" as far as IIS is
concerned. If access is limited to localhost, then users MUST go through the
gateway service in order to reach IIS (or they must be connecting from the
console of the web server). They will not be able to access port 80 or port
444 directly. Ideally, you should have a firewall that blocks any port other
than 443 anyway.
2) Secure the link between the gateway service and IIS
I don't like this option as much but it also works. Keep the "Require SSL"
option enabled, and reconfigure the gateway service to access IIS as though
it were located on another machine. So instead of saying Web Interface is
installed on "this computer", you say it's installed on another computer,
then enter the FQDN of your IIS server and tell it to secure the link with
HTTPS to the IIS SSL port (444). The gateway service then makes an HTTPS
connection to IIS on the same machine instead of an HTTP connection to
localhost.
The reason I don't like this option as much is because it unnecessarily
slows you down and may introduce more problems if your certificates aren't
all installed correctly. Also if you use this route users will be able to
access the WI site using port 443 (via the gateway service) or port 444
(accessing IIS directly). This could cause some confusion when it's time to
configure your address translation options which are based on the IIS
"client" address.
Thats from JayT
-----Ursprüngliche Nachricht-----
Von: Stuart Hall [mailto:SHall@xxxxxxxxxxxxxx]
Gesendet: Mittwoch, 10. September 2003 22:14
An: thin@xxxxxxxxxxxxx
Betreff: [THIN] Re: CSG and WI 2.0
OK, but I want to secure my WI login page with HTTPS. Somehow with WI and
CSG on the same box the WI forwards the request back through SG?
____________________________
Msg: #45 in digest
Subject: [THIN] Re: CSG and WI 2.0
Date: Wed, 10 Sep 2003 21:03:23 +0200
From: =?iso-8859-1?Q?Anders_Hansen-=D8vre?= <Anders.Hansen-Ovre@xxxxxxxxx>
When you install CSG and WI on the same server you don't have to enable
HTTPS on your IIS. Just install a server certificate and select the
certificate from the SG config. When you access your WI, SG will "relay"
your request from the <https://wi.company.com> https://wi.company.com to
the WI you selected in your SG config. This way you only have to enable
https (port 443) from your unsecure network to the WI/SG server.
Hope this helps.
---
mvh/yours
Anders Hansen-Øvre, Seniorkonsulent
Other related posts:
