In the Article (part1) Tom talks about advanced settings regarding the use of different ports on the Terminal server. In the article below you can read: "How to Change the Listening Port in the Windows Terminal Server Web Client" :
Posts: 37
Joined: 16.Dec.2003
From: Upstate NY
Status: offline
Hi, I just went through this article and set up a server on our ISA Array to publish RDP using this method. The ISA Servers are in the domain, and I've checked the set up, but when I get the authentication dialog box, it won't accept any authentication. I have made certain that All Authorized Users is the user group in the listener, and that Basic authentication is all that's selected. I get the error page that authentication is required. Any hints? Thanks, G
I am having trouble publishing my terminal server through ISA2004. Here is my set up: ISA 2004 on Win 2003 SP1 with rules for OWA publishing and a RPC over HTTP publishing using the same SSL listener. Now when I follow Tom's article I get the message there is already a listener using a similar IP address or port. I understand after researching that this is because of my owa ssl listener, but I was wondering what my options were to bring my terminal server behind ISA. Could I simply put the terminal server behind ISA without using ssl? I know this is less secure but no less secure then what we currently have.
Posts: 37
Joined: 16.Dec.2003
From: Upstate NY
Status: offline
Just a follow up - I since found out that you need to use two SSL certs, not just one. The one that you create and install on the ISA server must have the common name of the public site being accessed. The second one that you create and install on the web server, must match the internal name of the server being published. While it was implied in 4 or 5 different spots in the article, it was never stated just that plainly, that "you need two certs with different names". After I installed those certs, it worked fine. Now, of course, I'm having problems with the RDP side of the connection, which will take another few hours/days to weed out.
You don't need two different certs. In fact, I almost never use two different certs. As long as you have a well designed split DNS (or even a simple HOSTS file entry) you can use the same cert on both the ISA firewall and the Web site. I do this about 99.98745 of the time.
For the split DNS, your ISA server needs to point to a DNS server that can resolve the host name to the proper internal IP Address... I use the 1 cert only for each of my SSL sites, point my ISA server to an internal DNS server, and forward external requests from that DNS server to the internet..
Tom,
How do you feel about allowing access through the firewall from browsers on computers that you don't control?? You always hear about the danger of public terminals possibly possessing key loggers or other malware that could be used to get access credentials?? Is this an application where you really need an application like SecureID?
Posts: 37
Joined: 16.Dec.2003
From: Upstate NY
Status: offline
Well, I needed two certs. In Microsoft's article:" Troubleshooting SSL Certificates in ISA Server 2004 Publishing", it states "The name of the certificate on the ISA Server computer must match the name that external clients will specify to reach the published Web site." and in the same article, referring to HTTPS to HTTPS connections, it states "...the name of the certificate on the IIS Web site of the published server must match the name by which ISA Server identifies the Web server", thereby implying that you need two certs. And, in Microsoft's article "Publishing Multiple Web Sites using a Wildcard Certificate in ISA Server 2004", it describes the method of using the Wildcard cert, then replacing the Wildcard cert with the internal common name cert on the internal Web server. We were receiving the 500 error regarding the "Target Principal Name" Using a Hosts entry didn't work to correct this problem, I tried that. I read this article AFTER I discovered that the two certs worked. I then changed and issued the Wildcard cert on the ISA server so I wouldn't have to create a new listener on the ISA every time. The reason is; we have a single solid DNS structure internally with a different internal domain name (internalcompany.org) than external public domain name (externalcompany.org), which initially had no public servers hosted from our network. This design was the prevailing wisdom at the time we implemented Windows 2000 Active Directory and is the same as (I'm certain), 99.98745% of the companies out there. Thanks for your reply! HTH Gary
I am in the same boat is you as far as internal versus external domains...
Here is how I set up my DNS. Depending on how many external hosts you have, this may be cumbersome for you, but it works for me!
Internal AD domain, internalcompany.org set up in DNS.
Second Zone create for externalcompany.org, with entries for hosts on the internet and whatever hosts exist internally. This allows me to browse internal hosts by their external host name so that employees can access resources by the same name whether they are on the road or at work.
So, when I host www.externalcompany.org on my DMZ let of my ISA server, I create an A record on our external DNS servers for the internet IP address and an A record on our internal DNS servers for the DMZ IP address. The ISA server points to the internal DNS server for name resolution. Now, when I publish SSL sites, I initially install the SSL cert on my web server, then export it and install it on the listener in ISA and publish the server from the DMZ to the internet. Since the client on the internet resolves the www.externalcompany.org to the listener on ISA, and ISA resolves www.externalcompany.org to the DMZ IP Address, the certificate is valid for both the original client AND the ISA server and works fine.
In any case, your solution of the wild card cert works great too as long as you have a single domain (I am not so lucky).
Posts: 37
Joined: 16.Dec.2003
From: Upstate NY
Status: offline
Tony, Thanks for that insight. I did once have a new zone on our DNS servers to handle external addresses, but I eliminated it. It sounds like it works for you without setting up 2 DNS servers. We don't host our own public DNS, but rather contact our registrar company to do the public changes. I'll probably experiment with that.
I actually use our registrar to manage DNS as well... I just recreate those entries on our internal DNS server for the same zone and private addresses.
Well, I needed two certs. In Microsoft's article:" Troubleshooting SSL Certificates in ISA Server 2004 Publishing", it states "The name of the certificate on the ISA Server computer must match the name that external clients will specify to reach the published Web site." and in the same article, referring to HTTPS to HTTPS connections, it states "...the name of the certificate on the IIS Web site of the published server must match the name by which ISA Server identifies the Web server", thereby implying that you need two certs. And, in Microsoft's article "Publishing Multiple Web Sites using a Wildcard Certificate in ISA Server 2004", it describes the method of using the Wildcard cert, then replacing the Wildcard cert with the internal common name cert on the internal Web server. We were receiving the 500 error regarding the "Target Principal Name" Using a Hosts entry didn't work to correct this problem, I tried that. I read this article AFTER I discovered that the two certs worked. I then changed and issued the Wildcard cert on the ISA server so I wouldn't have to create a new listener on the ISA every time. The reason is; we have a single solid DNS structure internally with a different internal domain name (internalcompany.org) than external public domain name (externalcompany.org), which initially had no public servers hosted from our network. This design was the prevailing wisdom at the time we implemented Windows 2000 Active Directory and is the same as (I'm certain), 99.98745% of the companies out there. Thanks for your reply! HTH Gary
Hi Gary,
You really don't need two different certs. If you read thorugh the articles on this site you'll learn lots of tips and tricks used by the ISA pros that show you how to make this work. Best and easiest way is to use a single cert, and create a well-designed split DNS. This was the most common configuration I heard about from the ISA firewall pros I talked to last week at TechEd.
I am in the same boat is you as far as internal versus external domains...
Here is how I set up my DNS. Depending on how many external hosts you have, this may be cumbersome for you, but it works for me!
Internal AD domain, internalcompany.org set up in DNS.
Second Zone create for externalcompany.org, with entries for hosts on the internet and whatever hosts exist internally. This allows me to browse internal hosts by their external host name so that employees can access resources by the same name whether they are on the road or at work.
So, when I host www.externalcompany.org on my DMZ let of my ISA server, I create an A record on our external DNS servers for the internet IP address and an A record on our internal DNS servers for the DMZ IP address. The ISA server points to the internal DNS server for name resolution. Now, when I publish SSL sites, I initially install the SSL cert on my web server, then export it and install it on the listener in ISA and publish the server from the DMZ to the internet. Since the client on the internet resolves the www.externalcompany.org to the listener on ISA, and ISA resolves www.externalcompany.org to the DMZ IP Address, the certificate is valid for both the original client AND the ISA server and works fine.
In any case, your solution of the wild card cert works great too as long as you have a single domain (I am not so lucky).
The AD domain and the internet domain name are not the same, and I am stuck with that...
So, I implemented "parallel" Split DNS that you mention in that article. My internal users will resolve the external domains to the internal addresses, as will the ISA server eliminating the need to remember different FQDN's.
I just did a TERRIBLE job of describing my implementation...
I SHOULD have just put a link in to your article and said "due to poor decision making by previous AD admins, I am stuck with 'parallel' Split DNS"!!
If only that was the worst of the poor decisions the previous admins made! (apparently nobody ever told them that you can apply rights to a Group OR that there is a 260 character limit full path names)
Tony
< Message edited by tonygauderman -- 23.Jun.2006 9:33:28 PM >
No problem with a parallel split DNS. I use them sometimes in environments that I build from the ground up.
I've been there too! Sometimes I think it would be easier to rebuilt from the ground up than to try to undo what the guys who came in before did. But I try to avoid it at all costs :)