Impersonate User

There are times when a system administrator will need to access domain or user specific information — a mailbox rule that isn't firing, a content filter that seems misconfigured, a signature that isn't applying correctly, and so on. Rather than asking the end user for their password (which you shouldn't do) or resetting it (which locks the user out of their own credentials until they're told the new one), SmarterMail lets a system administrator impersonate the account instead. Impersonating opens a new, separate browser session that is logged in as that domain or user — with no password required and no change made to the account's actual password — so you can view and edit settings exactly as the account owner would see them.

Technically, impersonation is not a "read-only" preview. When you impersonate a user, SmarterMail issues that session its own access and refresh tokens for the target account, in essentially the same way as if the user had logged in themselves. This means that, while impersonating, you have full access to that account — including its email content, content filters, and other personal settings — and you can change anything the user could change, including their password. Keep this in mind before impersonating an account for troubleshooting: any change you make while impersonating takes effect for that user immediately, just as if they'd made it themselves.

Note: When a system administrator is impersonating a user, the interface will be displayed using the language that is set for system administrator, NOT in the language of the account/User they are impersonating.

Security and the Audit Trail

Because impersonation grants full access to a user's account without their password, every impersonation request is written to the Administrative Log. The log entry records which system administrator initiated the impersonation and which account they impersonated, so there's always a record tying account changes made during an impersonated session back to the administrator who made them. If your organization has compliance or security requirements around who can access user mailboxes and why, review the Administrative Log periodically (or after a support ticket involving impersonation) to confirm impersonation was used appropriately.

To impersonate a user, do the following:

Use Impersonate User on the navigation pane. A modal window opens.
From the modal, select the Domain from the dropdown, then start typing the User's name. If you're already on the Configuration tab for a domain, that domain's name will automatically populate the Domain dropdown in the modal. (However, you can change this if needed.) When you start typing the User's name, SmarterMail should offer some autocomplete options. You can select one of those options or finish typing out the User's name.
Once you've selected the Domain and User, click the Impersonate button. A new window will open and you'll be logged in as that user. By default, you'll be placed in that User's Settings.
You can tell you're impersonating a user because an orange "Impersonating" flag is displayed in the upper, right corner of the SmarterMail interface.
To exit impersonation, you can either log out of the impersonated user or simply close the browser window.

Once impersonating, you are able to edit user/domain settings, content filters, or other settings that need to be changed or reviewed.

Alternatively, you can impersonate a user by going to a Domain's Accounts tab, right-clicking on a user and selecting Impersonate User from the context menu. (Or by selecting "Impersonate User" from the Actions (⋮) dropdown.)

Example: Troubleshooting a Missing Content Filter Rule

A user contacts support saying messages from a specific sender keep landing in their inbox even though they created a content filter rule to move them to a folder automatically. Rather than walking the user through re-explaining every click over the phone, you can impersonate the account, navigate to Settings > Content Filtering, and see the rule exactly as the user configured it. From there you might discover the rule's conditions don't quite match the sender's actual address, that the rule is disabled, or that an earlier rule in the list is already matching the message and stopping rule processing before it reaches the rule in question. Because you're working inside the user's own account, you can correct the rule immediately instead of describing the fix and hoping it's applied correctly.

Changing Impersonated Users

It's also possible to change the User you're impersonating, or even change the domain and user, from the Impersonating window. Simply click the orange Impersonating flag in the upper right corner of the interface and a new Impersonate User modal window opens. Here, you can change the domain or user you want to impersonate and, by clicking the Impersonate button, change to that user or to a new domain and user.

Note: Because the impersonated session runs in its own browser window with its own access token, exiting impersonation — whether by logging out of the impersonated account or simply closing that window — only ends that session. Your original system administrator session, in the window or tab you started from, remains logged in and is not affected.

Impersonation Permissions

Only the primary system administrator has impersonation privileges by default. If you are logged in as a secondary system administrator and do not see the Impersonate User menu item in the Navigation pane, then impersonation privileges have not been enabled for your account. Ask your primary system administrator to enable the Allow impersonation option for your account under Settings > Administrators. A secondary administrator can only grant the Allow impersonation permission to another secondary administrator if their own account already has that permission enabled.

Note: In a SmarterMail High Availability (HA) environment, the Hub automatically determines which Node hosts the target account and routes the impersonation request to that Node for you — you don't need to know or select the Node yourself, and no additional configuration is required to impersonate accounts across Nodes. The same Allow impersonation permission is enforced on these cluster-routed requests as well.