Monday, September 4, 2017

Exchange 2010 / Online - cross organization permissions and access - PART 4

In my previous blog posts, we examined two types of situations: granting a migrated user access to mailboxes that remain onsite and granting an on-premises user access to mailboxes migrated to Office 365 (O365). In this blog post, I want to define permissions before the migration of a user mailbox and observe to what extent the permissions continue to function.


***


We will migrate the mailbox of user Alex Heyne to Office 365.

Permissions are configured as follows...

Alan Reid (on-premises user) has Full Access and Send As permissions to Alex Heyne's mailbox:





Alex Heyne has Full Access and Send As permissions to Alannah Shaw's mailbox (which will remain onsite):





Alex Heyne also has Full Access and Send As permissions to the on-premises Finance shared mailbox:





Lastly, Alex Heyne, through membership in the CALPER_FinCal security group has Publishing Editor rights to the "FinCal" (Finance Calendar). This is distinct from the Finance shared mailbox and serves the purpose of testing permissions if they were granted in this manner.



Before the move, I ensure that the "mynet.lan" domain name is not present as part of an email address. Since this is not an accepted domain in O365, its presence would cause the migration to fail, as we have observed in previous migrations.





Out of curiosity, I note the size of the mailbox to be migrated. Since these are test mailboxes containing only some test messages, it is not surprising that the mailbox is only 176 KB in size:



Besides observing permissions and access in a hybrid environment, I also have secondary objectives in executing these migration operations and in particular, taking note of the time necessary to migrate the mailbox. I would predict that a 176 KB mailbox would take very little time to migrate. We'll see if that is the case.


I'm also interested in the protocols used to access the mailbox. Before migration, Outlook 2010 (SP2 - with patches) uses encrypted RPC to access the mailbox hosted on an Exchange 2010 SP3 (RU18) server:




Note: observe the use of the CAS array, the protocol (RPC/TCP), and the RPCPort.

After the migration, we'll see if the same protocol or different protocols are used.



***


Now we will migrate Alex Heyne's mailbox to O365. I will leave his Outlook client open so I can see the effects of a live migration on the end user experience.

I will refer the reader to this blog post for the step-by-step directions ...

Exchange 2010 / Online - mailbox migration steps

And limit my commentary to some observations in the lines below.

First, I initiate the migration in the recipients | migration section of the Exchange admin center (EAC).

There was a transient error that did not prevent the migration from finishing:








If I look at the details of the migration (not shown in the screenshot), it looks like the process took at least 20 minutes, which leads me to conclude that there is a minimum amount of time required to set up the new mailbox in O365 / Exchange Online. The amount of data migrated is listed as 508 KB compared to the 176 KB mailbox size shown in an earlier screenshot.

It is very important to assign a license to the mailbox manually if you do not have an automatic process for this (unlicensed mailboxes are purged after 30 days). We do this in the Office 365 Admin center:






Now we have two licensed users (Aisha Bhari and Alex Heyne). Our other users are listed as unlicensed but that is not a concern since their mailboxes have not been migrated to O365 and therefore do not risk deletion:






And now, let's return to Alex Heyne's Outlook client...

Since we have no Single Sign-On (SSO), Outlook attempts to reconnect and prompts us for credentials:




No sooner do I provide the credentials than a message appears, stating that Outlook requires a restart:


Note: observe the state of the connection ("Send/Receive error" and "Disconnected").


Once I restart Outlook (connected as Alex Heyne"), I observe the connection status and notice that two different protocols are being used concurrently. The three connections with Office 365 use HTTP instead of RPC. However, we also have an RPC connection because Alex Heyne still connects to mailboxes onsite where RPC is still used:






***


Now we will observe if the mailbox permissions configured for our various mailboxes still function as desired (I will only provide screenshots if the operation fails).

Note: they were all verified as functional when all the "actors" were still on-premises.


  • Can Alan Reid access the mailbox of Alex Heyne? - Yes


(But if originally auto-mapped it must be re-added manually)




Alex Heyne's  mailbox was auto-mapped to Alan Reid's Outlook profile and disappeared after I enter the credentials. It was visible when I first opened Outlook (as Alan Reid) but when I attempted to expand the folders the error message above displayed. However, if I (re)add the mailbox to Alan Reid's Outlook profile manually, I can access and expand the folders. Of course, lacking SSO, I must enter my credentials multiple times.


  • Can Alan Reid send as Alex Heyne? - Yes (message received by Alannah Shaw)


  • Can Alex Heyne access the mailbox of Alannah Shaw? - Yes (but after an initial failure)



After a second try, it succeeds (note the message Alan Reid sent as Alex Heyne):




  • Can Alex Heyne send as Alannah Shaw? - Yes


  • Can Alex Heyne access the Finance shared mailbox? - Yes (but after an initial failure - see example of Alannah Shaw above)


  • Can Alex Heyne send as the Finance shared mailbox? - No (this fails consistently)





Is this because the right is granted through group membership that O365 cannot validate? We should keep in mind that Alex Heyne was granted Send As rights to Alannah Shaw's mailbox directly (and not through membership in a security group).

I'll attempt some troubleshooting in just a moment but I'll answer one more question first:

  • Can Alex Heyne access and edit the FinCal shared calendar? - Yes (no problems here)


***

It seems that we can "send as" another user if we are granted Send As rights directly to their mailbox but not necessarily if these rights are granted via group membership. Let's attempt some troubleshooting...

Is the group granting permissions (GMPER_Finance) synced to O365?

No (because of filtering by OU)

What if I sync it?

No change (Alex still cannot "send as" Finance)



What about Aisha Bhari who is also member of the GMPER_Finance security group?

She cannot send as the Finance shared mailbox either.



What if we mail-enable the GMPER_Finance security group?

I make the change and to ensure it takes effect immediately (on the server running Azure AD Connect)...

Start-ADSyncSyncCycle -PolicyType Initial

No change (even after successful sync).


I grant Alex Heyne "Send As" rights directly and attempt to send another message. This results in another failure. However, permission changes do not always take effect immediately so I will try again later. 

***

Directly granted permissions function just fine for user mailboxes (see the example of Alannah Shaw above). It is not clear if there is a particularity with shared mailboxes that would change expected behavior. Otherwise, I do remark that "Send As" permissions were also the type of permissions that encountered the most obstacles in the testing conducted by Henrik Walter in this blog post:

Exchange Hybrid Cross-Premises Mailbox Permissions Demystified (Part 4)


No comments:

Post a Comment