03-14-2013 05:30 PM
Check out the latest articles from the EV Content Coucil and get information on the various accounts and users that are involved in an Enterprise Vault environment, as well as the permissions required by each.
Enterprise Vault Accounts and Permissions
http://www.symantec.com/docs/TECH76700
Compliance Accelerator and Discovery Accelerator Accounts and Permissions
http://www.symantec.com/docs/TECH200788
03-15-2013 12:44 AM
Thanks for sharing these articles, good info.
03-19-2013 11:22 PM
Thanks Eileen for sharing the article here.
Cheers !
03-20-2013 12:46 AM
Good articles, however, there are a few bits that I don't necessarily agree with ...
VSA *must not be* a member of the Enterprise Admins or Domain Admins
My question on that would be why? Is it because of the restrictions in Exchange whereby (by default) Domain Admins don't have permissions to access everyone's mailbox?
Well, that's the main one I think :)
03-20-2013 04:31 AM
Rob I guess that is for security reason.
03-20-2013 04:39 AM
Could be, I guess. But it's not clear in the article -- and I question almost everything :)
03-20-2013 04:47 PM
Correct Rob, good thinking.
The idea is to give least privilege as possible.
03-21-2013 01:10 PM
Rob is technically correct, and I have modified the article to reflect this. Though we do not strictly forbid it, Symantec strongly recommends against making the VSA a member of Domain Admins, etc. The reason is that these groups have a default DENY permission on all mailboxes in the environment, which is ordained by the design of Microsoft Exchange. This will override any access the VSA is granted via other means; any customer who wants to place the VSA in one of these groups will need to modify the default permissions of the standard Microsoft-supplied AD group to remove the DENY. In addition to being more work for the EV admin, this also obviously has security implications for the other users in the group, which will find themselves no longer denied mailbox access. It also violates the principle of least privilege, as the VSA has access to all sorts of domain resources it doesn't need to do its job. Naturally we would like to avoid all this.
Ordinarily there is not really any benefit to having the VSA in one of these groups to begin with, so we find that the balance comes out easily in favor of not putting the VSA in these groups. I don't doubt that in some far-flung corner of the EV empire there exists a use case where the VSA's membership in Domain Admins is worthwhile, but it is pretty rare. Thus the strong recommendation.