V13 - Use of credentials for persisten guest agent and deployment kit?

[EviLin]

Hello,

Designing and setting up a completely new secure micro-segmented environment.
And Im gonna deploy Veeam deployment kits on all VMs for using certificate based auth. and persistent guest agent.

But what I dont get, even though I install the veeam deployment kit on the protected vms and enables persistent guest agent in the backup jobs, im still forced to set some credentials when using guest processing, what are these credentials for? Should'nt we be able to completely avoid using credentials, when all protected vms has the veeam deployment kit?

[dejan.ilic]

Its difficult to give a user for database handling unless there is some kind of classic user, unless veeam runs these as a known user.
These could be System (or) Administrator (windows) or root (or) veeam-user (for Linux).

But you might want to be able to run these guest processing commands (database snapshots) as a user that does not have a total control of the system, just a limited subset.

Then again I agree, Veeam would have to split processing depending on what is expected of the operating system.
Like Windows VSS snapshot that require Administrator or localsystem to work should be handled by certificate login before switching over to provided (less priviledged) account for database handling.
Right now GMSA-enabled service accounts for guest handling are the next best thing from security perspecive I guess, if you run Windows AD-managed servers.

[david.domask]

Hi EvilLin,

The main benefit of the persistent guest agents is reducing the port requirements significantly and bypassing the need for credentials for logon. However, Guest OS Credentials are still required for specific Application Aware Processing Operations, for example, SQL log truncation.

Persistent Guest agents allow for a more secure connection to the GuestOS, but the Veeam server certificate cannot be used to authenticate for specific application interactions. For applications that support it, you can set specific application credentials as seen here with Postgres. (we currently support this for Oracle as well)

I would second dejan.ilic's suggestion on gMSA if feasible for your environment.