Hi, all. I'm a little perplexed as I start to work with Exchange Server 2010 as to what the thinking was behind excluding accounts that have elevated AD rights from being able to perform administrative tasks? By elevated groups, I'm referring to groups such as Domain Admins, and by administrative tasks, I'm referring to the simple creation of mailboxes. Where this is causing us some issues (assuming we leave the deny rights in place, which is unlikely) is that we already work with a two account model. The first account is our normal day-to-day account that has no AD rights, and nor elevated rights to any other system, be that Exchange, SQL Server, server logons in general, etc. It is no more proviliged than any other user account. The second is our administrative account. This is the account that can do what needs to be done per assigned role (ie some people administer more than others). With that in mind, what we're facing is that the people who need to manage both Active Directory and Exchange can't do so out-of-the-box with the one account. So, in essence, if we were to leave the Deny permissions in place, we'd have to provision a third account. That then turns the internal philosophical discussion on its head in that instead of having the two account model, do we move to a n+1 model, where n = the number of back-end products we run? Of course, the answer to this in my opinion is no, but if we were to get more products designed like this, the justification for this kind of paradigm shift would become more profound. So, again, I go back to my first question: what was the actual thinking behind the decision? I'd like to know if I'm missing something that I should be factoring into our own rationale for why we do things the way we do. Cheers,Lain

I can't speak for them, but I can understand why it is that way. In a large enterprise, the domain administration and email administartation tasks will be separate responsibilites. That leaves you with a choice. You can either start with a default model that, in a small orgainzation requires you to have to remove a few dozen Deny permission to enable a single point of administartion for everything, or you can have one that if implemented in a large enterprise would require you to add hundreds or thousands of them in order to separate them.

Sure, I get that. Siemens is a good case in point. So if I just accept your statement, then what I'm left with is trying to reconcile that numerous times I have seen advice from both Microsoft representatives and MVPs in this very forum (being Exchange, not necessarily this Admin forum) that removing these permissions is not a good idea with why. Clearly not every company or institution is in the same position as a Siemens or Chevron, or even a government department (where typically they have technical silos even if their structure is very small). For these people, is there some guidance that says, "sure, it's okay to remove these permissions?" Cheers,Lain

I am neither MVP, nor MSFT. I have made permission changes that were officially considered "bad practice", but I would be very reluctant to advise someone else on a forum like this that it was OK for them to do it too.

As I know, the thought could be: “Split permissions typically make a distinction between the creation of security principals in Active Directory … This helps to reduce the chance of unauthorized access to the network by controlling who can create objects that grant access to it. Most often only Active Directory administrators can create security principals while other administrators, such as Exchange administrators, can manage specific attributes on existing Active Directory objects” Agree with you, not every company is same as the Siemens. The default shared permission model could be the one for them. “This model doesn't separate the management of Exchange and Active Directory objects from within the Exchange management tools. It allows administrators using the Exchange management tools to create security principals in Active Directory” Understanding Split PermissionsJames Luo TechNet Subscriber Support (http://technet.microsoft.com/en-us/subscriptions/ms788697.aspx) If you have any feedback on our support, please contact tngfb@microsoft.com

Thanks for the insight and the link, James. Cheers,Lain

Glad to help : )James Luo TechNet Subscriber Support (http://technet.microsoft.com/en-us/subscriptions/ms788697.aspx) If you have any feedback on our support, please contact tngfb@microsoft.com