Securing the VBR server at the Windows OS level using security policy settings

[massimiliano.rizzi]

Hello Community and good day,

first of all, apologies for the long thread but I wanted to provide as much context as possible.

I totally with agree with the recommendation I've been seeing lately regarding the use of physical boxes exclusively as VHRs and putting the VBR server role alone somewhere else (as long as backup data is physically separated from the VBR server itself). I strongly believe this should be the way to go from now on.

Looking at our install base, we still have some customers using physical Windows boxes hosting both the primary backup repository and the VBR server role at the same time (although we implement immutability for a backup copy if possible at all in such scenarios). To be completely honest, in a scenario where backup data is not physically separated from the VBR server itself I see little point to enabling two-factor authentication for Veeam Backup and Replication users without applying some hardening on these boxes, such as preventing some users from logging onto the operating system.

Although the first goal should be to put the VBR server role alone, physically separate backup data from it and implement end to end immutability for all the backup copies, realistically it will take time to transition all existing install base to this scenario (to the perfect scenario, if you will).

Sticking with the mantra from Sami Laiho "In Security, don’t let perfect be the enemy of good", it is possible to increase the security of the VBR server itself with relatively minimal effort and fast gains by creating separate, Veeam Console-specific users protected with MFA without admin rights of the VBR server itself for logging in and operating the v12 Console.

Besides disabling the Remote Desktop Service one the VBR server itself (which of course is not part of the production domain), the plan I have in my mind in order to accomplish this task is to end up with:

VBR server Default local Administrator account
==================================================
1) Not used for daily operations and intended as a Break Glass Account with a complex and unique password stored safely
2) Depending on the level of paranoia, it can be disabled in favor of a Break Glass Account whose username is automatically generated, with a complex and unique password stored safely and MFA (like Cisco Duo) at the OS level
3) Regarding the User Rights Assignments at the Windows OS level, I believe "Deny access to this computer from the network", "Deny log on as a batch job", "Deny log on as a service" and "Deny log on through Remote Desktop Services" can all be disabled using the Local Group Policy Editor, thus allowing log on directly at the device's console only
==================================================

VBR server local account(s) with administrator rights used for periodic operations on the VBR server itself, such as performing upgrades of Veeam Backup & Replication
==================================================
1) Username(s) for such account(s) can be automatically generated, with a complex and unique password and MFA (like Cisco Duo) at the OS level depending on the level of paranoia
2) Regarding the User Rights Assignments at the Windows OS level, I believe we can apply the same security policy settings listed above for the VBR server Default local Administrator account/Break Glass Account
==================================================

VBR server local account(s) without administrator rights used for daily Veeam Console-specific operations depending on the role assigned to them
==================================================
1) Username(s) for such account(s) can be automatically generated, with a complex and unique password and MFA at the Veeam v12 Console level
2) Regarding the User Rights Assignments at the Windows OS level, I believe "Deny log on as a batch job", "Deny log on as a service", "Deny log on locally" and "Deny log on through Remote Desktop Services" can all be disabled using the Local Group Policy Editor, while I am unsure whether the "Deny access to this computer from the network" can be safely disabled as it is required to allow proper logon through the Veeam console from a remote computer
==================================================

Any suggestions and thoughts will be greatly appreciated.

Kind Regards,

Massimiliano

[HannesK]

Hello,
looks like it should work. Any positive / negative experience with that?

Best regards,
Hannes