Microsoft

Modify Microsoft Exchange and restore Send As rights to your Blackberry users

After patching Microsoft Exchange Server 2003 for the changes in Daylight Saving Time in 2007, many network administrators were forced to contend with a loss of functionality among their Blackberry users. Josh Hoskins explains the problem and how to fix it.

This article is also available as a TechRepublic download.

Most administrators who run large RIM Blackberry implementations are already aware of the changes the Daylight Saving Time Exchange Server patch caused to their network environments and the issues it created. Many had even avoided patching their Exchange systems so as to sidestep these issues, though the need to apply the DST patch forced their hands.

The issue is that Microsoft (per request of many users) changed the way the Send As right worked in Exchange Server. Previously, Send As permission was given as part of the Full Mailbox access suite. After the DST patch, Send As was its own separate right and not part of the Full Mailbox access grouping. While this was a well known change, and fairly simple for most environments to adapt to, there was another issue that would rear its head after applying these updates to Exchange.

The problem

Many administrators were confused by the fact that some users were no longer able to send e-mail from their Blackberry devices, sometimes even receiving an error message about not communicating with a desktop device. Some more investigative administrators may have noticed that some users lost the Send As permissions granted to them. After granting these permissions explicitly (or inherited) to these accounts, they would just disappear within an hour.

However, some admins may not have even noticed or had these symptoms reported to them, as the problem applied to only a small portion of their user base. Other admins may have noticed that the issue seemed to occur only on their account and none of their users. While this seems like something that would get immediately fixed, most admins know that a technical problem affecting only them ranks very low on their priority scale, especially when it's something that may take a significant amount of time to track down.

After some investigating, the answer was discovered. It is related to a common Send As issue, but the effect comes from a completely different source. In Windows 2000, Microsoft introduced the AdminSDHolder Object for Active Directory. The servers holding the PDC emulator and FSMO roles compare the ACL (Access Control List) of the AdminSDHolder object and of every protected object in Active Directory hourly. If it notices a discrepancy, it will change the object to match the AdminSDHolder object. This is a great security measure, as it helps secure the most sensitive accounts in Active Directory from unwanted access.

Now, you may be asking how this is related to the change in Send As permissions. It comes from the fact that, by no longer being a part of the Full Mailbox access group, the Send As permission is now granted directly to an object's (including users) ACL. Now it comes down to how do you determine which user objects are protected. For Windows 2003 and Windows 2000 with SP4, Microsoft has provided the following list. If an object (user, machine, or other group) is a member of any of these groups, it will be considered a protected object and will hourly have its ACL reset:

  • Administrators
  • Account Operators
  • Server Operators
  • Print Operators
  • Backup Operators
  • Domain Admins
  • Schema Admins
  • Enterprise Admins
  • Cert Publishers

So now the issue begins to become clearer. Any account that is a member of one of these groups (even through group nesting) is considered protected and will have its ACL reset hourly. Now that we know the issue, we will look at what we can do to fix it.

The solution

The first option, and the one recommended by Microsoft, is to simply not use any account that is a member of these groups for e-mail purposes. While this is undoubtedly best practice, it is not always possible to do in real world IT. If it's impossible to simply not use the accounts for e-mail, you could also forward all of your e-mail to another account and run your Blackberry device from that account. Unfortunately, this will introduce a good deal of complexity into your infrastructure and could potentially cause you more problems down the road. Luckily, there is one other fix that can be run.

Using the dsacls utility (available in the Resource Kit for your version of Windows Server), you can change the AdminSDHolder object. By using this utility you can allow your Blackberry service account to be added to the AdminSDHolder object. This will allow the ability to add the Blackberry service account to users in protected groups and not have it overwritten. To do this, you will need to install the dsacls utility on a server, create a batch file containing the commands below, and run the batch file on the server with the utility installed:

dsacls "cn=adminsdholder,cn=system,dc=mydomain,dc=com" /G "\SELF:CA;Send As"
dsacls "cn=adminsdholder,cn=system,dc=<mydomain>,dc=com" /G "\SELF:CA;Receive As"
dsacls "cn=adminsdholder,cn=system,dc=<mydomain>,dc=com" /G "\SELF:CA;Change Password"
dsacls "cn=adminsdholder,cn=system,dc=<mydomain>,dc=com" /G "\SELF:RPWP;Personal Information"
dsacls "cn=adminsdholder,cn=system,dc=<mydomain>,dc=com" /G "\SELF:RPWP;Phone and Mail Options"
dsacls "cn=adminsdholder,cn=system,dc=<mydomain>,dc=com" /G "\SELF:RPWP;Web Information"
dsacls "cn=adminsdholder,cn=system,dc=mydomain,dc=com" /G "\%BLACKBERRYSERVICEACCOUNT%:CA;Send As"

You will need to replace %BLACBERRYSERVICEACCOUNT% with the actual name of your Blackberry service account. After this, you will need to add the Blackberry service account with Send As permissions to the protected object(s) that were receiving these errors. Unfortunately, doing this will allow any attack that compromises the Blackberry service account to then have access (by changing the ACL) to protected accounts. While typically service accounts are configured with highly difficult passwords and login restrictions, it is still another potential security hole you should be aware of.

Although there is no good fix for this situation, having a basic understanding of all of the varied components involved can allow an administrator to make the best overall decision for the environment. Whether it be to change group assignments, create forwarded mail accounts, begin following best practices and using different accounts for administration and daily usage, change the security of the AdminSDHolder object, or even just forge administrators use of Blackberry devices. This is an issue that can take quite a bit of effort to track down, but it can take even more effort to find the best solution for your environment.

Editor's Picks

Free Newsletters, In your Inbox