Clarity with gMSA vs Veeam Deployment kit (certificates)

[sdolcourt]

VBR 12 doesn't have certificate authentication, so gMSA seemingly makes sense to allow VBR mass access to Windows servers.

With V13, I'm not so sure gMSA is useful, if cert based authentication solves what gMSA can do. Yes, more individual deployment of certs, but ain't nobody gotta monkey around with setting up gMSA in AD.

Is there a use case for gMSA that I'm missing, something that it's better at, than Veeam's certificate deploy kit?

An aside - MS SQL can use MSA for authentication, what is the technical reason why Veeam does not support them?

Cheers, Seth

[HannesK]

Hello,
I would always go for the deployer kit because it has no domain / Kerberos dependencies.

MSSQL MSA: complexity of development vs. how many customers asked for it

Best regards
Hannes

[sdolcourt]

Hi, Hannes,

Thank you. Philosophically, I like certs better than managed service accounts.

However, Veeam is missing the support of MSA for SQL backup and restore, it seems a self-perpetuating problem - it doesn't exist, so no one asks. No one asks, so it doesn't exist.

Maybe I'll be the one: Feature Request - Veeam Explorer support of sMSA, gMSA and dMSA for SQL backup and recovery.

While we're at it, feature request for two level credential access for SQL backup and restore: one credential for admin$ access to the OS, and a second credential for SQL access.

There. Now someone asked.

Is it done yet?

[dejan.ilic]

Hello,
I would always go for the deployer kit because it has no domain / Kerberos dependencies.

MSSQL MSA: complexity of development vs. how many customers asked for it

Best regards
Hannes

Actually, we have replaced account-based login with certificate based (deployment model) across the board.
gMSA also forces us to have AD-joined proxy servers, contrary to Veeams recommendation not to have Veeam VBR AD-joined.
But we feel it is better due to higher security service-accounts, compared to old style account system.

The places I have not been able to remove the account dependancy is :
* application aware agent backup (gMSA used when possible for Windows)
* application aware VM backup (standard account for guest processing)
* file-level restore for Linux

I would love if Veeam can create a solution where we dont need to use standard or MSA accounts anywhere.

[sdolcourt]

Of not to argue, but to explore.

I'm a proponent of SSO and domain joining. I'm not exactly sure the benefits of Veeam's avoidance of domain join for backup components. If a hacker gorup is that talented to break into your internals, separation from the doman does not prevent them finding your backups. I'd argue that Active Directory's managed service accounts for password length, complexity and expiration reduces the exploit of stale or crack-able credentials.

From a Sarbanes Oxley (SOX) compliance perspective, life is much easier, given a user's domain account that is disabled / deleted via IDM tools immediately has no access to Veeam. Our situation is multiple VBR's across the corporate empire. Given Veeam's lack of vCenter style management to federate VBR's under one glorious banner, leveraging AD is the sanity needed for managing user access. Different battle, different day.

I was disappointed for VSA's initial deployment, Veeam didn't use LDAP binding as so many other Linux-based applications do. We have to domain-join it, and even then, Veeam does not (as of 13.0.x) support authentication to trusted domains. Different battle, different day.

Ultimately, there has to be authentication and authorization for Veeam to backup and restore. I suppose it's a philosophical battle of whether that's controlled by Veeam's authentication model or our domain's authentication model.

Circling back to managed service account, I am a bit struck by how much service account glue is needed for V12, and am happy that V13's certificate is reducing the service account Titebond. Where I need glue, e.g. SQL, having Veeam support MSA for standalone, group and delegated is needful.