Feature Request: More granular permissions (Like VBR)

[compconsult]

Hi All,

We really really like the way VBR enacts permissions. We have a single server that runs our internal VBR and VBO backups, and let the technicians connect to VBR read only so they can make sure our backups are working - but touch nothing else (that's my job). What would be really awesome is to have a similar way of supplying the techs access to Read/Restore/Create etc in VBO - without them being a local admin on the VBO server. I don't mind them having local admin on their own machines, but on a server that controls backups? No thanks. We don't have the infrastructure (nor do I believe it should be necessary) to separate out the VBO stuff into its own machine that the techs would be allowed admin access to.

[Mike Resseler]

Hey,

You are right that this doesn't exist yet. For your info, we already are separating different components of the solution and in the next version you will be able to deploy the UI on a separate workstation/ management server. It still won't be exactly as you want it, but step by step we are getting there.

If you have a few minutes of time, could you tell me exactly what you would like those technicians to do? That would give me a good understanding of your requirements (obviously I have others with similar requirements so I need to compare )

[compconsult]

For us at the moment it's specifically just "Log into the service using the console on a remote computer - Without having local admin rights on the server running the service". I've managed enough using a local group policy to disallow local logon, remote logon and disabled powershell remoting on the server - But it's kind of cumbersome

I expect that longer term:

• Allow the ability to view backup job status
• Allow/Deny the ability to add/remove Organisations
• Allow/Deny the ability to add/remove Backup Jobs
• Allow/Deny the ability to restore items to the original source
• Allow/Deny the ability to export items/mailboxes to PST/Different target.

I can see from an MSP or service provider perspective being able to apply these at some sort of grouping or management level (organisation?) would be good, but also much harder to implement than just to the system as a whole - especially considering the Jet Blue backend.

These are just throwing them out there as ideas though - I can't specifically see the need for us at this stage but it's certainly nice to have the options in a backup product. Say - We could allow our receptionist/dispatch to log in, and just make sure all the backups have run properly for the last week - but not have them able to make changes or get at anyone's data. Even though emails are nice and all, that quick check also covers if the service crashes, or there's some other weird issue.

[Mike Resseler]

Understood, and good information
Thanks again
Mike

[coreypenford]

To add onto this, the ability to have 'read' permissions for different jobs would be valuable

As I understand it, if you have the correct access (i.e. local admin) to launch the Exchange Explorer and connect to the 365 store, then you get all the emails from that server.

What I'd like is to have some sort of permissions or groups to be able to say helpdesk can see THESE mailboxes, but no others. Maybe based on jobs?

The idea being it's a nice feature for helpdesk to help Jane in accounting restore her deleted email from a month ago, but not give them access to the CEO's mailbox and be able to browse through that. Right now it's all or nothing.

[Mike Resseler]

It is all or nothing indeed at this moment. So certainly worth to look at in the longer run. Thanks for your ideas

[vipthomps]

This is still an issue for us with 2.0 as well. The authentication should mirror the permissions already defined in VBR as far as roles. We have engineers that should NOT be local admins but we cannot authenticate them via a Restful API portal unless they are.