|
Posted by =?Utf-8?B?Skxhd3JlbmNl?= on May 4, 2006, 5:30 pm
If you were Registered and logged in, you could reply and use other advanced thread options
Below is an old post that is exactly the issue I ran into when publishing
OWA on an ISA 2K4 server caused other users to login to someone else's
mailbox. Has there been any fix for this? I can't seem to find much on the
internet about this issue and MS doesn't seem to have anything on there site
(at least from my searching).
Thanks,
--
Jeremy Lawrence
MCP, MCSA, MCSE+S, CEH
Has there been any movement on this issue? I've got the same problem
on my network and it is just too big a security hole to allow to
continue. I've seen a lot of scuttlebutt on the UseNet about the
problem, but nobody seems to have a real solution.
Thanks in advance for your help.
Al Blake wrote:
> OK
> I have found out what is happening and a work around - but it is not
a real
> fix.
> I spent 3 days testing OWA access from the Outside (through ISA)
using a
> win98 'problem' machine and a WinXP 'new' machine.
> It seems that the are problems with the caching of incoming web
requests.
> This means that the ISA box is caching all the incoming OWA stuff.
When it
> receives a request to http://mailserver.ourdns.domain/exchange/ from
a
> different user it
> simply hands back all the info it already has to the client, which
starts to
> build the inbox OF THE LAST LOGGED ON USER!
>
> It is only when it encounters something that needs 'authentication'
that it
> prompts the user for username and password. This is AFTER it has
built
> 'Inbox - UserA' and displayed on UserBs browser but (usually) before
it
> actually displays any messages. If there are problems with the
> authentication mechnism - like the win98 box outlined below it may
build the
> whole thing.
>
> I knew that caching might be an issue so I already had a rule in my
ISA box
> to PREVENT caching of requests to the mail server. It doesnt work. My
rule
> is:
>
> Destination set: mailserver
> Action: Retrieve directly from specified destination.
>
> This should prevent ANY caching of content for that server. It
doesnt. If I
> connect to the OWA server after another user I get their mailbox
constructed
> on my browser BEFORE I get authenticated.
>
> I have confirmed that this is the problem by dropping the incoming
web
> listener and publishing the mail server via a server publishing rule
on port
> 443 (SSL). Since doing this I have not encountered that 'wrong
mailbox'
> problem - which is a relief. I now get prompted to authenticate
BEFORE
> anything gets to my browser. However, this is not ideal as by going
down
> this route I have lost the functionality of the web proxy (ie setting
up
> different rules for different host names).
> Can anyone confirm whether it is possible to TOTALLY disable caching
on
> incoming web requests for a listener?
>
> The problem above was coupled with a second problem applicable only
to
> specific browser/OS combinations. Its seems that the win98/IE6
machine I was
> using to test with CANNOT cope if integrated authentication is
enabled on
> the mail server. Netscape on the same machine is quite happy and
connects to
> OWA without problems - but it uses Basic authentication. IE will not
connect
> and reports 'server not found or dns error' unless integrated
authentication
> is disabled at the server .
> As soon as I disabled Integrated Auth on the OWA server IE quite
happily
> connects and prompts for credentials. I only allow connectivity by
SSL this
> is not too much of a drama - except that I now have to create a
separate
> virtual server under IIS to support my internal LAN users who DO want
> integrated auithentication.
>
> So, two weird problems contributed to the scenario we encountered.
The
> 'inbound caching' one is really worrying because it means that any
user
> could be shown any other users mailbox. Has anyone got a sure fire
way to
> diable this (other than by publishing the port directly which is what
I have
> just done).
>
> Regards
> Al Blake Australia
>
>
> > Please dont tell me this cant happen. It has. I watched it myself
this
> > afternoon with two other experienced engineers:
> >
> > - OWA2k published through ISA server to internet. We allow basic
and
> > integrated authentication at the ISA server and on the ex2k virtual
> servers
> > - SSL access only allowed (443).
> > - SOME clients (100+ out of 1200+) cannot connect to OWA from their
home
> > pcs. When they attempt to connect to OWA mailbox URL they NEVER get
> prompted
> > for authentication but get a "Server or dns error" displayed.
> > - If the SAME clients try to connect to a public folder published
for
> > anonymous access, still using SSL they connect without
difficutlties. (so
> > the certificate and the 128 bit browser stuff is ok)
> > - OCCASIONALLY (we saw it today) they will get connected to an OWA
mailbox
> > that IS NOT THEIR OWN!
> >
> > This is very scary and real. I really have no idea what is going on
but
> our
> > hypothesis is that the message back to the client from the Ex2k
server is
> > getting corrupted by ISA in such a way that some clients cant
understand
> it?
> > Instead of 'please authenticate' they just get 'server problem'.
Even
> > worse - sometimes ISA gets the credentials of one authenticated
connection
> > (current or previous) and applies them to a DIFFERENT
connection...or at
> > least this is what we think is happening.
> >
> > Has any one got any ideas on this? The clients are all running late
model
> > browsers (we just upgraded the one we were testing today from IE5.5
to IE
> > 6.0 but get the same result). Why dont the users get an
authentication
> > prompt?
> > Getting an unauthenticated user connected to a random mailbox
completely
> > blows any OWA security out of the water.
> >
> > Al Blake, Australia
> >
| 
XML site map