tsightler wrote:Of course I can, that's pretty much the whole point of this thread, Veeam is providing a way to access files in the backup that the users doesn't otherwise have permissions to (that's what's not working in the OP's case). The user can exploit that to read data from the backups that they shouldn't have access to.
Because the user doing FLR must be local administrator, he can perform this exploit manually anyway. Just needs to know how to grant extra privileges to self. If you agree to this, then what is wrong with Veeam doing this automatically within its own process, not even system-wide as the user could potentially do?
Without this feature, users were unable to restore some files when they really needed to, and had to open a support case... did not really help in disaster situation when fast recovery is needed. Yes, you were one of few who did figure out the Backup Operator workaround, but that was more of an exception.
tsightler wrote:And yes, a restore operator should be able to restore files he doesn't otherwise have access to, but he should not be able to actually access the contents of those files.
Well, unfortunately Windows security makes it impossible for an account to read the content of the file without access rights this content

and our current FLR architecture requires content copying.
tsightler wrote:With our other backups products the service account for the backup application was granted the "Backup Operator" role, and the application controlled access to who could perform restores on what systems. They could restore files that they didn't have access to but they couldn't actually read the files since the restore was handled by the backup application itself, the backup operator simply scheduled the restore.
You know this is not how our product works. Today, restores need to be done by users who are members of Local Administrators group on backup server, interactively, and by fetching the files directly from backup image that is mounted locally as a file system, to the user-specified location. Since you have questioned implementation of a very specific feature, in a very specific product (and version), why refer other products? They work differently, so they are irrelevant to this discussion. With this feature, we are addressing a very specific challenge users were facing with restores using our product with its current FLR architecture.
tsightler wrote:I also find it hilarious that your argument against using the "Backup Operators" group is that you add it only to the "process", but to do that the account has to be an admin. Requiring the account to be an admin seems far less secure than being a backup operator. If you notice, my suggestion was to add this permission in lieu of making the account a Domain Admin so my suggestion would provide far less privileges than what the OP actually did.
Well, the fact that using Domain Admin resolved the issue for Darhl does not yet mean this is a system requirement for our product. Just local admin should be sufficient. This is exactly why I requested 2 set of log files.
Now, because local admin (which we do require) is not a backup operator by default, it still cannot get files he/she does not have access to (other than from backup file). He can indeed grant himself Backup Operator at any moment, but this operation would be captured through Event Log monitoring system (which is always in place since we are talking about "an enterprise security setting"), so he would have explaining to do. With your workaround however, you grant this privilege and thus let the account full uncontrolled access to all files on the system... "officially" and forever. Which is why I thought this workaround is not as good (and is less secure) than what our software provides. See, this is not so hilarious in the end. Unless I am missing something funny in what I am saying
By the way, this feature was documented since early v5 aplhas (check out the Alpha3 release notes in focus group). I guess it just did not look too alarming until now, when this whole argument started
