Stop Support Staff from deleting archives?

[Anthony1st]

Hi all

I'm designing the administrative model for Enterprise Vault within my environment and have a requirement that appears to not be addressed within the product.

My understanding of the product is that it is a really big pain to get an archive back if someone deletes it from within the administrative console. Pretty much a full server and database recovery in an offline environment.

So... I want to give the helpdesk staff the ability to go into archives and change the permissions on the archive and be able to look inside the archives to see if an E-mail is in there and the like, as well as being able to see what archives exist and the properties of them.

However, I don't want the helpdesk staff to be able to right-click, "Delete" an item because my understanding of it is that one "Oh, Whoops" moment might require a couple of days in the test lab to bring back a given archive.

I've looked around in authorization manager and played around with various settings, but it doesn't look like you can give this level of granularity of administration. People can either see the archives and do things with them, including deleting, or nothing at all.

Has anyone had this requirement and figured out a way of giving some, but not all access to archives?

Is there any other way of people being able to give permissions to archives or look around inside them other than via the admin console?

Thanks,

Anthony.

[TonySterling]

Here is a technote on how to create a read only role.

Article URL http://www.symantec.com/docs/TECH76981

I will have a poke around the Authorization Manager to see what I can see about modifying permissions.

[Anthony1st]

Hey Tony,

Thanks for the technote. A read-only role with enable/disable mailboxes could be useful for my organisation.

Also, I've found with these permissions, sometimes the GUI makes it look like you can do something but when you actually go to perform the action, that's when you find out that you can't actually do it. During my experimentation I was seeing whether or not the delete option was available when right-clicking on an archive rather than actually deleting the archive.

I'll also investigate whether the permissions defined within the archive can be used to stop someone from deleting the entire archive itself. For example, putting a "Deny Write" permisison on the archive to the helpdesk group within the archive properties and then trying to delete it.

I'm not trying to stop malicious damage (although that would be nice) so much as trying to avoid "fat finger syndrome", as I believe it's called.

[Mohawk_Marvin]

What about making the retention categories prevent deletion?

[Rob_Wilcox1]

This sounds like a good requirement to capture - has it been added to the ideas section of the forums?

[MarkBarefoot]

I've put forward requests to improve RBA as I don't think its a) easy to use, b) easy to see who has what and c) easy to customize as there isn't the granularity available.

It would be VERY BENEFICIAL if people add these requirement to the Ideas page, as Rob mentioned below. The PM's hoover these up and act on them accordingly. If we get the same requests from Customers as well as ourselves it makes things easier to push.

[Anthony1st]

Hey MM,

Thanks for the thought. However, I'm not really trying to stop people from deleting data from within their archives. I've set the recovery period for 99 days and I've got journaling turned on, so I'm fine if people want to clean up their archive of junk data. What I'm trying to avoid is a IT helpdesk support staff member from deleting an entire archive. I know how to stop them from seeing archives altogether via the Authorization Manager, but I actually want them to be able to go in and set permissions on archives through the "Permissions" tab within the Archive's properties.

