New Exchange fixes may disrupt Blackberry, Goodlink and other services


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

Comments (72)
  1. Abby says:

    Will this Effect If we assign Send As and Receive As Permission at the Exchange Org Level also ?

  2. Brian.Kronberg says:

    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!

  3. Anonymous says:

    Under the heading of: "You may already be aware of this, but we wanted to make sure…"

    Some of our…

  4. Mike Lee says:

    @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.

  5. Anonymous says:

    …and now PSS is likely getting slammed by phone calls.

    For the last time, you Exchange Admin…

  6. Mike Lee says:

    @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."

  7. Anonymous says:

    Well, although I started this blog with the best intentions, I have been very bad at keeping it regular. …

  8. Peter says:

    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

  9. Anonymous says:

    Pozor na změnu v Microsoft Exchange 2003! Pokud jste používali přidělení práv na poštovní schránce v…

  10. Anonymous says:

    From the May advance notification…

    • One Microsoft Security Bulletin affecting Microsoft…

  11. Anonymous says:

    Since there was no "weekend reading" last week, today’s list is abnormally long. If you don’t have the…

  12. Anonymous says:

    Huomenillalla julkaistavista tietoturvapäivityksistä yksi koskee Exchange-sähköpostipalvelinta, ja kuten…

  13. Jason Shaw says:

    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.

  14. Jason Shaw says:

    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.

  15. Mike Lee says:

    @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.

  16. Petri says:

    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 ?

  17. Mike Lee says:

    @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.

  18. Mike Lee says:

    @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).

  19. Petri says:

    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… :-|

  20. Kevin says:

    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.

  21. Dan Sheehan says:

    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.

  22. tom says:

    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?

  23. Miles Holt says:

    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.

  24. Mike Lee says:

    @Petri, RE: Associated External Accounts

    Associated external accounts are also exempted from the "Send As" restriction. KB 912918 has details.

  25. Mike Lee says:

    @Kevin, RE: Clarifying MS06-019.

    Thanks for the suggestion. Text has already been forwarded, and the bulletin should be amended soon.

  26. Mike Lee says:

    @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?

  27. Mike Lee says:

    @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.

  28. Joe Stocker says:

    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

  29. my55tec says:

    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?

  30. Ken West says:

    Are any of you having trouble with OWA after applying MS06-019?

  31. my55tec says:

    Ken … no, I’ve have no problems with OWA.  What issues are you experiencing?

  32. Ken West says:

    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.

  33. my55tec says:

    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.

  34. mathandmetal says:

    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.

  35. Volker Wend says:

    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.

  36. Brian says:

    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?

  37. Mike Lee says:

    @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.

  38. Mike Lee says:

    @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.

  39. Brian says:

    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?

  40. Dean says:

    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?

  41. Mike Lee says:

    @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.

  42. Dean says:

    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.  

  43. Yonkey says:

    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?

  44. Nate says:

    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

  45. Sam Tudorov says:

    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

  46. Brian Hampson says:

    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! :(

  47. Mike Lee says:

    @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.

  48. Mike Lee says:

    @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.

  49. Mike Lee says:

    @Nate

    Q: "Send AS" is an AD perm and "Full Mailbox Access" an Exchange perm?

    That’s right. "Send As" permission applies to AD objects and is completely stored in AD. "FMA" is in an Exchange database, and is reflected in the AD interface so you can see it and change it.

    Q: How do I grant multiple users "FMA" all at once?

    There’s no way to to do this through the normal GUI administrative interfaces. It would have to be scripted or done with an additional utility. However, you can grant by inheritance on a test container in Active Directory.

    Q: How much AD replication traffic will this generate if I change the ACLS for many users at once?

    I’m not an AD replication expert, and someone may correct me or have closer estimates. I believe that the ACL must replicate entirely when you make a change. And there is some network traffic overhead/back and forth with the PDC emulator from making security attribute changes. A lot therefore depends on ACL sizes, which typically depend on number of group memberships. I would guestimate that you’re looking at 4K/user/DC if you have less than 80 group memberships on average, and double that for every 100 group memberships above that. Between sites, I would expect you to get a lot of benefit from compression (80%? 90%?).

  50. Mike Lee says:

    @Sam Tudorov

    I apologize for the length of the article! But I’m glad it’s informative… :)

    SAM: 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.

    MIKE: It’s not a horrible method, except that it may capture objects you didn’t intend, or miss objects that get moved. It’s easy, years later, to forget that user X in container Y needs special treatment if ever moved to another container.

    SAM:  So if we use the Blackberry application as an example, would the preferred method be to…when we add a new Exchange/Blackberry user, we grant Send-As permission in the same manner.

    MIKE: Currently, it is what I would recommend. At some point, I believe RIM will have an update to correclty provision users, but I don’t have details on an ETA for that. You can somewhat automate this by periodically running the script in the KB article to catch new users or as part of your normal provisioning. RIM also has a script.

    Again, if you don’t want to do this, managing this by inheritance isn’t a bad thing–you just need to remember that’s the way you’re managing it.

    SAM: 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.

    MIKE: As a general best practice, you really shouldn’t have someone reading their email or surfing random web sites while logged on as domain admin. What if an administrator’s curiosity about that purported new Anna Kournikova pic gets the better of him for a second? I know this is inconvenient. But ignoring this best practice isn’t just less than optimal, it’s close to reckless. I don’t want to be a scold, but this is scold-worthy.

  51. Mike Lee says:

    @Brian

    What should you do if you have mailbox-enabled domain admins? You should take away their mailboxes or take away their admin rights! Ok, that’s a little facetious, but I mean it. While I’m still in scold mode (see above post), I’ll say this:

    The net is getting to be a very hostile and criminal place. It’s to the point where running as admin on a WinXP Home box connected to the Internet is gutsy, if not reckless. Ignoring the principle of "least privilege" when it comes to an account that owns your entire security infrastructure–in my view, that’s negligent. </scold>

  52. Alan Gordon says:

    It sounds like Microsoft is playing some kind of game by not explicitly pointing me to the instructions for modifying adminSDHolder permissions. I need to know the exact instructions, and I need them RIGHT NOW.

  53. f1tech says:

    I see a double standard here…

    The fix, supposedly, has been implemented as a necessary security measure.  But there has been nothing done, and probably won’t be anything done, to prevent admins from being mailbox enabled.

    MIKE: As a general best practice, you really shouldn’t have someone reading their email or surfing random web sites while logged on as domain admin. What if an administrator’s curiosity about that purported new Anna Kournikova pic gets the better of him for a second? I know this is inconvenient. But ignoring this best practice isn’t just less than optimal, it’s close to reckless.

    As a best practice, yes I agree that we all should be dilligent and follow best practices…  However, if we are allowed to mailbox enable admin users, you should be obliged to provide information to fix what you have broken.

  54. Josh says:

    I have some very peeved superiors right now. You can spout best practice methods off, but the fact remains that MANY Domain Admins have mailboxes. I agree 100% that if you’re so adamant about the best practice to be that Domain Admins are not mailbox enabled, then why not make a patch to kill that ability?? You take it away from us as a side-effect of a patch and then more or less tell us "it should be like this anyway"??? :confused:

    So as see it, I have 2 options right now, as my CTO and Manager are in Las Vegas at Networkers and can’t send any mail (they’re Domain Admins).

    1) Uninstall the patch and make sure I NEVER install it again.

    2) Modify the adminSDholder permissions

    I’m not a fan of backing out patches, but I’m leaning towards number 1.

    Side Note: I’m sure Microsoft was aware that this would break BES. It’s not like BES is some small, 3rd party app that a few companies run. Was RIM contacted ahead of time? I spent 3 hours on hold yesterday, just to find out that anyone with a mail-enabled Admin account was more or less screwed.

    Time to back the patch out, and I’m pulling my Exchange server from WSUS, because I’m not going through this again.

  55. SubEffect says:

    Regardless of best practices, it is up to the administrators and management to assess the risks involved in using domain admin accounts for normal, daily use.  There are circumstances, admittedly rare, where admins may be confident enough of their environments enough to use enterprise/domain accounts wherever they log in (usually their own).  Is my environment that safe?  Possibly.. possibly not.  At this point, it has not led to any disasters.

    That said, we pay the licensing on MS software and should be allowed to configure it as we please, provided it is legal.  Since this isn’t a legal issue, why enforce this function and make it so difficult to work around when it was expected that it would affect users in this manner.  

    I have even made the SD container changes and still have issues with the permissions getting revoked.  I’d rather not back out on any patches.  I removed the admin accounts from protected groups for now, but it’s been highly annoying.

  56. Josh says:

    *sigh*

    I backed the patch out, reapplied the proper permissions, and they’re STILL disappearing now. Unbelievable. Back to the drawing board I go.

    /waits to get fired when Bosses return from Vegas..

  57. Alan Gordon says:

    I fixed the problem with admin accounts not being able to send email by by using adsi edit to modify the inheritance on the AdminSDHolder object. The procedure is included in Microsoft KB 817433.  

    Be patient, it took about 2 hours for all the domain admins Blackberrys to return to full functionality. I didn’t have to restart the Blackberry router service.

    I don’t know which was worse – having to wait on hold for hours to get NO SUPPORT from RIM, or having to read the crap on this Board about Microsoft knowing better than me how to conduct my company’s business.

  58. Josh says:

    Alan,

    can you be a bit more specific. I didn’t use ADSI edit, I set the permissions on the AdminSDHelper Object to allow Domain Admins and BESAdmin to SEND AS.  

    I checked the rights on the Exchange Store itself and somehow the Send As and Resceive As had explicit DENY’s on them, even after backing the patch out. I turned oiff inheritence so I could remove the DENY statements.

    Any help with the ADSI Edit steps would be GREATLY appreciated.

  59. f1tech says:

    After working with MS Partner suppoprt newsgroups, I got the following answer on how to easily modify the adminsdholder object permissions to grant send as permission to the BES service acct.  Their disclaimer (obviously) is that MS did not and does not endorse or recommend the following solution, although it works.  Best practices aside, please do not hold me responsible (another disclaimer).

    Remember to replace domainname with your own, as well as domainnameBlackberrySA (the name of your service account).  Hope this allows some fellow CTOs to keep their jobs… And their temporarily useless Blackberries!

    dsacls "cn=adminsdholder,cn=system,dc=domainname,dc=com" /G "domainnameBlackberrySA:CA;Send As"

  60. SubEffect says:

    I used ADSI Edit as well.  I added the BB service account to AdminSDHolder with Send As.  Now, the admins get to keep the BB service account, but it has no permissions.  The admins only exist in one OU and that OU also has the Send As permissions.  I can’t find what is stripping it off now.

    I’ll check 817433..  

    I just ran the DSACLS command shown above.  Thanks for the tips folks..  

  61. guillermo says:

    Could we just uninistall that dreaded patch MS06-019 ? would that revert back the exchange / ad settings to how it was?

  62. SubEffect says:

    Finally..

    The ONLY thing that worked for me was the DSACLS command.  It’s been 3 hours since I performed the function and admins in two protected groups have the Send As permission.

    Thanks again..

  63. shawn says:

    Ok, so if I’m running AD with an empty forest root and I want to be brave enough to use the dacls command, would I run it in the forest root domain or my child domain (where the users accounts and mailboxes are located?

    Thanks!

  64. Alin.achim says:

    Ok here’s my story.

    I wanted to be able to let admin sending mails via BB devices.

    I used ADUC, view – advanced features and opened SYSTEM container, right click on AdminSDHolder- Security – and added blackberry service account with full permissions. That seem to fix it.

    Previously I tried just to add "send as" permission, the way I did wit regular users, but that didn’t work.

    A

  65. Alan Gordon says:

    Here is the procedure I used from KB817433. Not sure why they say you can use Active Directory Users & Computers – I had to use Adsi Edit.

    *****************

    You can enable inheritance on the adminSDHolder container by using ADSI Edit or Active Directory Users and Computers. The path of the adminSDHolder container is CN=AdminSDHolder,CN=System,DC=<MyDomain>,DC=<Com>

    Note If you use Active Directory Users and Computers, make sure that Advanced Features is selected on the View menu.

    To enable inheritance on the adminSDHolder container: 1. Right-click the container, and then click Properties.

    2. Click the Security tab.  

    3. Click Advanced.  

    4. Click to select the Allow Inheritable permissions to propagate to this object and all child objects check box .

    5. Click OK, and then click Close.  

    The next time the SDProp thread runs, the inheritance flag is set on all members of protected groups. This procedure may take up to 60 minutes. Allow sufficient time for this change to replicate from the primary domain controller (PDC).

    **************

  66. Alin.achim says:

    Alan, indeed you can do it that way, but you will break security mecahnism that prevents domain admins to have permissions being manipulated. Is it a big deal ? I don’t know but I’d like to approach it with less disruptive scenario.

    Instead I preffered just to add BB service account full permissions to AdminSDHolder, and that will propagate to every domain admin. Still not sure why "send as" didn’t work. Perhaps I should have used ADSI Edit :)

  67. Alan Gordon says:

    Not having any meaningful guidance from RIM or from Microsoft, I used the only documented procedure I could find. Where did you find your procedure? Is it documented in a KB article?

    Thanks

  68. evilghost says:

    f1tech, thank you for posting the dsacls command.  Prior to this we could not get BES to send on behalf of the Domain Admin enabled accouts even though we explicitly enabled the send-as rights on the adminSDholder container per the shovelware knowledge base article (can you say ‘Prep for MS Activesync 2007?’).  Let me say that my chest hurts from the classic strong-arm tactics by Microsoft and the massive arch changes under the guise of security changes.  Keep up the good work admin-base and please Microsoft continue to dictate end-luser policy as you see fit; perhaps this is the new "Trustworthy Computing" model we heard about so long ago.  Meanwhile, I eagerly await the next unholy incarnation of "Typical Tuesday".

  69. flylta says:

    f1tech, THANK YOU.  I have been looking at this thinking I should be able to do this but have not been able to find anywhere that said I can just set the SEND AS in dsacls.  Finally.

    Without Tuesday what would we do, work on projects that our organizations need completed to function more effeciently for our customers???  Worrying about our customers experience? That doesn’t fit the business model from the NW…

  70. Anonymous says:

    As everyone in the US IT industry is now aware, there will shortly be a change to Daylight Saving Time…

Comments are closed.

Skip to main content