My last UPDATE column, about the ever-populartopic of Microsoft Exchange Server licensing, generated quite a bit of reader feedback. I'm still sorting through it all, and I'll have more to say about licensing in the next UPDATE. In the meantime, I'd like to ask you to spend a few minutes to take a 9-question research survey about licensing; I'm using the gathered data to help me better understand what the Exchange community knows—and doesn't know—about Microsoft's licensing requirements. To take the survey, please go to the Exchange Server Licensing Survey page.

I've written several columns about the benefits of two-factor authentication systems. The recent compromise of RSA's SecurID token system by Chinese crackers doesn't lessen my enthusiasm for two-factor authentication; in fact, just the opposite is true. The security of RSA's system depended on keeping secret the "seeds" used to initialize a particular set of tokens. This scenario is somewhat like buying a safe whose security depends on keeping the plans for the lock mechanism secret. Wouldn't you be more inclined to trust a safe whose specs were widely known and which had proved resistant to attack despite that knowledge?

That's the type of security that smart cards provide. Because the smart card has its own embedded cryptographic processor, it can sign, encrypt, decrypt, and verify data without ever exposing its secret key to the outside world. It's very difficult for an attacker to recover the secret key from a smart card—it would require a level of effort generally thought to be within the reach of nation-states but not individuals, or even criminal syndicates.

Windows has supported smart card–based user authentication for a number of years. Over time, this support has expanded to the point where now you can use a smart card for user authentication, website access control, VPN connections, and interaction with files protected by the Encrypting File System (EFS)—all these features are built into Windows. However, one missing feature has been the ability to use smart cards as a second authentication factor with Outlook Anywhere. Happily, that feature is no longer missing; last week, Microsoft released guidance on how to use smart card authentication with Outlook Anywhere.

The magic begins when you configure your Internet-facing Client Access servers to accept Outlook Anywhere connections. The SSL connections from the client must terminate at the Client Access server; you can't use an ISA, Forefront Threat Management Gateway (TMG), Forefront Unified Access Gateway (UAG), or third-party servers to bridge or terminate SSL. After you've successfully set up plain Outlook Anywhere, you run a script that's installed as part of the Exchange distribution: Enable-OutlookCertificateAuthentication.ps1. As you might infer from the name, this script turns on smart card authentication for Outlook Anywhere.

The documentation for setting this feature up is in the TechNet article "Configure Smart Card Authentication for Outlook Anywhere." I was somewhat surprised to find that only Outlook 2007 SP2 with Exchange 2010 SP1 is supported at present. If you've already deployed Outlook 2010, you can't enable smart card authentication on your Client Access servers because when you do so, the Client Access role will expect all connections to use smart card authentication.

I'm glad to see smart card authentication support extended to Outlook Anywhere, as that was one of the last common Windows-based services that couldn't use it. I'm realistic enough to understand that we probably won't see a huge wave of smart card deployments just because this feature is now supported, but it's great to have the option for organizations that want the benefits of smart card–based authentication and access control.

Related Reading: