Exchange Cross Forest Work

Perhaps you are caught up in the work of migrating users from one domain to another (then again perhaps you actually have really fun things to do besides dealing with the politics of moving people across domains).  One interesting thing that makes sense when you look at it but at first glance is a bit confusing is establishing Exchange permissions.

There are really two types of Exchange permissions when dealing with mailboxes.  There is full access and send as/on behalf of.  I say there are two permissions because send as and on behalf of, while assigned differently are generally assigned the same way.

So on to the story!  While moving people's mailboxes from domain A to domain B we discovered that going into Exchange and saying "Hey, grant this dude full access" via the MMC just was not getting us where we wanted to be (in other words, they got no access at all).  It was not till we sat down and really thought about the "Full Access" requirements.

So you have "Joe User" logging into his PC in domain A with the account DomainA\joe.user and the mailbox that Joe users is on domain B.  For that to work, there is a disabled account setup in Domain B that the linked mailbox is tied too.  That disabled account in turn is tied to Joe.User in Domain A (with me so far)?

So Joe logs in with his Domain A account and accesses his mail in Domain B.  Then comes along Sally User and Joe wants her to have full access to his mailbox.  So there we were thinking "Dude, this is easy, right click, Full Access, Sally, click a few times, get some Cheetos.

Sally fires up her Outlook, opens up Joe's mailbox and BAM, no access!

So what happened?  Well, Sally is just like Joe and she is logging into Domain A as DomainA\Sally.User and then accessing her mailbox (which has that same linked mailbox type with a disabled user in Domain B).  Then she clicks on Joe's mailbox and it tosses the error.  Well... Sally is trying to open Joe's mailbox as DomainA\Sally.User, not DomainB\Sally.User (the linked mailbox account) and we did not grant rights to that Sally!  We granted them to the linked mailbox and the account in Domain B.

Darn silly of us; but why doesn't Exchange tell us?  Well... my guess is it is partly evil with a chance of this is why they have Exchange experts and tech support.

So you have to get a little brave and fire up the old PowerShell and get Sally the access she so desperately needs!  That command looks a little like this:

Add-ADPermission -Identity ”joe.user” -User ”DomainA\sally.user” -AccessRights ‘FullAccess’

The thing to note is that you only have to identify Joe's mailbox (in Domain B) but you have to qualify Sally's account in Domain A with the domain name.

Easy right?  Well, here comes another twist!  Want to grant send as rights or send on behalf of?  Well, you can do that from the MMC or via PowerShell.  The reason this works is because it is not a permission that is checked as you access the system, it is checked on the Exchange server as the email is sent.

So Exchange says "Hey, an email from Sally's account going out as Joe.  Does her mail account have that right?  Well, the mail account is the Domain B linked account.  There you can go into the MMC, right click, send as, add the user, click a few times, and you'll get some tasty success action!

You can also dig into the account and grant send on behalf of rights.

One last thing to note.  If you grant "Send on Behalf of" and "Send As" rights to the same account, it will send on behalf of, not send as.  So keep an eye on that!

All of this might not be new to those of you out there that know more than me (which covers just about everyone) but I learned something that day, and it was jolly good!