?
Solved

OWA requires client authentication twice

Posted on 2005-04-05
15
Medium Priority
?
1,244 Views
Last Modified: 2008-01-09
I'm running OWA in IIS 5.1 w/ Exchange 2000 on Win2k Server. Yesterday I ran the IIS Lockdown Tool and messed up my OWA (not a single mention in the interface about SSL, but it destroyed my SSL settings nevertheless).

I have seen both of the following KB articles:

327843
327349

Neither applies AFAIK, so please read on:
Prior to the Lockdown Tool mishap my SSL redirection was working perfectly. I have since re-implemented SSL, and followed Article 839357 to the last detail to re-create the redirection using the custom error and asp page combination recommended in that article.

Before it was undone by the Lockdown Tool, my redirection would send all of the following requests directly to SSL with one authentication:

mail.domain.com
http://mail.domain.com
https://mail.domain.com

But now:
  -  it authenticates "https://mail.domain.com" once (directly to SSL)

  -  it authenticates both "mail.domain.com" and "http://mail.domain.com" to "http://mail.domain.com", then requires a second authentication to "https://mail.domain.com"

AFAIK, no settings in Exchange have been changed. From what I'm reading here, it sounds as if maybe I should be allowing anonymous access someplace where I'm not, but I have tried various possiblities, and none have made a difference. (I have been restarting IIS Admin service with every change, which stops & restarts everything.)

Here's what I have for directory security settings in IIS:

Default Web Site: Anonymous:YES / Basic:YES / Integrated: NO / SSL required:NO
Exchweb:             Anonymous:YES /  Basic:NO / Integrated: NO / SSL required: NO
Public:                 Anonymous:YES /  Basic:YES / Integrated: NO / SSL required: YES
Exchange:            Anonymous:YES /  Basic:YES / Integrated: NO / SSL required: YES
Exadmin:              Anonymous:YES /  Basic:NO / Integrated: NO / SSL required: NO
OWA_Redirect      Anonymous:YES /  Basic:YES / Integrated: NO / SSL required: NO
Owaasp               Anonymous:YES /  Basic:NO / Integrated: NO / SSL required: NO

Through tiral & error I've determined that without Basic authentication on Default Web Site, no password is accepted, and users can't log in.
Furthermore, without Basic authentication on Default Web Site + Exchange + OWA_Redirect, the login attempt always results in either a 401 (unauthorized) or 403 (forbidden) error. But as long as Basic authentication is set on those 3 directories, a user can log in, but will always be presented first with a login for http, then with a login for https. Furthermore, the 2 logins persist regardless how many directories have Basic authentication set, as long as at least Default + Exchange + OWA_Redirect are set. The only way to log in is to log in twice, first to http, then to https.
Right now I'm pretty stuck. This is my first time having to get under the hood of OWA so deep, and I have to admit I'm pretty clueless. Any suggestions?
0
Comment
Question by:WinsorGeek
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 8
  • 7
15 Comments
 
LVL 104

Expert Comment

by:Sembee
ID: 13706005
The IIS Lockdown tool should have recorded a file that you can use to undo the changes. Have you tried that?

Otherwise, remove the requirement for basic authentication on the default web site.

Then check/adjust the authentication on the Exchange virtual folders within IIS manager:

/exchange
/exchweb
/exadmin
/public

All should be integrated and basic ONLY.
/exchweb should also have anonymous permissions.

Simon.
0
 

Author Comment

by:WinsorGeek
ID: 13708076
Hi again Simon,
Replies are inline.

Simon said:
"The IIS Lockdown tool should have recorded a file that you can use to undo the changes. Have you tried that?"

Rich replies:
I re-ran the lockdown tool. When you do that it automatically un-does all of its changes. Unfortunately it doesn't un-do all of my changes... I can never duplicate what I had without restoring from backup - and I'm loathe to do that on the mailserver.

Simon said:
"Otherwise, remove the requirement for basic authentication on the default web site."

Rich replies:
As I stated in my posting, "Through tiral & error I've determined that without Basic authentication on Default Web Site, no password is accepted, and users can't log in."
So I can't do that or no one will be able to authenticate at all. I just confirmed that that is still the case.

Simon said:
"Then check/adjust the authentication on the Exchange virtual folders within IIS manager:

/exchange
/exchweb
/exadmin
/public"

All should be integrated and basic ONLY.
/exchweb should also have anonymous permissions."

All are indeed Basic and Integrated only, and the same holds true for OWA_Redirect, and Owaasp, the directories that get created when one follows Article 839357 to configure SSL redirect.
/exchweb has Anonymous permissions.

I'm still having to log in twice unless I use the explicit "https://" prefix. I'm beginning to think the issue goes beyond the IIS directory permissions. I noticed just now that when I log in on a Mac, I see that the domain is "mail.domain.com"; it used to be "domain.com". Thinking I had a hot lead, I set the Basic permissions on all folders to authenticate explicitly to "domain.com", but it had no effect. I restarted the Default Web Site, still no effect. I restarted the IIS Admin service, still no effect.
I have been working my way through my 12 servers running the Microsoft Baseline Security Analyzer (MBSA) to tighten security, and running the IIS Lockdown Tool in addition to that. The fact that I can't seem to get the login domain on the mail server to = the server's domain (I can't get it to = anything but the server itself) suggests to me that perhaps another change I made or combination of changes is bringing this about. One suspect in particular is the change to registry setting:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous=1
I think this may be the culprit. M$ recommends making this change on all servers, and I've been doing that. (The prior setting was "0") Then again, maybe this gives enough information to someone out there to resolve the issue???
If worse comes to worse, I can instruct all users to use the explicit "https://" to avoid having to log in twice each time. But I'm still hoping that the simplicity that was lost might be regained.
Rich
0
 
LVL 104

Expert Comment

by:Sembee
ID: 13708306
The Mac's domain as "mail.domain.com" is probably the server address. The fact that you cannot login unless basic configuration is enabled means that anonymous isn't working. The IUSER is corrupt or not working correctly. Check that the anonymous account is correctly set to IUSER_<servername> in IIS Manager.

Simon.
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 

Author Comment

by:WinsorGeek
ID: 13709774
Simon,
Replies are inline:

You said:
" The Mac's domain as "mail.domain.com" is probably the server address."
Yes, as I said: "The fact that I can't seem to get the login domain on the mail server to = the server's domain (I can't get it to = anything but the server itself)"

You said:
"The fact that you cannot login unless basic configuration is enabled means that anonymous isn't working. The IUSER is corrupt or not working correctly. Check that the anonymous account is correctly set to IUSER_<servername> in IIS Manager. "

The anonymous account *is* correctly set to IUSER_<servername> in IIS Manager - I just checked it again. And IIS is allowed to control the password. IUSER_<servername> exists in AD. IUSER_<servername> is set as the default user in every instance where Anonymous access is granted. Below is how security is set on my directories. The requests are still being authenticated to the server and not the domain, despite my having set it explicitly to authenticate to the domain:

                             Anonymous   Basic   Integrated
WWW Service              Y               N           N
Default Web Site           Y               Y**       Y**
Exchweb                      Y               --          --
public                          Y                Y           Y
Exchange                     Y                Y           Y
OWA_Redirect (virtual)  Y                Y           Y
aspnet_client                Y                Y           Y
Owaasp                        Y                Y           Y

**Now when I take away Basic authentication on Default Web Site, I get:

HTTP 401.3 - Access denied by ACL on resource Internet Information Services

This error links to a M$ Article 247603, which tells me that the user is being denied access by NTFS file permissions. So I drilled down to wwwroot, and set "_Web Anonymous Users", "_Web Applications" and "Domain Users" (those who actually use the mail server) all to Read & Execute, making sure to reset permissions on all child directories.

When I disable Basic authentication on Default Web Site after doing this, I *still* get the same HTTP 401.3 error. When I re-enable Basic authentication on Default Web Site, I still have to log in twice.
 Just a reminder - "https://" works with one login - it's just when a request has to undergo redirection that there are two logins.
Does any of this shed any light for you?
Rich
0
 
LVL 104

Expert Comment

by:Sembee
ID: 13710219
You don't need anon on /exchange or /public
These should be taken away. That might be the cause of at least one of the problem logins as the anonymous account doesn't have an account to login to. So the login request will fail, prompt and then you are in.

Simon.
0
 

Author Comment

by:WinsorGeek
ID: 13710290
Hi Simon,
I took away anon on /exchange and /public. Still the same behavior - one login with "https://", 2 logins with "http://"...
Rich
0
 
LVL 104

Expert Comment

by:Sembee
ID: 13710373
Remove the requirement for SSL.

Then go to http://mail.domain.com/exchange

What happens? Single login or mutiple?

I am still convinced that this is an IIS problem not Exchange, as OWA appears to be working correctly.

Simon.
0
 

Author Comment

by:WinsorGeek
ID: 13710733
Hi Simon,
I just confirmed that the /Exchange and /public folders were the only directories requiring SSL. (and I'm now using a spreadsheet to track the configurations.) I removed the SSL settings and requested http://mail.domain.com/exchange. I got a "403.5 - Forbidden: SSL 128 required" error.  Keep in mind that in accordance with Article 839357, I have added an .asp page (Owahttps.asp), a virtual directory, (OWA_Redirect) and a Custom Error on the /Exchange directory for 403.4, diverting the error to the Owahttps.asp.

When I reset the /Exchange 403.4 Custom Error to default, (to ensure that the Owattps.asp is out of the loop) I get the same result - "403.5 - Forbidden: SSL 128 required".
Rich
0
 
LVL 104

Expert Comment

by:Sembee
ID: 13710887
If you removed the requirement for SSL (which is small box to enable in IIS manager) yet it continues to prompt for it, then it is starting to look like IIS has got its authentication totally screwed up.

Concentrate on the root of the default web site first. Put something in there (a small html file or something like that). The position you want to be in is to view that page without any authentication prompts over http.

Next go through the default web site configuration and remove the requirement for SSL, and the requirement for it to be a 128 bit encrypted SSL.
The default web site should have anonymous and integrated enabled only. No basic. Restart Internet Explorer to ensure that no credentials are cached.

If that still generates the same error, then we are looking at a reinstall of IIS. While it is straightforward to do, it is further complicated by Exchange, and will involve Exchange being reinstalled - with the consequential downtime.

There are a number of areas that are complicating the problem, including your redirect, and they need to be removed from the configuration as much as possible - trying to get IIS back to a standard config as you can.
The problem is of course that the more times you fiddle, the further away from that standard config you are. That is when you have to concede defeat and reinstall IIS to get it back to a working operation.

Simon.
0
 

Author Comment

by:WinsorGeek
ID: 13710910
Simon,
I replaced the Custom Error & re-set the SSL requirements on /Exchange and /public. I'm back to where I was, 2 logins on http://...
FYI, the current settings
OWA Properties:                        
                        Req SSL  Anon       Basic      Integ
WWW Service        n/a          Y      -      -
Default Web Site     -            Y         Y        Y
Exchweb                      -           Y            -      -
public                         Y              -       Y      Y
Exchange             Y          -           Y           Y
Exadmin                      -           -            Y            Y
OWA_Redirect (virtual)      -      Y      Y      Y
aspnet_client            -              Y           Y           Y
Owaasp                     -           Y           Y           Y

Rich
0
 
LVL 104

Expert Comment

by:Sembee
ID: 13711116
Forgetting about OWA for a moment...

If you have a file in the root of the web site, and when you try to access that web site with anonymous authentication enabled you still get prompted for a username and password, then something is wrong with either IIS or the physical file permissions.

You said that you have checked the NTFS permissions. The file would be located in c:\inetpub\wwwroot if everything is in the default location.

I am starting to run out of ideas... IIS reinstall seems the only option left.
This is the article that explains how to the reinstall when Exchange is involved. http://support.microsoft.com/?kbid=320202

Simon.
0
 

Author Comment

by:WinsorGeek
ID: 13711308
Hi Simon,
I removed Basic authentication from the Default Web Site, and put a small page in c:\InetPub\webroot. I then made the following request:

http://mail.domain.com/page.htm

and I got the page, no authentication, no problem at all. That got me thinking (very dangerous, I know...)

The default request to the mail server that people have grown accustomed to around here is "mail.domain.com". However, somehow the act of connecting to this page I inserted in the webroot directory reminded me that the request that OWA would normally expect is "http://mail.domain.com/exchange", and the redirect .asp is probably set up to operate that way. So I tried the URL with "/exchange" appended, I received an authentication prompt, and was trasparently redirected to SSL, and lo and behold, there was my Inbox...

I confirmed this by re-launching the browser on that machine, and going to another with a different browser (Firefox) and everything works as long as you include the "/exchange" in the request to the OWA server.

It looks like all I have to do now is figure out how to redirect incoming "mail.domain.com" requests to "mail.domain.com/exchange". I'm sure that's a simple step, it's just that I've never set that one up on an OWA, and my brain is complete mush at the moment (I was up 'til 4:30 this morning trying to resolve the issue in off-hours). If you know a quick way to accomplish that I would be ever grateful (even more than I am for your having helped me to keep at this madness to a presumably successful result!)
Rich
0
 
LVL 104

Accepted Solution

by:
Sembee earned 2000 total points
ID: 13712362
If you aren't going to put anything else on to this web site then you can change the web site configuration itself to avoid the requirement for /exchange

http://www.amset.info/exchange/default-web.asp

This will mean that the users just need to put in https://mail.domain.com to get logged in to OWA.

Simon.
0
 

Author Comment

by:WinsorGeek
ID: 13712712
Simon,

For the past day or so I have really doubted whether I would ever get my OWA back in order without a re-install. On an Exchange server, that would not be a pleasant prospect.  Thank you for seeing me through this ordeal - I'd be in sorry shape without your expert help!

For anyone else reading this thread, let this serve as a cautionary tale - don't run the IIS Lockdown Tool without first *CAREFULLY* documenting your OWA configuration in IIS!!!

Thanks again, Simon!

Rich

0
 
LVL 104

Expert Comment

by:Sembee
ID: 13714087
Excellent. So pleased to hear that you have it working.

Simon.
Exchange MVP
0

Featured Post

On Demand Webinar - Networking for the Cloud Era

This webinar discusses:
-Common barriers companies experience when moving to the cloud
-How SD-WAN changes the way we look at networks
-Best practices customers should employ moving forward with cloud migration
-What happens behind the scenes of SteelConnect’s one-click button

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

How to resolve IMCEAEX NDRs in Exchange or Exchange Online related to invalid X500 addresses.
If you troubleshoot Outlook for clients, you may want to know a bit more about the OST file before doing your next job. IMAP can cause a lot of drama if removed in the accounts without backing up.
In this video we show how to create an email address policy in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.:  First we need to log into the Exchange Admin Center. Navigate to the Mail Flow…
This video discusses moving either the default database or any database to a new volume.
Suggested Courses

765 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question