Administrators may choose to delete user accounts from either their Mimecast account or from their internal LDAP environment. Typical reasons for this would be for account management, or to ensure that inbound emails to a particular user are no longer accepted by Mimecast.
User accounts cannot be deleted until all accepted email (such as emails in the Delivery or Held queues) for that user are processed by Mimecast.
Mimecast provides different options to validate the recipient of an inbound email. Depending on the Recipient Validation method configured for the Internal Domain, and the status of the user account, will determine if the email will be accepted or not.
Email Address accounts have an icon which displays the status of this account, i.e. whether the account is added to the Internal Domain based on a Directory Sync, or because of being a Known Recipient (i.e. Mimecast has processed an email for this address, and then added the user account to the Internal domain ).
For example, if the Recipient Validation method is set to LDAP users only, and the user account status is Known Recipient, an inbound email to this address would be rejected as an Invalid Recipient. If Validation is set to Known Recipients, emails will be accepted for any LDAP or manual email addresses within the Internal Domain.
Validation methods can be configured differently for each internal Domain within a Mimecast Account. The validation method can only be configured by Mimecast Support
Deleting Users from Mimecast
Mimecast recommends that you do not delete email address accounts from your Mimecast Account. If an address is purged from the User Directory, any active items relating to that user (such as Accepted Email) will not be added to the Archive and therefore will not be available. All existing emails in the Archive will however still be available when an Administrator performs an Archive Search.
It is not possible to delete Directory synced email address accounts from your Mimecast Account, as these will simply be re-added during the next Directory Sync. The user accounts must first be removed from the Directory, and then removed from Mimecast, as described in the next section of this article.
A Retention Adjustment can also be used to permanently remove emails for a specific user from the Archive if required.
To delete a email address from Mimecast, you will need to be logged onto the Administration Console with sufficient permissions:
- Navigate to Directories | Internal
- Search for the relevant email address
- To delete a single address, right-click on the address, and select Purge Address
- To delete multiple addresses, check the selection box on the left of each email address, and select the Purge Selected Addresses button to mark for deletion
- A warning notification is displayed and includes a list of all the log entries that will also be purged:
- Click on Confirm Data Removal to proceed with the purge request
Once an email address account has been marked for deletion, it will be added to the purge cycle for that evening.
To prevent the purge from taking place, the address can removed from within the Internal Domains | View Purge list menu.
Once purged, although the email address account is no longer listed in the Internal Domain, Archive searches can still be performed.
Deleting Users from Active Directory
When accounts are deleted from Active Directory, the account is not actually deleted from your Mimecast account, but instead the status is changed from Extracted from Directory to Message in Transit after the next Directory Sync. This means that if your Recipient Validation is set to Directory Users only, external senders will no longer be able to send inbound emails to these addresses.
Only users with a Cloud password for that account will be able to access the content of the emails for that specific address. Administrators will still be able to access the email data (according to their permissions) in the Archive.
A protection mechanism is in place that only allows 10 Active Directory addresses to be updated during a sync. This is to prevent any mass changes should a customer experience a configuration issue internally.