OWA 2003's New Security Features

Before I dive into this week's discussion of more Outlook Web Access (OWA) 2003 features, I want to add OWAToolkit.com to the list I provided last week of vendors that offer OWA spell checkers. Now, on with enumerating OWA's new features.

Microsoft has put an enormous amount of effort into improving the security of Exchange Server 2003, and that effort is apparent in the new version of OWA--especially when you run Exchange 2003 on Windows Server 2003. (In that scenario, OWA runs on Microsoft IIS 6.0, which has a much improved security model compared to IIS 5.0 and earlier.) If you have more than a handful of OWA users, the changes to OWA are well worth upgrading to Exchange 2003. The most noteworthy features are support for encryption, cookie authentication, and various content blocks.

I cut my security teeth years ago writing software to support Secure MIME (S/MIME) from within Outlook, Eudora on the Macintosh, and cc:Mail. At the time, I couldn't understand why S/MIME wasn't more widely deployed. Now, S/MIME's market penetration is increasing steadily as various vendors work out its underlying infrastructure and compatibility problems. One big advantage of S/MIME is that it provides end-to-end security. When a user wants to encrypt a message, the S/MIME client software encrypts that message on the desktop, and the message remains encrypted until the recipient opens it. The public-key cryptographic security method that S/MIME implements restricts access to the sender's private key, so neither the sender's nor the recipient's mail server can decrypt the message during transit. This security restriction has prevented an effective and secure way to send and receive encrypted mail through OWA--until now. The new OWA can use locally stored digital certificates to give OWA users the ability to create signed or encrypted messages and to decrypt received messages. Because the user must have a local copy of his or her certificate, you'll need to use some kind of portable certificate technology. Smart cards are the obvious favorite, but tools such as Dallas Semiconductor's iButton will work, too. You can even use locally stored certificates in personal information exchange (.pfx) files; users can copy certificates from their work machines to a .pfx file, put the file on a 3.5" disk, then transfer the file to their laptops or home computers for use with OWA.

Another welcome improvement is support for cookie authentication. Earlier versions of OWA have no way to control the duration of a user's OWA session. After a user authenticates to any Web server, the user's browser caches the user's credentials (thus, Microsoft has always advised that users close all browser windows to ensure that they've successfully logged off of an OWA session). In the new OWA, however, you can specify the use of cookie-based authentication. Users will notice the difference when they log on to OWA because they'll get an online logon form rather than the Enter Network Password dialog box they get in earlier OWA versions. After users enter their credentials, IIS will generate an authentication cookie, which the client browser will store. Cookies have expiration times, so after a preset period, the user's session will end automatically. In the same vein, when users click "Log off" in the new OWA, the cookie is deleted, so an attacker can't recycle the user's credentials. OWA leverages these features to let you specify timeout periods. (You can add cookie-based authentication to the Exchange 2000 Server version of OWA, but most sites haven't bothered to do so.)

Another improvement is that you'll be able to block access to some types of attachments to help ensure that users don't accidentally leave sensitive materials on public computers. You can also control whether users can open hyperlinks embedded in messages.

None of these features, of course, change the fact that you must educate your users about good security practices. Several Microsoft consultants I know refuse to use OWA on any machine not under their control because you can never be absolutely sure that a public machine hasn't been tampered with in some way. Keep in mind that security is only as good as your operational practices.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.