My understanding is that if you nuke an archive and want it back, then you're recovering your server from scratch in a test lab. I don't want to lose 3 days of my life because someone accidentally clicked on "Delete" rather than "Properties" (and they're next to each other).

[TonySterling]

You know that you do get a prompt confirming the delete, don't you? 

[Anthony1st]

Yeah, I know, and usually that'd be enough. But it looks like it's really, really hard to get back, and I can just imagine someone saying, "I could've sworn I clicked on "General Matters" shared rather than "General Managers" shared archive" - or whatever. It'd only have to happen once to ruin my week.

I suspect we'll have a policy of doing periodic deletion of archvies whereby all info is exported to a PST and kept on separate media prior to deletion.

[Anthony1st]

As I said previously, most of my testing was to see if the "Delete" option was available.

I actually had a go at deleting the archive with a user who was in a customised role that I created. Although you could click on "Delete" and "OK" at the prompt, I then got an error "An unexpected error occured while deleting the archive 'ArchiveName'. Error: The server threw an exception"

Checking the Event Log of Vault, I saw this: "Event ID 4261. Source: Enterprise Vault. Category: Storage Delete. Description: Access denied. User is not in a role that allows '{STO} Can Administer Archives'.

So, that's cool. I'll have to go through the various settings, but I was mucking around at the "Operations' rather than the "Tasks" level.

The custom role does have the "Can manage Exchange Mailbox Archives", "Can administer Enterprise Vault archives", "{DIR} Can manage archives" and "Can administer Enterprise Vault archives" Operations but not the "{STO} Can Administer Archives"

I've checked and the custom role can look at archives, give permissions to other users on archives, but can't rebuild indexes or recover deleted items. The deleted items thing is a bit of a shame, but I'll keep poking around. Either way, it's progress.

[Rob_Wilcox1]

Sounds like good research here.

[Anthony1st · Accepted solution]

Alright, after a few fairly tedious hours, I've created a role definition that allows a helpdesk operator to:

• Run the Provisioning Task. I figure it's fairly low overhead and useful if a helpdesk person wants to get a user up and running so they can show them vault
• Enable or Disable an archive. They can also kick off a full archiving run, which I'm not too thrilled about. This comes with the territory of giving them Can manage Enterprise Vault Exchange Mailbox tasks, which they need to Enable / Disable. It could cause performance issues if someone kicks it off in the middle of the day, but so long as they don't muck around in this area, it should be okay.
• Go into the properties of an archive and set permissions on it. This'll allow them to deal with delegation of archives and being able to do searches in archives, if required. I might restrict this as well from normal helpdesk staff.
• Not much else; They can't delete an archive (although they could go in and delete individual E-mails, but like I said, this is to stop accidental rather than malicious deletion. They also can't recover the deleted items. If I give them the {STO} Can Administer Archives, which they need to recover deleted items, then they can delete the archive as well. However, I'm not too torn up about this.

Here's the permissions I used to get to here. Note that there may be extras that aren't need or haven't done anything. I was fairly granular in my approach but I haven't gone through each and every one of these. For example, I threw in all of the "Can View xxxxx" without doing testing for each.

*******************************************************

Your Enterprise Vault role is: Vale EMail Operations - Restricted

Entitlements associated with this role:

=======================

Can enable and disable Exchange mailboxes

Can administer Enterprise Vault archives

Can view Site General property page

Can view Site Archiving Defaults property page

Can view Site Shortcut Deletion property page

Can view Site Schedule property page

Can view Site Storage Expiry property page

Can view Site Archiving Usage Limit property page

Can view Site Monitoring property page

Can administer Enterprise Vault servers

Can manage Enterprise Vault Exchange Mailbox tasks

Can manage Enterprise Vault tasks

Can use ServerManager

Can manage Exchange Mailbox Archives

Can manage Shared Archives

Can manage Enterprise Vault Exchange provisioning tasks

{REP} Can View Symantec Enterprise Vault Folder

{REP} Can View Operation Reports Folder

{REP} Can View Generic Reports

{REP} Can View Exchange Server Reports

{REP} Can View Vault Store Reports

******************************************************* 

　

So, all of this makes we wonder whether or not it's really necessary that the backup account needs to be a "Power Administrator" and a "Storage Administrator". I mean, really, it's just putting the system in and out of backup mode and resetting some archive bits. I suspect that you could get the backups working with far fewer permissions to the application.

However, that's a task for another day.

[Rob_Wilcox1]

Good work Anthony, I'd suggest adding this particular snippet to the BLOG section, or if you're feeling more daring, the IDEAS section .. after all these type of roles would be good to have in the product out-of-the-box, in my opinion.

[MarkBarefoot]

Hence my post earlier in the thread. If we can capture these kind of requests from customer who are facing the issue, then it makes sense to see if we can add or improve in these areas.

[Rob_Wilcox1]

Yep - good.