AAP gMSA in 12.1 Seems Worse for Security

[mkaec]

In a standard configuration, AAP might be setup as follows:
Veeam uses a service account to connect to VMs for AAP.
The service account is in the Administrators group of each VM.

This allows the backup server to have administrator access to the VM (which it needs), but doesn't grant any special permissions to the guest VMs.


When B&R 12.0 was released, I moved AAP from a regular service account to a gMSA. I did this using the following steps:
Create the gMSA
Add the Veeam server to the AD group that is allowed to retrieve the gMSA password
Add the gMSA to the Administrators group of the VMs

This replicated the legacy configuration with the added benefits of gMSA.

After I updated to 12.1, the jobs started logging the following error:
Unable to subscribe to guest processing components: Failed to detect Oracle installation.
Failed to create a process token for MSA account

I opened a case (07077926) noting the my gMSA setup had broken after updating to 12.1. Support wanted me to verify that Test-ADServiceAccount returns true not only on the backup server, but also on all of the guest VMs. The only way I could get that to happen is to add the guest VMs to the AD group that authorizes retrieval of the gMSA password. Indeed, once I do that, the AAP error goes away.

But I see a problem with this. If every guest is allowed to retrieve the gMSA password, then it seems the security posture is worse than using a regular service account. If a VM is compromised, the attacker could use the gMSA to gain administrative access to all of the other servers in the domain. With a regular service account, only compromise of the backup server posed that kind of risk.

[PetrM]

Hi Marc,

I'm not aware of any code changes related to gMSA processing in 12.1. I will ask our support leaders to escalate the case, I'm curious to know what the root cause is.

Thanks!

[PetrM]

Hi Marc,

I see that you continue working with our support team, that's good. In the meantime, I discussed the issue with my colleagues and in fact, we already pointed out this requirement in our user guide:

If you back up a machine using a gMSA, both the guest interaction proxy and the target machine must have network access to the domain controllers and be in the same domain to obtain the gMSA password.

Most probably, you had the same issue in version 12 but just did not see the error due to a glitch in the reporting logic which is fixed in 12.1. So there is no difference between 12 and 12.1 from the security perspective. However, I'll think about possible ways to eliminate this requirement in one of our future versions.

Thanks!

[mkaec]

I solved this problem for my environment by creating a gMSA for each VM. The environment is small enough that this wasn't a terrible burden. Veeam B&R allows overriding the AAP credentials in a job per VM, which allowed the applicable gMSA to be assigned without having to break up jobs. Each gMSA only has administrative access to one VM.

[TimoB]

However, I'll think about possible ways to eliminate this requirement in one of our future versions.

Hi Petr,
as we are currently running into the same situation, I was wondering whether any changes are planned.
From v12.3 documentation, I can see that the situation did not change and that all guests need to be allowed to receive the gMSA password from AD.
Any insights would be appreciated.
Thanks.

[PetrM]

Hello,

There are currently no changes planned. However, could you please elaborate a bit more on that? How are you using gMSA outside of the domain? As far as we can see in this article, a server must be able to retrieve credentials over LDAP:

Use of the gMSA is scoped to any machine that is able to use LDAP to retrieve the gMSA's credentials.

Thanks!

[TimoB]

Hi,
the systems to be backed up are not outside the domain, however, there are some concerns against adding all systems to the list of devices allowed to retrieve the gMSA password.
Unless I am not using different accounts for every guest system, it would be easier to get administrative privileges on all other systems using that same account - if I am not mistaken.
Of course, things like interactive logon can be restricted, but still, some access will be possible.

[PetrM]

Hello,

I understand the plan in theory, but I'm not sure about the technical implementation. At least now, I see in the official documentation that if a system is unable to retrieve the gMSA password, it is outside the scope of gMSA usage.

Thanks!

[mkaec]

...
Unless I am not using different accounts for every guest system, it would be easier to get administrative privileges on all other systems using that same account - if I am not mistaken.
...

That's what I ended up doing. I created a different gMSA for each guest. That wasn't too many because most VMs are backed up without AAP at all. But a handful needed it and so they got their own dedicated gMSA accounts.