Skip to main content
  • EN

gMSA with VBR

 

Why you should,

how you do it

and why they don’t solve all your problems

 

This is the first part of a three-part series on gMSA usage with Veeam. This part will cover the background and the basic concept behind it. We will also answer the question, why to use gMSA accounts in the first place.

 

gMSA - one account to rule them all?

 

Background

One of the vulnerable spots of every backup infrastructure originates to the fact that we must communicate with the inside of the workloads to get them in good shape for a proper backup. This is what we call transaction consistency or “Application-Aware Processing” when it comes to Veeam Backup and Replication.

 

Without this functionality all your backups would only be considered “crash-consistent”. That might be ok for some semi-relevant workload, but the crown jewels in every environment need to be backed up transactionally consistent. In many cases we even want to do additional things inside the workload. This can be purging transaction logs of databases or even shipping those to your backup server on a per-minute basis in addition to the image level backups every night.

Therefore, we need credentials in Veeam that allow us to carry out those tasks inside the workloads. This implies to install the Veeam guest-helper component and in the case of Windows e.g. talk to the VSS components of the OS. A local administrator account is needed here.

Here comes our problem. What account of your domain should Veeam use, that has local admin credentials to each system in your environment? An easy but very unsecure approach would be to use the same password for your local admin on every system. Don’t do it. If someone hacks this password, he can access all your systems at once. Even worse would be, to use a domain admin account for that reason. A domain admin happens to be local admin on every domain joined system. So, it would do the job and I’ve (unfortunately) seen this approach. But never ever do you use a domain admin for anything else then administering the domain.

Of course there is LAPS. With LAPS all local admin passwords are unique and complex. But AFAIK there is no connection to Veeam so far.

Group Managed Service Accounts (gMSA) have been introduced to Windows domains with the release of Windows 2012 more than 10 years ago.

Before that, there only were sMSA accounts, that were only valid on a single server system.

There have been feature requests to integrate gMSA into Veeam to be used for guest interaction since the early days.

Version 12 finally brought us support for gMSA and I’m already using them in most projects if possible.

 

Why?

What makes gMSA accounts more secure than regular service accounts in a Windows domain?

They integrate several advantages at the same time.

  • Multiple servers: gMSAs – in contrast to sMSAs – can be set and run across multiple servers.
  • Password management: Passwords for gMSAs are automatically generated, handled and rotated by the OS. You never get in contact with the highly privileged password. Default rotation time if 30 days but can be adjusted.
  • Password safety: gMSA passwords are randomly generated and consist of 240 bytes. This length and complexity helps to ensure the security of the account by minimizing the likelihood of compromise through brute force or dictionary attacks
  • Even if someone manages to steal the password, the attacker cannot just login to the Windows desktop as the gMSA is a service account. One can though use “psexec” to run things in the context of the gMSA.

A good overview can be found here.

 

Now, stay tuned for part two and three of this blog. We will cover how to use gMSAs with Veeam and how to keep them safe and secure against attackers. Yes, there are already known attacks on gMSA.

 Very interesting read on this as it is something I am looking at for our new domain.  Will keep an eye out for part two.

Thanks for sharing @Michael Melter . Looking forward to the other 2 parts 😊

Thank you for sharing. Happy to see the following articles. gMSA is a good way to go.
We have already some environments with gMSA in place. Unfortunately i would say less then 25%, but more to come. 

Good article. 

Just out of interest, how are you keeping track of your accounts? How do you manage the decommissioning of these accounts?

Just stated to dip my toe into gMSA the other day, but still trying to wrap my head around the setup.  Looking forward to the other parts!

I talked about it recently with one of my customer. The usage is more e secure than implement an specific account with admin privilege, unfortunately when you have implemented AD Tiering it could be difficult to configured it.

Great idea. We are starting to use gMSA’s more and more in our environment. Veeam is going to be the next place we use them as indexing on the file servers is needed for Enterprise Manager. Also on our Application aware servers it would be another option. 

Hello,

 

I like the idea and I m happy to find some ressources on it but with my knowledge it s no so usefull to implement on most environment 

1)Best practice says : application guest  processing should be use on ALL windows and not only DC, exchange, SQL,…

That mean you should have a gmsa account for all virtual machine (1 for all or différents but you need to set up all of them).

If you don t want, you could juste use it for all veeam  application avare only and ignore this best practice.

2)By design, you need to use a guest application proxy inside the domain. Most of backup infrastructure today are workgroup environment and you don t want any domain computer for this type of environment. (For dedicated forest for backup it s ok ! ).

 

I like the idea of gmsa ans I use it everytime I can but not for backup because of these both limitation…

To backup domain controller, I prefer to use veeam pre-installed agent. You don t need domain account for this. 

However I use a domain account I add as local admin on all my other server and I use this account for backup…this is also "bad" but there is no good solution for this I'm avare.

 

Comment


Terms & Conditions