Exchange Server Forums

Forums | Register | Login | My Profile | Inbox | RSS RSS icon | My Subscription | My Forums | Address Book | Member List | Search | FAQ | Ticket List | Log Out

Form Based and Integrated Windows Authentication Clashing?

Users viewing this topic: none

Logged in as: Guest
  Printable Version
All Forums >> [Microsoft Exchange 2003] >> Outlook Web Access >> Form Based and Integrated Windows Authentication Clashing? Page: [1]
Login
Message << Older Topic   Newer Topic >>
Limited time MSExchange.org offer! -- 1.Sep.2008 1:00:00 PM
TechGenix and SolarWinds have partnered to provide free copies of SolarWinds Exchange Monitor to all visitors who join the MSExchange.org Forums. SolarWinds Exchange Monitor is a handy desktop dashboard that continuously monitors Microsoft Exchange to deliver real-time insight into Exchange services, mail queue sizes, and host server health. Learn more about Exchange Monitor and the free offer!
Form Based and Integrated Windows Authentication Clash... - 24.Sep.2008 11:45:04 AM   
wozzles

 

Posts: 11
Joined: 16.Sep.2008
Status: offline
Exchange 2003 SP2 in FE/BE, both on Windows Server 2003 Stan Ed
 
Hi All,
 
We have a bizarre problem whereby hitting the https://domain/exchange URL directly (internally or externally) causes us no issues; but when our users already have our corporate intranet pages open and then type the OWA URL into their browser, their login fails (the OWA login screen displays OK).  We have tried launching the OWA URL from our intranet via shortcut that opens in a new window, but the same problem occurs.
 
Some of you may be thinking "just get the users to type the URL directly". Valid point, but our corporate machines run in locked down environment and they have no access to the Run... command and they IE6 home page is set to the corporate intranet. Hey presto...problem!  Outside the org, they type in directly; but we want our roaming users to use OWA from the offices they are visiting.
 
I am certain this is related to Intergrated Windows Authentication, https and OWA; but I have no idea how.
 
Our configuration is as follows:
 
FE Server:
Windows Server 2003 R2 Standard Ed
Exchange 2003 SP2 in FE Mode
IIS 6
Default web site is our corporate intranet
Default web site requires https and valid certificate from Comodo is in place
Default web site has IWA enabled - to allow invisible logon from LAN/domain.  When users hit intranet from outside organisation, they receive standard username/password challenge dialog box
OWA configured for forms based authentication
Exchange Virtual Directory configured for basic authentication only
 
BE Server:
Windows Server 2003 Standard Ed
Exchange 2003 SP2 in BE Mode
IIS 6
Exchange Virtual Directory configured for basic authentication only
 
I should explain that our users are getting the following error after entering their details in the OWA form logon screen...

https://domain/exchweb/bin/auth/owaauth.dll
HTTP 400 - Bad Request

And the IIS default website logs is reporting...

2008-09-24 15:24:15 192.168.2.1 POST /exchweb/bin/auth/owaauth.dll - 443 - 192.168.2.50
Mozilla/4.0+ compatible;+MSIE+6.0;+Windows+NT+5.1;+SV1;+.NET+
CLR+1.0.3705;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727) https://domain/exchweb/bin/auth/owalogon.asp?url=https://domain/webmail&reason=0 400 0 0
 
And the FE server Security logs are reporting...
 
Success Audit Logon/Logoff 538
Success Audit Logon/Logoff 540
 
which detail the successful kerberos authentication to the Exchange BE server.
 
 
Can anyone help me here?
 
TIA,
 
Ade
 

< Message edited by wozzles -- 26.Sep.2008 4:07:48 PM >
Post #: 1
RE: Form Based and Integrated Windows Authentication C... - 24.Sep.2008 11:52:02 AM   
leederbyshire

 

Posts: 968
Joined: 4.Jan.2006
Status: offline
A 400-Bad Request response from IIS when FBA is enabled is normally the result of a Host Header name being configured for the Default Web Site.

