Right now Veeam is installed and running using the domain account administrator (yes I know, bad IT guy). In efforts to become more secure I was going to do what I thought was the correct thing and create a backup domain account. Put that account in the backup operator group on the VM’s being backed up and then do what ever else was needed to backup things with a less privileged approach.

Looking at Veeam’s documentations in order to back up anything in a vsphere environment you need to give the account root access to VMware, local admin to the server running Veeam, local admin on the VM’s you are backing up and domain admin access to do AD. So is there a benefit to changing Veeam over to this back up account that I am not seeing? Since I want to back AD the account will have domain Admin access. Is there a link that maybe describes least privileged access that I am not finding?

I do have an immutable repository so I have some protection

14 Spice ups

I guess I’m not 100% sure what you’re asking, but I can explain how I do it on my, and my clients, smaller networks. (Mind you my largest client is about 20 people, same with my office). We backup just the 3 servers in my office. All windows, 2 servers to 1 repository, and the financial server to its own repository.

I have two accounts for myself. One is an admin account, the other is my normal user account. My admin account is used for things like you explain (backups, giving approval to individuals who want to install things locally, the sonicwall AD account, etc.), and my user account is what I use for everything else. They use two separate passwords and are configured completely different.

Like I said, not sure if this helps, it’s just the way that I do it. I feel it’s a bit more secure since I use the admin account extremely rarely.

Run Veeam on a non-domain-joined computer with a local account. It will connect to domain guests just fine with credentials, and isn’t flapping in the breeze for ransomware or whatever else might go stomping through your network.

1 Spice up

You would just create another user on VMware to backup the VMs and use the backup account to do in OS Snapshot and make sure the location where you back up to is not tied to a domain.

These are the requirements

but if you using a non-domain joined Veeam and you are backing up shares you will not get the permissions, right?

We (Managecast) highly recommend not having the Veeam server on the domain and use different credentials than your domain accounts. A stand-alone Veeam installation can backup your domain environment just fine by putting in the domain credentials into the backup job. It’s also good to have a dedicated domain backup account that has administrator access, because then you can do things like control where that account can login from, etc.

1 Spice up

I feel that the linux immutable repositories are a very important safegaurd. With that said if (when) I run Veeam on it’s own server out of the domain, would running it as VM on it’s own host be a good (Ok) practice? My thought was I could have the Veeam server and the required linux server for the immutable repository on one VM host in efforts of saving some money on hardware. I realize there is still the risk of the host being compromised and ransomed or something like that. I do have offsite, and unattached rotating backups so not totally hanging myself but trying to do things as right as budgets allow.

Your Veeam server should not be domain joined. You add the credentials it uses for connecting to the resources within the veeam interface itself and specify those in each back up job.

This prevents your backups being at risk if your domain credentials are compromised. As an aside, also make sure your backup storage is not domain joined and those domain credentials cannot be used to encrypt/wipe the storage device in any way.

Yes, Linux Immutable Repo’s would be a good option that is a lot better than nothing, but like you said, with the Linux option you have other vulnerabilities if you run it as a VM or if the underlying storage security is weak. Again, better than nothing, but not as robust as a dedicated immutable solution like Zadara, Cloudian, etc.

By the way, we offer offsite Zadara immutable storage for our Veeam clients. https://managecast.com/immutable