DC without NTLMv2

[ESXIGuy]

Running newest version B&R for vSphere with Veeam non-domain joined

Do not want to use NTLMv2 for creds/hashes to authenticate

Preferably do not want to use Domain Admin creds for DC's

Do not have another forest for Veeam so I don't want to domain join

All servers including DC's are VM's

What is the most secure way to go about this?

[mdwophil]

Application Aware processing is going to require credentials, which will mean NTLMv2

VMware Tools Quiescence should be sufficient to properly back up NTDS via VSS

Sources:
https://helpcenter.veeam.com/docs/backu ... ml?ver=120
https://docs.vmware.com/en/VMware-Live- ... 29C03.html
post433057.html#p433057

[ESXIGuy]

Would the Veeam Persistent Guest Agent solve these problems?

No NTLMv2 authentication required since it runs as Windows system service on backup VMs

Run from current Workgroup Veeam VM not requiring being domain joined

Could I use Veeam Persistent Guest Agent on all my windows VM's?

I need to be sure that if I have to restore it will work without fail and dont want to take a chance on Quiescence

[ESXIGuy]

Or would Pre-installed backup agents be the answer? Or something else?

[mdwophil]

I don't believe those components require authentication once they are installed and configured, but I believe the installation will still require authentication for the initial setup: without authentication, the installer service won't know the B&R console is authorized

This may be a question that you need to take up with support.

Regardless of whether you use the persistent agent (as opposed to "native" VMware Tools VSS snapshots), you still need to test and validate your backups.

[Andreas Neufert]

For Kerberos Authentication you need a domain memebership.
If you force the backup infrastructure to not use NTLM, you need to create a (separate) domain to be able to authenticate.

For the communication with the VMs at backup application-aware processing you can install a guest interaction proxy and let this server be in the domain where the VMs are. That way the system can use NTLM.
I would use the same system then for Explorer based restores and as a mount server for restores when you process data back to the original VMs.

For backup there is the option as described above to enable VMware Tools quiescence in the job and to disable Veeam Applicaiton Aware processing in the same job. Then we would use VMware Tools to create consistency. There is no authentication needed for this. This can be helpful if you want to backup the Active Directory Servers without giving us Administrator Rights.

[Andreas Neufert]

Please check as well this page:
https://helpcenter.veeam.com/docs/backu ... ml?ver=120

[bobcat]

Hi,

I had similar case when I wanted to back up Domain Controllers without using Domain Admin account.

I have created backup jobs for Active Directory Domain Controllers running on Windows Server 2022, using only VMware Tool Quiescence. I chose not to use Application-Aware Processing because I wanted to avoid using the Administrator (Domain Admin) account.

In theory, VMware Tools should be sufficient to quiesce the VM and create an application-consistent backup using VSS. The backup completes successfully, but when I attempt to use it in a SureBackup Job, I encounter the following error: "Unable to perform Domain Controller restore from a crash-consistent backup. Be sure application-aware processing is enabled in the backup job settings."

I use ESXi and vCenter version 8.0 U3. I checked the VMware Tools version (version 12389), and it shouldn't be a problem according to this article: https://knowledge.broadcom.com/external ... st-op.html.

I also checked the VM options, and "disk.EnableUUID = TRUE" is set. Additionally, I verified that the VMware Tools config file does not have "vss.disableAppQuiescing = false" applied.

Based on this, I believe VMware Tools should be capable of creating an application-consistent backup of Active Directory. However, I really need to avoid using the Administrator account. What is your suggestion in this case?
I upload logs later both of the Surebackup and the Backup Job.

This was the support's answer (support case: #07450217):

[Moderator: Replaced Support ID with case number]

As per the requirements to backup DC using Veeam backup, Application-aware image processing option must be enabled in the job properties and the right credential must be provided as well. To avoid using administrator account as an alternative, use gMSA to avoid using admin privileges:-

Please check below documents and let me know if this help you with the required information.
https://bp.veeam.com/vbr/4_Operations/O ... ctory.html
https://www.veeam.com/blog/backing-up-d ... ction.html