_____________________________

Lee.
___________________________________

Outlook Web Access for PDA and WAP:
www.leederbyshire.com
___________________________________

(in reply to wozzles)
Post #: 2
RE: Form Based and Integrated Windows Authentication C... - 24.Sep.2008 2:43:37 PM   
wozzles

 

Posts: 11
Joined: 16.Sep.2008
Status: offline
Hi Lee,
 
Many thanks for getting back so quickly - this IIS server used to use host headers on its (4 or so) web sites, but when we went live with our intranet we required https and thus host headers couldn't be used.  So, we removed the host headers and now use ports for the other sites.
 
The default web site responds to 80 and 443, but does require https; so nothing is really served on port 80.
 
Have checked the site settings and no host header is specified. Have checked for white space and applied setting. No difference I'm afraid.
 
If this is the issue, could a setting be stuck in the registry (or elsewhere)?
 
TIA,
 
Ade

(in reply to leederbyshire)
Post #: 3
RE: Form Based and Integrated Windows Authentication C... - 24.Sep.2008 3:08:27 PM   
leederbyshire

 

Posts: 968
Joined: 4.Jan.2006
Status: offline
Is the Default Web Site configured to use a specific IP Address, or 'All Unassigned'?

_____________________________

Lee.
___________________________________

Outlook Web Access for PDA and WAP:
www.leederbyshire.com
___________________________________

(in reply to wozzles)
Post #: 4
RE: Form Based and Integrated Windows Authentication C... - 24.Sep.2008 3:34:19 PM   
wozzles

 

Posts: 11
Joined: 16.Sep.2008
Status: offline
"All unassigned" - it has to be, the web server is multi-homed. One NIC to the LAN and one NIC to the DMZ (with public ip address).
 
Thanks,
 
Ade

(in reply to leederbyshire)
Post #: 5
RE: Form Based and Integrated Windows Authentication C... - 25.Sep.2008 8:39:27 AM   
leederbyshire

 

Posts: 968
Joined: 4.Jan.2006
Status: offline
Hmm.  Well, that's the two most common causes covered.  Have you tried searching for similar accounts of this error?
http://www.google.co.uk/search?q=owa+400+bad+request

(in reply to wozzles)
Post #: 6
RE: Form Based and Integrated Windows Authentication C... - 25.Sep.2008 11:04:43 AM   
wozzles

 

Posts: 11
Joined: 16.Sep.2008
Status: offline
Hi,
 
Yep, been there for a few days now! The only thing I've found is this technet article (http://support.microsoft.com/kb/920862) which references a specific 400 error (request header too long).
 
I haven't applied the suggested registry changes as yet.  As OWA works fine if you hit the URL directly (internally and externally), I'm not convinced that this is the problem?
 
The problem really is only if our IWA enabled intranet has been loaded in the browser window beforehand (internally and externally again), which convinces me it must be IWA.  Additionally, if you use Firefox it all works perfectly - again, this strengthens the arguement for IWA, Kerberos, FBA and IE clashing somewhere?
 
I do remember an article about IIS and OWA not liking the Server 2003 licensing service - am off to find that article.  Have also noticed error with DAVEX on the FE server - so will look at the application pools too.
 
Thanks for getting back to me.
 
Ade
 

(in reply to leederbyshire)
Post #: 7
RE: Form Based and Integrated Windows Authentication C... - 26.Sep.2008 7:15:06 AM   
wozzles

 

Posts: 11
Joined: 16.Sep.2008
Status: offline
UPDATE: Am getting somewhere and nowhere with this...our users are absolutely 100% able to access the OWA site using any browser other than IE - both by hitting the OWA site URL directly and by following the hyperlinks we have in our intranet.
 
When we have HTTP 400 bad requests with IE, we have found corresponding errors in the http.sys log file (system32\LogFiles\HTTPERR) as follows:
 
80 HTTP/1.1 GET /w00tw00t.at.ISC.SANS.DFind:) 400 - Hostname -
 
Plus, we cannot repeat the error in our intranet development site that doesn't use or require SSL.
 
All in all, we came to the conclusion that its something to do with the SSL and IE.  Which led us to look at the SSL certificate for the site...and we've found that the SSL Friendly Name is different to "Default Web Site".
 
We can only assume that this is causing the problem and IE is being particular about it.  We are going to request a new cerificate from our authority and see if that helps.
 
I'll post an update.
 
Regards,
 
Ade
 
 

(in reply to wozzles)
Post #: 8
RE: Form Based and Integrated Windows Authentication C... - 26.Sep.2008 8:28:44 AM   
leederbyshire

 

Posts: 968
Joined: 4.Jan.2006
Status: offline
Weird.  The only difference between IE and non-MS browsers, as far as OWA is concerned, is that in IE you will always get the 'Premium' GUI.  Does it make any difference if you select the Basic UI on the FBA login form, when using IE?

(in reply to wozzles)
Post #: 9
RE: Form Based and Integrated Windows Authentication C... - 26.Sep.2008 8:37:15 AM   
wozzles

 

Posts: 11
Joined: 16.Sep.2008
Status: offline
Hi, just checked - Basic client makes no difference, still fails.
 
Ade

(in reply to leederbyshire)
Post #: 10
RE: Form Based and Integrated Windows Authentication C... - 26.Sep.2008 8:57:43 AM   
leederbyshire

 

Posts: 968
Joined: 4.Jan.2006
Status: offline
How about if you go into your IE options and turn off Integrated Auth? Non-MS browsers don't support IA.  That's another difference.

(in reply to wozzles)
Post #: 11
RE: Form Based and Integrated Windows Authentication C... - 26.Sep.2008 10:10:23 AM   
wozzles

 

Posts: 11
Joined: 16.Sep.2008
Status: offline
No joy - still the same error with IE6 IWA turned off (after re-start too).
 
I should mention that our corporate intranet is ASP.net based and we are using a web.config at the root of the site.  IWA is turned on in IIS; so even with it off in IE6 there is no challenge on opening the intranet site (IIS and the webconfig handle the pass-through).
 
Should get my new certificate in the next hour.
 
Cheers,
 
Ade

(in reply to leederbyshire)
Post #: 12
RE: Form Based and Integrated Windows Authentication C... - 26.Sep.2008 4:10:43 PM   
wozzles

 

Posts: 11
Joined: 16.Sep.2008
Status: offline
Completely new certificate, with correct friendly name, has no made no difference - didn't think the friendly name would make any difference, but at least that's the certificate ruled out.
 
Ade

(in reply to wozzles)
Post #: 13
RE: Form Based and Integrated Windows Authentication C... - 29.Sep.2008 8:27:27 AM   
leederbyshire

 

Posts: 968
Joined: 4.Jan.2006
Status: offline
My next guess would be that the browser is losing all the cookie data that the FBA mechanism relies on.  This happens whenever the servername that the browser uses to access OWA changes.  How is the FBA logon page accessed from your Intranet?  Is it in a frame, or from a hyperlink?

(in reply to wozzles)
Post #: 14
RE: Form Based and Integrated Windows Authentication C... - 30.Sep.2008 4:51:13 AM   
wozzles

 

Posts: 11
Joined: 16.Sep.2008
Status: offline
Hi,
 
The FBA page is accessed via a hyperlink from our intranet, the hyperlink opens in a new window; no frames involved.
 
However, the problem can still occur if you access our intranet and then type the OWA URL directly into the same browser window (again, internally or externally).  All this only with IE6 and IE7.
 
I think I'm with you on the "IE not passing, or masking, something" front; but there should be no change of server name (one FE and one BE server only).
 
TIA,
 
Ade

(in reply to leederbyshire)
Post #: 15
RE: Form Based and Integrated Windows Authentication C... - 25.Nov.2008 5:06:34 PM   
wozzles

 

