Delegate "Impersonate User" to Domain Admins
Idea shared by Jay Dubb - 12/23/2022 at 10:27 AM
PLEASE UP-VOTE if you agree.

We've made this request in prior versions but no joy yet.  Am adding as a feature request for the beta, since it's a major rewrite.

System admins can delegate certain privileges to Domain admins-- such as the ability to View User Passwords.  But this isn't enough.  We need to be able to delegate permission to Impersonate Users within their own domain.  It's a huge time saver when assisting users or troubleshooting.

We have customers who've migrated to us, who HAD impersonation ability at their former hosts (Rackspace offers it, for example) and are begging and pleading with us to get the feature back.

System Admins can impersonate with a mouse click, and we should have the ability to delegate that same function to Domain Admins (for their own domain).


6 Replies

Reply to Thread
Gabriele Maoret - SERSIS - Head of SysAdmins
Currently manages 3 SmarterMail installations (1 in cloud for SERSIS which provides service to a few hundreds 3rd party Mail Domains + 2 on premise to customers)
Okay, Rackspace was not the best example after their massive problems but I like the idea itself :)

It is important that it can be activated or deactivated individually per domain (customer). Because from a purely legal point of view, this is a very sensitive issue if administrators of customers can impersonate the mailboxes of employees unhindered. In any case, this form of impersonation should also be logged somewhere.
@Roger S -- Yeah, Rackspace had a miserable few weeks for sure.  I used them as the example, because the customer that has been the most vocal in pushing for it came from Rackspace, where they had impersonate-user ability, and used it almost every day.  It was a big "loss" to their IT team when they moved to us, and I can vouch for the added pain it's cost them.

And yes, definitely set per-domain, not global, just like we can delegate the show-password permissions on a per-domain basis.

A setting for a domain to turn on/off, most certainly.

However, our team typically does not let customers know that we can impersonate.  It makes them feel more secure.

E-mail contains very private conversations.  Domain admins can get into any account anyway (by changing the password).

Our opinion is that Impersonation by domain admins is creepy.  Some of us have thousands of domain admins and "snooping" isn't something that should be on the menu.

That's where that level of trust comes in for your admins.  It's a very important feature for companies with older employees who tend toward the "helpless" end of the spectrum, and just want I.T. to do everything for them. It's also important NOT to delegate that ability unless you get approval from someone in authority on the client's side-- CEO, COO, a principal in the business, etc.

Other hosting providers DO offer impersonation for admins, and it ranks among the first (and loudest) complaints from admins who once had that ability but lost it when we moved them to Smartermail.

Our customers needing Domain Admin-level impersonation found a NEW REASON:  Multi-Factor Authentication.

Currently, admins access user mailboxes by viewing the password, then logging in as the user.  HOWEVER, when a user has 2FA/MFA enabled on their mailbox, the admin cannot login unless the user provides an Authenticator PIN code at that moment.

Admins handle email support TICKETS, not phone calls, and are not able to work these ticket requests without first getting the user on the phone and coordinating the admin login with the user reading back the PIN code. 

This makes timely support very difficult-- and IMPOSSIBLE for the overnight support team to do anything needing mailbox access, until the next morning when they can make contact with the user first.  Admins NEED the impersonation option to handle support tickets, without having to chase down each and every user who has a support request pending.

Reply to Thread