Permission Changes Surprise Mobile Device Administrators

Security is a tricky thing; there's always pressure to balance improved security against user convenience. You also need to consider factors such as backward-compatibility and the Principle of Least Astonishment (which says that software should always be written so that its behavior is as unsurprising as possible).

The difficulty of trading off security against functionality has recently been highlighted by a change Microsoft made to the way mailbox permissions are applied in Exchange Server 2003 and Exchange 2000 Server. This change has resulted in some puzzled administrators, some broken BlackBerry Enterprise Server (BES) for Exchange deployments, and a lot of complicated technical explanations. Let's see if we can get to the bottom of what's really going on.

The first thing to understand is that the Full Mailbox Access permission has historically granted holders the right to use the Send As and Receive As permissions. If Alice has Full Mailbox Access on Bob's mailbox, you would expect that she could read Bob's mail; you might not expect that she could send mail that appears to come from Bob (and that appears in Bob's Sent Items folder), but that's the way the permission has worked since the release of Exchange 2000.

This permissions assignment came about because the two permissions involved are divided between the Exchange database and Active Directory (AD). Full Mailbox Access is an Exchange permission; Send As is an AD permission. In the original Exchange 2003/2000 behavior, Exchange didn't perform a separate authorization check for the Send As permission if the requestor already had Full Mailbox Access. This is a reasonable optimization, as well as a convenience for administrators who want both permissions granted together. However, it made life more difficult for organizations that separate Exchange permission assignment from AD management.

Combining the permissions in this way led to two undesirable side effects. Most obviously, it allows for spoofing, because an intruder could use a service account to send mail from any of the mailboxes for which it has Full Mailbox Access privileges. Also, there's no way for a recipient to tell the difference between a message sent by the mailbox owner and one sent by a delegate who has Full Mailbox Access.

To remedy these problems, Microsoft released a hotfix for store.exe, which was first included in store.exe version 7650.23 for Exchange 2003 Service Pack 2 (SP2), plus earlier versions for Exchange 2003 SP1 and Exchange 2000 SP3. The hotfix changes Exchange's behavior so that it explicitly checks for the "Send As" permission before allowing delegate access. This seems simple enough, and for many Exchange sites, it is.

However, organizations that were using BES or Good Technology's GoodLink packages quickly found that the fix affected their installations--BES, GoodLink, and some other third-party (and custom) applications depend on having both permissions granted. Users who had Full Mailbox Access permissions granted to the BES or GoodLink service account, without also having Send As permissions granted, quickly found that they could no longer send mail.

In Microsoft's defense, the company published the article "Users cannot send e-mail messages from a mobile device or from a shared mailbox in Exchange 2000 Server and in Exchange Server 2003" http://www.support.microsoft.com/?kbid=912918 when the hotfix was released. The article clearly explained the problem and what to do about it. However, apparently not everyone got the word; I was surprised to see a new post on the Exchange team blog last week describing the fix in more detail. The Microsoft article was also updated with a more in-depth explanation of what changed; best of all, it now contains a script that you can run to identify users who have Full Mailbox Access but not Send As permissions. The script outputs a tab-delimited file listing accounts, which you can edit and then feed back to the script to apply Send As permissions to the accounts that you actually want to have it.

Do you need to do anything? It depends. If you're using BES or GoodLink software, you'll definitely know when you need to make this change; as soon as you apply a store.exe hotfix more recent than 7650.23 (or the equivalent for your version of Exchange), this behavior will kick in. You should run the script before then to avoid any interruptions in service. If you're not using either of these programs, you should probably still use the script to see whether you have any lurking permissions that you don't know about. It's not uncommon for an administrator who inherits an Exchange organization to be unpleasantly surprised by the permissions granted by his predecessor.

-----

Calling All Windows IT Pro Innovators! Have you developed a solution that uses Windows technology to solve a business problem in an innovative way? Enter your solution in the 2006 Windows IT Pro Innovators Contest! Grand-prize winners will receive airfare and a conference pass to Windows and Exchange Connections in Las Vegas, November 6-9, 2006, plus more great prizes and a feature article about the winning solutions in the December 2006 issue of Windows IT Pro. Contest runs through August 1, 2006. To enter, click here: http://www.windowsitpro.com/AWARDS/innovators_2006.cfm