Exchange Sustained Engineering (Exchange SE) recently fixed a problem regarding “Send As” permissions and “Full Mailbox Access” permissions. Up until now, “Full Mailbox Access” permissions had been sufficient for one user to be able to send email as another user. While “Full Mailbox Access” sounds like it should be sufficient for sending mail as another user, it was not intended to work that way. From now on, all Exchange 2003 store hotfixes contain a fix that will require the “Send As” permission for one user to be able to send an email as another user. This change was documented in the following KB article:
The “Send As” permission fix is included in all store.exe hotfix builds 7233.51 and higher for Exchange Server 2003 Service Pack 1 (SP1). The “Send As” permission fix is also included in all Store.exe hotfix builds 7650.23 and higher for Exchange Server 2003 Service Pack 2 (SP2).
Very soon some of you may run into a problem after applying one of these recent Exchange 2003 Store.exe hotfixes where your BlackBerry or GoodLink servers will be unable to send messages. In fact, any application that uses a service account to send messages as another user may experience a problem if “Send As” permissions weren’t granted properly. Here are a few clues to keep in mind when you encounter a problem with an application not being able to send mail with Exchange 2003:
1) Was a store.exe hotfix recently installed on your Exchange 2003 server and if so, does the build number match the builds that contain the ‘Send As” permissions fix?
2) Is the application using an account to send messages as other users?
3) Is the application receiving an “Access Denied” error?
All of these clues added together indicate that your application is being affected by the “Send As” permission fix. Fortunately, the permission fix is NOT in Exchange 2003 SP2 which will give us time to proactively spread the word and help avoid problems from occurring.
GoodLink and RIM were contacted as soon as we discovered the fix was going to be a problem for their products. We gave them the solution to resolve the problem for existing installations while encouraging them to update their setup programs to apply “Send As” permissions properly in the future. In addition, both companies wrote their own KB articles to prepare their own support staff. The KB article I wrote for Microsoft regarding this issue can be read here:
This is the resolution section straight out of the KB article:
To resolve this issue, grant the following permission to the account under which the application runs:
The Send As permission on the user object in Active Directory
You can grant this permission directly or by using inherited permissions. To grant the Send As permission on all non-administrator accounts in a domain, follow these steps:
1. Start the Active Directory Users and Computers tool.
2. On the View menu, click Advanced Features if this option is not already enabled.
3. Right-click the domain object, and then click Properties.
4. Click the Security tab, and then click Advanced.
5. Click Add.
6. In the Name box, type the name of the account under which the application runs, and then click OK.
7. In the Permission Entry for domainName dialog box, select "User objects" in the Apply onto list.
8. In the Permissions list, click to select the Send As check box in the Allow column.
9. Click OK three times to save your changes and to close all the dialog boxes.
To verify that the Send As permission has been successfully granted on a user object, follow these steps:
1. In the Active Directory Users and Computers tool, right-click a typical non-administrator user account, and then click Properties.
2. Click the Security tab.
3. Make sure that the account under which the application runs appears in the Name list. Additionally, make sure that the Send As check box in the Allow column is selected for this account.
Administrator accounts require the use of a dsacls command to grant Send As permissions to an administrator account. To grant the Send As permission for an administrator account, run the following command:
dsacls "cn=AdminSDHolder,cn=system,dc=domain,dc=example,dc=com" /G "domain\ApplicationAdminAcct:CA;Send As"
In this command line, replace the placeholders as follows:
· Replace domain.example.com with the name of your domain.
· Replace dc=domain,dc=example,dc=com with the distinguished name of your domain.
· Replace domain\ApplicationAdminAcct with the name of the account under which the application runs.
The following is a link to Goodlink’s article on the subject:
This is a link to RIM’s article on the subject:
If you have any problems with RIM’s link, try incrementing the number at the end of that link. That number changes each time they update the version of their KB.
Both GoodLink and RIM were each attempting to assign “Send As” permissions when their products were being installed but there was some confusion over the way permission inheritance worked. The GoodLink Server setup program granted “Send As” permission to the GoodLink Administrator at the Exchange Organization level which was propagated through inheritance down to the Exchange store. The BlackBerry server setup program granted the BESAdmin “Send As” permission at the store level. The problem here is that the mailboxes are stored within the Users Active Directory container while the Exchange store is in the Exchange Org Active Directory container. Permission inheritance within Active Directory only propagates within the same container. Thus, the “Send As” permissions that GoodLink and RIM were dutifully attempting to set were not being replicated to the mailboxes which are held in a separate container. This was not an issue in previous builds of the Store.exe which weren’t enforcing the “Send As” permission properly. Thus, both GoodLink and BlackBerry did not experience a problem with previous builds of the Store.exe. While I am focusing on GoodLink and BlackBerry specifically, this problem may affect other applications as well. I am currently working with Cisco to determine if Cisco’s Unity Unified Messaging product also has a problem. So far Cisco’s tests have been inconclusive.
There is understandably quite a bit of confusion regarding the “Send As” permission. The “Send As” permission is actually not an Exchange specific permission (even though it obviously pertains to the ability to send mail as someone else). “Send As” is actually a Windows 200x specific permission. The “Send As” permission option appears on the Security tab of a user's properties dialog box when you view the properties of that user account by using the Active Directory Users and Computers tool. The “Send As” permission option does not appear when you click Mailbox Rights on the Exchange Advanced tab of that user account's properties dialog box.
By default, you cannot view the “Send As” permission entries by using the Exchange System Manager tool. To view these entries, you must set the following registry entry:
HKEY_CURRENT_USER\Software\Microsoft\Exchange\EXAdmin Value name: ShowSecurityPage Value type: REG_DWORD Value data: 1
When you set this registry entry, the Security tab appears in the following properties dialog boxes in the Exchange System Manager tool:
· Administrative Group
· Mailbox Store
This registry entry does not cause the security settings to appear for individual mailboxes in the Exchange store. To view mailbox and user permissions, you must use the Active Directory Users and Computers tool.
I hope you all find this Blog entry and my KB article useful in preventing and resolving problems with the new “Send As” permission fix.
- Paul Bonrud