Re: Outlook Web Access through ISA on internal- - - LAN
- From: "Deus, Attonbitus" <Thor@xxxxxxxxxxxxxxx>
- To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx>
- Date: Thu, 16 May 2002 09:40:01 -0700
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 02:08 AM 5/16/2002, you wrote:
>The only thing I can think of that is causing this is something along
>these lines:
>- The Exchange server allows external clients to use basic authentication
>and they don't need Log on Locally rights to do this
I've been testing this to see if I can reproduce it, but
can't. Everything I have ever done w/Basic Auth requires LOL, regardless
of the app running- it must be authenticated before the app kicks in
anyway. My guess is that there is something about your ISA -> Ex2k
authentication that is authenticating these users on ISA, and building an
access token including some sort of group membership that the Exchange
server recognizes as one that can LOL. The way to test this is to go to
the Ex2k, and enable successful "logon events" and "account logon events" -
then have them logon externally- you will see the logon even in Ex2k, and
can examine the username and logon type... If it is Logon Type 2, you
*know* that the user has been granted interactive logon (LOL) rights to the
box, and you can see what ISA is doing to cause this.
This is of particular interest to me, as if you indeed have some membership
structure where the ISA server will pass tokens to the internal Ex2k server
that allows them to impersonate LOL rights without actually having those
rights on the server itself, I would really like to know. I see many
configurations like this where Ex2k is on the DC, and I too want to avoid
giving the scrubs LOL rights for all the DC's.
>- For internal clients the ISA server won't pass Integrated Windows
>Authentication credentials. The Exchange server won't allow internal
>clients to use basic authentication because it recognises that they're
>part of the domain and therefore tries to force Integrated Windows
>Authentication onto them which ISA won't pass. How it recognises this I
>don't know. The IIS logs show that the URLs /Exchange, /Exchange/username
>and /Exchange/username/Inbox all authenticate (HTTP status code 200) but
>as soon as there's a redirect to /Exchweb/controls it fails (HTTP status
>code 401). Perhaps this is the stage at which active content is run which
>determines that it's an internal client not an external one (though this
>would have to be run on the server as there is no active content fetched
>by the client at this stage)? This is pure speculation...!
So, did you go to a client's IE config and add the FDQN to the Intranet
sites, and then verify that "automatically logon only in intranet zone" is
selected? That will ensure that the client first passes NTLM creds to the
site when accessed via the FDQN. Can you check that and let us know?
Thanks
Tim
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1
iQA/AwUBPOPg4YhsmyD15h5gEQK9YgCcCM8fS02ENpwmXfE3Ftv4Joz+Nd0AnAzG
wMtoryNFvTbeQh6G8P0/n7+f
=CHQ2
-----END PGP SIGNATURE-----
Other related posts:
