New Exchange fixes may disrupt Blackberry, Goodlink and other services
Published Apr 28 2006 09:19 AM 19K Views

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 permissions  is 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

 

EDIT: Wanted to let you know that the security bulletin, the KB article pointing to the security bulletin and article 912918 were all updated to answer some of the questions that were coming up on this issue. If you had some remaining questions, please check those again.

 

- Mike Lee

72 Comments
Not applicable
Will this Effect If we assign Send As and Receive As Permission at the Exchange Org Level also ?
Not applicable
Not applicable
ADModify.Net can also grant this access and it is much easier to use than the script if you wish to select a subset of users with an LDAP query or by OU.  The setting is on the Mailbox Rights tab, the first item.

Otherwise, thanks for bringing attention to the issue!
Not applicable
Under the heading of: "You may already be aware of this, but we wanted to make sure..."
Some of our...
Not applicable
@Abby,
No, you can't grant "Send As" on Exchange servers or the organization object to get the same effect as granting "Send As" on user accounts.

For the Exchange organization and server objects, "Receive As" is the functional equivalent of "Full Mailbox Access." Getting this permission on a database gives you access to all the contents of the database--including mailboxes and folders.

So you'd think "Send As" on a database or on the whole organization would give you rights to send as any mailbox in a database, but it doesn't. It actually gives you the right to send as *the database object* (lot of good that does you).

Send As must be granted on the user account or on a container that holds user accounts, not on a database or server.

To grant Send As for all users inside a container, you must use the Advanced button on the Security properties for the container. From there, you can grant an account Send As for all User Objects in the container.

Not applicable
…and now PSS is likely getting slammed by phone calls.
For the last time, you Exchange Admin...
Not applicable
@Brian--


Thanks very much, Brian, for the pointer to ADModify.Net. The development website for this very useful tool is here:



http://www.gotdotnet.com/workspaces/workspace.aspx?id=f5cbbfa9-e46b-4a7a-8ed8-3e44523f32e2



This is a good tool for every Exchange administrator to become familiar with, and it does indeed have a specific task (just mark the checkbox) to grant Send As to users who already have Full Mailbox Access (FMA). For administrators who wish to give everyone

FMA and be done with it, and don't want to mess with a script, this is a perfect tool.



One thing that the script does more easily than ADModify is show you exactly who has FMA for a mailbox. Suppose there are several users who have FMA but not Send As on Mailbox1. The script will dump you a report that looks like:



"mailbox1" "domainHasFMA-1" "Has FMA 1",....

"mailbox1" "domainHasFMA-2" "Has FMA 2",....


By deleting the 2 line and feeding the 1 line back to the script, you can grant to 1 but not 2. ADModify will force you to grant FMA to both 1 and 2--which may be just fine with you.



Keep in mind that granting "Send As" to delegates who have FMA will cause the delegate to always "Send As" instead of "On Behalf Of."

Not applicable
Well, although I started this blog with the best intentions, I have been very bad at keeping it regular. ...
Not applicable
Not applicable
not a nice patch.



Imagine the number of SBS servers with al their tweaky configurations depending on it, with no skilled personal in their comp.



Also if i am an administrator.


It isn't that hard to stil perform a send as.


Altough the user would notice this, just reset password, loing as the user start outlook. Oh yeah and inform the person that of security reasons he had a new password.



The last one may not sound as treu security break, but that's how hackink inside organisations works. And also what underlines the point i want to make, if you cann't trust your administrator who can you trust....



just hope it wil not get into windows update



Not applicable
Pozor na změnu v Microsoft Exchange 2003! Pokud jste používali přidělení práv na poštovní schránce v...
Not applicable
From the May advance notification…
• One Microsoft Security Bulletin affecting Microsoft...
Not applicable
Since there was no "weekend reading" last week, today's list is abnormally long. If you don't have the...
Not applicable
Huomenillalla julkaistavista tietoturvapäivityksistä yksi koskee Exchange-sähköpostipalvelinta, ja kuten...
Not applicable
Any reason you can't just Delegate Authority to your User OU's for the GL/BB service accounts and move on with your life?  Seems simple enough to me.  No need to run a script.

If someone knows why this won't work, PLEASE tell me.
Not applicable
Any reason you can't just Delegate Authority to your User OU's for the GL/BB service accounts and move on with your life?  Seems simple enough to me.  No need to run a script.

If someone knows why this won't work, PLEASE tell me.
Not applicable
@Jason

Yes, Jason, you can delegate by container or domain to grant the appropriate Send As by inheritance. Due to popular demand, KB 912918 has been revised now to include specific instructions for doing this.

I still stand by my caveat that this is not an optimal solution because it may grant permissions for users you didn't intend and you may lose permissions when months later you move an account and forget that the Send As was granted by container inheritance.

But it definitely works as a quick way to get the job done.
Not applicable
Should we be worry about the users which have been created by the ADC ? These were disabled at first, but not after when we have ran the ADMT and ADClean. Do we have old SID from the NT4 in the msExchMailboxGUID ? If yes, is it harmful because of this fix ? Are there any possibilities that Store might believe that I'm not the owner of my mailbox ?
Not applicable
@Jason

Yes, Jason, you can delegate by container or domain to grant the appropriate Send As by inheritance. Due to popular demand, KB 912918 has been revised now to include specific instructions for doing this.

I still stand by my caveat that this is not an optimal solution because it may grant permissions for users you didn't intend and you may lose permissions when months later you move an account and forget that the Send As was granted by container inheritance.

But it definitely works as a quick way to get the job done.
Not applicable
@Petri

Users migrated via ADC/ADMT/etc should be just fine. As a spot check, go to a migrated user object's properties and verify in Exchange AdvancedMailbox Rights that SELF has "Full Mailbox Access." As long as SELF has Full Mailbox Access, then technically you don't even need "Send As" (though Send As is also granted by default to SELF).
Not applicable
Okay, we just don't have SELF on everyones mailbox. But they have account there which have Associated External Account (by ADC maybe) and that user have permissions to use Send As. But if that is also missing... :|
Not applicable
The information in MS06-019 should be revised to state that this permissions behaviour change does not occur as a result of applying this security patch to Exchange 2003 SP2. There is a reference to Microsoft Knowledge Base Article 912918 in the FAQ, but what's missing is "This doesn't apply to Exchange 2003 SP2". Also, information from a third-party vendor did not make this clear either.

I speculate there are a lot of folks out there on Exchange 2003 SP2 that are delaying applying MS06-019 (perhaps to their peril) because they haven't been able to make heads or tails out of incomplete or incorrect information they've seen so far.
Not applicable
FYI - if for some reason your organization uses your user accounts as any of the built-in security group roles (I.E. They are in Domain Admins, Account Operators, etc...) they will break when this STORE update is applied even if you apply permissions to an OU.

