If you’re using Blackberry, Goodlink or other similar services, this is a very important read.
CALL TO ACTION
A change in Exchange permissioning behavior may impact mobile communications and other add-on applications for Exchange. Shared and resource mailboxes may also be affected.By evaluating in advance whether this change will impact your environment, you can take simple remediation steps to ensure that installation of a new Exchange update will not impact critical services. A script is available to help you identify accounts and applications in your environment that may be affected.
EXECUTIVE SUMMARY
A change has been made in how the “Send As” permission works in Microsoft Exchange. In the past, additional accounts could be granted the “Full Mailbox Access” permission to a mailbox and these accounts could then send mail as the mailbox owner. From now on, the “Send As” permission must be explicitly granted to additional accounts or they will not be able to send mail as the mailbox owner.
This change can affect add-on services that have relied on “Full Mailbox Access” alone for impersonating users to send messages on their behalf. For example, the user of a mobile email device may compose a message on the device. This message is transmitted to the mobile access service, which logs on to Exchange and sends the message as the user.
New rollups and service packs for both Exchange 2000 and Exchange 2003 will include this change, as will all updates and hotfixes for the Exchange Information Store service (store.exe).
The change was made several months ago and has been documented in Microsoft Knowledge Base Article 912918. However, many administrators have been caught by surprise after downloading an Exchange store update for a different issue. Therefore, the Knowledge Base article has been rewritten to more fully explain the change, and Microsoft will be publicizing the article widely, both internally and externally. A sample script has been added to the article that shows administrators how to quickly identify affected accounts and to correct their permissions, if necessary.
This change in permissions behavior will not keep Exchange mailbox owners from sending mail when logged on as themselves. But it may keep them from sending from a mobile device that impersonates them, or affect other applications or users who send mail as them. This change also does not affect “cross-forest,” “resource forest” or mixed Exchange 5.5 and Exchange 2000/2003 installations.
Nonetheless, running the script right now is a good idea, both to get familiar with how it works, and to find out whether you have affected accounts you don’t know about. You may have created resource or other shared mailboxes and forgotten to grant “Send As.” Or you may be running scripts and applications that do not grant “Send As” when they should.
The script for finding affected accounts and granting them the right permissionsis available from this link:
http://support.microsoft.com/kb/912918
FREQUENTLY ASKED QUESTIONS
WHY DID YOU MAKE THIS CHANGE IF IT BREAKS SOME APPLICATIONS?
The change was implemented because of multiple requests from customers, and it provides additional security functionality in several scenarios. For example, consider a disaster recovery situation where an Exchange administrator needs full access to all mailboxes in a database in order to merge or salvage mailbox contents. Before, you could not grant such access without also giving the administrator the ability to send as any user in the database.
Correcting problems created by the change is straightforward–just go to the mailbox owner account and grant the “Send As” permission to the account that needs to send as that mailbox.
The old behavior was confusing too. An administrator might explicitly deny “Send As” rights and the Deny would have no effect when an account had “Full Mailbox Access”. The way it works now is easier to understand and administer.
IS THERE A REGISTRY KEY OR SOME OTHER WAY TO OVERRIDE THE NEW BEHAVIOR UNTIL I’M READY FOR IT?
No, there is not. Providing a registry key or other override was considered and rejected because it would allow temporarily overriding the enhanced security whenever someone wanted to.
Something to remember is that this change applies only to additional accounts that are granted “Full Mailbox Access.” If you are the mailbox owner, you don’t need additional “Send As” permission. In cross-forest or Windows NT 4 mixed domain scenarios, the “Associated External Account” is treated like the mailbox owner, and so is a delegate who has been granted “Full Mailbox Access.” Microsoft Knowledge Base article 912918 discusses each of these scenarios and exceptions in detail.
WHAT EXACTLY DOES THE SCRIPT DO?
The script is pretty simple. It works on one Active Directory domain at a time. In its Export mode it finds all accounts in the domain that have “Full Mailbox Access” to a particular mailbox, but don’t also have “Send As.” It ignores accounts that already have both permissions. So the output file only contains accounts that might have a problem.
The Export file is tab-delimited. You can sort it and edit it in Notepad or Excel, and then feed the file right back into the script to grant “Send As” in bulk for all accounts listed in the file.
Full documentation and tips on using the script are included in the Knowledge Base article.
ARE THERE OTHER WAYS OF CORRECTING THE PROBLEM WITHOUT USING THE SCRIPT?
You can use the Active Directory Users & Computers console to set permissions on individual accounts. You can also grant “Send As” for all objects in a domain or container, and thus have the permission take effect by inheritance.
WHERE DO I GO FOR MORE INFORMATION?
Microsoft KnowledgeBase article 912918 is the place to start. It includes the script and the details about how all of this works – including information about Outlook delegation scenarios. To really dig in to how Exchange permissions work, settle in with these white papers:
Working with Active Directory Permissions in Exchange Server 2003
http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/ex2k3ad.mspx
Working with Store Permissions in Microsoft Exchange 2000 and 2003
http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/storperm.mspx
Source: http://blogs.technet.com/exchange/archive/2006/04/28/426707.aspx