Posts: 11
Joined: 16.Sep.2008
Status: offline
Hi anyone who's still there?
 
I've been working off-forum with another forum user on this and thought I would update the thread with our various conversations.  Unfortuantly, the problem hasn't yet been fixed and it continues to be work in progress for me.  We have actually moved a hardware exchange migration forward, in the hope that a fresh server will help (the current BE server has been upgraded from Win2000 and Ex2000, so we are hoping that the problem is being caused by something deep in registry???).
 
Anyway, I'm a great believer in posting any information, even if its not a solution...so hear goes (personal information has been removed)...
 





From: wozzles from MSExchange.org Forums: Exchange Server Discussions
Sent: 30 September 2008 09:57
To: leederbyshire
Subject: Re: Forms based and IWA Clashing

Hi Lee,
Many thanks for the assistance you are providing with the thread on
msexhange.org - I'd be willing to give you the OWA URL (and a test
login), so you can see the issue yourself?

Many thanks,
Ade (wozzles)
 
---------------------------------------------
 
From: leederbyshire
Sent: 30 September 2008 10:15
To: Ade
Subject: RE: Forms based and IWA Clashing

Sure.  I can't guarantee that it will help, but it can't do any harm,
either.

 
---------------------------------------------
 
From: Ade
Sent: 01 October 2008 09:52
To: leederbyshire
Subject: RE: Forms based and IWA Clashing

Great, I'll send you the details in a msexchange.org PM.
Many thanks,
Ade
 
---------------------------------------------
 
From: Ade
Sent: 01 October 2008 15:18
To: leederbyshire
Subject: RE: Forms based and IWA Clashing

Hi Lee,
Sorry for the delay - can't PM you through the forum, so we'll have to
go for unsecured email instead!  Please use username of "xxxxx"
and password of "xxxxxxxxxxxx".  You're account will expire on Friday
night.

The URL of the intranet site is https://xxxxx.xxxx.xxx.uk
The OWA hyperlink is in the following page ICT > Applications > Webmail
and it will open in a new window.

The direct URL of OWA is https://xxxxx.xxxx.xxx.uk/webmail
(.../exchange will work, obviously).
I have to warn you that OWA doesn't appear to be working at all at the
moment - although I'm working on that as we speak.  I stopped the
License Logging service on the Exchange FE and BE servers and this seems
to have made things worse - I do recall seeing some article about the
License Logging service causing issues, but may be that was that it had
to be running, rather than not?

IIS on my BE server is also showing the status of "system cannot find
the path specified" for the /exadmin; /exchange; and /public virtual
directories - I'm guessing this is not good either?  The /webmail
virtual directory is OK.  I also seem to have lost the ability to access
OWA directly on the BE server?

Like I said, going from bad to worse?
Many thanks,
Ade
 
---------------------------------------------
 
From: Ade
To: leederbyshire
Sent: Wednesday, October 01, 2008 3:43 PM
Subject: RE: Forms based and IWA Clashing

Hi again - BE is working OK now (I was just being slightly daft - am
putting it down to the fact that I've been off ill for the last two
days).  Still have the IIS "system cannot find the path specified"
errors, but all working OK.

Have you managed to get in?
Thanks,
Ade
 
---------------------------------------------
 
From: leederbyshire
Sent: 01 October 2008 15:52
To: Ade
Subject: Re: Forms based and IWA Clashing

I logged into the Intranet okay, but I just get a blank page after
logging
into the OWA FBA page.  So, I tried to go to
https://xxxx.xxxx.xxx.uk/exchweb/bin/auth/
expecting to see a Directory Listing Denied error; but instead, I got
the
FBA logon page, which is completely wrong.  Only the Exchange VDir
should be
protected by the FBA logon page, not any other part of the Default Web
Site.
Unless the owalogon.asp page has been configured as the default page for

that folder?  Anyway, it just seems easier to me to delete exchweb, and
re-create it.

 
---------------------------------------------
 
