[What (else) is new in v12 - V] gMSA support


Userlevel 7
Badge +7
  • Veeam Legend, Veeam Vanguard
  • 1195 comments

With v12 it will be supported to use group Managed Service Account (gMSA) for user credentials.

For my understanding of gMSA it will be necessary to have VBR server in a domain. Because it will still not be recommended to join this server the production domain, a special resource or management domain could be needed. For more details we will have to wait for general availability to get the user guide.

If you have more ideas about gMSA implementation, let us know 😀


12 comments

Userlevel 7
Badge +4

Hi @vNote42 

 

Currently in Beta2 only the guest interaction proxy has to be in the domain :)

The VBR server can be outside of the domain. I believe that will not change in GA.

 

Thanks

Fabian

Userlevel 7
Badge +7

Hi @vNote42 

 

Currently in Beta2 only the guest interaction proxy has to be in the domain :)

The VBR server can be outside of the domain. I believe that will not change in GA.

 

Thanks

Fabian

Thanks for the insights @Mildur! Great info and great new feature! I am looking forward to see how this works without domain 😀

Userlevel 7
Badge +7

Hi @vNote42 

 

Currently in Beta2 only the guest interaction proxy has to be in the domain :)

The VBR server can be outside of the domain. I believe that will not change in GA.

 

Thanks

Fabian

Thanks for the insights @Mildur! Great info and great new feature! I am looking forward to see how this works without domain 😀

Yes I can finally convince management about no domain.  😂

I cannot wait for many of these new features to come it is going to solve many things for us.

Userlevel 7
Badge +4

Yes I can finally convince management about no domain. 

 

@Chris.Childerhose 

No Domain? gMSA works only in a domain.

Or what you are referring to with “finally no domain?” :)

Are you talking about Domain Admin Permission to backup the domain controller with AAP?

Userlevel 7
Badge +9

If I am not mistaken the keeping the vbr out of the domain is mainly so that it is not an easy target for ransomware that hits a domain? Obviously if someone gets in the network they can plug away at the isolated VBR server and repos but it will be an extra barrier. What other reasons are there that I might not have thought of? (not network segregation which is more for performance I believe?)

Userlevel 7
Badge +7

We are in the process to remove all out Veeam Server from the Windows Domains, to protect them from attacks with domain accounts.

But in my understanding does this not prevent use domain accounts with AAP and similar functions. Even the group accounts should be usable without having the the VBR server domain joined...

Userlevel 7
Badge +4

 @vNote42 what @Mildur means is that Veeam has integrated the use of Service accounts managed autonomously from Active Directory via the gMSA feature.

Now it is no longer necessary to manually create an Active Directory account with custom permissions afferent to the appllicative we are going to back up ex AD\SQL \Exchange\SharePoint ect with the Application Aware feature. 
The Backup Application Aware relies on the Veeam feature "Guest Interaction Proxy "so that the domain account with grant "Domain Admins" or the Service account (gSMA) has the necessary grants to log on the Guest VM ( example AA backup of a Domain Controller) and perform a consisitent backup of the application.

I prefer to use VIX which is a networkless connection. fewer interactions with the customer server farm network.

gSMA autonomously manages the automatic Service account password change service, avoiding extra administrative effort.


Grade feature ! 
Correct me if I am wrong :P
Regards

 

gSMA autonomously manages the automatic Service account password change service, avoiding extra administrative effort.
Grade feature ! 

If I am not mistaken the keeping the vbr out of the domain is mainly so that it is not an easy target for ransomware that hits a domain? Obviously if someone gets in the network they can plug away at the isolated VBR server and repos but it will be an extra barrier. What other reasons are there that I might not have thought of? (not network segregation which is more for performance I believe?)

In my opinion, network segregation also helps to hinder and isolate possible attacks. You need to segregate networks by Firewall e\o ACL open only end-to-end ports with specific ports and protocols between veeam and the server farm\Hypervisor network.
Segregation is also good for performance and not overloading the network.


regards

Userlevel 7
Badge +7

Yes I can finally convince management about no domain. 

 

@Chris.Childerhose

No Domain? gMSA works only in a domain.

Or what you are referring to with “finally no domain?” :)

Are you talking about Domain Admin Permission to backup the domain controller with AAP?

Yeah sorry that is what I meant.  gMSA is good but I prefer Veeam servers not on the domain at all which they tend to do around here for ease of access for management.  😋

Userlevel 7
Badge +7

Guest interaction proxy in domain could be more secure if you remove domain-admins from local admins and add server using local administrator to VBR. Or do I miss something?

Userlevel 4
Badge +1

Add Veeam to a Workgroup, Domain or Forest? For security perspective but also recoverability you normally do not want to integrate the environment which protects and backups the production environment with each other. Looking at security having the Veeam components in a separate forest with domain can be best of both worlds. I wrote about that some time ago here Several new features coming in V12 will require the VBR to be part of a domain, which does NOT mean add it to the production domain! 

My advice normally is from a security perspective but in balance with operational efficiency:

For the most secure deployment add the Veeam components to a management domain that resides in a separate Active Directory Forest and protect the administrative accounts with two-factor authentication mechanics. This way the Veeam Availability Infrastructure does not rely on the environment it is meant to protect!

Userlevel 7
Badge +4

I agree with everything written by @Viperian .

I agree with everything written by @viperian.

There is also to say that not everyone has the possibility to have a parallel production AD Forest for Veeam admin.
Also it has to be an isolated and dedicated Active Directory and secured for Veeam server managment.

Although this way all the security features of GPOs are used.

“Hardening MS Windows for NIST SP 800-171 Compliance” by the California NIST Manufacturing Extension Partnership (MEP) www.cmtc.com ---- > PowerPoint Presentation (af.mil)

Group Policy Objects – DoD Cyber Exchange

Enjoy :)

Userlevel 7
Badge +7

Add Veeam to a Workgroup, Domain or Forest? For security perspective but also recoverability you normally do not want to integrate the environment which protects and backups the production environment with each other. Looking at security having the Veeam components in a separate forest with domain can be best of both worlds. I wrote about that some time ago here Several new features coming in V12 will require the VBR to be part of a domain, which does NOT mean add it to the production domain! 

My advice normally is from a security perspective but in balance with operational efficiency:

For the most secure deployment add the Veeam components to a management domain that resides in a separate Active Directory Forest and protect the administrative accounts with two-factor authentication mechanics. This way the Veeam Availability Infrastructure does not rely on the environment it is meant to protect!

Great post, thanks for sharing!

Comment