BlackBerry and GoodLink users may be unable to send messages after applying latest Exchange 2003 store hotfixes

[The_Exchange_Team]

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:

          http://support.microsoft.com/kb/895949/

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:

          http://support.microsoft.com/kb/912918/en-us

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:

          http://www.good.com/faq/17540.html

This is a link to RIM’s article on the subject:

http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/8021/8149/8064/Support_-_Use...

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:

·         Organization

·         Administrative Group

·         Server

·         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

[#2]

Thanks for the info Paul.

Hasn't this been something that has switched back and forth a couple of times with E2K as well? I seem to recall running into issues depending on what QFE levels of Exchange was running.

Overall this is an area, permissions, that has been one of much issue for nearly everyone trying to work out minimum permissions properly since Exchange related permissions are stored in at least four places. The config container perms which eventually gets mapped/copied to the msExchMailboxSecurityDescriptor, the domain NC permissions (such as Send As), the publicDelegates attribute, and the actual MAPI folder "attributes" aka permissions in the mailbox folders themselves.

I realize that some of it is for backwards compatability but I would rather see interfaces that thunk the old mechanisms up to new mechanisms and publish some new consistent mechanisms that people can start using. Permissioning shouldn't be this difficult and it is why so many people screw it up or don't have any permissions in place really at all (another form of screwing it up but they don't know until someone does something bad).

While I am at it, the whole trying to segregate and delegate Exchange perms when you have separation of duties is a train wreck as well. I spent weeks in a lab with some good Enterprise level MCS folks trying to work out good minimal perms for Exchange admins that followed good AD best practices for ACLs as well and was unsuccessful at hitting our goals. In the end, we had to give up and allow the Exchange admins more rights than they should have instead of populate AD with a ton of deny ACEs which would have just bloated the 2K DIT and slowed things down due to all the ACEs. Of course that does nothing to help the extra permissions that Exchange admins can also grant themselves by assuming localsystem on an Exchange server and going off doing things (say like adding themselves to the same groups the Exchange servers are in). If I knew then what I know now, there would have been no way Exchange would have been in the main production AD, it would have been in a single domain resource forest.

Anyway, sorry to rant, I didn't intend to. I would like to see this stuff addressed in E12. I don't expect much of a change but I would really hope to see it.

[#3]

Isn't this old stuff? http://support.microsoft.com/kb/327174/

[#4]

Nicely timed :o) I am running a blackberry install this week, so I'll keep an eye out for this issue.

Thanks

[#5]

How about this particular issue with third party (Blackberry and Goodlink) wireless calendars?
http://support.microsoft.com/?id=899919

It seems to me that deleting a calendar item and recreating it will only cause confusion for any third party applications.
The cut over from using Entry IDs to Global Object IDs seems to be dependant on switching from Outlook 2003 SP1 to Outlook 2003 SP2. This feat is darn near impossible to coordinate in large organizations, and third party vendors will have a terrible time trying to figure out which field to key on.
In other words Microsoft is pretty much forcing third party vendors to code in for both situations simultaneously, otherwise organizations have to hold off deploying Exchange 2003 SP2 to try an deflect this problem.
This doesn't make sense to me...

[#6]

The KB article (and therefore the bit copied into this blog) is slightly confusing/misleading with respect to the dsacls command.

The KB article makes reference to a "domain.example.com" placeholder, which doesn't exist.

The article also has "AdminSDHolder" in italics (although this isn't reproduced in this blog) which suggests that it needs changing but my intial examination of the process is that it should be left alone, as should the "cn=system" bit. There are actually only two things that need changing - the "dc=domain,dc=example,dc=com" and "domainApplicationAdminAcct".

A valuable blog entry though and good to get some heads up on this.

[#7]

So what you are saying is that having a Send As permission on the Store level does not give an account ability to send as mailboxes in that Store?
If that is the case, then what is the point of having Send As permission at the Store level?

[#8]

GeneK:

The SendAs/ReceiveAs that you apply to the config container (store level) are used to indicate Full Mailbox control (which is what you will see if you look at the Exchange Security Tab of a mailbox, it will be the inherited Full MBX) over the store and all mailboxes in it.

[#9]

I guess this could also affect the service account that Cisco's Unity software requires?

Teo

[#10]

I'd like to get an answer to Joe's question. Our service account has an explicit Send As perm at the store level and wanted to know whether that is enough to ensure service account's ability send as once the hotfix will be applied. Anyone seen articles with explanations on store level perms?

[#11]

Hmm...

http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/8021/8149/8064/Support_-_Use...&vernum=6">http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/8021/8149/8064/Support_-_Use...&vernum=6


Why not http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/8021/8149/8064/Support_-_Use... ?  This will take you to the latest version - whatever it is..

[#12]

I happened to stumble upon this one by chance-and I do admit I am really happy since I am very familiar...

[#13]

Following the change to the way the Information Store working with Exchange 2003 (http://blogs.technet.com/exchange/archive/2006/01/13/417440.aspx)...