From: Ade
To: leederbyshire
Sent: Wednesday, October 01, 2008 4:46 PM
Subject: RE: Forms based and IWA Clashing

Hi,
Thanks for that - so are you saying re-create the exchange virtual
directories on the backend that have the "system cannot find the path
specified" error AND re-create the exchweb virtual directory on the
front-end?

Found the article that references IIS and License Logging Service, its
"Microsoft Exchange Server 2003. Preview: Using Exchange 2000 Server and
Exchange Server 2003 Front-end Servers" by Microsoft.  A "tip" on Page
33 states "Ensure the Windows License Logging Service is running on the
front end server.  IIS does not allow more than ten simultaneous
connections unless this service is running."

I'm sure "Windows License Logging Service" is a Server 2000 term, but
I'm going to turn it back on anyway.

Thanks,
Ade
 
---------------------------------------------
 
From: leederbyshire
Sent: 01 October 2008 16:50
To: Ade
Subject: Re: Forms based and IWA Clashing

Yes, that would be my suggestion.  But on the FE, you'd also need to
delete
exchweb beforehand.

 
---------------------------------------------
 
From: Ade
Sent: 02 October 2008 09:55
To: leederbyshire
Subject: RE: Forms based and IWA Clashing


Morning Lee,
OK, using method 2, we have re-created all the virtual directories on
the BE and FE (BE first) this morning.  There were no errors and
everything went as per the method.

Still getting the same problem if our intranet is loaded first - can you
see the same?

Can access OWA on the backend directly, but am getting the attached
error if I access the BE by IP address (no errors when by name)?

When we used method 2 on the BE, when resetting the access permissions
to anonymous (item 10), the Inheritance Overrides dialog box only showed
"bin" - when we did the same on the FE, the dialog box showed "bin" and
"bin\auth".

Still getting the FBA logon page when accessing the URL
https://xxxx.xxxx.xxx.uk/exchweb/bin/auth/ - we've checked the
FE IIS Documents tab [for bin\auth] and "Enable default content page is
ticked" and owalogon.asp is the only page specified in the list - I'm
guessing this is not correct?  The BE IIS Documents tab again has
"Enable default content page is ticked", but the list is populated by
the standard IIS list of index/default pages.

Do you have a document that gives the definitive
permissions/settings/directory security requirements for OWA Virtual
Directories in FE/BE?

Please do let me know if you would rather we communicate within the
thread and thanks again for your patience!

Regards,
Ade
 
---------------------------------------------
 
From: leederbyshire
Sent: 02 October 2008 10:08
To: Ade
Subject: RE: Forms based and IWA Clashing


If you let the server rec-create the Vdirs, then the permissions will be
okay.  You shouldn't have to touch them after that.  I don't have E2003
any more, but ISTR that exchweb has Anonymous Access.  So does
everything underneath, except bin.  And under that, everthing has
Anonymous Access again.  The FBA page is appearing when you go to /auth
because that is the default doc, not because authentication is avtually
required.

The JavaScript error you see is simply because the server name (in this
case it is an IP address) is not in an Internet zone that has
sufficiently relaxed permissions to allow full active scripting.  Check
the browser status bar to see which zone your browser puts the server
in, and compare it to the zone when you use the name.  When you use the
IP address, it will no longer be in something like Local Intranet ot
Trusted Sites, both of which have very relaxed permissions.

 
---------------------------------------------
 
From: Ade
Sent: 02 October 2008 11:09
To: leederbyshire
Subject: RE: Forms based and IWA Clashing


Hi again,
Ok, so following through the instructions in method 2 - wouldn't that
mean that Exchweb and everything beneath will be anonymous access?  So
bin and bin\auth would be anonymous?

Should I, therefore, remove owalogon.asp from the Documents tab and/or
remove the tick to server default documents?  What about the BE - which
appears to be at default settings?

Sorry, wasn't thinking about the IE zones - forgetting the basics.  Our
BE server's name is in the Trusted Sites list, IP isn't.

