Posts: 18
Joined: 22.Jul.2002
From: Boston, MA
Status: offline
Thanks, Tom. Do you see a problem with the configuration I have described? It is all "by the book" as far as I can tell, and I have been over it a number of times. Are there some specific setting(s) you think I may have overlooked or configured improperly? (Yes, I have both of your books. Excellent resources!)
Posts: 18
Joined: 22.Jul.2002
From: Boston, MA
Status: offline
I've found what is causing this behavior. My ISA Server is in a separate forest with a one way trust to the internal domain. On the "applies to" tab of the OWA rule, I have an entry of "InternalDomain\OWA Users".
If I remove this and set it back to "Any Request", http requests are immediately rejected with "403 Forbidden", which is what I expected all along. "Https" requests are still processed fine.
I even tried temporarily setting the "Applies to" to a local domain group, but got the same Basic Authentication dialog as before, rather than the "403" error, so I don't think it is specific to my separate forest setup.
I've decided it is better to have the group level control at this point, rather than the proper error response to "http".
You're right. If you require authorization to access the listener, you are challanged to provide credentials when using HTTP. If you don't require authentiation with the listener, then you get the SSL box.
This is a bit concerning because the credentials are being sent in the clear, without SSL protection. If you have users who forget to put the HTTPS in, they could create real problems for you.
The best way to solve this is use an HTTP page that redirects users to the OWA site. Create a page at, for example, http://webmail.domain.com that uses a meta redirect to https://owa.domain.com That way users never need to remember to type HTTPS and you're not exposed to basic credentials crossing the internet when requireing authentication to access the rule.
Posts: 18
Joined: 22.Jul.2002
From: Boston, MA
Status: offline
This is a follow up to my post of January 24th. I opened a case with MS PSS on this problem on January 29th. After investigation, I was informed that the behavior I documented is apparently the designed behavior when ISA evaluates a Web publishing rule. (i.e., when a user or group is assigned in the "applies to" tab, ISA evaluates that part of the rule before it evaluates the SSL requirement).
However, they also agreed that the existing web rule evaluation logic didn't seem appropriate. I clearly don't know if this will get changed, but I can tell you that the case was escalated. I received a call from a "Team Leader" within the "CPR" group who indicated they were now involved.
Posts: 18
Joined: 22.Jul.2002
From: Boston, MA
Status: offline
This is to let everyone know, that after all these months, and working with PSS, Microsoft has fixed the problem I documented in previous posts. See KB article 821724 Titled: "FIX: Basic Credentials May Be Sent over an External HTTP Connection When SSL Is Required".
It turns out this also fixes another issue with Pre-Authentication. With this fix applied, you can now have the Web Publishing rule (OWA in my case) "applies to" tab set to use an internal trusted Domain security group that is allowed to access the web site. ISA will now properly do the pre-authentication of the users before the request is passed on to the web server. So the web server never sees bad login attempts.
I have been using a private build of this fix for several weeks with no problem.
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
Printable Version
All Forums >> [ISA Server 2000 General] >> Web Publishing >> RE: Discussion for Using ISA Server Feature Pack 1 to Forward Basic Authentication 
RE: Discussion for Using ISA Server Feature Pack 1 to F... - 
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