Re: Outlook Web Access through ISA on internal-- - - LAN

  • From: "Thomas W. Shinder" <tshinder@xxxxxxxxxxxxxxxxxx>
  • To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx>
  • Date: Fri, 17 May 2002 14:23:05 -0500

Hi JD,

What does the NetMon trace on the Exchange Server reveal?

Thanks!

Tom
www.isaserver.org/shinder


-----Original Message-----
From: JD [mailto:jgd@xxxxxxxxxxxxxxxx] 
Sent: Thursday, May 16, 2002 2:31 PM
To: [ISAserver.org Discussion List]
Subject: [isalist] Re: Outlook Web Access through ISA on internal-- - -
LAN

http://www.ISAserver.org


> -----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.
> 
Enabled logon events and account logon events (and waited until the
audit
policy had been applied).  Then logged on to OWA from an external
client. 
Nothing shows up in the Audit event log at all.  The W3SVC log shows
that
authentication is happening as mydomain\MyUsername with status code 304
and it all works wonderfully.  This account definitely has no Log on
Locally rights to any DC including the Exchange server - it's a regular
standard user, not member of any admin groups at all.  On the ISA server
I
have the external listener configured for no authentication at all, so
it
should all be passing through to the Exchange box.

> 
> >- 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
> 
I did go to the client's IE config and add the FQDN etc as recommended
but
this made no difference - still got asked for mutliple authentications.

Thanks again for your interest.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 7.1
> 
> iQA/AwUBPOPg4YhsmyD15h5gEQK9YgCcCM8fS02ENpwmXfE3Ftv4Joz+Nd0AnAzG
> wMtoryNFvTbeQh6G8P0/n7+f
> =CHQ2
> -----END PGP SIGNATURE-----

------------------------------------------------------
You are currently subscribed to this ISAserver.org Discussion List as:
tshinder@xxxxxxxxxxxxxxxxxx
To unsubscribe send a blank email to $subst('Email.Unsub')





Other related posts: