Frequently Asked Questions:
OUTLOOK WEB ACCESS
Is enabling Outlook Web Access a security risk on Exchange 2000?
The simple answer to this is yes. From a network security standpoint, enabling port 80 (HTTP/OWA) on any device is a security vulnerability. Of course, the bad news from a security standpoint is that every installation of Exchange 2000 and Exchange 2003 has Outlook Web Access installed and enabled by default.
When you get down to brass tacks, it is the fact that Internet Information Services (IIS) -- which includes the HTTP, NNTP, SMTP, IMAP4, POP3 and a number of other Internet protocols -- is the source of vulnerability. However, you can not install Exchange 2000/2003 without it running.
The real risk is not planning for it. Here is a short list of things you can do to secure Outlook Web Access.
- Implement Secure Socket Layer (SSL) for secure HTTPS communications between the client (browser) and the server.
- Use front-end servers for Internet clients to connect to. No data is stored on the front-end server and therefore it is a lower risk if compromised.
- Implement IPsec between front-end and back-end servers. SSL can't be used between front-end and back-end servers, but IPsec can.
SSL is really the key to securing Outlook Web Access. You should not allow clients to connect to Outlook Web Access without using SSL.
Is there a location in Exchange System Manager to check security logs for Outlook Web Access? I have a user that would like to know if someone logged onto his account via Outlook Web Access.
There is a log for the HTTP virtual server, but not in the Exchange System Manager. It is configured in the Internet Information Services Manager (ISM) and it is enabled by default. The log itself can be found in the C:\Windows\System32\LogFiles\W3SVC1\exyymmdd.log file. Open up the log file for the day in question, and you should be able to see the date, timestamp and username of the person that connected to the mailbox in question.
If you cannot find the log file in the location I have specified here, it may have been moved from the default location. To check the current location:
- Open the ISM.
- Navigate to Servername (local computer)\Web Site\Default Web Site.
- Right click on Default Web site and click Properties.
- Verify that the Web site tab is selected and click on the Properties button in the Enable logging section (Note if there was no checkbox next to Enable Logging then this feature was disabled).
The path should be listed in the Log file directly field.
I am running Exchange 2000 Standard Edition in my organization. We currently use VPN to access e-mail from remote locations. I would like to set up access to Outlook Web Access (OWA) straight through our firewall. Someone told me that I need to set up a front-end server configuration in order to use SSL and configure security correctly. Do I really need a front-end server for SSL, and what are my other options for setting up secure, encrypted OWA?
You got some good advice but it is not 100% accurate. You can implement SSL for OWA on your current Exchange 2000. The question becomes -- do you really want to?
In order to set up SSL on any Exchange 2000 or 2003 server, you simply obtain a Web server certificate from a certificate authority (CA). You then configure the Exchange virtual directory in your Default Web site on the Exchange 2000 server to only allow secure HTTP (https://) connections. This will encrypt communications from the Web-based clients to the Exchange server end-to-end using Public Key Cryptography.
An example of a public CA is the well known and very popular VeriSign, which will lease you a certificate that must be renewed periodically. It is also possible to establish your own CA on a Windows 2000 server and manage your own certificates. The process of configuring SSL for OWA is fully detailed in Microsoft KB article 320291, Turning On SSL for Exchange 2000 Server Outlook Web Access.
The next step, as you alluded to, would be to create rules on your firewall(s) to allow communication on ports 80 (HTTP) and 443 (HTTPS) from every external address to your Exchange 2000 server and vice versa. Since your Exchange 2000 server is most likely using a private IP address, you can use Network Address Translation (NAT) on your firewall to translate a public IP address (of your firewall) to the private IP address of your Exchange 2000 server.
So why create a front-end server? A common reason is to add one more layer of security to the mix. Front-end servers do not store data. Therefore they can be locked down and fortified to a greater degree than your current back-end server. Front-end servers can also be strategically placed on the network in a de-militarized zone (DMZ). This area sits between your private network and the Internet, giving you even more control over what communication you will allow in and out of your environment. One or more of these reasons could easily justify you adding a front-end server to your Exchange organization.
If you do decide to go with a front-end server in a DMZ, be prepared to have to open additional ports on your internal firewall to allow the front-end server to function as a member of your Active Directory domain, as described in Microsoft KB article 280132, Exchange 2000 Windows 2000 Connectivity Through Firewalls.
As an alternative to a front-end server, you can consider two other options. You could add a Microsoft ISA (Internet Security and Acceleration) server and use the ISA server to "publish" OWA. This is also known as proxy. The Microsoft ISA server can function as an external firewall, internal firewall and proxy server all-in-one. Microsoft ISA is also Exchange friendly, making it fairly easy to use in a Microsoft-centric environment. See KB article 290113, How to publish Outlook Web Access behind Internet Security and Acceleration Server. And finally, if an upgrade to Exchange 2003 is on your horizon, then it might be worth your time to research RPC over HTTP. Exchange Server 2003 running on Windows Server 2003 can be configured as an RPC proxy server. Outlook 2003 can be configured to send its RPC communications to the server encapsulated in a HTTP header. This can be further secured by enabling SSL communications on the RPC proxy server. This would give you thick client functionality and secure connections without a VPN connection. If you would like more information on RPC over HTTP reach KB article 833401, How to configure RPC over HTTP on a single server in Exchange Server 2003.
I have attachment blocking enabled in Exchange 2003. How do I stop a smart user from renaming a file (e.g. from file.exe to file.txt) and attaching it in OWA, as Exchange will let it through?
You can block the attachments for the specific user by changing the registry:
1. Click Start, click Run, type regedit, and then click OK.
3. On the Edit menu, point to New, and then click String Value.
4. Type Level1Add, and then press ENTER.
5. On the Edit menu, click Modify.
6. Type <file_name_extensions>, and then click OK.
I am unable to log on through Outlook Web Access 2003 through the front-end server. I can, however, log on through the back-end server. It states: HTTP/1.1 401 unauthorized.
- Make sure you install the latest service packs for Exchange 2003.
- Check the user SMTP address and//or creates a new one. Go to Active Directory Users and Computers, select User, right click on Properties, then click E-mail Addresses tab.
- Check the Exchange virtual directory. Go to Exchange System Manager, expand Recipients and select Recipient Policies. Click on Properties for the default policy and click on the E-mail address tab.
- Create additional SMTP domains and HTTP Virtual Servers. Start Exchange System Manager and expand Server name. Expand Protocols -> HTTP -> Virtual Server and right click New. Click Virtual Directory, type the name for a new directory and select SMTP domain.
Is it possible to limit access to Outlook Web Access for Exchange 2000 and 2003 to just a group of users, and deny access to others?
You can use the Outlook Web Access Web Administration Tool to restrict Outlook Web Access options to users. Using this tool allows you to change the way Outlook Web Access looks, calendar access, signatures, attachment handling, and much more. It requires installation to a server running Windows 2000, XP or 2003.
I have a small company with two sites; each one has an Exchange 2000 server. Is it possible to get Outlook Web Access working for both servers using a single SSL certificate without a "front-end server," which would mean additional hardware and licensing costs?
It's a Windows 2000 single forest domain and all users have e-mail addresses of email@example.com. Apparently, this was doable with Exchange 5.5, but not with Exchange 2000. I installed a certificate on the "master" Exchange 2000 server and it works fine, but users whose mailboxes reside on the second server can't use it.
What you have described is by design. As you have determined, without a front-end server, you can not centralize the SSL access to all mailboxes. It is a give and take scenario.
There are two pieces of good news I can give you. One is that certificates for your Exchange servers do not have to cost a fortune. You can shop around for cheaper third-party certificate authorities (CA), or you can even configure one of your existing servers in your domain as a Windows CA. The other good news is that the Standard Edition of Exchange Server 2003 can be used as front-end servers. This is significantly cheaper then the Enterprise Edition that we were required to use with Exchange 2000 Server. And, front-end server hardware generally does not cost nearly has much as back-end servers, because there are virtually no disk storage requirements beyond the OS and the Exchange application. Finally, Exchange 2003 front-end servers are backwards compatible with Exchange 2000 back-end servers.
We are currently running Exchange 5.5 on a NT4 operating environment. I am looking to build a Windows 2000 server that will be dedicated to running Outlook Web Access. Do you know if there are any issues with this and if there are any white papers that I can follow for the install?
From your question it appears that you're deploying the version of Outlook Web Access (OWA) that ships with Exchange 5.5 Server, which I'll refer to as OWA 5.5. Note that the Exchange 2000 Server version of OWA, which I'll call OWA 2000, is not supported running against an Exchange 5.5 Server back-end. There's a useful Microsoft white paper on configuring OWA 5.5 called "Planning and Deploying Outlook Web Access 5.5," available for download. Also, make sure you're running the most recent Exchange 5.5 service pack.
One important thing to note is if you plan on having Outlook 2003 clients in this environment, you'll need to install the Exchange 5.5 CDP Patch 2657.55 from Microsoft. Have a read through Microsoft Knowledge Base Article 301036 (HOW TO: Install and Configure Exchange Server 5.5 and the Active Directory Connector in a Windows 2000 Domain) prior to your installation to make sure you have the correct security settings configured in your environment.
I am trying to set up my Outlook Web Access (OWA) 5.5 in a DMZ and would like to connect using SSL to my Exchange 5.5 Server. I have installed a stand-alone IIS 5.0 with OWA 5.5. Users can connect to my Exchange box only if I add them as a local user to that box. Is there another way to do this? I really don't want to have to add new users in two different places, not to mention dealing with password changes.
It sounds like you've set your authentication settings incorrectly on your IIS server. Since you have OWA on a separate IIS server in your DMZ, you won't be able to use either NTLM or Challenge/Response authentication. Neither of these credentials can be passed through multiple hops. I suspect that one of these options (NTLM or Challenge/Response) is set, which would cause authentication to fail and explain the behavior you're seeing.
I would try setting the authentication on the OWA site in IIS to permit only basic authentication. This will prompt your users to authenticate using the appropriate domain, user and password information. They should be using their domain credentials and there should be no requirement for you to create local accounts on the OWA server.
I maintain an Exchange 2000 server for a small company. Users outside of the office can log onto Outlook Web Access with no problem, but users inside the office, signed on to the domain, cannot use Outlook Web Access. (They normally just use Outlook.) What do I need to do to allow inside users to get into Outlook Web Access?
Try using the local IP address instead of the Exchange server name. If you are able to connect, check your DNS setting. Make sure the DNS setting is pointing to the local server, and add the DNS entry for Outlook Web Access. Also, check your firewall. It is possible that it is preventing users from going out to the Internet and coming back up.
This was first published in October 2005