In October of 2008, I wrote the article adminCount, adminSDHolder, SDProp and you! This article discussed why membership in privileged groups could cause permissions challenges. You may want to refer to it before proceeding.
With Exchange Server 2010, the overall situation has continued to get more restrictive. Exchange Server 2010 needs for users who have mailboxes to inherit permissions in order for Role-Based Access Control (RBAC) and overall Exchange access to work properly. Membership in a privileged group will stop a mailbox from inheriting permissions. Usually, normal mailbox access will work fine (i.e., using Outlook with MAPI) due to historical permissions present on a mailbox, but any other IIS based or MAPI service will fail. This includes, but is not limited to, Blackberry Enterprise Server, Exchange ActiveSync, Outlook Web App, etc.
You can see a complex way of working around this issue described in KB Article 907434: The “Send As” right is removed from a user object after you configure the “Send As” right in the Active Directory Users and Computers snap-in in Exchange Server.But that method is an administrative nightmare.
Realistically speaking – what can you do?
The answer is simple: Get your users out of privileged groups.
No user who is Administrator, a Domain Admin, an Enterprise Admin, or a Schema Admin should be signing into Exchange with an account that is a member of those groups. This is also true for any member of the Built-in\Administrators group that exists on Domain Controllers. Every user who has access to a high-privilege account should also have a normal user account that they use for day-to-day usage – just like everyone else.
For the other privileged groups (Account Operators, Server Operators, Print Operators, Backup Operators, Cert Publishers) – these are legacy groups. They are a carry-over from Windows NT. Don’t use them. Instead, use a computer’s Local Security Policy – or a Domain Security Policy when appropriate – to assign users who need those capabilities the specific rights they require.
Usually, you will find that the built-in groups provide more power than you think they do (e.g., a member of Account Operators, Server Operators, Print Operators, or Backup Operators can log in locally to a domain controller and shut it down). Mapping between the groups is fairly simple by examing User Rights Assignments in any Local Security Policy. An online version of this is available at: http://technet.microsoft.com/en-us/library/bb726980.aspx in tables 7-7, 7-8, and 7-9.
You may not normally consider <insert-any-group-name-here> to be a privileged group. But Active Directory does. Get users out of privileged groups where possible, and where not possible – assign (and require use of!) users a normal account and a privileged account.
Until next time…
As always, if there are items you would like me to talk about, please drop me a line and let me know!
Follow me on twitter! : @EssentialExch