Thanks,
Ade
 
---------------------------------------------
 
From: leederbyshire
Sent: 02 October 2008 11:43
To: Ade
Subject: RE: Forms based and IWA Clashing


Strange that the 400 status isn't reported back to the client.  At least
it isn't to mine.

Yes, if you follow method 2 then everything is set to AA.  I've only
ever used method 3, though, so I've never really noticed that particular
detail.  I guess the the setting on bin isn't particularly important.
I've known people that have fixed their exchweb problems by setting AA
on the entire exchweb heirarchy, but ISTR that in a brand new install,
bin alone has Basic auth.

Does your FE server have any kind of AV or firewall installed that the
BE doesn't have?  I just wonder if something is blocking the data POSTed
from the FBA form.

 
---------------------------------------------
 
From: Ade
To: leederbyshire
Sent: Thursday, October 02, 2008 1:57 PM
Subject: RE: Forms based and IWA Clashing

 
Hi,
My IE6 browser reports a 400 error, bad request.
No firewall directly on the FE server, but it is sitting in a DMZ
between two hardware firewalls.  Sophos AV installed, but on-access
scanning is disabled and customised for Exchange server (not scanning
certain files, stores etc) - same on backend.

I can't get away from the fact that OWA works perfectly if you hit the
...\webmail URL directly - irrespective of browser.  Yet when you load
our intranet first, OWA fails in IE - but not in Firefox?

The common denominator seems to be IE, the bin\auth directory and POST?
Regards,
Ade
 
---------------------------------------------
 
From: leederbyshire
Sent: 02 October 2008 14:25
To: Ade
Subject: Re: Forms based and IWA Clashing


I had a poke around with IeWatch, to see what gets set/sent when you
access
the intranet first, and when you directly access /webmail .  The only
difference I can see is that it is showing that the user is already NTLM

authorized when you go to the intranet first.  Interesting to see that
it
doesn't happen if you go to /webmail first, then to the intranet, then
back
into /webmail.

What do you have enabled on the Default Web Site?  Both Integrated and
Basic?  It would be interesting to see what happens if you only had
Basic
enabled.  You will need to make sure that the default auth domain for
basic
auth is set to xxxx.xxx.uk .  Although just \ usually works, too.

 
---------------------------------------------
 
From: Ade
To: leederbyshire
Sent: Thursday, October 02, 2008 3:28 PM
Subject: RE: Forms based and IWA Clashing

 
Hi,
The DWS is set for IWA only - to allow pass through authentication for
our users in the LAN, IIS then hands over to an ASP.net application (aka
the intranet) (using a web.config).

I'm not getting the same results as you..with the webmail, intranet,
webmail thing - still fails, either in the same browser window or new
window?

We have an identically configured intranet development site, but its not
https.  Launching webmail from there works like a dream!


OK, turned off IWA and turned on basic authentication - was prompted to
cascade down value of "UNCPassword" and "AuthFlag" to the Exchange
virtual directories, which I cancelled out of...

Loading up our intranet now provokes standard NTLM challenge response
dialog, I assume this is the ASP.net application wanting Windows
authentication, which is what we have it set to in the web.config?
Logged in OK and OWA launches in a new window like a dream!

Have turned the DWS back to IWA only and again not cascaded down value
of "UNCPassword" and "AuthFlag" to the Exchange virtual directories -
before my users complain - and now we are back where we started - not
working.

Does all this mean we have a NTLM issue?  I would have expected kerberos
to be used within the LAN (XP SP2/IE6 clients and W2K3 domain
controllers)?

Does this make sense to you?  Should I be cascading those "UNCPassword"
and "AuthFlag" values down?

Thanks,
Ade
 
---------------------------------------------
 
From: leederbyshire
Sent: 02 October 2008 15:38
To: Ade
Subject: Re: Forms based and IWA Clashing


No, I wouldn't allow anything to cascade down to Exchange.  With FBA
enabled, only Basic Auth is allowed on Exchange.  It might be worth
checking
that that is still the case.

