Least Priviledge Principle

[LittleNickey]

I've recently taken over as backup admin at my place of work and am trying to adopt least priviledge principle for Veeam backups, especially for Guest Processing. I.E. I'd like to limit the use of Administrator credentials.

Based on Required Permissions
, guest processing requires Logon as Batch. Nothing strange there. Then come some special required permissions for specific application, nothing strange here either. Next come permissions for using Guest File Indexing and VIX, which both requires admin priviledges. Fair enough.

However, if you don't enable Indexing and want to use RPC instead of VIX, would I be correct in that no admin permissions is required, only the logon as batch permission?

When I configure such at job and test the permissions however, I still get RPC connection failed based on it trying to connect to the $admin share with Access Denied error.

Also, as I'm quite new to Veeam, is there any gain in having Guest Processing without Indexing for non-DC/SQL/Exchange/Sharepoint/Oracle servers?

[jorgedlcruz]

Good morning,
The File Indexing will only be useful to you in case you are using Enterprise Manager to trigger restores of these files. Imagine if you have a few critical file servers, and you have like a dozen or more agents triggering restores of these files every day. If that is not the case, you can still perform files restores from EM, it just takes a bit longer for a file server.

For things like SQL, DC, SP, etc. Indexing does not apply anyways, and the restores will be lighting fast anyways, indexing only has that specific use-case in mind.

Hope it helps!

[LittleNickey]

Hi @jorgedlcruz,

thanks for your reply, but my question isn't really pertaining the indexing and the speed, I'm more after if there is any use for guest processing on servers that don't run AD/SQL/Oracle/Exchange/Sharepoint (ie regular "App" servers) and what the minimum permissions required would be on such servers if I don't use Indexing but still use Guest Processing.

[david.domask]

Hi @LittleNickey,

> However, if you don't enable Indexing and want to use RPC instead of VIX, would I be correct in that no admin permissions is required, only the logon as batch permission?

Not quite. Both require Administrator Privileges. Check the bullet points in this section for the requirements: https://helpcenter.veeam.com/docs/backu ... processing

VIX (Actually VMware Web Services, but vix is shorter to write) requires either Administrator Access or that you disable UAC. This is a limitation of VIX access in order to access the required locations.

> Also, as I'm quite new to Veeam, is there any gain in having Guest Processing without Indexing for non-DC/SQL/Exchange/Sharepoint/Oracle servers?

There is! Guest Processing gets the system to a quiesced state, meaning that all pending writes/IO/buffered/cached items are flushed to disk and guaranteed consistent. So it's _always_ recommended for your most critical servers. Appliance-like machines (e.g., some webserver or something) likely don't need it as much though as the backup rules for those from the Vendors is usually to dump the configuration and back that up, and if the machine breaks, just deploy a new appliance and restore the configuration.

So strongly recommend it for your machines

[LittleNickey]

@david.domask thank you for the reply!

Not quite. Both require Administrator Privileges. Check the bullet points in this section for the requirements

I have checked the bullet points, but the only admin mentions I can see is for VIX, Indexing and those specific applications, nothing regarding RPC/non-VIX. I get that VIX does require it and those specific apps, and maybe I'm misinterpreting the text but I can only see that "networkless guest processing over VMware VIX" (and indexing, and those apps) require Admin/root priviledges. If you could quote the documentation what I'm missing I'd be very glad, either way it sounds on you that even RPC does require admin/root priviledges?

There is! Guest Processing gets the system to a quiesced state, meaning that all pending writes/IO/buffered/cached items are flushed to disk and guaranteed consistent.

Thanks for clearing up my question regadring guest processing for other types of servers. I'm guessing however that gettig the system to a quiesced state requires VSS? The reason why I ask is that the admin before me have enabled "Application-aware processing" for some jobs, but when checking the settings via the "applications" button it says "VSS Disabled" ("Disable Application Processing"). Also scripts and exclutions are disabled. Am I right in understanding that this means that the servers are not processed and "Application-aware processing" might as well be set to "Disabled"?

[david.domask]

Ah, I misunderstood slightly, I thought the focus was VIX, but rereading your statement, I see I misread.

Indeed, if you're not processing those applications, you can get away with far fewer privileges. I would recommend using Persistent Agents if you're aiming for least privileges, as with non-Persistent Agents, the components need to be deployed to the Admin$ share and depending on policies, you might need to open up permissions for the account a bit more: https://helpcenter.veeam.com/docs/backu ... components

> Am I right in understanding that this means that the servers are not processed and "Application-aware processing" might as well be set to "Disabled"?

Correct. Quiescing can happen two ways:

VSS
Vmware Tools Quiescence (which actually also engages VSS)

Basically, with the current setting your mention and VSS disabled, the backups are crash-consistent right now, and you're correct, you may as well just disable Application Aware Processing if that's the case. But as above, it's of course a good idea to get them Application Consistent. (Small hint, even applications we don't integrate will can still benefit from AAIP; any Application with a VSS writer will still be quiesced. We won't be able to do any special restores, but at least you'll have a consistent backup)

[LittleNickey]

@david.domask thanks for the link!

with non-Persistent Agents, the components need to be deployed to the Admin$ share and depending on policies, you might need to open up permissions for the account a bit more

Gotcha, and RPC also uses the Admin$ share, that of course require admin permissions as that is the only users with access to the share.

Correct. Quiescing can happen two ways:
VSS
Vmware Tools Quiescence (which actually also engages VSS)

And using VMware Tools we wouldn't need any extra permissions, as that is handles via the installed Tools agent, much like what would be accomplished if using Veeam Persistent Agent I'm guessing.

So basically there are 4 options:
1. VMware Tools (but can't be used with AAIP for SQL/AD/etc and thus don't get the benefit of the Explorers I'm guessing)
2. Persistent Agents (where the drawback is management such as installation and updates)
3. Using admin credentials. This account should however be possible to restrict using GPO's so it cannot logon locally, via RDP or as a service, thus minimizing the attack surface.
4. Not using AAIP or VMware Tools quiescence and only get crash consistent backups.

[david.domask]

Yep! Think you got it @LittleNickey I think some combination of 2 and 3 is best here; I know that the management of the persistent agents can be a bit beastly, but with GPOs it shouldn't be too bad.

The script from this thread on the community forums may be useful for management: https://community.veeam.com/script-libr ... c-ps1-2319

I would add in a check for the Installer Service also, as it's required for the installation. If any are out of date compared to what's on the Veeam Server, just pull the necessary .msi from the Packages directory on the Veeam Server and deploy it, as it will always be "up to date".

[LittleNickey]

Awesome, thanks for the tip and explanations @david.domask!