Rotorblade
Posts: 1002
Joined: 27.Feb.2007
Status: offline
|
Ok, let’s backup here and see if we can come to a conclusion on your issue
quote:
Current Config.
- I setup 2 new destination sets. 1st for the original website www.mywebsite.com. 2nd for the new website support.mywebsite.com.
Ok, before the destination sets, let’s look at your DNS. From what I'm gathering, it sounds like a DNS issue. You mentioned that you have “split DNS” configured. So that would mean that the internal FQDN naming and the external FQDN naming are the same and has been tested and resolves correctly internally to their respective internal server FQDN to IP? If not, that is issue #1. For any destination set to work, DNS must work! This also leads me to believe that you may have something amiss with your DNS configuration, possibly not resolving to an Internal DNS which is properly configured as a forwarder.
In your original destination set, are there any “Include these destination” entered in the box below?
When creating the two destination sets, be very specific as to the FQDN. For instance, If you’re using mywebsite.com as the destination, then all requests for mywebsite.com will be directed to the web server using that destination in it’s rule! If you have another rule that listens for requests for the FQDN of support. mywebsite.com and the rule is second in order, request will still go to the first rule because you told it too.
quote:
I then setup a New web publishing rule for the new website and selected "Specific Destination" and put /support/* for the folder option.
As I mentioned, using the path of /support/* is probably is not called for because you’re publishing, redirecting to two separate web servers. Using the path in the destination set would mean that the virtual folder structure on the published Web server exists and you’re directing inbound requests based on the FQDN to the virtual folder path. If you are publishing to the “root” web, then using a path other than /* will not work!
Secondly, if you are truly configured for “split DNS” but your internal web server is using a different name, you may need to configure host headers on the IIS web server. In the web rule, you have the option to send the original host header instead of the actual one specified in the redirect box. (IP or name) If you’re redirecting using the “original host header” then the server must be configured as an ISA SecureNAT client. If it is not, requests will fail!
quote:
I updated my Public DNS records to reflect the new support.mywebsite.com.
Good, hopefully your Internal DNS is configured with the proper A zone records or using an alias CNAME to reference the internal servers and not the external IP!
quote:
Just created a user IUSR_<servername>.
Not sure why you would want to do this. The IUSR_servername is the account IIS uses for Anonymous access and by default is created for you at time of install. Setting authentication is either done at the ISA web listener or at the web server. My suggestion to you is to get it working without authentication first then worry about locking it down. If the web server is not a member of the domain, then a local account needs to be configured to authenticate against. Using Basic authentication, it’s is recommended that you use SSL.
Hopefully, this information will be of some help. It’s been a few years since working with ISA 2k!
Anyway, please let me know on your outcome.
HTH
RB
_____________________________
David Melvin
Ohio
MCSE: Security 2003, MCSA:Security 2003
|
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
Printable Version
403 Forbidden ... on ISA Server 2000 - 
RE: 403 Forbidden ... on ISA Server 2000 - 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread