Skip to main content

 

Introduction

In the first of 4 blog posts of this iMigrate Veeam Infrastructure Off Production Domain series], we described the fundamental security reasons behind moving the Veeam infrastructure components OFF Production domain.

 

 

Disclaimer: This is not intended to be a complete Security Best practice reference, nor does it address every possible scenario. A Veeam Solutions Architect can be engaged as needed to assist with VBR Security Best Practices, especially with complex deployments.

 

Setup

 

 

Namespaces:

  • Veeamhol.local (this is the ‘Production domain’)
  • Backupdomain.local (this is the domain in the separate forest, referred to as the ‘Backup Domain’)

The scenario is comprised of the following servers:

  • A Production Domain Controller / DNS server
  • A Backup Domain Controller (with 1-way trust from the Backup Domain to the Production Domain)
  • 2 ESX hosts and 1 vCenter
  • Veeam Backup and Replication server (VBR) with local PostgreSQL database
  • Veeam Enterprise Manager server (VBEM) with local PostgreSQL database
  • Veeam Gateway server
  • Veeam Mount server
  • Veeam ONE server
  • Veeam Proxy server
  • Veeam Recovery Orchestrator server

 

All servers are currently joined to the Production Domain.

 

 

VBR is configured with multiple backup jobs.

 

 

Move VBR from a Production Forest/Domain to a Backup Forest/Domain

In this scenario, like with many existing environments, Veeam components will have been deployed onto the Production Domain. This scenario describes how to better protect the Veeam environment by moving it into a Backup Domain with a one-way trust to the Production Domain.

 

 

Assumptions

  • One-way incoming external trust from the Production Domain to the Backup Domain has been established.

 

 

  • The Backup Domain’s DNS server has been updated with a conditional forwarder to the Production Domain DNS server.

 

 

Order of operations

This is the order in which we need to address the Veeam components for a successful move to a Backup Domain with a one-way trust.

  1. Enterprise Manager server
  2. Veeam Backup and Replication server
  3. All other Veeam components

Enterprise Manager

  • Log into Enterprise Manager Server as a local account Administrator to avoid issues while getting off the Production Domain.
  • Export the Enterprise Manager Keyset and store it in a safe location as per the user guide.

 

 

  • Add the local administrator user as a portal administrator.

 

 

  • Identify and backup the Enterprise Manager Configuration database (see kb1471).

We will use the DBconfig utility.

 

 

  • Stop all Veeam Services.

 

 

  • Backup the Enterprise Manager database using pgdump from an elevated powershell console to the directory of your choice.

& "C:\Program Files\PostgreSQL\15\BIN\pg_dump.exe" -U postgres -F c -b -f "C:\BACKUPS\VBEM DB BACKUP\PGDBBackup_$($env:computername)_$(get-date -f yyyy-MM-dd_HH.mm).sql" VeeamBackupReporting

 

 

  • Remove the Enterprise Manager server from the Production Domain and reboot.

 

 

  • Ensure that the Enterprise Manager server was properly removed from the Production Domain.
  • Change your DNS to the Backup Domain DNS and join the Backup Domain.
  • Validate that you can still connect to the database with DBconfig.

Note: If you run into a “SSPI authentication failed for user” then modify the pg_ident.conf with the Backup Domain’s account used to log in.

For instance, you can add the local administrator used to login to Enterprise Manager to pg_ident.conf (see kb4542).

 

 

  • Edit the following registry keys with Enterprise Manager’s new FQDN.

HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup Reporting\EnterpriseServerName

HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup Reporting\XMLURL

  • Note that HTTP access works but the certificate must be fixed to enable HTTPS access (see kb1168).
  • Make sure to add a Backup Domain user as a portal administrator. Remove Production Domain accounts and groups.
  • Note that VBR is disconnected.

 

 

To reinstate the connection to the VBR server one can:

  • After joining the Backup Domain, add a static DNS entry on the Production DNS server and update every Veeam Server’s primary DNS suffix to match the Production Domain.

Note: Alternatively, DNS can be handled with local hosts files (more cumbersome).

  • Edit the connection by using VBR local administrator credentials.
  • Note that the connection vCenter is broken. Follow similar DNS steps to fix the connection.