Also, not that on your BE, you can't require SSL or have FBA enabled on
Exchange.  You must have both Basic and Integrated enabled.  No FBA, and
no
SSL required.

 
---------------------------------------------
 
From: Ade
To: leederbyshire
Sent: Thursday, October 02, 2008 4:50 PM
Subject: RE: Forms based and IWA Clashing

 
Hi,
I'm going to check the settings on all the exchange virtual directories,
but won't be able to do this until tomorrow morning.  I'm 99% certain
they are all OK - as we know it works from a direct URL.

Thanks for your help today.
Cheers,
Ade
 
---------------------------------------------
 
From: leederbyshire
Sent: 02 October 2008 16:56
To: Ade
Subject: Re: Forms based and IWA Clashing


Yes, I keep forgetting that it works from a direct URL.  Very odd.  The
only
difference I have found is that going from the intranet, the user has
been
authenticated using NTLM.  One thing you can try while you are doing
your
own testing is to go into your IE options, and disable Integrated Auth.

 
---------------------------------------------
 
From: Ade
To: leederbyshire
Sent: Thursday, October 23, 2008 1:10 PM
Subject: RE: Forms based and IWA Clashing


Hi Lee,
The powers that be decided that this wasn't so urgent anymore, and I've
been working on something else for the past three weeks.  That's now
done and I can re-visit this again.

I've removed the forced requirement for SSL on the default web site.  If
I launch our intranet via http and then OWA via https (in a new window)
it all works as it should!  Could the SSL be applied incorrectly to an
OWA path/component somewhere in the Default web site structure?  Perhaps
the SSL is masking parameters being passed to the ISAPI file
owaauth.dll?

Any thoughts?
Thanks,
Ade
 
---------------------------------------------
 
From: leederbyshire
Sent: 23 October 2008 13:35
To: Ade
Subject: Re: Forms based and IWA Clashing


SSL shouldn't mask anything being posted from the client, no.  One
interesting thing to be aware of with SSL is that you can't use it with
Host
Header names.  IIS needs to pick a site on the server, and use its
certificate to decrypt the request, which includes the server name sent
from
the client.  So, by the time it has decided which site it is going to
use,
it is too late to act on the host header information.  It's worth
checking
your IIS configs to see if you are using Host Headers on any of the web
sites.

 
---------------------------------------------
 
From: Ade
To: leederbyshire
Sent: Thursday, October 23, 2008 3:24 PM
Subject: RE: Forms based and IWA Clashing

 
Hi,
No host headers here - we used to use them on this server, but moved to
ports when we implemented SSL (for exactly the reasons you state).  Do
you think re-installing IIS on the FE would help?  If I restored the
websites from xml backups, is that likely to just restore the fault -
i.e. should I re-install IIS and re-build all the sites?

Thanks,
 
---------------------------------------------
 
From: leederbyshire
Sent: 23 October 2008 16:19
To: Ade
Subject: Re: Forms based and IWA Clashing


I don't think it would help to re-install IIS, particularly as you would
then need to re-install Exchange.

I don't know if you tried this:
How to reset the default virtual directories that are required to provide
Outlook Web Access, Exchange ActiveSync, and Outlook Mobile Access services
in Exchange Server 2003:
http://support.microsoft.com/kb/883380

---------------------------------------------
 
From: Ade
Sent: 24 October 2008 08:29
To: leederbyshire
Subject: RE: Forms based and IWA Clashing


Yep, we tried that about half way down - I used method 2.  I might give it another try.
Thanks,
Ade
 



(in reply to wozzles)
Post #: 16

Page:   [1] << Older Topic    Newer Topic >>
All Forums >> [Microsoft Exchange 2003] >> Outlook Web Access >> Form Based and Integrated Windows Authentication Clashing? Page: [1]
Jump to:

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
 Reply to Message
 Post New Poll
 Submit Vote
 Delete My Own Post
 Delete My Own Thread
 Rate Posts