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
- Configuring user groups
- About defining a user group and users
- 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
- Allowing or disallowing automatic certificate reissue
- 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
Implication of clock skew on certificate validity
When a master server issues a certificate, it determines for how long the certificate will be valid for the host to use. The master server sets the validity of the certificate based on its own time, recording two timestamps: Not before and Not after. The certificate is valid only between these two timestamps.
The clock on the master server and the clock on the host that will receive the certificate should be in sync so that the certificate is valid for as long as is expected, given the timestamps.
The hosts can reside in different time zones, as long as the clock on each host is set to the correct time for that host's timezone. As a general practice, NetBackup recommends using a service such as Network Time Protocol (NTP) to automatically keep all clocks on all hosts in the NetBackup domain synchronized.
If the clocks are not in sync, the difference can result in the following consequences:
If the host clock is ahead of the master server, the validity period of the certificate will be less than expected on that particular host. If the difference is extreme and the clocks vary by more than the certificate's validity period, it is possible that if the master server issued a fresh certificate, it could be treated as expired.
If the host clock is behind the master server, a fresh certificate issued by the master server could be considered as unusable by the host because the host considers the certificate as not yet valid.
To determine whether the master server clock and the host clock are in sync
- Run the following command on the host to determine whether the host clock is in sync with the master server clock:
nbcertcmd -checkClockSkew -server master_server_name
- If the clock skew on the host is causing a problem with the certificate validity, take corrective actions as necessary.
The command returns one of the following results:
If both clocks are in sync, the following displays:
The current host clock is in sync with the master server.
If the current host is behind the master server, the command reports the difference in seconds:
The current host clock is behind the master server by 36 seconds(s).
If the current host is ahead of the master server, the command reports the difference in seconds:
The current host clock is ahead of the master server by 86363 second(s).
If the command is run on the master server, the command skips the check and displays the following:
Specified server is same as the current host. Clock skew check is skipped.