Using a gMSA created in the Backup/Management Domain for Veeam guest processing

[AlexisB]

Hi,

I'm designing a secure Veeam B&R v13 infrastructure with a dedicated Backup domain and struggling to find anyone who has tested a specific gMSA configuration. Looking for real-world feedback.

My setup:

• Dedicated Backup Domain (backup.lan) hosting all Veeam components: Backup Server, Proxy, GIP, Repository, Mount Server
• Production Domain (prod.lan) hosting vCenter, ESXi, and all VMs
• One-way trust: PROD trusts BACKUP (BACKUP accounts can authenticate against PROD resources via Kerberos)
• Goal: Kerberos only, no NTLM, gMSA for all service accounts

The specific scenario I want to test:

Instead of creating the gMSA in the Production domain (which is what every official guide recommends), I want to:

1. Create the gMSA in the Backup domain (backup.lan)
2. Add the GIP machine account (GIP$@backup.lan) to PrincipalsAllowedToRetrieveManagedPassword
3. Keep the GIP in the Backup domain — it retrieves its own gMSA from its own KDC natively
4. The GIP then authenticates against Production VMs using that gMSA, leveraging the one-way trust (PROD trusts BACKUP → Production VMs should accept Kerberos tickets issued for BACKUP accounts)
5. Add the gMSA to the local Administrators group on Production VMs

Why this should theoretically work:

• The trust direction (PROD → BACKUP) means Production VMs accept authentication from BACKUP accounts
• The GIP is in BACKUP, so it can retrieve the gMSA password from its own KDC without any cross-domain complexity
• The gMSA then presents a valid Kerberos ticket (trusted by PROD) to the guest VM
• No Veeam component ever needs to join the Production domain

What official sources say:

Veeam's helpcenter states: "the GIP must be joined to the domain where the gMSA was created" — which would be satisfied here since both GIP and gMSA are in BACKUP.

However, the same doc also states: "both the GIP and the target machine must be in the same domain" — which would NOT be satisfied, since the target VMs are in PROD.

HannesK confirmed after QA testing in a previous thread that "the GIP has to be in the production domain" for gMSA guest processing, but this was in the context of a gMSA created in PROD. It's unclear whether the same conclusion applies when the gMSA is created in BACKUP and the trust goes the right direction.

My actual questions:

• Has anyone tested this exact scenario (gMSA in BACKUP domain, GIP in BACKUP domain, VMs in PROD domain, PROD trusts BACKUP)?
• At what step does it fail, if it does? Password retrieval by the GIP? Veeam credential validation? SMB/RPC connection to the guest VM? Token creation on the guest?
• Is the "same domain" requirement a hard OS/Kerberos constraint, or a Veeam software limitation?

haslund suggests the same thing I want to do : veeam-backup-replication-f2/veeam-desig ... 94168.html

Thanks in advance — couldn't find a single person who tested this specific combination anywhere online.

[Mildur]

Hi AlexisB,

Welcome to the forum.
I have not tested it myself, but I would suggest using deployment kits (a v13 feature) instead of gMSA. It will likely make your life much easier by avoiding domain and Kerberos dependencies.
It is also more secure, since it uses certificate-based authentication instead of credentials.

Best,
Fabian

[AlexisB]

Hi Mildur,

Thank you for your response. However, using deployment kits isn't enough for Application Aware Processing, right ?

[AlexisB]

So using the deployment kit together with the persistent guest agent allow us to perform Windows Backup with Application aware Processing (Active Directory, SQL...) ? That sounds great

[Mildur]

Yes, I double-checked internally.

You can provide any credentials (fake ones), in the backup job properties, as long as you have pre-deployed the deployment kit and selected the option to use persistent guest agents.

Best,
Fabian

[EviLin]

I can confirm.

Running on V13, we have 3 domains, NO trust between any of them.

We have a single GIP (Guest interaction Proxy) joined 1 of the domais and via Veeam deployment package installed on all 6 DCs (2 in each domain of course), and persisent guest agent choosen in the backup job.
We get application aware backup on all 6 DCs.

I've created a "Dummy credential" because you need to fill in something in the credential field, even if you only use persistent guest agent.

[AlexisB]

Thanks Fabian & EviLin.
@EviLin, GIP isn't needed right ?

[Mildur]

A Guest Interaction Proxy is still required.
Starting with v13, it can also be a Linux machine (self managed or Veeam Infrastructure Appliance).

Best,
Fabian

[AlexisB]

Sorry, I mean GIP in the production domain (joined to the production domain).

[Mildur]

Any domain or workgroup configuration will work for GIP.
If you are on v13, I would suggest using Veeam Infrastructure Appliances as your GIP proxy to enhance security.

Best,
Fabian