Adventures of Exchange 2010 and AdminSDHolder
Posted by BPuhl on August 29, 2009
For those of you who haven’t heard by now, there have been many threads over the past few days around the setup of Exchange 2010, and how one of the things which it does is to modify AdminSDHolder ACL’s, and the associated security implications.
Far as I can tell, this was kicked off by this blog post, which gives a good description of what’s going on and what the fuss is about: http://dloder.blogspot.com/2009/08/exchange-2010-rc1-and-adminsdholder.html
It didn’t take long for threads to spawn on the public forums, such as http://www.activedir.org/ListArchives/tabid/55/Default.aspx as well as several internal distribution lists.
While I won’t claim that inside Microsoft, the left hand and the right hand always know what each other is doing. We are very security conscious and in general the product groups do go out of their way to try to do things “right”
In the meantime, who does this affect? Well, technically Exchange 2010 is only supported for production by a small number of TAP partners. Of course, MSIT is on that list, so you might be wondering – what do we think about it?
While it’s not an official “policy”, in general, when it comes to managing Microsoft’s internal directory, we’ve got a fairly basic principle:
If you create it, it’s yours, if you don’t – leave it alone.
In this case, AdminSDHolder isn’t something that Exchange created or even ‘owns’, it’s a base AD function. Because we know that also by policy, none of the accounts which are impacted by AdminSDHolder are mailbox enabled (and thus within the scope of Exchange), we went through and removed the ACE’s from AdminSDHolder. Does this mean that Exchange RBAC won’t be able to touch those objects? Yup, but that’s by design of our security model. We require separate (in our case, smartcard required) administrator accounts for all elevated permission users, and those accounts aren’t allowed to have mailboxes.
I won’t claim to know what’s going to happen in the future with Exchange 2010, but this is how we’re approaching it internally (and why).