[rasobey]

Hi all

Some time ago when I first moved to the world of Exchange and Blackberry administration, someone told me that the Send As permission should be automatically applied to a BES user's mailbox when you add said user to BES. This doesn't work, and I have to manually add Send As these days.

Does anyone know if)

a) this functionality ever existed,
b) if so, what broke it?
c) how I can get the functionality back?

Cheers

Richard

[hdawg]

Back in the day (early 2006 and previous), when you set the permissions in ESM, it propagated and stuck with the user.

Microsoft has since released patches modifying how Exchange (store.exe) processes these permissions (Specifically Send As). So now, you need to set the Send As on the user account directly or you can set it on an OU / Domain and have the permissions propagate through AD.

How to Grant Send As Permissions for a Mailbox and BlackBerry - Send As Issue

I'd recommend setting the permission at the root of the domain or at the root of your Users container and letting the permission propagate to all user objects ... then when you add new users you don't need to stamp them manually.

[Lowtrac]

Originally Posted by hdawg

I'd recommend setting the permission at the root of the domain or at the root of your Users container and letting the permission propagate to all user objects ... then when you add new users you don't need to stamp them manually.

I agree. One thing to look our for is that members of protected groups (Domain Administrators, Administrators, etc.) will not inherit this permission.

[rasobey]

Thanks folks. I'm not keen on giving my BES admin account Send As over everyone, so I'll continue doing it manually.

[hdawg]

Why are you not keen on providing an account permissions that you've obviously secured and audit account activity against?

IMO, you're creating yourself an administrative nightmare; but you're not alone ... too many people choose this route and waste their time foolishly.

[blincoln]

Originally Posted by Lowtrac

I agree. One thing to look our for is that members of protected groups (Domain Administrators, Administrators, etc.) will not inherit this permission.

You can, of course, make those groups inherit the permission by modifying the AdminSDHolder object in AD.

I tend to agree with rasobey though, at least for organizations with a small percentage of BlackBerry users. Where I work, we have somewhere between 15,000 and 20,000 users with email, but only about 300 with BlackBerries.

If someone wanted a fancy alternative, it would be fairly easy to script out a query of the database to determine BlackBerry users, then applying the Send As permission to their accounts. It could be set up as a scheduled task to run once a day.

[hdawg]

Why would you go through all this rather than simply secure the account? You let your BackupAgent account access all sorts of information don't you? I guess I just don't understand WHY you'd manually stamp ... or why you'd modify AdminSDHolder; god that'd be even more potential trouble.

[blincoln]

For multiple layers of security. If the BESAdmin account is compromised, it being able to send as ~300 people is a lot less than being able to send as 15,000. I dislike the need to give it that permission at all - I'm a little unsure why RIM didn't use some sort of credential pass-through design where the access to each user's mailbox was done as the actual user instead of a shared service account. Yes, it would have meant being unable to reuse the same MAPI connection for multiple mailboxes, but that's a tiny bit of overhead IMO.
The AdminSDHolder thing I would have preferred not to do, but it was the only option I could find because back when Windows 2000 was rolled out here, there was a decision made to delegate permission to the desktop service techs by making them members of the Server Operators group. A lot of those techs have BlackBerries now. I tried to get them to agree to having a separate account that was used for their administrative work, but was overruled.
Also, the exposure was not that great because aside from those users, the accounts that are members of those special groups don't generally have mailboxes (our Domain Admin accounts are separate from the ones we use to log onto our workstations, for example).

[BBAdmin]

I agree with hdawg on this one. I can see why people might be concerned about it, but granting the permission on a per user basis is a nightmare and the risks are microscopic if at all. Save yourself the headache and set it at Domain level.

Still what do I know, I only support about 80 BES servers across the world which includes financial institutions, embassies and Governments!!!!

[hdawg]

I feel like I'm playing devils advocate here ... but I really can't be as I see and manage environments that do it both ways.

What did you do before Microsoft released the updates to store.exe to how it processes the 'Send As' permissions? Surely you weren't stamping attributes manually ... because you didn't have to.

Were you one of the companies that convinced Microsoft to make this change? Heck, maybe, and if this was such a big security concern for you, then this absolutely applies to you, and my view on this is 100% off.

BES's MAPI is tiny only when your user base is tiny ...

In a totally oversimplified look at MAPI:

1000 normal users (using cached Exchange) + 250 BES users = 2000 + effective users (at best)

Remember, all BES MAPI connections are persistent, and you always plan for peak capacity.

When you start seeing disk queue lengths on subsystems with 20 spindles exceed 500 and RPC latency off the wall and "Connection lost to Exchange Server" popups in the task tray you truly realize how much overhead BES adds to a messaging environment that wasn't planned with BES in mind. That said, I love BES.

With regards to AdminSDHolder ... heck, as long as you know what you're doing you're all good ... its just when changes get made because laziness wins and administrative best practices aren't followed ... that I shiver.

Yup, I've rambled a bit ... I just want to drive home the idea that your time might be better spent worrying less on security with this given account and more on performance, or something else ... like will Spider Pig save the world.

Spider Pig, Spider Pig, does whatever Spider Pig does ...

[rasobey]

Touchy topic! Well for one, I don't believe in giving any account a permission when there is simply no need for it. It adds to overhead, even if it's not noticeable ("Every little helps" to coin a phrase).

Secondly, I only have around 150 users on BES, and I have a four step process of adding someone's account to the BES server, so one extra step of adding the Send As permission is not a big deal for me.

I appreciate what you're saying, I really do. Quite a few of our service accounts are given full access to mailboxes etc, but again, I'm not one to give permissions across everything when only a minority will benefit.