Impersonation

The impersonation allows a Z-Push user to open a store of another user on a mobile device or in Outlook with KOE if he has permissions for that store. This feature is available since Z-Push version 2.4.0.

It is similar to opening shared folders in webapp but without the possibility to select which folders to open. Z-Push will always open all folders for which the permissions were granted.

How-to

It is necessary to grant the permissions before setting up an impersonated account. In the below example user1 will create an account to access user2's store. user2 granted owner permissions to user1 on his entire store (for the more detailed explanation about permissions see the FAQ section).

On his mobile device user1 creates a new ActiveSync account. It's not possible to set this using autodiscover, so user1 will have to configure the account manually. The only difference from a regular user account is the user name field. There user1 enters:

user1#user2

(it's always the user who will open the shared account, followed by the hash sign, followed by the shared account).

The same is valid for Outlook when setting up a new ActiveSync account.

That's it. Now the user1 has the access to user2's store using only permission schema of Kopano. He is able to open, add, remove, and modify the items in user2's store (depending on permissions).

To confirm that the impersonation worked, there's a DEBUG level log entry in z-push.log:

11/04/2018 21:57:48 [ 7069] [DEBUG] [user1#user2] KopanoBackend->Logon(): User 'user1' is authenticated impersonating 'user2'

The short ids of folders in an impersonated store have an "I" prefix, e.g. Icfd22.

FAQ

1. The usernames are [email protected] and [email protected]. Does it work in this case?
   • Yes. The username in this case is [email protected]#[email protected]
2. Has the user2 to grant full permissions for user1 for impersonation to work?
   • No. It's sufficient to grant read-only permissions. user1 then will only be able to open objects in user2's store. If user1 adds, modifies, or removes an object in user2's store, the ReplyBackImExporter kicks in. The changes won't even be applied on the server and synced back to user1's device on the next Sync request.
3. Has the user2 to grant permissions of the entire store for impersonation to work?
   • Not necessarily. Just be aware that user2 has to grant at least "Folder visible" permission for his store (the top one containing inbox, calendar, contacts, sent items and so on). The user1 should then select only the granted folders to sync on his mobile device (e.g. calendar). Be aware that after creating an account on mobile it jumps to the inbox, and if the inbox permissions weren't granted, it will look like the sync doesn't work, but the available folders will be synchronised.
4. Does this work with public folders?
   • Somewhat. It's possible to use SYSTEM as shared account to open the public folder (user1#SYSTEM). Mobiles will create Inbox, Calendar, Contacts etc. folders that are not available in the public folder and these will always fail to synchronize. This results in a rather confusing view. In this case the Z-Push shared folders functionality should be used..
5. What about private items?
   • If user2 has private items, the user1 will only see "Private" and no further information (except start and end time for appointments). Editing such item will result in ReplyBackImExporter not saving changes on the server and restoring the original item on the next sync.
6. What about send-as?
   • When sending from an impersonated account, send-as is done automatically. Make sure that the email address of the impersonated account on the mobile is of the impersonated store. It's of course also required that user1 has send-as permissions for user2.