Why? Because their permissions inheritence is turned off - and you cannot properly set "Send As" on the AdminSDHolder role (it is a container and not a user object, so the permissions don't match 100%). The only work around I have seen is to basically give the service accounts "full control" over the AdminSDHolder container.
More information can be found here:
http://support.microsoft.com/kb/817433/?sd=RMVP&fr=1
and here:
http://support.microsoft.com/kb/318180/en-us

The proper way to handle this is to NOT user your user mailbox/AD accounts as your administrator accounts. NOTE: if you do undo this at your organization - you will need to go turn permissions inheritence back on for your "cleaned up" users as removing them from the groups does not reset this.
Not applicable
When I run the script I see several accounts that give BES full access but not send as permission. When I look at the permissions on the individual accounts in AD Users & Computers I'm showing the Send As permissions as being allowed for BES. I've run this against several of my DC's so I don't think it's a replication issue. Any ideas?
Not applicable
Ok, so how do we grant this permission to our Domain Admins? (Any yes we DO know that it is "Bad for Security", but we like it that way and have a bunch of users to support in this configuration.)

These midstream changes really suck for your users.
Not applicable
@Petri, RE: Associated External Accounts

Associated external accounts are also exempted from the "Send As" restriction. KB 912918 has details.
Not applicable
@Kevin, RE: Clarifying MS06-019.

Thanks for the suggestion. Text has already been forwarded, and the bulletin should be amended soon.
Not applicable
@Tom, RE: script not properly catching accounts.

Without digging into your AD, I'm not sure of the reason for this. Is it possible these accounts also have Deny set somewhere for Send As? (Do you see both Allow and Deny checked somewhere in the container tree?)

If this is happening for a subset of accounts, is there something else they have in common? Are they admin users, perhaps?
Not applicable
@Miles Holt, RE: Granting Send As to domain admins.

KB 9121918 discusses this. In fact there's a new revision just published this morning that has some more specifics and references around the adminSDHolder issue. Explicit instructions for editing the adminSDHolder object were omitted from the article, to avoid giving the impression that we recommend editing it for mail purposes. However, if you just follow the links.... :)

I'm sorry about the hassle caused by this change. We know it's not easy. There was a lot of discussion about whether or not to do the change, because we knew it would be a pain for many administrators. In the end, we decided that the security improvement was valuable enough that we should make the change, including backporting it to Exchange 2000.
Not applicable
The syntax given for the script is wrong.
In the KB article says to use the following:
CSCRIPT AddSendAs.vbs CORP-DC-1 –Export

However, the export parameter must be in UPPERCASE as follows otherwise the script will not run!
CSCRIPT AddSendAs.vbs CORP-DC-1 -EXPORT
Not applicable
This is not a big deal, I don't see why a lot of folks are fuming about this.  If your AD OU structure has a parent "Users" OU, and then several sub-User OUs (like ours), simply add the BES account (or other) to the parent User OU with SEND AS permissions on the User objects.  Of course this assumes you allow inheritance to sub-OUs.  Once this is done, apply the hotfix to all your E2K3 SP2 servers, and your done.

I talked with PSS on this last night ... they suggest the OU approach if you have many BES users.

Where do you think "all the extra work" comes in at?  Is it because your OU structure is different?
Not applicable
Are any of you having trouble with OWA after applying MS06-019?
Not applicable
Ken ... no, I've have no problems with OWA.  What issues are you experiencing?
Not applicable
Our web interface is garbled and never loads the mailbox.  We've had 2 units experience this.  The OWA frontend servers are in a different administrative unit than these 2 particular backends where the problem is occurring.
Not applicable
Not experiencing any issues here ... we have 3 front-end OWA servers, in 3 different Admin groups.  I connected to my mailbox via each front-end server without any problems.  My backend server has the hotfix installed.
Not applicable
We had the same thing occur.  The 6.5.7651.9 (highest version) directory in c:Program FilesExchsrvrexchweb wasn't created on the front-end server.  Simply copy that folder to your front-end server.
Not applicable
I have the same issue as Ken West. The Premium Web Interface on the Frontend Server does not work for one Backend Server. The Second BE works fine.

I don't know, what went wrong.
Not applicable
Does anyone know if uninstalling the patch will restore the functionality pre-patch (allowing admin mailboxes to be used by Goodlink, etc)?

Also, does installing the patch on one Exchange server (2000 in our case) affect ALL users in the domain or just users on the exchange server where the patch was installed?
Not applicable
@Joe RE: Script parameters are case sensitive

You may have gotten hold of a pre-release version of the script. This was fixed before its initial release in the KB article. Parameters are not case sensitive.

Also, stay tuned for an update to the script in the next several days which will include the ability to suppress specific accounts that you don't want to see in the output.
Not applicable
@Brian RE: Uninstalling the MS06-019 security update

The security update is completely uninstallable, and will put back the original files, returning you to original functionality.

With regard to the "Send As" change, installing MS06-019 on Exchange 2000 makes no difference. Only the Exchange 2003 SP1 version of the update includes store.exe, which is where the "Send As" change is implemented.
Not applicable
Thanks Mike for the feedback.  Maybe I'm just having a rough week but doesn't the article mention that it affects Exchange 2000 if you have store version 6619.4 or later?  We are running 6603 so I'm assuming our Goodlink server will be unaffected by applying this update?  I assumed that if we apply this it will automatically apply this functionality change?
Not applicable
I patch is absolutely horrible.  If customers wanted this so much, fine split it from the calendar vulnerability and offer as a separate update, don't force admins to apply the patch because of security vulnerability, a poison pill so to speak.  All of IT is crippled and no communication can occur from our Blackberries, we have resorted to SMS to get a hold to one another.  We have a really small IT staff and support many system and different platforms, we need this functionality and they keep revising the KB Article.  I want to modify the adminSDHolder permission to restore send as permissions.  In rev 5.2 it was listed ho how to modify the adminSDHolder permission to allow protected groups to have the send as permission once again.  I am feeling the heat from my web group as well as my IT Group.  Can anything be done?
Not applicable
@Dean



Hello, Dean, I'm sorry the behavior change is causing you this amount of pain. For reasons discussed in the comments above, we were unable to make the behavior change optional.



And you are correct that we have modified the KB article several times, in response to user feedback. In fact, the article will be updated again soon with a new version of the script that allows custom filtering of accounts you don't want reported, and that suppresses the "Exchange Services" account, thus reducing the export file size for organizations that have used the Active Directory Connector.



We don't recommend modifying the adminSDHolder permissions because we don't recommend making administrator accounts into mailbox owners. The instructions for modifyng adminSDHolder permissions were removed from the article to avoid giving the impression that we recommend doing this.



Nonetheless, I left links in the article to several other articles about adminSDHolder, including one article with the instructions for granting a group Send As on all administrator accounts. These articles explain the security issues and our recommendations in some detail. If you wish to modify adminSDHolder to resolve the issues you are experiencing, you can follow those instructions, although, again, we do not consider it a best practice to do so. In the long run, it is better to follow the instructions in the article for granting an administrator access to a mailbox owned by a limited account.

Not applicable
I understand the best practices part of this, I have already tried granted the adminSDholder permissions.  This still failed to resolve my issue.  I have had a call open with MS Support services for over a week now, as they still do not know how to get this working correctly.  It is very, very much of a problem on this end.  I have even gone so far as to delete the elevated permissions as a test on one of the mailboxes. This still failed to allow the user to send emails from their Blackberry.  So now I have to figure out the command syntax to remove the sendas permissions from the adminSDholder permissions....

The only way I see for this to work, is to remove your mailbox from your primary account.  Then instead of creating a new mail account on the secondary account, rejoin the old primary mailbox to the secondary mailbox.  The problem with the KB workaround is this...if I create a standard user account lets call it bbjdoe and my account with admin rights is called jdoe.  The KB article is not clear exactly what I am supposed to do with bbjdoe, so I assume I am to replace the jdoe account on the Blackberry server with bbjdoe.  So now my Blackberry device can send email messages, but now I no longer can receive email messages that are going to my jdoe account, because AD wants a unique email address for each account...you can't have jdoe@domain.com in two locations.  So I set up forwarding from the jdoe account to the bbjdoe account, still however all email messages being replied from the Blackberry account with show up as bbjdoe@domain.com.  Am I wrong here?  Help me understand this please.  I have already spent many of hours on this and have put critical projects behind schedule because of this change in behavior.  
Not applicable
I heard from my colleague in India who supporting another customer mentioned that there is a problem for PDA which will not sync after patch installed. Is this true?
Not applicable
Quick Q - this is an AD perm, whereas 'full mailbox rights' are exchange perms - correct?

Second, I'm testing this but want to grant a number of users 'Full mailbox rights' so that i can then test this script. Rather then going into each individual user and enabling 'Full mailbox rights' can do this en bullk?

Finally, If I set the 'send as' right at the container level, and force inherit to child objects, this will result in a new ACE being created for each user object, with this permission. These changes will then need to replicate to all other DC's - Anyone able to comment on how much replication on the wire will result per user object. I'm thinking in our large environment with thousands of users, is this likely to be a large replication overhead?

Thanks
Nate
Not applicable
912918 is a long and informative article.  I'd like to make sure I understand the bottom line.  The article mentions that granting Send-As permissions for multiple accounts (either applied to a container or all AD objects) is not the preferred method.  So if we use the Blackberry application as an example, would the preferred method be to ?:


* Grant Send-As permissions for the Blackberry service account to each existing individual Exchange/Blackberry user account.  Likewise, when we add a new Exchange/Blackberry user, we grant Send-As permission in the same manner.


* For domain administrators that are also Blackberry users, we remove these users from the domain admin group. To perform tasks that require domain administrator security, these users would either log in with an account that has domain admin privileges, or use the RunAs command to accomplish same.



Does this sum it up ?




Sam Tudorov

Not applicable
Summary for best practices for Admins?

OK, so what should people that have Domain admins that are mail enabled do?

Can we get a nice step-by-step that will end up with BB's still sending mail as the same account as well as the domain admin prived account bing able to do so as well?

You guys forgot one of the rules of a tech company... don't breeak the tech guys' toys! :(
Not applicable
@Dean

If you will ask the PSS engineer who is handling your case to follow up with Michael Lee on the Exchange team, I will be happy to take a look at what is going on. The behaviors you describe are not xconsistent with any other case I've encountered. There may be something additional in your environment that is the source of the trouble.
Not applicable
@Yonkey

I can't address the issue without knowing more specifically which PDA, but it is very possible. Any application or service that sends as / for a user could be affected.  Even without knowing which PDA you mean, I can tell you that the solution is the same in all cases: grant Send As for affected mailboxes to the account under which the application runs.
Version history
Last update:
‎Jul 01 2019 03:13 PM
Updated by: