This post is focused on those of you who have decided to deploy Exchange in a resource forest. You’re in for tears. While the resource forest is technically a supported deployment method for Exchange, I’m going to point out what can go wrong in your Exchange world that will keep your admins up at night.
Let’s start with the definition of a resource forest, just in case you’re not sure. The resource forest approach means that you have one Active Directory forest where your user accounts live and another Active Directory forest where your application (Exchange, in this case) lives. You have user accounts in the resource forest that are disabled and then externally associated with the users in the user forest. This of course, requires a trust between the two forests, which you likely have anyway, right? Right.
A disabled user in the resource forest means the attribute msExchMasterAccountSID is empty. This value is required for Exchange to identify and resolve the user account when permissions are calculated against a mailbox or folder in a mailbox; for instance, in a delegation scenario. If your user accounts and Exchange live in the same forest, then this is set to “SELF” in Active Directory Users and Computers/Exchange Advanced/Mailbox Permissions. This will write the SID of the user account into the msExchMasterAccountSID attribute and then be used to identify the user. This also means that the forest is able to “track” the operations of this account. If the account is disabled or deleted, when ACL‘s are calculated against the msExchMasterAccountSID value, everything is hunky dory and happy.
When you have a resource forest setup and you externally associate a user from the user forest to a disabled user in the resource forest, what you’re really doing is writing the SID from the user object in the user forest to the msExchMasterAccountSID. Now, that’s the SID that will be stamped on a folder or object that gets ACL’d with your permissions… keep in mind, this is the SID from the user forest.
Now when Exchange needs to calculate the permissions, it will run across that SID and go talk to a domain controller to resolve it. The DC will refer to the trusted user forest DC for resolution, but it proxies this communication over to the trusted DC, then returns with the answer. This traffic pattern can be headache-inducing all to itself, but that’s a topic for another day.
So now here’s the problem. Because these SIDs are external to the forest, it has no way of realizing if the SID is valid or not. In other words, if you whack a user account in the user forest, the resource forest has no way of being notified of that SID’s destruction. You now have what I call “SID ghosting.” I’m sure there’s a term for it, but that’s the term I use around here.
Let’s look at an example.
Mary D. is a manager. She has an administrative assistant, Ken G. She assigns delegate permissions to Ken G. so he can manage the calendar. What she has really done is stamp Ken G.’s SID from the user forest on her calendar as a permission object. If you were to look at her calendar with pfdavadmin and check the permissions, you would see Ken’s access expressed as USERFOREST\KenG, not RESOURCEFOREST\KenG. This is because the SID value from Ken’s account in the user forest is stamped in his msExchMasterAccountSID attribute in the resource forest.
Now let’s pretend Ken G. was looking at pr0n one day and got busted. He’s terminated at the user forest and his account is deleted. Now the resource forest still has his account and the ACL still exists on the calendar. To preserve Ken G.’s data, his account in the resource forest is not deleted, but let’s say they shut down mail delivery by setting his mailbox quota to 0 or something.
What you have now is thus: every time Mary gets a meeting invitation, she will get an automatic bounce from Ken G.’s mailbox.
From a usability perspective, this sounds crazy. If it’s happening to a top end manager (which, let’s face it, is where this will usually happen), they’re likely to go berserk and demand that you fix it right away. When you research it, you find out that Ken G.’s SID is still stamped on Mary’s calendar. This is because the resource forest has no way of knowing that the user object in the user forest was whacked and the mail delivery is now failing due to the disabled mailbox in the resource forest.
Let’s make it worse. What is Ken G. had an assistant? What if that assistant had another assistant? What if your users created a delegation chain about twenty people deep? Well, then what might happen is Mary would get a meeting invitation and then she’d get a bounce from someone way down in the chain, perhaps someone she doesn’t even know! That one is really hair raising.
How do you debug this? Well, so far that we’ve determined, the best you can do is open up pfdavadmin and figure out who delegated rights to whom and follow the breadcrumb trail. If your users overuse delegation, this can be a painful exercise. They should not be adding more than 4 delegates to their mailbox under any circumstances, but that’s a talk for another day. Anything more than 4 delegates and they probably only need sharing permissions anyway, so consider using that instead.
If you’re really paying attention, apply all of this knowledge to Sharepoint. Try setting permissions to your trusted user objects in the user forest.
Now think of all this (Sharepoint included) and think of the day that management decides that this just isn’t working – you need to get all applications and user objects into the same forest. Did your brain just explode? If not, you’re not paying attention. Key words are SID and msExchMasterAccountSID and Sharepoint permissions.
Run. Run screaming from the resource forest. Friends don’t let friends set this up.
Really.