So is it possible to have an application-consistent backup using Vmware tools and not using Domain Admin account or gMSA or not?

[HannesK]

Hello,
VMware tools triggered VSS creates an application-consistent backup like any other VSS triggered option (e.g. via Veeam Backup & Replication). To get SureBackup working, the Veeam integrated Application Aware Processing needs to be used. During the SureBackup run, Veeam logs into the machine and that means credentials need to be stored somewhere.

Best regards,
Hannes

[bobcat]

Thank you for your response.

However, I am curious as to why SureBackup generates the error message: "Unable to perform Domain Controller restore from a crash-consistent backup..." This seems somewhat misleading to me.

Please correct me if I am wrong, but as far as I understand, selecting Roles under the Verification options is not mandatory to run a SureBackup job or an On-Demand Sandbox (with the "Keep Application Group Running" option).

So, why would Veeam need to log in to the virtual machine in this case?

As far as I know, SureBackup is designed to automate the testing process, which can also be done manually. For instance, I can manually start a Domain Controller using Instant Recovery on a separate network, without requiring Domain Admin privileges.

Regarding the credentials, they are indeed stored in the credential manager, and I can select them when assigning Roles and configuring test scripts, if needed.

Using a Domain Admin account for backup purposes when other options are available seems like a significant security risk. If I understand correctly, are you suggesting that without Domain Admin access to the domain controllers, SureBackup cannot be used for recovery tests? This would appear to conflict with the "0" part of the 3-2-1-0 rule, as well as the core concept of SureBackup.

[HannesK]

hmm, are you saying you get the error without having "Domain Controller (Authoritative Restore)" or "Domain Controller (Non-Authoritative Restore)" enabled?

Correct, roles are optional. Without roles, there is nothing we do inside the VM.

The error exists because Application Aware Processing was not used. We could change it to "Unable to perform Domain Controller restore from a non Application Aware Processing backup backup.", but you are the first person since 15 years or so with that request...

SureBackup as it is working today requires Application Aware Processing for Domain Controllers, yes.

[bobcat]

I encountered an error with Non-Authoritative Restore enabled, even though I deselected the Test Scripts and did not select the Domain Admin credentials. With these settings, the application-aware processed Domain Controllers were restarted, likely in DSRM, during the SureBackup job.

Additionally, when I used VMware Tools for quiescing, the error occurred regardless of whether I selected credentials or not.

This seems misleading because it’s stated that a VMware Tools quiesced backup is crash-consistent, but it appears that it is not.

[Andreas Neufert]

There are many things that you need to prepare for recovery of an AD and Veeam does automate all the steps within our backup, restore and SureBackup processing.

Yes, VMware Tools quiescence is bringing the AD database in a consistent state, but this is about it.
It does not leave restore awareness flags behing (that the OS is aware of a recovery situation later) and as well it does not allow Veeam to set the correct Authoritative restore flags at restore and surebackup processing.

The error in the SureBackup is basically, that we detect that we can not bring the AD in a state that it can work without issues in the lab and therefore end up with the error/warning messages. The restore awareness flags where not set at backup and therefore we can not interrupt the regular boot process to bring AD in a state that it can work independently in the SureBackup Virutal Lab environment. It might work with the VMware Tools Quiescense-based backup that other services that use AD (like Exchange) would work but there is no guaranty as the correct restore processing for AD was not set. I saw environments taking forever until services like Exchange could be started. In the end SureBackup is there to test your recovery sitaution to the point that everything works correctly to ensure that you restore, but it is not the case with VMware Tools Quescense, so it gives you the warning for it.

At regular restore (when backup happens with the Veeam Guest processing) we set the non-authoritative restore mode of AD automatically to allow this domain controller to correctly sync with the remaining domain controllers to avoid split brain situations.

Yes, you can use VMware Tools Quiescence with AD servers, but you would need to perform all needed AD recovery steps manually (follow Microsoft AD restore guidelines) yourself. You should make yourself familiar anyway with these in case your complete AD forest is completely gone, then you need to restore a server with GC role and set manual the Authoritative Restore mode while booting the server.

Application Aware processing with gMSA is currently the best way of backing up AD servers.