|
wozzles -> RE: Form Based and Integrated Windows Authentication Clashing? (25.Nov.2008 5:06:34 PM)
|
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
|
|
|
|