Veeam Backup and Replication

  • Add the VBR local admin as a Veeam Backup Administrator (BUILTIN\Administrators group is not enough)

 

 

  • Wait for all jobs to complete.
  • Backup the Veeam Backup and Replication server config. Make sure encryption is enabled.

 

 

  • Disable running jobs (CDP, T-Logs, BCJ …) and close the console.
  • Remove Veeam Backup and Replication server from the Production Domain and reboot.

 

 

  • Ensure that the Veeam Backup and Replication server was properly removed from the Production Domain.
  • Change your DNS to the backup domain DNS and join the backup domain.
  • Add a static DNS entry for Veeam Backup and Replication on the Production Domain DNS.

 

Domain joined CDP Proxy

  • After joining the Backup Domain, add a static DNS entry on the Production DNS server.
  • Under Managed Server, update the CDP proxy credentials.
  • Note that the I/O filters are still managed by VBR registered with the Production FQDN.

 

 

 

 

​​​​​​​App-Aware Backups and Domain joined Guest Interaction Proxy

Leave the Guest Interaction Proxy on the Production Domain as stated in the Veeam documentation in order for Application-Aware backups to function properly.

If the Guest Interaction Proxy is removed for the Production Domain, Veeam will fail to inject the necessary runtimes and Application Aware backups will fail.

 

 

Domain joined Proxy

  • Remove the proxy from the Production Domain and ensure that the server has been removed from the Production Domain AD.
  • Point the proxy’s DNS to the Backup Domain DNS and join the backup domain.
  • Note that the proxy is no longer available.

 

 

  • Ensure proper DNS resolution by either updating the local hosts file on all Veeam Servers or by adding a static entry on your Production Domain’s DNS. Adding DNS suffix is also recommended.
  • Update the proxy server’s credentials using a Backup domain service account (or local account).

 

 

​​​​​​​Domain joined Gateway or Repository

  • Remove the proxy from the Production Domain and ensure that the server has been removed from the Production Domain AD.
  • Point the proxy’s DNS to the Backup Domain DNS and join the backup domain.
  • Note that the server is no longer available.
  • Ensure proper DNS resolution by either updating the local hosts file on all Veeam Servers or by adding a static entry on your Production Domain’s DNS. Adding DNS suffix is also recommended.
  • Update the server’s credentials using a Backup domain service account (or local account).

 

Summary

In this blog post, we provided detailed step by step instructions to Migrate the Veeam Infrastructure OFF the Production Domain onto a Backup Domain with a one-way trust.

This provides the best approach to security domain separation.

This concludes our hMigrate Veeam Infrastructure Off Production Domain series].

Great conclusion to the series.  😎👍


The whole series was pretty detailed and thorough Olivier. Thanks for posting them. 🙌🏻


Merci @olivier.rossi for this complete guide.


Thank you for the guide @olivier.rossi 👍🏻

I didn't understand if post migration completed, the trust is not removed?

I attach a supplementary link for securing (Hardening Active Directory) the management domain dedicated to veeam from my blog to complete your series.

Hardening Active Directory - GPO MSCT 1.0 CIS Benchmark - Poicy Analyser | Veeam Community Resource Hub


Thanks for sharing @olivier.rossi  can I make one suggestion though? Please try to avoid the use of .local as a domain extension because of the following reasons - 

 


Thanks for sharing @olivier.rossi  can I make one suggestion though? Please try to avoid the use of .local as a domain extension because of the following reasons - 

 

This was a great article as well for domain implementation. 👍


Above and beyond @olivier.rossi! Cheers


Thanks for sharing @olivier.rossi  can I make one suggestion though? Please try to avoid the use of .local as a domain extension because of the following reasons - 

 

For those who wish to Perform Active Directory Rename, I have a blog post here: 

 


Thanks for sharing @olivier.rossi  can I make one suggestion though? Please try to avoid the use of .local as a domain extension because of the following reasons - 

 

For those who wish to Perform Active Directory Rename, I have a blog post here: 

 

This rename one is great too. 👍


Comment