Security gaps mar Exchange Web access

Microsoft Exchange Server 5.0, in
conjunction with Microsoft Internet Information Server 3.0, lets users log into e-mail
accounts from any current World Wide Web browser.

That's mighty convenient for Webbed users on the road. They need only Web access from a
local number to read and reply to e-mail without paying long-distance charges or carrying
specially configured notebook computers.

Their offices no longer have to support a dedicated PC or server with modem attached
for remote users. The Web and Exchange bear the load.

Except for enhanced Web access, Exchange 5.0 doesn't differ much from Version 4.0. The
GCN Lab staff found the upgrade to 5.0 simple enough. Installation took hardly any input
from the administrator. Within 20 minutes, we were up and running and had lost nothing
from Exchange Server--bravo.

But if you're installing 5.0 from scratch, you'll find configuring it similar to 4.0
[GCN, Feb. 24, Page 27].

Internet Information Server 3.0 also didn't cause any problems when we installed it
over Version 2.0. The newer version is required for Microsoft's Active Server Pages, which
have an .asp file extension rather than the standard .htm or .html extensions for Web
pages. ASP, which installs separately from IIS, produces dynamic Web pages on the fly for
user mailboxes.

Be warned that the default load of IIS will put your server on the Internet
automatically.

Prior to the release of Exchange's Service Pack 1 in late June, we'd experienced
problems with the Web access features. We were often locked out of mailboxes but other
times got full access without entering proper passwords.

If you have enabled Exchange's Web access without loading Service Pack 1 for Exchange
and Service Pack 3 for Windows NT, we recommend you disable it immediately.

Once both Service Packs are installed, you're on safer ground. While loading the
Service Packs, you also must load the Outlook Web Access clients.

Microsoft needs to clean up its Exchange download area and make it easier to navigate.
Although you start out in http://www.microsoft.com/exchange,
you end up at a File Transfer Protocol site that lacks clear explanations of the files
needed.

There are updates to the Outlook client application itself on the site, but if you
installed what came with Office 97, you have Version 8.0 and cannot update to 8.02. If you
installed the Outlook application that came with Exchange Server 5.0, you have Outlook
8.01 and can update to 8.02.

Some individual updates that apply to Outlook 8.0 are posted at http://www.microsoft.com/outlook.

Getting Exchange's Web access to work properly takes a lot of troubleshooting. First
and foremost, you must have IIS 3.0--along with its Active Server Pages--installed and
running. The Web service must be running within IIS 3.0.

How you configure IIS is extremely important. Microsoft should create a Wizard to
activate each service step by step.

Internet access to IIS--and therefore Web access to Exchange--is bonded directly to the
user account within Windows NT 4.0 Server. To get in via the Internet, you must use the
same password you would use to log in at your desktop machine.

Future versions of IIS should give greater control over access and should integrate
better with NT Server, giving user-dependent access with a password different from the
user's LAN log-on.

The initial log-on transmission is not secure, so folks out on the Internet could catch
your alias name within Exchange. The user name and password are transferred via Windows NT
LAN Manager--not via Secure Sockets Layer, the more common and secure method for Web
browsers.

In NT 5.0, the NT LAN Manager transfer will be dropped in favor of the newer Kerberos
authentication.

NT LAN Manager is fine within a single domain, but its trust is basically one-way. A
client provides verification to the server, and the server opens the door.

Under Kerberos, developed at the Massachusetts Institute of Technology, the trust goes
both ways. Client and server verify each other. Following log-on, packets must have a
ticket to gain access.

But Microsoft is still working on how to implement Kerberos--it may not even be used
for authentication across the Internet.

On your first effort to log on using Outlook Web Access, you'll likely get the error
message, "The log-in request was denied." Try again and you'll get through.
Microsoft technicians said they fixed this problem in NT Service Pack 2.

Note that under Windows 95, you have the option of saving the NT authentication
password in your .pwl file. If you do, the browser on the PC you're using will let anyone
else using that browser into your mailbox via the history of recent Web sites visited.

Also, once you log in, other people can access your mailbox without the authentication
password as long as they don't quit the browser application.

The main screen of Outlook Web Access looks similar to the Outlook application. But you
see only your mailbox, not contacts or calendar or any other component. If you want to
send e-mail, you can't even look up the address. Only users on that particular Exchange
server will be listed.

Using JavaScript and ActiveX, Outlook Web Access pops up dialog boxes and separate
windows for reading, composing and replying to mail. The 3.0 or higher versions of
Netscape Navigator and Microsoft Internet Explorer browsers supporting Hypertext Markup
Language frames all work with Outlook Web Access.

We tested Web access with Netscape Communicator 4.0 and found it worked much like
Internet Explorer 3.02.

Attachments to e-mails have become a necessity. Netscape users are out of luck here,
but you'll find an add-on to send attachments with Internet Explorer 3.02 at http://www.microsoft.com/msdownload/ieplatform/iewin95/01000.htm.
It's easy to use.

Remember that Outlook Web Access mail is not secure because none of it uses SSL.
Microsoft technicians told me it's possible to secure all your Web pages under SSL by
using IIS 3.0's Key Manager.

To generate an encryption key, you must pay $290 to VeriSign Inc. of Palo Alto, Calif.
Visit http://www.verisign.com. If you generate a .req file for a key, you can attach to
https://digitalid.verisign.com/ss_getCSR.html.

With Outlook Web Access, the network administrator can use a master password to log on
to any mailbox account and read its mail. Under Exchange itself, the only way an
administrator can peek into a user's mailbox is to change the user's NT password and log
on as that user.

To keep the administrator from prying, Microsoft engineers advise not making the
default load of the administrator as Exchange's service account manager on initial setup.
They said instead to create another account as the service manager. However, that account
will have the same level of access via the Web; Microsoft technicians said this loophole
is a "known issue."

Lack of security becomes more ominous with the possibility of Web e-mail access under
Exchange DMS, a version of Exchange 5.0 that recently was certified for the Defense
Message System. No Web security policy has yet been set for DMS. Officials of prime
contractor Lockheed Martin Corp. would say only that the policy is evolving.

In any case, it probably is not a good idea for someone outside your agency to see
information in e-mail. I'm not familiar with the ways hackers could intercept Web
transmissions, but none of the standard Internet encryption protocols are in Exchange to
make access difficult or impossible.

Overall, IIS 3.0, its Active Server Pages component, Exchange Server 5.0, Windows NT
Server 4.0 and Internet Explorer 3.02 manage to work together to give you Web access to
your e-mail on the road.

But the lab staff has some advice for Microsoft as it works on future releases:

Finally, here are
some tips for you, the user, if you worry about security with Outlook Web Access:

Under IIS 3.0, run only Web service and not FTP or gopher. Be sure the
Web service is set to Windows NT Challenge/Response only. Do not check Basic (Clear Text)
or the Allow Anonymous options.