Veritas NetBackup™ Read This First Guide for Secure Communications
- NetBackup Read This First for Secure Communications
- About secure communications in NetBackup
- How host ID-based certificates are deployed during installation
- How certificates are deployed on hosts during upgrades
- How secure communication works with master server cluster nodes
- When an authorization token is required during certificate deployment
- Why do you need to map host names (or IP addresses) to host IDs
- How to reset host attributes or host communication status
- What has changed for catalog recovery
- What has changed with Auto Image Replication
- How the hosts with revoked certificates work
- How communication happens when a host cannot directly connect to the master server
- Are security certificates backed up
- How communication with legacy media servers happens in the case of cloud configuration
- How NetBackup 8.1 hosts communicate with NetBackup 8.0 and earlier hosts
- Communication failure scenarios
- Secure communication support for other hosts in NetBackup domain
Why do you need to map host names (or IP addresses) to host IDs
Hosts can be referenced with multiple names.
For example: In the case of multiple network interfaces or if hosts are referenced by both short names and Fully Qualified Domain Names (FQDN).
For successful secure communication in NetBackup 8.1, you should map all associated host names to the respective host ID. The NetBackup-configured client name of a host (or the primary name) is automatically mapped to its host ID during certificate deployment. Additional host names are discovered during communication and may be automatically mapped to the respective host ID or may appear in the Mappings for Approval list. Perform this configuration in the Host Management properties on the master server.
For more information on host ID-to-host name mappings, refer to the NetBackup Security and Encryption Guide.
Examples of configurations that have multiple host names include:
If you have multiple network interfaces, a host has both a public and a private host name.
A host can have a short name and a fully qualified domain name (FQDN).
A host can be associated with its IP address.
For a file system or database that is clustered, a host is associated with its node name and the virtual name of the cluster.
Note the following:
The Exchange, SharePoint, and SQL Server agents also require that you configure host information in the Distributed Application Restore Mapping host properties on the master server.
For highly available environments, the SQL Server agent no longer requires a second policy that contains the cluster or AG node names. You also do not need to configure permissions for redirected restores for the cluster or AG nodes. For successful backups and restores of a SQL Server cluster or AG, you need only configure the mappings in the Host Management properties and the Distributed Application Restore Mapping host properties.
The following diagram illustrates the host ID-to-host name mapping process:
Host name-to-host ID mapping occurs in the following order:
The FQDN of Host 2 is mapped to its host ID during certificate deployment.
Host 1 initiates a secure connection to Host 2 using the short name. Both hosts exchange their host ID-based certificates as part of the TLS handshake.
Host 1 sends the host ID and short name of Host 2 to the master server for validation.
The master server looks up the host ID and the short name in its database. Since the provided short host name is not already mapped to the host ID of Host 2, one of the following occurs:
If the option in the NetBackup Administration Console is selected and the short name is not already mapped to another host ID, the discovered short name is automatically mapped to the host ID of Host 2, and Host 1 is instructed to continue the connection.
If the option is not selected or the short name is already mapped to another host ID, the discovered mapping is added to the pending approval list and Host 1 is instructed to drop the connection. The mapping should be manually approved before any connections to Host 2 using the same short name can succeed.
Connection is established between the hosts if the mapping is approved. If the mapping is not approved, the connection is dropped.