Domain admin in a non domain server?

[PonzioDiLato]

Hi guys,
we want to harden our B&R infrastructure with a fresh install and implementing some security tips like the ones on this page https://bp.veeam.com/vbr/Security/infra ... ening.html

our local Veeam vendor suggest us to achieve this installing B&R in a non domain joined server, but, because of administrator needs of Veeam in order to backup our vsphere VMs (DCs, SQL databases, Windows Vm), they also suggest us to mantain domain admin rights for veeam service account in order to avoid access rights issues (see this document https://bp.veeam.com/vbr/Security/harde ... ive-access)

My question is: does it make sense to use domain admin rights for veeam, installed in a non domain virtual server?

[Mildur]

Hi Symon

Having the Veeam infrastructure outside of your protection domain is good.

they also suggest us to mantain domain admin rights for veeam service account in order to avoid access rights issues

I assume, they meant the permission requirements for doing guest application aware processing:
https://helpcenter.veeam.com/docs/backu ... processing
The service account for the guest application aware processing requires local admin permission expect for domain controllers, where domain admin permission are required.

So yes, a domain admin is the easiest way to do it. If you don't want to use domain admin accounts, you can use a service account which has only local admin permission on all servers. For the Domain Controller, you could use pre-installed Veeam Agents. With this agents, you don't have to give Veeam the credentials of a domain admin.
Another option will come with V12. You can use gMSA accounts then.

You must protect your VBR server from any sort of unauthorized access. If an intruder have administrative access to the VBR server, he can export all configured credentials in clear text. So think about using MFA for the RDP access. Don't use Veeam inside a VM on your production hypervisor, use a standalone server.

Thanks
Fabian

[PonzioDiLato]

Hy Fabian,
thank you for your reply.
we use domain admin service account for "Guest OS credendials for Backup job"

Personally i don't think local admin in every VM would be the best way: 70 vm to manage, NTLM weak auth instead of Kerberos, UAC must be disabled because of elevated privileges and so on.
also we cannot implement Veeam as a standalone server, only VM.
what do you think?

[matteu]

Hello,

We don't talk about local admin. You need to create a domain user account and put it in local admin group of the server with GPO.
If you can't use dedicated server, you can use VM , there is no other way . For security, you can disable the RDP to the veeam server and use remote management console.
It always depend about what security level you want.
On the best practice you will find a way to disable console on the VBR itself too.

[PonzioDiLato]

but this is not possible with domain controllers, we prefer to not use agents

[Mildur]

Good inputs, matteu

also we cannot implement Veeam as a standalone server, only VM.

If you want to truly harden your backup environment, it cannot be a vm. A VM can be taken over within minutes from someone who has access to the VM console through the hypervisor.

If it has to be a VM, then please make sure to use at least 1 immutable backup repository. Best option would be object storage with object lock. If you can't deploy physical servers, Linux Hardened Repo is out of question.
You can also copy your backups to a veeam cloud connect provider.

but this is not possible with domain controllers, we prefer to not use agents

There is currently no other way. But you can wait for V12 and use gMSA to protect the domain controller.

Thanks
Fabian

[matteu]

If you don't want to use agent for domain controller, you're right, you need at least 1 domain admin account configured on veeam server to backup them.

For your information, it takes arround 5 sec (time to launch a powershell command) if someone take local admin right on your veeam server to know every account and password you configured on the veeam credentials. It's just for you to know it.
If an hacker gain control on your VBR server, even on workgroup, he will be able to compromise all your entire AD domain / forest.

[PonzioDiLato]

in other words you are telling me it's useless a non joined veeam server that use a domain admin as user to backup other vm, in a security poit of view of course
better harden access to vm voiding rdp, uninstalling console, etc.. am I right?

[Mildur]

It's not useless. There are multiple options to harden a backup server. You must combine them together to have a good protection.

Removing the server from the production domain is the first step. No reason to keep it in the production domain.
If you don't remove it from the production domain, an attacker with domain rights in the production domain, can use this rights to get back access to the backup server. He has the permission, because he is domain admin. There is always a way. Even if it has to be physically. Could be a malicious admin from your production domain who can get access to the machine.

Then make sure, that the server cannot be accessed per RDP or other Remote Tools. As Matteu and I already mentioned, credentials can be exported. I don't see how that will work if you use it as a VM. The VM Console cannot be disabled in the hypervisor. At least don't connect your vCenter/hypervisor to the production domain.

Using the correct backup storage with immutability is an additional step to protect your backups.

[matteu]

I can't say useless because if attacker got only domain admin credentials, he can't compromise your veeam server with it and he will need some more time. This time will be short if you use virtual veeam server and your hypervisor use domain authentication because you just need to mount an ISO to the VM and you access to the guest OS as admin...
If you use physical server or your Hypervisor is not linked to the domain, this time will be higher because he will need to find the password.

If an attacker got access to your VBR server as local admin and you store domain admin credential, game over in 5 sec.

I don't want to afraid you, but just for you to know what is the risk you accept or not...

From my point of view, I don't make any new VBR installation with domain account credential. I use veeam agent on DC and client don't want something else when I do a demo to show him how easy is to get all account credentials store in VBR database.

For your last point : see my 1st answer because if veeam it's a VM...

There is no 100 % secure solution but you have lot of option to protect more than do nothing ^^ .
MFA, no RDP, no console, no VM, no admin credentials, no linked between vcenter and domain and veeam and domain (if you don't have ressource / account forest model)

I know it's not an easy subject, but security has never been ^^

PS : Some minute later mildur :p but I see we are on the same way

[matteu]

Sorry, I miss 1 important word
From my point of view, I don't make any new VBR installation with domain admin account credential. I use veeam agent on DC and client don't want something else when I do a demo to show him how easy is to get all account credentials store in VBR database.