Veritas NetBackup™ Security and Encryption Guide
- Increasing NetBackup security
- Security deployment models
- Port security
- About NetBackup daemons, ports, and communication
- Additional port information for products that interoperate with NetBackup
- About configuring ports
- Auditing NetBackup operations
- Configuring Enhanced Auditing
- Access control security
- NetBackup Access Control Security (NBAC)
- Configuring NetBackup Access Control (NBAC)
- Configuring Access Control host properties for the master and media server
- Access Control host properties dialog for the client
- Troubleshooting Access Management
- Windows verification points
- UNIX verification points
- Verification points in a mixed environment with a UNIX master server
- Verification points in a mixed environment with a Windows master server
- About determining who can access NetBackup
- Viewing specific user permissions for NetBackup user groups
- Security management in NetBackup
- About the Security Management utilities
- About audit events
- About host management
- Adding shared or cluster mappings
- About global security settings
- About host name-based certificates
- About host ID-based certificates
- Using the Certificate Management utility to issue and deploy host ID-based certificates
- About certificate deployment security levels
- Setting up trust with the master server (Certificate Authority)
- About reissuing host ID-based certificates
- About Token Management for host ID-based certificates
- About the host ID-based certificate revocation list
- About revoking host ID-based certificates
- Security certificate deployment in a clustered NetBackup setup
- About deployment of a host ID-based certificate on a clustered NetBackup host
- Data at rest encryption security
- About NetBackup client encryption
- Configuring standard encryption on clients
- About configuring standard encryption from the server
- Configuring legacy encryption on clients
- About configuring legacy encryption from the client
- About configuring legacy encryption from the server
- Additional legacy key file security for UNIX clients
- Data at rest key management
- About the Key Management Service (KMS)
- Installing KMS
- Configuring KMS
- About key groups and key records
- Overview of key record states
- Configuring NetBackup to work with KMS
- About using KMS for encryption
- KMS database constituents
- Command line interface (CLI) commands
- About exporting and importing keys from the KMS database
- Troubleshooting KMS
- Regenerating keys and certificates
- NetBackup web services account
About shared or cluster mapping scenarios
Host ID to host name mappings can be shared across multiple hosts in the following scenarios:
If multiple hosts from different domains use the same host name
In a cluster setup where the same virtual name is used by multiple cluster nodes
However, in a scenario where the associated hosts do not have the same communication status (some are 8.0 or earlier and can communicate insecurely and some are 8.1 or later and communicate securely), communication may fail.
See Add or Remove Host Mappings dialog box.
Consider the following example:
Host1 - abc.secure.domain1.com, version - 8.1, policy - P1
Host2 - abc.insecure.domain2.com, version - 7.7.3, policy - P2
Host1 and Host 2 use the same name - abc - as their host name. Security Administrator adds abc as a shared mapping for Host2.
Insecure communication with 8.0 and earlier hosts is enabled.
See About insecure communication with 8.0 and earlier hosts.
When Host2 initiates communication with another host, the master server validates the communication status of host2 (which is insecure), which is different than Host1 (which is secure). Because both hosts use the same host name, but their communication status do not match, the communication with Host2 fails.
Recommendation - Host2 should be upgraded to 8.1 or later.
Consider the following example:
Host1 - abc.secure.domain1.com, active cluster node, version - 8.1
Host2 - abc.secure.domain1.com, inactive cluster node, version - 8.0
Host1 and Host2 use the same virtual name that is abc. Security Administrator adds abc as a shared or cluster mapping for Host2.
Insecure communication with 8.0 and earlier hosts is enabled.
See About insecure communication with 8.0 and earlier hosts.
Host1 fails over to Host2. The master server validates the communication status of host2 (that is insecure), which is different than Host1 (that is secure). Because communication status for both hosts do not match, the communication with Host2 fails.
Recommendation - Host2 should be upgraded to 8.1.
Workaround - Delete the host ID-to-host name mapping abc for Host1. In case of shared mapping, if the associated hosts do not have the same communication status (secure), communication fails for the host that has insecure communication status.