Posts: 15
Joined: 6.May2003
From: San Diego, CA
Status: offline
I have done Parts 1 and 2 and I am anxiously awaiting part three. I also need some help trying to configure RPC over HTTP on Exchange 2003 with ISA Server 2000. I am currently using RPC publishing in Feature Pack 1 to publish the exchange server but sometimes firewalls have port 135 blocked so the RPC plushing doesn't work. Hopefully RPC over HTTP will solve this issue.
I wasted a day this week trying to figure it out. I suspect the problem is that you need to hard code the RPC ports. I did get it to work with a Web Publishing rule with a /rpc* for the path along with the /exchange*, /public* and /exchweb* paths. The problem was that it was extraordinarily slow. It may have been a problem with my scenario, because I co-located the Exchange Server with a DC, and the docs say that you need to use a FE/BE config for it to work. I'll try that next week and report my finding for Exchange RPC over HTTP when I get a definitive finding.
I was wondering why you need to enable the Basic authenticate on the ISA box? Is this only for Ecxhange 2003? On Exchange 2000 I don't recall that being necessary. By turning that on, all request for that IP are prompted for authentication.
If you carry out all the procedures as described in parts 1 through 5, you will *not* be asked to authenticate twice. And, you'll allow the ISA Server firewall to forward the authentication request to the OWA site, so unauthenticated users never get near the OWA Web server. Very secure, and very cool!
You need to enable basic auth to provide delegation of basic authentication credentials and to provide the widest availability to clients that do not support integrated authentication (such as Netscape and some versions IE related to bugs).
I've gone through all 5 of the articles as described and it works great! Although I ran into a snag when trying to customize a bit of it. I have another Exchange 2003 server running, and I have it set so that users just need to type in their username, not domain\username. I was under the impression that the basic authentication along with the default domain let them do this. So I tried to do the same on the installation following the article.
Come to find out an odd occurance...the security settings on the exchange directories had changed! Under Directory Security->Authentication and Access Control, on /exchange and /public, the default domain had changed to just "/". Under the /exchweb, the domain was the same as I set it per the article, but anonymous access was turned back on! So I went through and set them all back to how they should be, and now I get a "440 Login Timeout" error when I try to access the page. Never even get to the login.
I did turn on the nice login screen in the System Manager for Exchange, as I have it on the other server.
Also, when you set the directory permissions for the /exchweb folder, it asks if you want those to also apply to /bin and /bin/auth. Do those get the same permissions?
Thanks in advance, and good job with the articles! John Clayton
Thanks for the compliments on the articles. I'll have to go back and see if I mentioned that Exchange likes to go back and change the authentication settings you set on the folders when you restart the server or the services. This was a problem with Exchange 2000 as well, and I know I mentioned it in ISA Server and Beyond regarding Exchange 2000. I go back and look at the articles and make sure I make a note of this "permissions reset" problem. Thanks!
I recall having the same problem with the so-called "forms based" authentication. I'm not sure I resolved that issue. I'll hopefully be doing a comprehensive ISA Server 2000/Exchange Deployment Kit with the same large scope that the VPN Deployment Kit has and I'll have some access to the Exchange team to answer questions like this. I suspect its related to the cookie the forms auth uses or caching. It'll take some troubleshooting, but I'm sure I'll be able to cipher it out. For the time being, I'm not using the forms based auth, just the traditional stuff.
I allow the basic permissions to be used on all folders in the inheritance list and required SSL on all of them too. The philosophy being that both internal and external users that access OWA should be using SSL. In a future article I'll discuss scenarios using client certificate authentication and two-factor authentication using tools like the very cool Authenex AOne product (www.authenex.com).
Posts: 1
Joined: 21.Feb.2003
From: San Diego, CA
Status: offline
Hello Tom:
We met briefly at TechEd. 2003, ( My company ran the Internet CafT Kiosks, and I asked you about the IPSEC VPNs for NORTEL. Thanks again for the 'threads' by the way.)
I followed your 5 chapter dissertation on installation of ISA on Windows 2003 for Exchange OWA 2003. In part 5, there is a check box in the web publishing rule that states ôallow delegation of basic authentication credentialsö that does not appear on my server.
Can you explain to me how to be able to enforce that, or should I consider reinstalling from scratch. The original ISA was installed on a Win 2000 enterprise server and upgraded with 2003. I also installed the HotFix for 2003 and FP1 (SP1 was already on the machine.)
Yes, I remember you well! I hope you're wearing those threads in fine fashion
The delegation option appears after installing Feature Pack 1. You may need to restart the console, or the server. I don't recall needing to restart the server, but I do always close the ISA Management console before installing the feature pack.
One thing worth checking is whether basic authentication is enabled on the Incoming Web Requests listener.
I went through all five steps and i gotta say it worked liked a charm. I was surprised as I usually have to go back and tweak things a little. I do have one thing to add. How can you set it up so that the user just types in mail.domain.com in the address bar and get redirected to https://mail.domain.com/exchange ?
Thanks! Good to hear that you got it working. I'm hoping that we'll be able to put an entire ISA/Exchange Secure remote email access Kit together in the next month or so.
Jason Jones has some good recs for you regarding making things simpler for your users:
Jason Jones Senior Member Member # 8026
Member Rated: posted June 11, 2003 06:46 PM -------------------------------------------------------------------------------- Two ways simple ways...
Non-ASP:
Place a default.htm file in the web root with the following text in it (without dashes):
Hi Tom, thanks for this great article. I have followed parts 1-5 and checked everthing twice. I am able to login securly but everytime I do all it says is Loading... in the inbox. I am not able to view messages in my inbox. All the graphics and frames show up fine.
One thing to note, that when i use http://10.10.1.5/exchange (my internal server ip) everthing works ok. I DO NOT get the loading... text. I can see all the messages in the inbox.
Any ideas on what I could be my problem?
Thank you for all your help!, Sotty for double post!
quote:Originally posted by murph123: Hi Tom, thanks for this great article. I have followed parts 1-5 and checked everthing twice. I am able to login securly but everytime I do all it says is Loading... in the inbox. I am not able to view messages in my inbox. All the graphics and frames show up fine.
One thing to note, that when i use http://10.10.1.5/exchange (my internal server ip) everthing works ok. I DO NOT get the loading... text. I can see all the messages in the inbox.
Any ideas on what I could be my problem?
Thank you for all your help!, Sotty for double post!
Murph
Hi Murph,
Make sure you're testing from an EXTERNAL network host.
Also, the Destination Set in the Web Publishing Rules must use FQDNs, never, EVER IP addresses.
P.S. Remove the **'s from above text as I couldn't post without adding these...
-OR-
ASP:
Place a default.asp file in the web root with the following text in it (without dashes):
-----------
<% Response.Redirect "/Exchange/" %>
HTH, Tom
Tom,
Thanks for the response earlier. I did have a question regarding this response of yours.
I've seen in many places how to do the redirection with a web page, such as the ASP sample. I've found it also works by making another web site under IIS, and simply setting the home directory to something else. For instance I can run only 1 certificate, as I only have 1 IP. So anything I run secure is at secure.mydomain. I want easy access, so that webmail.mydomain forwards to secure.mydomain/exchange. This works well so far (except IE takes forever to claim that the certificate is self-signed).
I was wondering 2 things about the page redirection. Is there any benefit of using an ASP page to redirect as opposed to setting IIS to redirect? And is there any way to have ISA send the redirection? As I understand it, one of the benefits of using ISA publishing is that, like in the article, ISA authenticates and can reject bad traffic before it even gets to the E2k3 box. If so, could ISA redirect them without having to get to the E2k machine to keep that secure?
Perhaps there are other methods. But I'm sort of a hard a**. If the users can't remember to type /exchange/ at the end, I figure they're just playing games with me. They're able to get out of bed in the morning, take bread out of a bag and actually put it in a toaster, push the lever down, and take it out when its done. Then they take a knife out of the drawer, push it through a slab of butter, and then move that slab on the knife over hot bread.
Are you telling me that if someone can make toast and butter it, that they can't type /exchange/ in the path?
That always provides context and allows me to get back to some real work.
P.S. Remove the **'s from above text as I couldn't post without adding these...
-OR-
ASP:
Place a default.asp file in the web root with the following text in it (without dashes):
-----------
<% Response.Redirect "/Exchange/" %>
HTH, Tom
Tom,
Thanks for the response earlier. I did have a question regarding this response of yours.
I've seen in many places how to do the redirection with a web page, such as the ASP sample. I've found it also works by making another web site under IIS, and simply setting the home directory to something else. For instance I can run only 1 certificate, as I only have 1 IP. So anything I run secure is at secure.mydomain. I want easy access, so that webmail.mydomain forwards to secure.mydomain/exchange. This works well so far (except IE takes forever to claim that the certificate is self-signed).
I was wondering 2 things about the page redirection. Is there any benefit of using an ASP page to redirect as opposed to setting IIS to redirect? And is there any way to have ISA send the redirection? As I understand it, one of the benefits of using ISA publishing is that, like in the article, ISA authenticates and can reject bad traffic before it even gets to the E2k3 box. If so, could ISA redirect them without having to get to the E2k machine to keep that secure?
Thanks again, John Clayton
Hi John,
Jim Harrison is a kinder soul than I, and he has some cool redirect pages over at www.isatools.org
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
Printable Version
All Forums >> [ISA Server 2000 General] >> General >> Discussion of Publishing OWA 2003 article 
Discussion of Publishing OWA 2003 article - 
![[Big Grin]](/image/smiles/biggrin.gif)
RE: Discussion of Publishing OWA 2003 article - ![[Wink]](/image/smiles/wink.gif)
RE: Discussion of Publishing OWA 2003 article - 
RE: Discussion of Publishing OWA 2003 article - ![[Smile]](/image/smiles/smile.gif)
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