+12
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
Hi
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
+12
Hi
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
+18
Hi
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
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.
+12
Yes I can finally convince management about no domain.
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?
+20
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?)
+15
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...
+7
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
+18
Yes I can finally convince management about no domain.
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. 😋
+12
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?
+6
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!
+7
I agree with everything written by
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 :)
+12
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!
+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?)
Same thoughts exactly. Outside the easy target for attackers, I do not think there is any other reason.
+9
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 😀
I have worked with the gMSA. What would you like to learn? I have a blogpost on this: https://techdirectarchive.com/2020/04/09/how-to-create-a-kds-root-key-using-powershell-group-managed-service-accounts/
One great benefit is that the gMSA password management moves to the Windows operating system. Due to the complexity and length of gMSA passwords, the likelihood of brute force attacks are minimised.
+3
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 😀
Would it be possible to implement this and not require a veeam server to be domain joined? I am guessing not.
+12
The backup server doesn’t have to be in the domain, just the guest interaction proxy must be in the production domain. gMSA is an active directory domain feature, so a domain is required.
+9
The backup server doesn’t have to be in the domain, just the guest interaction proxy must be in the production domain. gMSA is an active directory domain feature, so a domain is required.
+1
Hello,
I want to use this feature and I see I need domain server as guest interaction proxy
=> Do you use dedicated server for this role and in all job you specified this guest interraction proxy ?
If I have 20 parallel VM, can he stay stable or do I need more of them ?
I don’t find a lot information about this role and his sizing / architecture.
Gmsa can solve lot of problem about account created + gpo to be local admin + pre provisioned agent on DC + security issue with privilege escalation :/ .
after V12 arrived and i managed to use gMSA now ah little… i did find some compliacted things with it… on one side there are “issues” when you’ve multiple domains, it makes it more complicated..
and one other thing i just found out… you can’t use gMSA everywhere… for like adding proxys you still have to have normal accounts… also for (managed) Agent backups you still could only use “normal” accounts… so ah lot of work todo for veeam here ;)
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
