290226

Veritas NetBackup
Security and Encryption Guide
UNIX, Windows, Linux
Release 6.5
12308344
Veritas NetBackup Security and Encryption Guide
Copyright 2007 Symantec Corporation. All rights reserved. NetBackup 6.5 Symantec, the Symantec logo, and NetBackup are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners. Portions of this software are derived from the RSA Data Security, Inc. MD5 MessageDigest Algorithm. Copyright 1991-92, RSA Data Security, Inc. Created 1991. All rights reserved. The product described in this document is distributed under licenses restricting its use, copying, distribution, and decompilation/reverse engineering. No part of this document may be reproduced in any form by any means without prior written authorization of Symantec Corporation and its licensors, if any. THIS DOCUMENTATION IS PROVIDED AS IS AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO BE LEGALLY INVALID, SYMANTEC CORPORATION SHALL NOT BE LIABLE FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS DOCUMENTATION. THE INFORMATION CONTAINED IN THIS DOCUMENTATION IS SUBJECT TO CHANGE WITHOUT NOTICE. The Licensed Software and Documentation are deemed to be commercial computer software and commercial computer software documentation as defined in FAR Sections 12.212 and DFARS Section 227.7202. Symantec Corporation
20330 Stevens Creek Blvd.
Cupertino, CA 95014
www.symantec.com Printed in the United States of America. Third-party legal notices
Third-party software may be recommended, distributed, embedded, or bundled with this Veritas product. Such third-party software is licensed separately by its copyright holder. All third-party copyrights associated with this product are listed in the accompanying release notes.
AIX is a registered trademark of IBM Corporation. HP-UX is a registered trademark of Hewlett-Packard Development Company, L.P.
Linux is a registered trademark of Linus Torvalds.
Solaris is a trademark of Sun Microsystems, Inc.
Windows is a registered trademark of Microsoft Corporation.
Oracle is a registered trademark of Oracle Corporation.
Licensing and registration

Veritas NetBackup is a licensed product. See the NetBackup Installation Guide for license installation instructions.
Technical support
For technical assistance, visit http://support.veritas.com and select phone or email support. Use the Knowledge Base search feature to access resources such as TechNotes, product alerts, software downloads, hardware compatibility lists, and our customer email notification service.
Contents
Chapter 1
Increasing NetBackup security

NetBackup security implementation levels .....................................................14
World level ....................................................................................................14
Enterprise level ............................................................................................15
Data center level ..........................................................................................16
Combined world, enterprise, and data center levels ..............................23
NetBackup security implementation types ......................................................25
Operating system security ..................................................................................26
NetBackup security vulnerabilities ...................................................................27
Standard NetBackup security ............................................................................28
MSEO (Media Server Encryption Option) security .........................................29
Client side encryption security ..........................................................................30
NBAC on master, media server, and GUI security ..........................................31
NBAC complete security .....................................................................................32
All NetBackup security ........................................................................................33
Chapter 2
Security deployment models

Workgroups ..........................................................................................................36
Single data centers ..............................................................................................36
Multi-data centers ...............................................................................................36
Workgroup with NetBackup ...............................................................................36
Highlights ......................................................................................................37
NetBackup parts for workgroup ................................................................37
Single data center with standard NetBackup ..................................................41
Highlights ......................................................................................................41
NetBackup parts for single data center with standard NetBackup ......41
Single data center with Media Server Encryption Option (MSEO) ..............44
Highlights ......................................................................................................44
NetBackup parts for single data center with MSEO ...............................46
Single data center with client side encryption ................................................48
Highlights ......................................................................................................48
NetBackup parts for single data center with client side encryption ...50
Single data center with NBAC on master and media servers ........................52
Highlights ......................................................................................................52
NetBackup parts for single data center with NBAC on master
6 Contents
and media servers ................................................................................ 54

Single data center with NBAC complete .......................................................... 57
Highlights ..................................................................................................... 57
NetBackup parts for single data center with NBAC complete .............. 59
Single data center with all security implemented .......................................... 62
Highlights ..................................................................................................... 62
NetBackup parts for single data center with all security
implemented ......................................................................................... 64
Multi-data center with standard NetBackup ................................................... 67
Highlights ..................................................................................................... 67
NetBackup parts for multi-data center with standard NetBackup ...... 69
Multi-data center with Media Server Encryption Option (MSEO) ............... 71
Highlights ..................................................................................................... 71
NetBackup parts for multi-data center with MSEO ............................... 73
Multi-data center with client side encryption ................................................ 77
Highlights ..................................................................................................... 77
NetBackup parts for multi-data center with client side encryption .... 79
Multi-data center with NBAC on master and media servers ........................ 84
Highlights ..................................................................................................... 84
NetBackup parts for multi-data center with NBAC on master
and media servers ................................................................................ 86
Multi-data center with NBAC complete ........................................................... 91
Highlights ..................................................................................................... 91
NetBackup parts for multi-data center with NBAC complete ............... 93
Multi-data center with all NetBackup security ............................................... 98
Highlights ..................................................................................................... 98
NetBackup parts for multi-data center with all security ..................... 100
Chapter 3
Port security
Ports in general .................................................................................................. 108
Reserved ports ............................................................................................ 108
Non-reserved ports .................................................................................... 108
NetBackup ports ................................................................................................ 108
Call-back ...................................................................................................... 108
Registered ports ......................................................................................... 109
Dynamically allocated ports .................................................................... 109
Overriding or modifying port numbers .................................................. 109
Default NetBackup ports .................................................................................. 109
Default 6.5 NetBackup ports .................................................................... 110
Default port numbers for NetBackup 6.5 ............................................... 110
Master server outgoing ports list .................................................................... 112
Media server ports list ...................................................................................... 115
EMM server ports list ........................................................................................ 117
Contents
Client outgoing ports list ..................................................................................120

Netware client outgoing ports list ...................................................................122
Windows admin console or Java server outgoing ports list ........................124
Java console outgoing ports list .......................................................................126
Configuring ports ...............................................................................................127
Accept connections from non-reserved ports ...............................................127
Using random port assignments .....................................................................129
Random port assignments in the NetBackup configuration ...............129
Random port assignments in the media manager configuration .......129
Firewall connection options on a NetBackup server or client ....................130
Ports .............................................................................................................131
BPCD connect-back ....................................................................................132
Daemon connection port ..........................................................................132
Firewall connection options on media manager ...........................................134
Specifying NetBackup-Java connection options ...........................................135
Client attributes .................................................................................................135
Specifying ports (reserved or non-reserved) .........................................136
Specifying a BPCD connect-back method ..............................................138
Specifying a Daemon connection port ....................................................139
Specifying port ranges ......................................................................................141
Miscellaneous port numbers ............................................................................143
BPJAVA_PORT and VNETD_PORT ..........................................................143
BPCD and BPRD ports ...............................................................................143
ICM port usage ...................................................................................................144
Windows system administration console ..............................................144
NDMP port usage ...............................................................................................145
ICMP pinging NDMP ..................................................................................145
NDMP in a firewall environment .............................................................145
Media Manager port usage ...............................................................................146
ACS storage server interface ....................................................................146
Additional Media manager port information ........................................146
Configuring port usage without a GUI ...................................................147
Port usage settings in NetBackup configuration - bp.conf ..........................148
Port usage-related NetBackup configuration settings .........................148
Configuring port usage client attribute settings - bpclient .........................153
bpclient -client name -update -connect_options 0|1|2 0|1|2 0|1|2|3 ...153
Port usage settings in Media Manager configuration - vm.conf ........155
RANDOM_PORTS = YES | NO ...................................................................155
CLIENT_PORT_WINDOW = min max .....................................................156
CONNECT_OPTIONS = host 0 0 0|1|2 ......................................................156
Chapter 4
Access control security

Access management administration ..............................................................160
8 Contents
Access management components ................................................................... 160

Symantec Product Authentication and Authorization
components ........................................................................................ 160
Root broker ................................................................................................. 161
Authentication broker .............................................................................. 161
Security administrator .............................................................................. 162
NBAC installation and configuration ............................................................. 163
NBAC installation sequence ..................................................................... 163
NBAC quick configuration sequences .................................................... 163
NBAC upgrade ............................................................................................ 168
Including authentication and authorization databases in
the NetBackup catalog backup ......................................................... 168
Symantec Product Authentication and Authorization component
distribution ......................................................................................... 169
Installing and configuring access control on master servers ............. 171
Installing and configuring access control on media servers .............. 174
Installing and configuring access control on clients ........................... 177
Establishing a trust relationship between the broker and the
Windows remote console .................................................................. 179
Installing the authentication service root broker ................................ 180
Configuring authentication for use by NetBackup ............................... 180
Installing the authorization server ......................................................... 181
Configuring access control host properties ........................................... 183
Client host properties ............................................................................... 189
Access management troubleshooting guidelines ......................................... 192
Windows verification points .................................................................... 192
UNIX verification points ........................................................................... 199
Verification points in a mixed environment with a UNIX
master server ...................................................................................... 206
Client verification points for mixed UNIX master ............................... 209
Verification points in a mixed environment with a Windows
master server ...................................................................................... 210
Other troubleshooting topics ................................................................... 214
Using the access management utility ............................................................ 218
Determining who can access NetBackup ....................................................... 219
Individual users ......................................................................................... 220
User groups ................................................................................................. 222
User group configuration ......................................................................... 224
Defining user groups and users ............................................................... 228
Permissions for NetBackup user groups ........................................................ 232
Authorization objects ................................................................................ 232
Media permissions ..................................................................................... 233
Policy permissions ..................................................................................... 234
Contents
Drive permissions ......................................................................................234

Report permissions ....................................................................................235
NBU_Catalog permissions ........................................................................235
Robot permissions .....................................................................................236
StorageUnit permissions ..........................................................................236
DiskPool permissions ................................................................................237
BUAndRest permissions ...........................................................................237
Job permissions ..........................................................................................238
Service permissions ...................................................................................239
HostProperties permissions .....................................................................240
License permissions ...................................................................................240
VolumeGroup permissions .......................................................................241
VolumePool permissions ..........................................................................241
DevHost permissions .................................................................................242
Security permissions .................................................................................242
FT Server permissions ..............................................................................243
FT Client permissions ................................................................................243
Vault permissions ......................................................................................244
ServerGroup permissions .........................................................................244
Chapter 5
Data at rest encryption security

Data at rest encryption terminology ..............................................................246
Asynchronous encryption ........................................................................246
Synchronous encryption ..........................................................................246
Initialization vector ...................................................................................246
Advanced Encryption Standard (AES) ....................................................246
Data Encryption Standard (DES) .............................................................246
Public Key Encryption ...............................................................................246
What data at rest encryption can and cannot do ..........................................247
Computer performance impact of data encryption ..............................247
Data compression must be performed prior to data encryption ........247
Choice of an encryption algorithm .........................................................247
AES became the standard .........................................................................247
Suggested key size .....................................................................................248
NIST FIPS 140 .............................................................................................248
FIPS certification for my encryption solution ......................................248
Appropriate encryption key granularity ................................................249
Encryption security questions to consider ....................................................249
NetBackup data at rest encryption solutions ................................................249
Encryption options compared ..................................................................250
Option 1 - NetBackup client encryption .........................................................251
Running an encryption backup ...............................................................251
NetBackup encryption restore .................................................................254
10 Contents
Installing encryption security ......................................................................... 256

Installation prerequisites ......................................................................... 256
Installing encryption on a UNIX NetBackup server ............................. 256
Installing encryption on a Windows NetBackup server ...................... 257
Push installing from the NetBackup master server to a client ........... 258
Installing encryption locally on a NetBackup Windows client ........... 258
Installing encryption locally on a NetBackup UNIX client ................. 258
Configuring encryption security ..................................................................... 259
Configuring standard encryption ........................................................... 259
Configuring standard encryption from the server ............................... 260
Pushing standard encryption software to NetBackup clients ............ 260
Creating the NetBackup encryption keyfile on the clients ................. 261
Configuring NetBackup encryption on clients .............................................. 263
Managing NetBackup encryption configuration options .................... 263
Managing NetBackup encryption keyfile ............................................... 264
Redirected restores of encrypted files .................................................... 265
Setting the encryption attribute in policies .................................................. 266
Changing client encryption settings from the server .................................. 266
Configuration for standard encryption .......................................................... 267
Configuring from the server ............................................................................ 267
Pushing standard encryption software to clients ................................. 267
Creating encryption keyfiles on clients ................................................. 269
Configuring encryption on clients .................................................................. 271
Managing encryption configuration options ........................................ 271
Managing the NetBackup encryption keyfile ........................................ 272
Setting the encryption attribute in policies .................................................. 273
Changing client encryption settings from the server .................................. 273
Configuration for legacy encryption .............................................................. 274
Configuring legacy encryption from the server ........................................... 274
When clients have not been previously configured ............................. 275
Pushing legacy encryption software to clients ..................................... 275
Pushing legacy encryption configuration to clients ............................ 276
Pushing legacy encryption pass phrases to clients .............................. 277
Configuring legacy encryption on clients ...................................................... 278
Managing legacy encryption configuration options ............................ 278
Managing legacy encryption keyfiles ..................................................... 279
Redirected restores of legacy encrypted files ....................................... 281
Setting legacy encryption attribute in policies ............................................. 282
Changing client legacy encryption settings from the server ...................... 282
Additional legacy keyfile security for UNIX clients ..................................... 283
Running bpcd as a stand-alone program ............................................... 284
Terminating bpcd ...................................................................................... 285
Option 2 - Media server encryption ................................................................ 285
Contents
11
Media server encryption administration ...............................................285

Option 3 - Third party encryption appliances and hardware devices .......286
Index
287
12
Contents
Chapter
Increasing NetBackup security

The purpose of this chapter is to provide insight into increasing NetBackup security through each of the following:

NetBackup security implementation levels on page 14

NetBackup security implementation types on page 25
Operating system security on page 26
Standard NetBackup security on page 28
MSEO (Media Server Encryption Option) security on page 29
Client side encryption security on page 30
NBAC on master, media server, and GUI security on page 31
NBAC complete security on page 32
All NetBackup security on page 33
14 Increasing NetBackup security NetBackup security implementation levels
NetBackup security implementation levels
The NetBackup security happens at the following levels:

World level - web server access and encrypted tapes transported and vaulted Enterprise level - internal users and security administrators Data center level - NetBackup operations
The NetBackup security implementation perspective begins in a very broad sense at the world level. Security become more tangible at the enterprise level. Ultimately, security becomes very specific at the data center level.
World level
The world level, shown in Figure 1-1 on page 14, is the broadest part of NetBackup security implementation. At the world level external users can access corporate web servers behind firewalls. At the world level encrypted tapes can be transported and vaulted off-site. The world level encompasses the enterprise level and data center level and includes the following world level items. Figure 1-1 World level
Increasing NetBackup security NetBackup security implementation levels
15
External users
External users can access web servers behind firewalls. External users cannot access or use NetBackup functionality from the Internet as the external firewall prevents NetBackup ports from being accessed.
Internet
The Internet is a collection of interconnected computer networks, linked by copper wires, fibre cables, and wireless connections. Corporate web servers can be accessed from the Internet using http ports through firewalls.
WAN
The Wide Area Network (WAN) is not shown in the security overview illustration. The WAN is a dedicated high speed connection used to link NetBackup data centers that are geographically distributed.
Transport
The transport truck moves encrypted client tapes off-site to a secure vault facilities.
Vault off-site
Vaults provide safe encrypted tape storage facilities off-site at a different location than the current data center.
Enterprise level
The enterprise level, shown in Figure 1-2 on page 16, encompasses internal users, security administrators and the data center level. The enterprise level contains more tangible parts of NetBackup security implementation, and includes the following enterprise level items.
Figure 1-2
Enterprise level
Internal users
Internal users are those people who have permissions to access and use NetBackup functionality from within the data center. Internal users are typically a combination of individuals such as DBAs, backup administrators, operators, and general system users
Security administrator
The security administrator is a user who has been granted administrator permissions to access and manage the NetBackup security functionality from within the data center.
Data center level

The data center level, shown in Figure 1-3 on page 18 is where the core of NetBackup security functionality occurs. The data center can consist of a work group, single data center, or multi-data center as described below.

Workgroup - A workgroup is classified as a small group of systems (less than 50) used with NetBackup in a wholly internal fashion. Single data center - A single data center is defined as a medium to large group of hosts (greater than 50) and can back up hosts within the DMZ.
17
Multi-data center - A multi-data center is defined as a medium to large group of hosts (greater than 50) that span two or more geographic regions and are connected by a Wide Area Network (WAN). This configuration can also include hosts in the DMZ that will be backed up.
NetBackup security parts

It is at this workgroup, single data center, or multi-data center level where the specifics of NetBackup security play out. NetBackup provides basic security protection that is indicated in the following points.

Relying on the minor security of bpjava Relying on operating system file system user security Changing the default EMM database password Using proper file permissions Stopping casual access to system data through NetBackup command line and attempted raw file system access Requires the administrator privileged escalator or SUDO (superuser do) to use NetBackup NBAC is considered to be more advanced. To maintain the highest level of security protection, NetBackup needs to be kept current at proper security patch level. Patching to the most recent patch level of your supported version of NetBackup
The individual NetBackup parts containing security include master server security, media server security, and client security as described in the following paragraphs.
Master server security

NetBackup master servers can be made more secure by adding product security, including Symantec authentication and authorization service, client encryption option for physical tape safety, and operating system security.
Media server security

NetBackup media servers can be made more secure by adding operating system security to the hardware machine the clients are using and product security including Symantec authentication and authorization service.
Client security
NetBackup clients can be made more secure by adding product security including Symantec authentication and authorization service, client encryption option, and operating system security. Figure 1-3 Data center level
NetBackup access control (NBAC)

NBAC functionality incorporates into NetBackup the Symantec product authenticating and authorization which can increase security for the master servers, media servers, and clients. For more information on authentication and authorization refer to Access control security on page 159.

It is important to use authentication and authorization together NBAC uses authentication identities from a trusted source to reliably identify involved parties. Access decisions can then be made for manipulation of NetBackup based on those identities. Additional components are required from your Symantec Product Authentication and Authorization install kit on the ICS install disk(s). Symantec product authentication and authorization consists of the root broker, authentication broker, authorization engine, and GUI.
19
Root broker
There is only one root broker required in a data center installation. Sometimes the root broker is combined with the authentication broker. In this example (Figure 1-3) the root broker and authentication broker are shown as the same component. The root broker authenticates the authentication broker. The root broker does not authenticate clients.
Authentication broker
The authentication broker authenticates the master server, media server, GUI and clients by establishing credentials with each. The authentication broker also authenticates a user when using a command prompt. There can be more than one authentication broker in a data center installation. The authentication broker can be combined with the root broker.
Authorization engine
The authorization engine communicates with the master server and media server to determine permissions of an authenticated user. These permissions determine the functionality available to a given server. The authorization engine also stores user groups and permissions. There is only one authorization engine required in a data center installation. The authorization engine also communicates over the WAN to authorize other media servers in a multi-data center environment.
GUI
The GUI is a remote administration console that can receive credentials from the authentication brokers. The GUI then may use the credentials to gain access to functionality on the clients, media and master servers.
MSEO
The MSEO (Media Server Encryption Option) is a hardware appliance that connects to the media server and provides client data encryption. The MSEO is an alternative to client side encryption that can free up CPU processing power on the client.
NetBackup administrator
The NetBackup administrator is a user who has been granted administrator permissions to access and manage NetBackup functionality from within the data center.
Master server
The master server communicates with the root broker and authentication broker, GUI, authorization engine, media server, and clients.
Media server
The media server communicates with the master server, root broker and authentication broker, authorization engine, MSEO, and clients 1 through 6. The media server writes unencrypted data to tape for client 5 and encrypted data to tape for client 6.
Clients
Clients 1 through 4 are standard NetBackup type. Client 5 is a web server type located in the DMZ. Client 6 is a client side encrypted type also located in the DMZ. All client types are managed by the master server and have their data backed up to tape through the media server. Clients 5 and 6 communicate to NetBackup using NetBackup only ports through the internal firewall. Client 5 also receives connections from the Internet using http only ports through the external firewall.
Tapes
The tape security in NetBackup can be increased by adding the following:

Client side encryption MSEO (Media Server Encryption Option) Encryption of data at rest
Unencrypted and encrypted data tapes are produced in the data center. The unencrypted tape data is written for clients 1 through 5 and stored on-site at the data center. The encrypted tapes are written for client 6 and are transported off-site to a vault for disaster recovery protection.
Encryption
For more information on encryption refer to Data at rest encryption security on page 245. The encryption part of NetBackup can increase security by:

Ensuring data confidentiality The loss of physical tape is not as critical if all the data is effectively encrypted Determine what is the best risk mitigation tactic
21
Data over the wire security

Data over the wire security includes communication between master servers, media servers, clients and communication using ports through firewalls and over WANs. For more information on ports refer to Port security on page 107. The data over the wire part of NetBackup can help increase security in the following ways.

NetBackup Access Control (NBAC) Classic NetBackup daemons employ authentication when NBAC is enabled CORBA daemons use fully encrypted channels, supporting confidentiality and data integrity Firewalls Disabling the unused ports (see port chapter) in NetBackup and in other products PBX and VNETD dedicated ports provide increased NetBackup security Central set of ports to monitor and open through firewalls
Firewall security
The firewall support part of NetBackup can help increase security. Firewalls can include internal firewalls and external firewalls (Figure 1-4).

Symantec recommends the use of firewall and intrusion detection protection for NetBackup Firewall protection relates to general network security from a NetBackup standpoint. It focuses on reducing the possible door locks for a thief to try and pick. It might make sense to review the possibility of blocking NFS, telnet, FTP, email, etc., ports. They are not strictly needed for NetBackup use and could provide an open door for unwanted access. Secure the master server as much as possible
Internal firewall
The internal firewall allows NetBackup to access web server client 5 and encrypted client 6 in the DMZ. Only selected NetBackup ports and possibly other application ports are enabled for data communication through the internal firewall and into and out of the DMZ. Other ports, such as http, that are open in the External Firewall are not allowed to pass through the internal firewall.
External firewall
The external firewall allows external users to access the web server client 5 located in the DMZ from the Internet over http ports. NetBackup ports are open
for web server client 5 to communicate through the internal firewall to NetBackup. The NetBackup ports are not allowed to pass through the external firewall to the Internet. Only the http ports of web server client 5 can pass through the external firewall to the Internet.
Demilitarized zone (DMZ)

The Demilitarized zone (DMZ) support part of NetBackup can help increase security.

The de-militarized zone (DMZ) is a restricted area in which the number of ports that are allowed for specific hosts is highly controlled The DMZ (Figure 1-4) exists between the external firewall and the internal firewall. The common area in this example is the web server. The external firewall blocks all ports except for the http (standard) and https (secure) web ports. The internal firewall blocks all ports except for NetBackup and database ports. The DMZ eliminates the possibility of external Internet access to internal NetBackup server and database information.
The DMZ provides a safe area of operation for the web server client 5 and encrypted client 6 that exist between the internal firewall and external firewall. The web server client 5 in the DMZ can communicate to NetBackup through the internal firewall using designated NetBackup ports. The web server client 5 can also communicate through the external firewall to the Internet using only http ports.
23
Figure 1-4
Example firewalls and DMZ
Combined world, enterprise, and data center levels

The combined world, enterprise, and data center levels model, shown in Figure 1-5 on page 24, is the area where typical full functioning NetBackup operations occur. Through the outer most world level, external users can access corporate web servers behind firewalls and encrypted tapes are transported and vaulted off-site. At the next level deeper, the enterprise level, functions related to internal users, security administrators, and the data center level occur. At the deepest level, the data center level, the core NetBackup security functionality occurs through a work group, single data center, or multi-data center.
24 Increasing NetBackup security

NetBackup security implementation levels
Figure 1-5
Combined world, enterprise, and data level
Increasing NetBackup security NetBackup security implementation types
25
NetBackup security implementation types

Table 1-1 shows the NetBackup security implementation types, characteristics, complexity, and potential security deployment models. Table 1-1 Security implementation types Complexity
Variable
Security implementation type Characteristics

Operating system security on page 26


Workgroup Single data center Multi-data center
Operating system dependent Varies based on system components Administer as root or administrator Data is not encrypted
Standard NetBackup security on page 28
Low
Workgroup with NetBackup on page 36 Single data center with standard NetBackup on page 41 Multi-data center with standard NetBackup on page 67
MSEO (Media Server Encryption Option) security on page 29
Media server encryption Client to media server traffic is not encrypted May impact CPU performance on the media server Location of keys Data is encrypted on the client Encrypted data is sent over the wire May impact CPU performance on the client Location of keys
Low
Single data center with Media Server Encryption Option (MSEO) on page 44 Multi-data center with Media Server Encryption Option (MSEO) on page 71
Client side encryption security on page 30
Medium
Single data center with client side encryption on page 48 Multi-data center with client side encryption on page 77
NBAC on master, media server, and GUI security on page 31
NBAC gives authorization Medium when accessing master and media servers Authenticates the system and users when accessing master and media servers
Single data center with NBAC on master and media servers on page 52 Multi-data center with NBAC on master and media servers on page 84
26 Increasing NetBackup security

Operating system security
Table 1-1
Security implementation types Complexity Security deployment models

Single data center with NBAC complete on page 57 Multi-data center with NBAC complete on page 91
Security implementation type Characteristics

NBAC complete security on page 32

NBAC gives authorization High throughout the system NBAC gives authentication throughout the entire system (servers, clients, and users) Very High Incorporates all NetBackup security types The example diagrams and documentation employ all security mechanisms together
All NetBackup security on page 33
Single data center with all security implemented on page 62 Multi-data center with all NetBackup security on page 98
Operating system security

Operating system security can be enhanced for master servers, media servers, and clients by doing the following.

Installing operating system patches Operating system patches include those upgrades and patches that are applied to the OS to keep it running at the highest level of system integrity. It is important to keep the upgrades and patches at the level specified by the vendor. Following safe firewall procedures Employing least privilege administration Limiting root users Using security protocol over IP (IPSEC) hardware Turning off unused ports of the outward facing applications Providing a secure base on which to run NetBackup Adding a first line of intelligence in an investigation to determine if the operating system has been compromised Making sure security implementation is the same for all operating systems Adding full interoperability between various systems using NBAC in a heterogenic environment
Increasing NetBackup security NetBackup security vulnerabilities
27
NetBackup security vulnerabilities
Symantec suggests that the following protective measures are in place to guard against the rare instance of a possible NetBackup security vulnerability.

A full NetBackup update is provided with the next NetBackup maintenance patch The importance of accumulative NetBackup updates Use the Symantec web site for information on possible security vulnerability issues: www.symantec.com/avcenter/security/SymantecAdvisories.html, or www.symantec.com/security Use email contacts for possible security vulnerability issues: secure@symantec.com
28 Increasing NetBackup security Standard NetBackup security
Standard NetBackup security
The standard NetBackup security only includes that security offered by the operating system and hardware components used. The authorized NetBackup users administer as root or administrator. Client data is not encrypted. The master server, media server, and client are all run within a local enterprise data center. Unencrypted data is usually stored on site presenting a relatively high risk for no disaster recovery plan. Data sent off-site could be subject to a breech of confidentiality if it is intercepted. Figure 1-6 Standard NetBackup
Increasing NetBackup security MSEO (Media Server Encryption Option) security
29
MSEO (Media Server Encryption Option) security
The media server encryption option (MSEO) security type provides a client level data encryption solution. Encrypted tape data is transported and stored in a vault off site lowering data loss risk in a total disaster recovery scenario. The master server, media server, MSEO, and client are all run within a local enterprise data center.The MSEO can relieve CPU intensive operations on the individual clients (comparing MSEO to client side encryption) by moving encryption operations to the media server. However, MSEO can impact CPU performance on the media server. The MSEO to tape traffic is encrypted. Client to media server traffic is not encrypted. It is important to keep the keys on the MSEO device so that encrypted data can be future accessed. Figure 1-7 Media server encryption option (MSEO)
30 Increasing NetBackup security Client side encryption security
Client side encryption security
Client side encryption security is used to ensure data confidentiality across the wire as well as on tape. This helps to mitigate the risk of passive wire tapping within the organization and the risk of data exposure as the tapes are moved off site. The encryption key is located on the client. Data communication over the wire between the client and media server is encrypted. Data encryption by the client can be CPU intensive. Figure 1-8 Client side encryption
Increasing NetBackup security NBAC on master, media server, and GUI security
31
NBAC on master, media server, and GUI security
The NBAC on master server, media server, and GUI security method uses the authentication broker to provide credentials to the master server, media server, and GUI. This data center example makes use of the NetBackup access control on the master and media servers to limit access to portions of NetBackup and to allow non-root administration of NetBackup. Within this environment, NBAC is configured for use between the servers and the GUIs. This allows non-root users to login to NetBackup using your operating system (UNIX password or Windows local domain) or global user repositories (NIS/NIS+ or Active Directory) to administer NetBackup. In addition, NBAC can be used to limit the level of access to NetBackup for certain individuals. For example, you can segregate day to day operational control from environmental configuration such as adding new policies, robots, etc. Figure 1-9 NBAC on master and media server
32 Increasing NetBackup security NBAC complete security
NBAC complete security
The NBAC complete security method uses the authentication broker to provide credentials to the master server, media server, and client. This environment is very similar to the NBAC master, media server, and GUI model. The main differences are in the fact that all hosts participating in the NetBackup environment are reliably identified using credentials. And non-root administrators have the ability to manage the NetBackup clients based on configurable levels of access. Note that user identities may exist in global repositories such as Active Directory in Windows or NIS in UNIX. Identities can also exist in local repositories (UNIX passwd, local Windows domain) on those hosts supporting an authentication broker. Figure 1-10 NBAC complete
Increasing NetBackup security All NetBackup security
33
All NetBackup security
All NetBackup security combines all securities together. It represents a very sophisticated environment in which there are differing requirements for a variety of clients. Client requirements can necessitate using encryption off host (such as an underpowered host, or a database backup). Client requirements can also necessitate using encryption on host due to the sensitive nature of the data on the host. Adding NBAC to the security mix allows segregation of administrators, operators, and users within NetBackup. Figure 1-11 All NetBackup security
34 Increasing NetBackup security All NetBackup security
Chapter

This chapter on security deployment models provides information on examples of NetBackup workgroups, single data centers, and multi-data centers. It contains the following major sections:

Single data center with standard NetBackup on page 41

Single data center with Media Server Encryption Option (MSEO) on
page 44
Single data center with client side encryption on page 48
Single data center with NBAC on master and media servers on page 52
Single data center with NBAC complete on page 57
Single data center with all security implemented on page 62
Multi-data center with standard NetBackup on page 67
Multi-data center with Media Server Encryption Option (MSEO) on
page 71
Multi-data center with client side encryption on page 77
Multi-data center with NBAC on master and media servers on page 84
Multi-data center with NBAC complete on page 91
Multi-data center with all NetBackup security on page 98
36 Security deployment models Workgroups
Workgroups
A workgroup is a small group of systems (less than 50) used with NetBackup in a wholly internal fashion. An example workgroup is shown in the following list.
Workgroup with NetBackup
Single data centers

A single data center is defined as a medium to large group of hosts (greater than 50). Example single data centers are shown in the following list.

Single data center with standard NetBackup Single data center with Media Server Encryption Option (MSEO) Single data center with client side encryption Single data center with NBAC on master and media servers Single data center with NBAC complete Single data center with all security implemented
Multi-data centers
A multi-data center is defined as a medium to large group of hosts (greater than 50) that span two or more geographic regions and are connected by a Wide Area Network (WAN). Example multi-data centers are shown in the following list.

Multi-data center with standard NetBackup Multi-data center with Media Server Encryption Option (MSEO) Multi-data center with client side encryption Multi-data center with NBAC on the master and media servers Multi-data center with NBAC complete Multi-data center with all NetBackup security

A workgroup with NetBackup (Figure 2-12 on page 38) is classified as a small group of systems (less than 50) used with NetBackup in a wholly internal fashion. Typically this configuration does not have a unified naming service such as NIS or Active Directory and may not have an authoritative host naming service such as DNS or WINS. This set of configuration is typically found in test labs of large corporations, or as environments in small corporations.
Security deployment models Workgroup with NetBackup
37
Highlights

Very few NetBackup servers Small computer environments No externally facing equipment involved
NetBackup parts for workgroup

The NetBackup parts used with the workgroup include the following items.

Master server Media server Tape Clients Internal firewall (not used) DMZ (not used) External firewall (not used) Internet (not used)
Each of these parts is described in detail in the following sections.
38 Security deployment models

Figure 2-12
Security deployment models Workgroup with NetBackup
39
Master server
The master server communicates with the media server and clients 1, 2, 3, and 4.
Media server
The media server communicates with the master server and clients 1, 2, 3, and 4. The media server manages the writing of unencrypted data to tape for clients 1, 2, 3 and 4.
Tape
The tape contains unencrypted backup data that is written for clients 1, 2, 3, and 4.
Clients
Clients 1, 2, 3, and 4 are Standard NetBackup clients managed by the master server. They have their unencrypted data backed up to tape by the media server.
Internal firewall
The internal firewall allows NetBackup to have access to clients in the DMZ. Only selected NetBackup ports and possibly other application ports are enabled for data communication into and out of the DMZ. Other ports, such as http, that are open in the External Firewall are not allowed to pass through the Internal Firewall from the Internet. The internal firewall is not used with the Workgroup deployment model. In this example no clients access the Internal Firewall so the NetBackup ports should not be opened through it. Note: In this example there are no clients beyond the internal firewall. So the NetBackup ports should not be open through the internal firewall.
DMZ
The Demilitarized Zone (DMZ) provides a safe area of operation for NetBackup clients existing between the Internal Firewall and External Firewall. Possible clients operating in the DMZ include web server NetBackup clients using either standard NetBackup clients or encrypted NetBackup clients. Clients in the DMZ can communicate to NetBackup through the Internal Firewall using designated NetBackup ports. Web server NetBackup clients can receive connections from the External Firewall to the Internet using typical http ports. The DMZ is not accessible by clients in the Workgroup deployment model.
40 Security deployment models Workgroup with NetBackup
External firewall
The external firewall allows external users to access web server NetBackup clients that are located in the DMZ from the Internet typically over http ports. NetBackup ports open for clients to communicate through the Internal Firewall are not allowed to pass through the External Firewall to the Internet.
Internet
The Internet is a collection of interconnected computer networks linked by copper wires, fiber-optic cables, and wireless connections. The Internet is not used by clients in the Workgroup deployment model. Caution: Customers should never put NetBackup clients outside the DMZ and directly in the Internet. You must use an external firewall to block the outside world from NetBackup ports at all times.
Security deployment models Single data center with standard NetBackup
41
Single data center with standard NetBackup
A single data center with standard NetBackup (Figure 2-13 on page 42) is defined as a medium to large group of hosts (greater than 50). It includes the hosts that are both internal only and those that expand through the DMZ to the Internet. This configuration typically has centralized naming service for hosts (such as DNS or WINS). It also has a centralized naming service for users (such as NIS or Active Directory).
Highlights

Externally facing hosts Centralized naming services typically exist Greater than 50 hosts in size Simplest to configure requiring only general NetBackup knowledge Typical configuration used for NetBackup 4.5 to 5.x customers Assumes no fear of passive data interception on the wire as the backup runs
NetBackup parts for single data center with standard NetBackup

The NetBackup parts used with the single data center with standard NetBackup include the following items.

Master server Media server Tape Clients Internal firewall DMZ External firewall Internet

Figure 2-13
Security deployment models Single data center with standard NetBackup
43
Master server
The master server communicates with the media server, standard NetBackup client 4 and web server NetBackup client 5 in the DMZ.
Media server
The media server communicates with the master server, standard NetBackup client 4 and web server NetBackup client 5 in the DMZ. The media server manages the writing of unencrypted data to tape for clients 4 and 5.
Tape
The tape contains unencrypted backup data written for clients 4 and 5.
Clients
Client 4 is a standard NetBackup type and client 5 is a web server type. Both clients are managed by the master server and have their unencrypted data backed up to tape by the media server. Client 4 exists in the data center. Client 5 exists in the DMZ. Client 5 communicates to NetBackup using NetBackup only ports through the Internal Firewall. Client 5 receives connections from the Internet using http only ports through the External Firewall. Note that all NetBackup traffic for the lookup is sent unencrypted over the wire.
Internal firewall
The internal firewall allows NetBackup to have access to web server Netbackup client 5 in the DMZ. Only selected NetBackup ports and possibly other application ports are enabled for data communication into and out of the DMZ. Other ports, such as http, that are open in the External Firewall are not allowed to pass through the Internal Firewall from the Internet.
DMZ
The Demilitarized Zone (DMZ) provides a safe area of operation for NetBackup client 5, web server, that exists between the Internal Firewall and External Firewall. Client 5 in the DMZ can communicate to NetBackup through the Internal Firewall using designated NetBackup ports. The web server client 5 can communicate through the External Firewall to the Internet using http ports.
External firewall
The external firewall allows external users to access the web server client 5 located in the DMZ from the Internet over http ports. NetBackup ports are open for client 5 to communicate through the Internal Firewall.

Single data center with Media Server Encryption Option (MSEO)
Caution: NetBackup ports are not allowed to pass through the External Firewall to the Internet. Only the http ports to client 5 are open in the External Firewall to the Internet.
Internet
The Internet is a collection of interconnected computer networks, linked by copper wires, fiber-optic cables and wireless connections. The web server client 5 can receive connections over the Internet using http ports through the External Firewall.

This single data center with Media Server Encryption Option (MSEO)
(Figure 2-14 on page 45) example typically includes greater than 50 hosts. All
externally facing hosts make use of the Media Server Encryption Option (MSEO).
In this example clients use the MSEO option for all hosts.
Highlights

The MSEO is a fairly new option in NetBackup Useful for protecting data sent off-site Data is still sent from the client in the clear, implying that passive data interception off the wire is an acceptable risk Key management and encryption are managed in a central location equating to a single point of failure. Using the high availability cluster can help. Media server needs to be pretty robust to handle multiple clients at once Useful where you need to send encrypted tapes off-site but want to off load encryption from the client, which is CPU intensive Must have keys to get data back. Lost keys means lost data. (Refer to information on key share backup in the Encryption Chapter).
Security deployment models Single data center with Media Server Encryption Option (MSEO)
45
Figure 2-14
Single data center with MSEO

NetBackup parts for single data center with MSEO

The NetBackup parts used with the single data center with MSEO include the following items.

Master server Media server MSEO Tape Transport Vault off-site Clients Internal firewall DMZ External firewall Internet
Master server
The master server communicates with the media server, MSEO clients 1, 2 and 3 and the MSEO web server client 5 in the DMZ.
Media server
The media server communicates with the master server, MSEO clients 1, 2 and 3 and the MSEO web server client 5 in the DMZ. The media server communicates with the MSEO device that enables the writing of encrypted data to tape for clients 1, 2, 3 and 5.
MSEO
The MSEO hardware appliance off-loads encryption from individual clients and generates encrypted data for clients 1, 2, 3, and 5. That encrypted data is then written to tape. The individual client CPU performance is improved (relative to client side encryption) by using the MSEO appliance.
Security deployment models Single data center with Media Server Encryption Option (MSEO)
47
Tape
The tape contains MSEO encrypted backup data written for clients 1, 2, 3 and 5. The encrypted tape is transported off-site to a vault for disaster recovery protection. Note: In order to decrypt the data, the key(s) used to encrypt the data must be made available.
Transport
The transport truck moves encrypted tapes off-site to a secure vault facility. If in the remote case that a tape is lost during transport, the data center manager has potentially reduced the risk of a data breach through the use of data encryption.
Vault off-site
The vault off-site is a safe storage facility at a different location than the data center that promotes disaster recovery protection.
Clients
Clients 1, 2, and 3 are of the MSEO type and client 5 is a web server type (also using the MSEO option). Both types are managed by the master server and have their encrypted data backed up to tape through the media server attached MSEO hardware appliance. Clients 1,2 and 3 exist in the data center. Client 5 exists in the DMZ. Client 5 communicates to NetBackup using NetBackup only ports through the Internal Firewall. Client 5 receives connections from the Internet using http only ports through the External Firewall.
Internal firewall
The internal firewall allows NetBackup to access client 5, web server, in the DMZ. Only selected NetBackup ports and possibly other application ports are enabled for data communication into and out of the DMZ. Other ports, such as http, that are open in the External Firewall are not allowed to pass through the Internal Firewall.
DMZ
The Demilitarized Zone (DMZ) provides a safe area of operation for the web server client 5 that exists between the Internal Firewall and External Firewall. The web server client 5 in the DMZ can communicate to NetBackup through the
48 Security deployment models Single data center with client side encryption
Internal Firewall using designated NetBackup ports. The web server client 5 can also communicate through the External Firewall to the Internet using only http ports.
External firewall
The external firewall allows external users to access the web server client 5 located in the DMZ from the Internet over http ports. NetBackup ports are open for web server client 5 to communicate through the Internal Firewall to NetBackup. The NetBackup ports are not allowed to pass through the External Firewall to the Internet. Only the http ports of web server client 5 can pass through the External Firewall to the Internet.
Internet
The Internet is a collection of interconnected computer networks, linked by copper wires, fiber-optic cables and wireless connections. The web server client 5 can communicate over the Internet using http ports through the External Firewall.
Single data center with client side encryption

This single data center with client side encryption (Figure 2-15 on page 49) example uses the client side encryption to ensure data confidentiality across the wire as well as on tape. This helps to mitigate the risk of passive wire tapping within the organization and the risk of data exposure as tapes are moved off site. This data center model assures a medium to large number (greater than 50) of managed hosts, clients inside the data center as well as the DMZ, and the potential for centralized naming services for hosts and user identities.
Highlights

Useful for protecting off-site data Data from client is encrypted and eliminates passive interception of the data on the wire Key management is de-centralized on to the clients The original NetBackup encryption option Client CPU is used to perform encryption Must have the key to get data back. A lost key means lost data. Useful when you need to scan tapes off-site and/or you need confidentiality on the wire
Security deployment models Single data center with client side encryption
49
Figure 2-15
Single data center with client side encryption
50 Security deployment models Single data center with client side encryption
NetBackup parts for single data center with client side encryption
The NetBackup parts used with the single data center with client side encryption include the following items.

Master server Media server Client side encryption Tape Transport Vault off-site Clients Internal firewall DMZ External firewall Internet
Master server
The master server communicates with the media server and clients 1, 2 and 3. It also communicates with web server client 5 and encrypted client 6 in the DMZ.
Media server
The media server communicates with the master server and clients 1, 2 and 3. It also communicates with web server client 5 and encrypted client 6 in the DMZ. The media server enables the writing of encrypted data to tape for client 6.
Client side encryption

The client side encryption (not shown in the figure) ensure data confidentiality across the wire as well as on tape.
Tape
The tape contains client side generated encrypted backup data written for client 6. The encrypted tape is transported off-site to a vault for disaster recovery protection. Clients 1, 2, 3 and 5 could be backed up to a non-encrypted tape (not shown in the drawing).
Security deployment models Single data center with client side encryption
51
Transport
The transport truck moves encrypted tapes off-site to a secure vault facility. In the remote case that a tape is lost during transport, the data center manager has mitigated the risk of data exposure through the use of encryption.
Vault off-site
Clients
Clients 1, 2, and 3 are of the standard NetBackup type. Client 5 is a web server type. Client 6 has client side encryption enabled. All client types are managed by the master server. Client 6 has its encrypted data backed up to tape through the media server. Clients 1, 2 and 3 exist in the data center. Clients 5 and 6 exists in the DMZ. They communicate to NetBackup using NetBackup only ports through the Internal Firewall. Clients 5 and 6 communicate to the Internet using http only ports through the External Firewall.
Internal firewall
The internal firewall allows NetBackup to access web server client 5 in the DMZ. Only selected NetBackup ports and possibly other application ports are enabled for data communication into and out of the DMZ. Other ports, such as http, that are open in the External Firewall are not allowed to pass through the Internal Firewall.
DMZ
The Demilitarized Zone (DMZ) provides a safe area of operation for web server client 5 and encrypted client 6 that exists between the Internal Firewall and External Firewall. The web server client 5 and encrypted client 6 in the DMZ can communicate to NetBackup through the Internal Firewall using designated NetBackup ports. The web server client 5 and encrypted client 6 can communicate through the External Firewall to the Internet using http ports. The encrypted client 6 in the DMZ can communicate to NetBackup through the Internal Firewall using designated NetBackup ports.
External Firewall
The external firewall allows external users to access the web server client 5 and encrypted client 6 located in the DMZ from the Internet over http ports. NetBackup ports are open for web server client 5 and encrypted client 6 to communicate through the Internal Firewall. However, NetBackup ports are not

Single data center with NBAC on master and media servers
allowed to pass through the External Firewall to the Internet. Only the http ports of web server client 5 and encrypted client 6 can pass through the External Firewall to the Internet. The external firewall limits client 5 and 6 from accessing or being accessed by the Internet.
Internet
The Internet is a collection of interconnected computer networks, linked by copper wires, fiber-optic cables and wireless connections. The web server client 5 can communicate over the Internet using http ports through the External Firewall.

This data single data center with NBAC on master and media servers example (Figure 2-16 on page 53) makes use of the NetBackup access control on the master and media servers to limit access to portions of NetBackup and to allow non-root administration of NetBackup. Within this environment, NBAC is configured for use between the servers and the GUIs. This allows non-root users to login to NetBackup using your operating system (UNIX password or Windows local domain) or global user repositories (NIS/NIS+ or Active Directory) to administer NetBackup. In addition, NBAC can be used to limit the level of access to NetBackup for certain individuals. For example, you can segregate day to day operational control from environmental configuration such as adding new policies, robots, etc.
Highlights

Administer as non-root users Administer UNIX with a Windows User ID Administer Windows with a UNIX account Segregate and limit the actions of specific users Root or Administrator or client hosts can still do local client backups and restores Can be combined with other security related options All servers must be NetBackup version 5.x and higher
Security deployment models Single data center with NBAC on master and media servers
53
Figure 2-16
54 Security deployment models Single data center with NBAC on master and media servers
NetBackup parts for single data center with NBAC on master and media servers
The NetBackup parts used with the single data center with NBAC on master and media servers include the following items.

Master server Media server GUI Root broker Authentication broker Authorization engine Tape Clients Internal firewall DMZ External firewall Internet
Master server
The master server communicates with the media server, root and authentication broker, authorization engine, clients 1, 2, 3, and client 5, web server, in the DMZ. The master server also communicates with and receives a credential from the authentication broker. When a CLI or GUI accesses a daemon on a master server, a credential is exchanged to identify the user and the authorization engine is contacted to determine accessibility to the daemons functions.
Media server
The media server communicates with the master server, clients 1, 2, 3 and client 5, web server, in the DMZ. The media server also communicates with the authorization engine and receives a credential from the authentication broker. The media server enables the writing of unencrypted data to tape for clients 1, 2, 3, and 5.
Security deployment models Single data center with NBAC on master and media servers
55
When a CLI or GUI accesses a daemon on a media server, a credential is exchanged to identify the user and the authorization engine is contacted to determine accessibility to the daemons functions.
GUI
This remote administration console GUI receives a credential from the authentication broker. The GUI then uses this credential to gain access to functionality on the media and master servers.
Root broker
The root broker authenticates the authentication broker but not clients. In this example the root broker and authentication broker are shown as the same component.
The authentication broker authenticates the master server, media server and GUI by establishing credentials with each. The authentication broker also authenticates a user when using a command prompt.
The authorization engine communicates with the master server and media server to determine permissions of an authenticated user. These permissions determine the functionality available to a the user. It also stores user groups and permissions. Only one authorization engine is needed. Note: The authorization engine resides on the master server as a daemon process. It is shown in the figure as a separate image for example only.
Tape
The tape contains unencrypted backup data written for clients 1, 2, 3 and 5.
Clients
Clients 1, 2, and 3 are standard NetBackup types and client 5 is a web server type. Both types are managed by the master server and have their unencrypted data backed up to tape through the media server. Clients 1, 2 and 3 exist in the data center. Client 5 exists in the DMZ. Client 5 communicates to NetBackup using NetBackup only ports through the Internal Firewall. Client 5 receives
56 Security deployment models Single data center with NBAC on master and media servers
connections from the Internet using http only ports through the External Firewall.
Internal firewall
The internal firewall allows NetBackup to access web server Client 5 in the DMZ. Only selected NetBackup ports and possibly other application ports are enabled for data communication into and out of the DMZ. Other ports, such as http, that are open in the External Firewall are not allowed to pass through the Internal Firewall.
DMZ
The Demilitarized Zone (DMZ) provides a safe area of operation for web server client 5 that exists between the Internal Firewall and External Firewall. The web server client 5 in the DMZ can communicate to NetBackup through the Internal Firewall using designated NetBackup ports. The web server client 5 can communicate through the External Firewall to the Internet using http ports.
External firewall
The external firewall allows external users to access the web server client 5 located in the DMZ from the Internet over http ports. NetBackup ports are open for client 5 to communicate through the Internal Firewall. NetBackup ports are not allowed to pass through the External Firewall to the Internet. Only the http ports of client 5 can pass through the External Firewall to the Internet.
Internet
The Internet is a collection of interconnected computer networks, linked by copper wires, fiber-optic cables and wireless connections. Client 5 can communicate over the Internet using http ports through the External Firewall.
Security deployment models Single data center with NBAC complete
57
Single data center with NBAC complete
This single data center with NBAC complete (Figure 2-17 on page 58) environment is very similar to the single data center with NBAC master and media server. The main differences are in the fact that all hosts participating in the NetBackup environment are reliably identified using credentials. And non-root administrators have the ability to manage the NetBackup clients based on configurable levels of access. Note that user identities may exist in global repositories such as Active Directory in Windows or NIS in UNIX. Identities can also exist in local repositories (UNIX passwd, local Windows domain) on those hosts supporting an authentication broker.
Highlights

Similar to highlights for single data center with NBAC master and media server except for root or administrator on client On client systems, non-root / administrator users may be configured to do local backup and restores (setup by default) The environment facilitates trusted identification of all hosts participating in NetBackup Requires all hosts to be at NetBackup version 5.0 and greater

Figure 2-17
59
NetBackup parts for single data center with NBAC complete

The NetBackup parts used with the single data center with NBAC complete include the following items.

Master server Media server GUI Root broker Authentication broker Authorization engine Tape Clients Internal firewall DMZ External firewall Internet
Master server
The master server communicates with the: media server, root broker, authentication broker, authorization engine, clients 1, 2, 3 and client 5, web server, in the DMZ. The master server also communicates with and receives a credential from the authentication broker. When a CLI or GUI accesses a daemon on a master server, a credential is exchanged to identify the user and the authorization engine is contacted to determine accessibility to the daemons functions.
Media server
The media server communicates with the master server, clients 1, 2, 3 and client 5, web server, in the DMZ. The media server also communicates with the authorization engine and receives a credential from the authentication broker. The media server enables the writing of unencrypted data to tape for clients 1, 2, 3, and 5. When a CLI or GUI accesses a daemon on a media server, a credential is exchanged to identify the user and the authorization engine is contacted to determine accessibility to the daemons functions.
60 Security deployment models Single data center with NBAC complete
GUI
This remote administration console, GUI, receives a credential from the authentication broker. The GUI then uses this credential to gain access to functionality on the media and master servers.
Root broker
The authentication broker authenticates the master server, media server, GUI, clients, and users by establishing credentials with each.
The authorization engine communicates with the master server and media server to determine permissions of an authenticated user. It also stores user groups and permissions. Only one authorization engine is needed. Note: The authorization engine resides on the master server as a daemon process. It is shown in the figure as a separate image for example only.
Tape
The tape contains unencrypted backup data written for clients 1, 2, 3 and 5.
Clients
Clients 1, 2, and 3 are standard NetBackup types and client 5 is a web server type. Upon receiving credentials form the authentication broker, clients 1, 2, 3 and 5 are authenticated to the Symantec Product Authentication service domain. Both standard and web server types are managed by the master server and have their unencrypted data backed up to tape through the media server. Clients 1, 2 and 3 exist in the data center. Client 5 exists in the DMZ. Client 5 communicates to NetBackup using NetBackup only ports through the Internal Firewall. Client 5 receives connections from the Internet using http only ports through the External Firewall.
61
Internal firewall
DMZ
The Demilitarized Zone (DMZ) provides a safe area of operation for web server client 5 that exists between the Internal Firewall and External Firewall. The web server client 5 in the DMZ can communicate to NetBackup through the Internal Firewall using designated NetBackup ports. The web server client 5 can communicate through the External Firewall to the Internet using http ports.
External firewall
Internet
62 Security deployment models Single data center with all security implemented
Single data center with all security implemented
This single data center with all security implemented (Figure 2-18 on page 63) example combines all the previous examples together. It represents a very sophisticated environment in which there are differing requirements for a variety of clients. Client requirements can necessitate using encryption off host (such as an underpowered host, or a database backup). Client requirements can also necessitate using encryption on host due to the sensitive nature of the data on the host. Adding NBAC to the security mix allows segregation of administrators, operators, and users within NetBackup.
Highlights

Please see the previous single data center sections for individual option highlights Most flexible and complex environment Careful design following a similar model will allow you to utilize the strengths of each option
Security deployment models Single data center with all security implemented
63
Figure 2-18
Single data center with all security implemented
NetBackup parts for single data center with all security implemented
The NetBackup parts used with the single data center with all security implemented include the following items.

Master server Media server GUI Root broker Authentication broker Authorization engine Tapes Transport Vault off-site Clients Internal firewall DMZ External firewall Internet
Master server
The master server communicates with the: media server, root broker, authentication broker, authorization engine, clients 1, 2, 3, and client 5, web server, in the DMZ. The master server also communicates with and receives a credential from the authentication broker. When a CLI or GUI accesses a daemon on a master server, a credential is exchanged to identify the user and the authorization engine is contacted to determine accessibility to the daemons functions.
Media server
The media server communicates with the master server, clients 1, 2, 3 and client 5, web server, in the DMZ. The media server also communicates with the authorization engine and receives a credential from the authentication broker. The media server enables the writing of unencrypted data to tape for clients 1, 2, 3, and 5.
Security deployment models Single data center with all security implemented
65
When a CLI or GUI accesses a daemon on a media server, a credential is exchanged to identify the user and the authorization engine is contacted to determine accessibility to the daemons functions.
GUI
This remote administration console, GUI, receives a credential from the authentication broker. The GUI then uses this credential to gain access to functionality on the media and master servers.
Root broker
The authentication broker authenticates the master server, media server, GUI, clients, and users by establishing credentials with each.
The authorization engine communicates with the master server and media server to determine permissions of an authenticated user. It also stores user groups and permissions. Only one authorization engine is needed. Note: The authorization engine resides on the master server as a daemon process. It is shown in the figure as a separate image for example only.
Tapes
The first tape contains encrypted MSEO backup data written for clients 1, 2, 3, and client encrypted data for client 6. The second tape contains unencrypted backup data written for clients 4 and 5.
Transport
The transport truck moves encrypted tapes off-site to a secure vault facility. In the remote case that a tape is lost during transport, the data center manager has mitigated the risk of data exposure through the use of encryption.
Vault off-site
Clients
Clients 1, 2, 3 and 4 are standard NetBackup types. Client 5 is a web server type. Client 6 is uses client side encryption. Upon receiving credentials form the authentication broker, clients 1, 2, 3, 5 and 6 are authenticated to the Symantec Product Authentication service domain. Both standard and web server types are managed by the master server and have their unencrypted data backed up to tape through the media server. Client 6 has its encrypted data backed up to tape through the media server. Clients 1, 2 and 3 exist in the data center. Clients 5 and 6 exists in the DMZ. They communicate to NetBackup using NetBackup only ports through the Internal Firewall. Client 5 and 6 communicate to the Internet using http only ports through the External Firewall.
Internal firewall
DMZ
The Demilitarized Zone (DMZ) provides a safe area of operation for web server client 5 and encrypted client 6 that exists between the Internal Firewall and External Firewall. The web server client 5 and encrypted client 6 in the DMZ can communicate to NetBackup through the Internal Firewall using designated NetBackup ports. The web server client 5 and encrypted client 6 can communicate through the External Firewall to the Internet using http ports. The encrypted client 6 in the DMZ can communicate to NetBackup through the Internal Firewall using designated NetBackup ports.
External firewall
Security deployment models Multi-data center with standard NetBackup
67
Internet
Multi-data center with standard NetBackup

A multi-data center with standard NetBackup (Figure 2-19 on page 68) is defined as a medium to large group of hosts (greater than 50) that span two or more geographic regions and are connected by a Wide Area Network (WAN). In this example one data center is located in London and the other data center is located in Tokyo. Both data centers are connected through a dedicated WAN connection. A multi-data center includes the hosts that are both internal only and those that expand through the DMZ to the Internet. This configuration typically has centralized naming service for hosts (such as DNS or WINS). It also has a centralized naming service for users (such as NIS or Active Directory).
Highlights

NetBackup spanning two or more geographic regions through a WAN Centralized naming services typically exist Greater than 50 hosts in size Simplest to configure requiring only general NetBackup knowledge Typical configuration used for NetBackup 4.5 to 5.x customers with multiple data centers Assumes no fear of passive data interception on the wire as the backup runs

Figure 2-19
Security deployment models Multi-data center with standard NetBackup
69
NetBackup parts for multi-data center with standard NetBackup

The NetBackup parts used with the multi-data center with standard NetBackup implemented include the following items.

London data center Tokyo data center WAN Master server Media servers Tapes Clients Internal firewalls DMZs External firewalls Internet
London data center

The London data center contains the master server, media server 1, client 4 standard NetBackup, and the unencrypted data tape for client 4. The London data center connects to the Tokyo data center through a dedicated WAN connection.
Tokyo data center

The Tokyo data center contains the media server 2, client 10 standard NetBackup, and the unencrypted data tape for client 10. The Tokyo data center connects to the London data center through a dedicated WAN connection.
WAN
The dedicated Wide Area Network link that connects the London data center with the Tokyo data center. The WAN provides connectivity between the master server and media server 2 and client 10.
Master server
The master server, located in London, communicates with media server 1 in London. The master server also communicates over the WAN with the media
70 Security deployment models Multi-data center with standard NetBackup
server 2 in Tokyo. The master server communicates with standard NetBackup client 4 in London and client 10 over the WAN in Tokyo.
Media servers
There are two media servers. One media server is in London and the other is in Tokyo. The media server 1 in London communicates with the master server and standard NetBackup client 4 also in London. Media server 1 manages the writing of unencrypted data to tape for client 4 in London. The media server 2 in Tokyo communicates with the master server in London and standard NetBackup client 10 in Tokyo. Media server 2 manages the writing of unencrypted data to tape for client 10 in Tokyo.
Tapes
Tapes are produced in both the London and Tokyo data center. The London tape contains unencrypted backup data written for client 4. The Tokyo tape contains unencrypted backup data written for client 10.
Clients
Clients are located in both the London and Tokyo data center. Clients 4 and 10 are standard NetBackup types. Both clients are managed by the master server located in London. Their unencrypted data is backed up to tape by the media server. Unencrypted data is written to both client 4 tape in London and client 10 tape in Tokyo. Note that all NetBackup traffic for client 10 lookup is sent unencrypted over the wire (WAN) from Tokyo to London.
Internal firewalls
Internal firewalls are not used at the London or Tokyo data center with standard NetBackup.
DMZs
Demilitarized Zones (DMZ) are not used at the London or Tokyo data center with standard NetBackup.
External firewalls
External firewalls are not used at the London or Tokyo data center with standard NetBackup.
Security deployment models Multi-data center with Media Server Encryption Option (MSEO)
71
Internet
Internet is not used at the London or Tokyo data center with standard NetBackup.
Multi-data center with Media Server Encryption Option (MSEO)

A multi-data center with Media Server Encryption Option (MSEO) (Figure 2-20 on page 72) is defined as a medium to large group of hosts (greater than 50) that span two or more geographic regions and are connected by a Wide Area Network (WAN). In this example one data center is located in London and the other data center is located in Tokyo. Both data centers are connected through a dedicated WAN connection. This is an example of a multi-data center which typically includes greater than 50 hosts. All externally facing hosts make use of the Media Server Encryption Option (MSEO). In this example clients use both encrypted backups for some clients and the MSEO option for other hosts. Certain data that is too sensitive to be archived off-site is left at rest in an unencrypted format.
Highlights

NetBackup spanning two or more geographic regions through a WAN Fairly new option in NetBackup Useful for protecting off-site data Data is still sent from the client in the clear, implying that passive wire interception is an acceptable risk Key management and encryption are managed in a central location equating to a single point of failure. Using the high availability cluster can help. Media server needs to be pretty robust to handle multiple clients at once Useful where you need to send encrypted tapes off-site but want to off load encryption from the client, which is CPU intensive Must have keys to get data back. Lost keys means lost data. (Refer to information on key share backup in the Encryption Chapter.)

Figure 2-20
73
NetBackup parts for multi-data center with MSEO

The NetBackup parts used with the multi-data center with MSEO implemented include the following items.

London data center Tokyo data center WAN Master server Media servers MSEOs Tapes Transports Vaults off-site Clients Internal firewalls DMZs External firewalls Internet
London data center

The London data center contains the master server, media server 1, MSEO 1, clients 1, 2, 3, and client 5 web server in the DMZ. The London data center also contains the encrypted data tape for clients 1, 2, 3, and unencrypted data tape for client 5. The London data center connects to the Tokyo data center through a dedicated WAN connection.
Tokyo data center

The Tokyo data center contains the media server 2, MSEO 2, clients 8, 9 and client 11 web server in the DMZ. The Tokyo data center also contains the encrypted data tape for clients 8, 9, and unencrypted data tape for client 11. The Tokyo data center connects to the London data center through a dedicated WAN connection.

WAN
The dedicated Wide Area Network (WAN) link connects the London data center with the Tokyo data center. The WAN provides connectivity between the master server in London to media server 2 with clients 8, 9, 11 in Tokyo.
Master server
The master server, located in the London data center, communicates with media server 1 and clients 1, 2, 3, and 5. The master server also uses the WAN to communicate with media server 2, and clients 8, 9, and 11 in Tokyo.
Media servers
There are two media servers. Media server 1 is located in the London data center and media server 2 is located in the Tokyo data center. In London, media server 1 communicates with the master server, MSEO 1, and clients 1, 2, 3, and 5. Media server 1 writes unencrypted data to tape for client 5. Media server 1 also uses MSEO 1 to write encrypted data to tape for clients 1, 2, and 3. The encrypted tape is transported off-site to a vault in London. In Tokyo, media server 2 communicates with the master server in London through the WAN and clients 8, 9, and 11 in Tokyo. Media server 2 writes unencrypted data to tape for client 11. Media server 2 also uses MSEO 2 to write encrypted data to tape for clients 8 and 9. The encrypted tape is transported off-site to a vault in Tokyo.
MSEOs
There are two MSEO hardware appliances that off-load encryption from individual clients. The individual client CPU performance is improved (relative to client side encryption) by using the MSEO appliance. The MSEO 1 is in the London data center and MSEO 2 is in the Tokyo data center. The MSEO 1 generates an encrypted data tape for clients 1, 2, and 3 that can be stored off-site in London. The MSEO 2 generates an encrypted data tape for clients 8 and 9 that can be stored off-site in Tokyo.
Tapes
Both unencrypted and encrypted data tapes are produced in the London data center and in the Tokyo data center. The encrypted tape contains MSEO encrypted backup data. In London, the unencrypted tape is written for client 5 and stored on-site at the London data center. The encrypted tape is written for clients 1, 2, and 3. The encrypted tape for clients 1, 2, and 3 is transported off-site to a vault in London for disaster recovery protection.
75
In Tokyo, the unencrypted tape is written for client 11 and stored on-site at the Tokyo data center. The encrypted tape is written for clients 8 and 9. The encrypted tape for clients 8 and 9 is transported off-site to a vault in Tokyo for disaster recovery protection. Note: In order to decrypt the data, the key(s) used to encrypt the data must be made available.
Transports
There are two transports. One transport is located in London and the other is located in Tokyo. The transport truck in London moves the encrypted tape for clients 1, 2, and 3 off-site to a secure London vault facility. The transport truck in Tokyo moves the encrypted tape for clients 8 and 9 off-site to a secure Tokyo vault facility. Note: If in the remote case a tape is lost during transport, the data center manager has potentially reduced the risk of a data breach through the use of data encryption.
Vaults off-site
There are two vaults off-site. One vault is located in London and the other is located in Tokyo. Both vaults provide safe encrypted tape storage facilities off-site at different locations than the data centers. Note: Having the encrypted tapes stored at locations separate from the data centers promotes good disaster recovery protection.
Clients
Clients are located in both the London and Tokyo data centers. In London, clients 1, 2, and 3 are of the MSEO type and client 5 is a web server type (not using MSEO) located in the DMZ. Both types are managed by the master server and have their encrypted data backed up to tape through media server 1 attached MSEO hardware appliance. Client 5 communicates to NetBackup using NetBackup only ports through the Internal Firewall. Client 5 receives connections from the Internet using http only ports through the External Firewall. In Tokyo, clients 8 and 9 are of the MSEO type and client 11 is a web server type (not using MSEO) located in the DMZ. Both types are managed by the master

server in London and have their encrypted data backed up to tape through media server 2 attached MSEO hardware appliance. Client 11 communicates to NetBackup using NetBackup only ports through the Internal Firewall. Client 5 receives connections from the Internet using http only ports through the External Firewall.
Internal firewalls
There are two internal firewalls. One internal firewall is located in London and the other is located in Tokyo. In London, the internal firewall allows NetBackup to access client 5, web server, in the DMZ. In Tokyo, the internal firewall allows NetBackup to access client 11, web server, in the DMZ. Only selected NetBackup ports and possibly other application ports are enabled for data communication into and out of the DMZ. Other ports, such as http, that are open in the External Firewall are not allowed to pass through the Internal Firewall.
DMZs
There are two Demilitarized Zones (DMZs). One DMZ is located in London and the other is located in Tokyo. In London, the DMZ provides a safe area of operation for the web server client 5 that exists between the internal firewall and external firewall. The web server client 5 in the DMZ can communicate to NetBackup through the internal firewall using designated NetBackup ports. The web server client 5 can also communicate through the external firewall to the Internet using only http ports. In Tokyo, the DMZ provides a safe area of operation for the web server client 11 that exists between the internal firewall and external firewall. The web server client 11 in the DMZ can communicate to NetBackup through the internal firewall using designated NetBackup ports. The web server client 11 can also communicate through the external firewall to the Internet using only http ports.
External firewalls
There are two external firewalls. One external firewall is located in London and the other is located in Tokyo. In London, the external firewall allows external users to access the web server client 5 located in the DMZ from the Internet over http ports. The NetBackup ports are not allowed to pass through the external firewall to the Internet. Only the http ports of web server client 5 can pass through the external firewall to the Internet. In Tokyo, the external firewall allows external users to access the web server client 11 located in the DMZ from the Internet over http ports. The NetBackup ports are not allowed to pass through the external firewall to the Internet. Only the http ports of web server client 11 can pass through the external firewall to the Internet.
Security deployment models Multi-data center with client side encryption
77
Internet
There is only one Internet but there are two Internet connections in this multi-data center example. One Internet connection is located in London and the other is located in Tokyo. The Internet is a collection of interconnected computer networks, linked by copper wires, fiber-optic cables and wireless connections. In London, the web server client 5 can communicate over the Internet using http ports through the external firewall. In Tokyo, the web server client 11 can communicate over the Internet using http ports through the external firewall.
Multi-data center with client side encryption

A multi-data center with client side encryption (Figure 2-21 on page 78) option is defined as a medium to large group of hosts (greater than 50) that span two or more geographic regions and are connected by a Wide Area Network (WAN). In this example one data center is located in London and the other data center is located in Tokyo. Both data centers are connected through a dedicated WAN connection. This example data center makes use of client side encryption to ensure data confidentiality across the wire as well as on tape. This helps to mitigate the risk of passive wire tapping within the organization and the risk of data exposure as the tapes are moved off site. As with other examples, this data center model assures a medium to large number (greater than 50) of managed hosts, clients inside the data center as well as the DMZ, and the potential for centralized naming services for hosts and user identities.
Highlights

NetBackup spanning two or more geographic regions through a WAN Useful for protecting off-site data Data from client is encrypted and eliminates passive interception of the data on the wire Key management is de-centralized on to the clients The original NetBackup encryption option Client CPU is used to perform encryption Must have the key to get data back. A lost key means lost data. Useful when you need to scan tapes off-site and/or you need confidentiality on the wire

Figure 2-21
79
NetBackup parts for multi-data center with client side encryption

The NetBackup parts used with the multi-data center with client side encryption implemented include the following items.

London data center Tokyo data center WAN Master server Media servers Client side encryption Tapes Transports Vaults off-site Clients Internal firewalls DMZs External firewalls Internet
London data center

The London data center contains the master server, media server 1 and clients 4, 5, and 6. The London data center also contains the encrypted data tape for clients 6 and 7 and unencrypted data tape for clients 4 and 5. The London data center connects to the Tokyo data center through a dedicated WAN connection.
Tokyo data center

The Tokyo data center contains the media server 2 and clients 7, 10, 11, and 12. The Tokyo data center also contains the encrypted data tape for clients 7 and 12 and unencrypted data tape for clients 10 and 11. The Tokyo data center connects to the London data center through a dedicated WAN connection.
WAN
The dedicated Wide Area Network (WAN) link connects the London data center with the Tokyo data center. The WAN provides connectivity between the master server in London to media server 2 with clients 7, 10, 11, and 12 in Tokyo. The
80 Security deployment models Multi-data center with client side encryption
WAN also provides connectivity between media server 1 in London to client 7 in london.
Master server
The master server, located in the London data center, communicates with media server 1 and clients 4, 5, and 6. The master server also uses the WAN to communicate with media server 2, and clients 7, 10, 11, and 12 in Tokyo.
Media servers
There are two media servers. Media server 1 is located in the London data center and media server 2 is located in the Tokyo data center. In London, media server 1 communicates with the master server and clients 4, 5, and 6. Media server 1 also communicates with client 7 in Tokyo. Media server 1 writes unencrypted data to tape for clients 4 and 5. Media server 1 writes encrypted data to tape for clients 6 and 7. Note that client 7 is located in Tokyo but its tape backup is located in London. The encrypted tape for clients 6 and 7 is transported off-site to a vault in London. In Tokyo, media server 2 communicates with the master server in London through the WAN and clients 7, 10, 11, and 12 in Tokyo. Media server 2 writes unencrypted data to tape for clients 10 and 11. Media server 2 also writes encrypted data to tape for clients 7and 12. Note that even though client 7 is located in Tokyo and is backed up in London, client 7 is also backed up in Tokyo. The encrypted tape for clients 7 and 12 is transported off-site to a vault in Tokyo.
Client side encryption

The client side encryption (not shown in the figure) ensure data confidentiality across the wire as well as on tape.
Tapes
Both unencrypted and encrypted data tapes are produced in the London data center and in the Tokyo data center. The encrypted tape contains client side encrypted backup data. In London, the unencrypted tape is written for clients 4 and 5 and stored on-site at the London data center. The encrypted tape is written for clients 6 and 7. The encrypted tape is transported off-site to a vault in London for disaster recovery protection. In Tokyo, the unencrypted tape is written for clients 10 and 11 and stored on-site at the Tokyo data center. The encrypted tape is written for clients 7 and 12. Note that even though client 7 is located in Tokyo and is backed up in Tokyo,
81
client 7 is also backed up in London. The encrypted tape is transported off-site to a vault in Tokyo for disaster recovery protection. Note: In order to decrypt the data, the key(s) used to encrypt the data must be made available.
Transports
There are two transports. One transport is located in London and the other is located in Tokyo. The transport truck in London moves the encrypted tape for clients 6 and 7 off-site to a secure London vault facility. The transport truck in Tokyo moves the encrypted tape for clients 7 and 12 off-site to a secure Tokyo vault facility. Note that a backup copy of client 7 is vaulted both in London and in Tokyo. Note: If in the remote case a tape is lost during transport, the data center manager has potentially reduced the risk of a data breach through the use of client side data encryption.
Vaults off-site
Clients
Clients are located in both the London and Tokyo data centers. In London, client 4 is a standard NetBackup type. Client 5 is a web server type located in the DMZ. Client 6 is client side encrypted and is also located in the DMZ. All client types are managed by the master server and have their data backed up to tape through media server 1. Clients 5 and 6 communicate to NetBackup using NetBackup only ports through the internal firewall. Client 6 receives connections from the Internet using http only ports through the external firewall. In Tokyo, client 7 is a client side encrypted client but outside of the DMZ. Client 10 is a standard NetBackup type. Client 11 is a web server type located in the DMZ. Client 12 is client side encrypted also located in the DMZ. All client types are managed by the master server in London. Client 7 data is backed up to tape
82 Security deployment models Multi-data center with client side encryption
through media server 1 and 2. Client 10, 11, and 12 data is backed up to tape through media server 2. Clients 11 and 12 communicate to NetBackup using NetBackup only ports through the internal firewall. Client 12 receives connections from the Internet using http only ports through the external firewall.
Internal firewalls
There are two internal firewalls. One internal firewall is located in London and the other is located in Tokyo. In London, the internal firewall allows NetBackup to access web server client 5 and client side encrypted client 6 in the DMZ. In Tokyo, the internal firewall allows NetBackup to access web server client 11 and client side encrypted client 12 in the DMZ. Only selected NetBackup ports and possibly other application ports are enabled for data communication into and out of the DMZ. Other ports, such as http, that are open in the External Firewall are not allowed to pass through the Internal Firewall.
DMZs
There are two Demilitarized Zones (DMZs). One DMZ is located in London and the other is located in Tokyo. In London, the DMZ provides a safe area of operation for the web server client 5 and client side encrypted client 6 that exist between the internal firewall and external firewall. The web server client 5 and client side encrypted client 6 in the DMZ can communicate to NetBackup through the internal firewall using designated NetBackup ports. The web server client 5 can also communicate through the external firewall to the Internet using only http ports. In Tokyo, the DMZ provides a safe area of operation for the web server client 11 and client side encrypted client 12 that exists between the internal firewall and external firewall. The web server client 11 in the DMZ can communicate to NetBackup through the internal firewall using designated NetBackup ports. The web server client 11 can also communicate through the external firewall to the Internet using only http ports.
External firewalls
There are two external firewalls. One external firewall is located in London and the other is located in Tokyo. In London, the external firewall allows external users to access the web server client 5 located in the DMZ from the Internet over http ports. NetBackup ports are open for web server client 5 to communicate through the internal firewall to NetBackup. The NetBackup ports are not allowed to pass through the external firewall to the Internet. Only the http ports of web server client 5 can pass through the external firewall to the Internet. The client side encrypted client 6 cannot be accessed from the Internet.
83
In Tokyo, the external firewall allows external users to access the web server client 11 located in the DMZ from the Internet over http ports. NetBackup ports are open for web server client 11 to communicate through the internal firewall to NetBackup. The NetBackup ports are not allowed to pass through the external firewall to the Internet. Only the http ports of web server client 11 can pass through the external firewall to the Internet. The client side encrypted client 12 cannot be accessed from the Internet.
Internet
84 Security deployment models Multi-data center with NBAC on master and media servers
Multi-data center with NBAC on master and media servers

A multi-data center with NBAC on the master and media server (Figure 2-22 on page 85) example is defined as a medium to large group of hosts (greater than 50) that span two or more geographic regions and are connected by a Wide Area Network (WAN). In this example one data center is located in London and the other data center is located in Tokyo. Both data centers are connected through a dedicated WAN connection. This data center example makes use of the NetBackup access control on the master and media servers to limit access to portions of NetBackup and to allow non-root administration of NetBackup. Within this environment, NBAC is configured for use between the servers and the GUIs. This allows non-root users to login to NetBackup using your operating system (UNIX password or Windows local domain) or global user repositories (NIS/NIS+ or Active Directory) to administer NetBackup. In addition, NBAC can be used to limit the level of access to NetBackup for certain individuals. For example, you can segregate day to day operational control from environmental configuration such as adding new policies, robots, etc.
Highlights

NetBackup spanning two or more geographic regions through a WAN Administer as non-root users Administer UNIX with a Windows User ID Administer Windows with a UNIX account Segregate and limit the actions of specific users Root or Administrator or client hosts can still do local client backups and restores Can be combined with other security related options All servers must be NetBackup version 5.x and higher
Security deployment models Multi-data center with NBAC on master and media servers
85
Figure 2-22
Multi-data center with NBAC on the master and media servers
NetBackup parts for multi-data center with NBAC on master and media servers
The NetBackup parts used with the multi-data center with NBAC on master and media servers implemented include the following items.

London data center Tokyo data center WAN Master server Media servers GUIs Root broker Authentication brokers Authorization engine Tapes Clients Internal firewalls DMZs External firewalls Internet
London data center

The London data center contains the root broker, authentication broker 1, GUI 1, authorization engine, master server, media server 1 and clients 4 and 5. The London data center also contains the unencrypted data tape for clients 4 and 5. The London data center connects to the Tokyo data center through a dedicated WAN connection.
Tokyo data center

The Tokyo data center contains authentication broker 2, GUI 2, media server 2 and clients 10 and 11. The Tokyo data center also contains the unencrypted data tape for clients 10 and 11. The Tokyo data center connects to the London data center through a dedicated WAN connection.
87
WAN
The dedicated Wide Area Network (WAN) link connects the London data center with the Tokyo data center. The WAN provides connectivity between the root broker and authentication broker 1 and authentication broker 2. In addition, the WAN provides connectivity between the root broker and authentication broker 1 and GUI 2 along with media server 2. The WAN also connects the authorization engine to media server 2. Finally, the WAN connects the master server with GUI 2, media server 2, and clients 10 and 11.
Master server
The master server, located in the London data center, communicates with the root broker and authentication broker 1, GUI 1, authorization engine, and media server 1. The master server communicates with clients 4 and 5 in London. The master server also communicates with GUI 2, media server 2, and clients 10 and 11 in Tokyo.
Media servers
There are two media servers in this multi-data center example. Media server 1 is located in the London data center and media server 2 is located in the Tokyo data center. In London, media server 1 communicates with the master server, root broker and authentication broker 1, authorization engine, and clients 4 and 5. Media server 1 writes unencrypted data to tape for clients 4 and 5. In Tokyo, media server 2 communicates with the master server and authorization engine in London through the WAN. Media server 2 also communicates with GUI 2 and clients 10 and 11 in Tokyo. Media server 2 writes unencrypted data to tape for clients 10 and 11.
GUIs
There are two GUIs in this multi-data center example. The GUI 1 is in London and GUI 2 is in Tokyo. These remote administration console GUIs receive credentials from the authentication brokers. The GUIs then uses the credentials to gain access to functionality on the media and master servers. In London, GUI 1 receives a credential from authentication broker 1. GUI 1 has access to functionality on the master server and media servers 1 and 2. In Tokyo, GUI 2 receives a credential from the authentication broker 2. GUI 2 has access to functionality on the master server and media servers 1 and 2.
Root broker
There is only one root broker required in a multi-data center installation. Sometimes the root broker is combined with the authentication broker. In this
example the root broker and authentication broker are shown as the same component and are located in the London data center. In London, the root broker authenticates the authentication broker 1 also in London and the authentication broker 2 in Tokyo. The root broker does not authenticate clients.
Authentication brokers
There can be more than one authentication broker in a data center installation. Sometimes the authentication broker can be combined with the root broker. In this data center installation, there are two authentication brokers used. The authentication broker authenticates the master server, media server, and GUI by establishing credentials with each. The authentication broker also authenticates a user when using a command prompt. In London, authentication broker 1 authenticates a credential with the master server, media server 1, and GUI 1. All NetBackup servers and clients in Tokyo and London authenticate to authentication broker 1 in London. GUI 1 authenticates to authentication broker 1 in London. GUI 2 authenticates to authentication broker 2 in Tokyo.
There is only one authorization engine required in a data center installation. The authorization engine communicates with the master server and media server to determine permissions of an authenticated user. These permissions determine the functionality available to the user. The authorization engine also stores user groups and permissions. The authorization engine resides in London and communicates with the master server, and media server 1. The authorization engine also communicates over the WAN to authorize access to media server 2 in Tokyo. Note: The authorization engine resides on the master server as a daemon process. It is shown in the figure as a separate image for example only.
Tapes
Unencrypted data tapes are produced in the London data center and in the Tokyo data center. In London, the unencrypted tape is written for clients 4 and 5 and stored on-site at the London data center. In Tokyo, the unencrypted tape is written for clients 10 and 11 and stored on-site at the Tokyo data center.
Clients
Clients are located in both the London and Tokyo data centers. In London, client 4 is a standard NetBackup type. Client 5 is a web server type located in the DMZ.
89
All client types are managed by the master server and have their data backed up to tape through media server 1. Client 5 communicates to NetBackup using NetBackup only ports through the internal firewall. Client 5 also receives connections from the Internet using http only ports through the external firewall. In Tokyo, client 10 is a standard NetBackup type. Client 11 is a web server type located in the DMZ. All client types are managed by the master server and have their data backed up to tape through media server 2. Client 11 communicates to NetBackup using NetBackup only ports through the internal firewall. Client 11 also receives connections from the Internet using http only ports through the external firewall
Internal firewalls
There are two internal firewalls in this multi-data center example. One internal firewall is located in London and the other is located in Tokyo. In London, the internal firewall allows NetBackup to access web server client 5 in the DMZ. In Tokyo, the internal firewall allows NetBackup to access web server client 11 in the DMZ. Only selected NetBackup ports and possibly other application ports are enabled for data communication through the internal firewall and into and out of the DMZ. Other ports, such as http, that are open in the External Firewall are not allowed to pass through the internal firewall.
DMZs
There are two Demilitarized Zones (DMZs) in this multi-data center example. One DMZ is located in London and the other is located in Tokyo. In London, the DMZ provides a safe area of operation for the web server client 5 that exists between the internal firewall and external firewall. The web server client 5 and client side encrypted client 6 in the DMZ can communicate to NetBackup through the internal firewall using designated NetBackup ports. The web server client 5 can also communicate through the external firewall to the Internet using only http ports. In Tokyo, the DMZ provides a safe area of operation for the web server client 11 that exists between the internal firewall and external firewall. The web server client 11 in the DMZ can communicate to NetBackup through the internal firewall using designated NetBackup ports. The web server client 11 can also communicate through the external firewall to the Internet using only http ports.
External firewalls
There are two external firewalls in this multi-data center example. One external firewall is located in London and the other is located in Tokyo. In London, the external firewall allows external users to access the web server client 5 located
in the DMZ from the Internet over http ports. NetBackup ports are open for web server client 5 to communicate through the internal firewall to NetBackup. The NetBackup ports are not allowed to pass through the external firewall to the Internet. Only the http ports of web server client 5 can pass through the external firewall to the Internet. In Tokyo, the external firewall allows external users to access the web server client 11 located in the DMZ from the Internet over http ports. NetBackup ports are open for web server client 11 to communicate through the internal firewall to NetBackup. The NetBackup ports are not allowed to pass through the external firewall to the Internet. Only the http ports of web server client 11 can pass through the external firewall to the Internet.
Internet
Security deployment models Multi-data center with NBAC complete
91
Multi-data center with NBAC complete
A multi-data center with NBAC complete (Figure 2-23 on page 92) example is defined as a medium to large group of hosts (greater than 50) that span two or more geographic regions and are connected by a Wide Area Network (WAN). In this example one data center is located in London and the other data center is located in Tokyo. Both data centers are connected through a dedicated WAN connection. This environment is very similar to the multi-data center with NBAC master and media server. The main differences are in the fact that all hosts participating in the NetBackup environment are reliably identified using credentials. And non-root administrators have the ability to manage the NetBackup clients based on configurable levels of access. Note that user identities may exist in global repositories such as Active Directory in Windows or NIS in UNIX. Identities can also exist in local repositories (UNIX passwd, local Windows domain) on those hosts supporting an authentication broker.
Highlights

NetBackup spanning two or more geographic regions through a WAN Similar to highlights for multi-data center with NBAC master and media server except for root or administrator on client. Non-root administration of clients and servers are permitted in this configuration. On client systems, non-root / administrator users may be configured to do local backup and restores (setup by default) The environment facilitates trusted identification of all hosts participating in NetBackup Requires all hosts to be at NetBackup version 5.0 and greater

Figure 2-23
93
NetBackup parts for multi-data center with NBAC complete

The NetBackup parts used with the multi-data center with NBAC complete implemented include the following items.

London data center Tokyo data center WAN Master server Media servers GUIs Root broker Authentication brokers Authorization engine Tapes Clients Internal firewalls DMZs External firewalls Internet
London data center

The London data center contains the root broker, authentication broker 1, GUI 1, authorization engine, master server, media server 1 and clients 1 and 5. The London data center also contains the unencrypted data tape for clients 1, 5, and 10. The London data center connects to the Tokyo data center through a dedicated WAN connection.
Tokyo data center

The Tokyo data center contains the authentication broker 2, GUI 2, media server 2 and clients 10 and 11. The Tokyo data center also contains the unencrypted data tape for clients 10 and 11. The Tokyo data center connects to the London data center through a dedicated WAN connection.
94 Security deployment models Multi-data center with NBAC complete
WAN
The dedicated Wide Area Network (WAN) link connects the London data center with the Tokyo data center. The WAN provides connectivity between the root broker and authentication broker 1 and authentication broker 2. In addition, the WAN provides connectivity between the root broker and authentication broker 1 and GUI 2 along with media server 2. The WAN connects the authorization engine to media server 2. The WAN connects the master server to GUI 2, media server 2, and clients 10 and 11. Finally the WAN connects media server 1 to client 10.
Master server
The master server, located in the London data center, communicates with the root broker and authentication broker 1, GUI 1, authorization engine, and media server 1. The master server also communicates with GUI 2 and media server 2, and clients 10 and 11 in Tokyo.
Media servers
There are two media servers in this multi-data center example. Media server 1 is located in the London data center and media server 2 is located in the Tokyo data center. In London, media server 1 communicates with the master server, root broker and authentication broker 1, authorization engine, and clients 1, 5, and 10. Media server 1 writes unencrypted data to tape for clients 1, 5, and 10. In Tokyo, media server 2 communicates with the master server, root broker and authentication broker 1 and authorization engine in London through the WAN. Media server 2 also communicates with GUI 2, and clients 10 and 11 in Tokyo. Media server 2 writes unencrypted data to tape for clients 10 and 11.
GUIs
There are two GUIs in this multi-data center example. The GUI 1 is in London and GUI 2 is in Tokyo. These remote administration console GUIs receive credentials from the authentication brokers. The GUIs then uses the credentials to gain access to functionality on the media and master servers. In London, GUI 1 receives a credential from authentication broker 1. GUI 1 has access to functionality on the master server and media servers 1 and 2. In Tokyo, GUI 2 receives a credential from the authentication broker 2. GUI 2 has access to functionality on the master server and media servers 1 and 2.
Root broker
There is only one root broker required in a multi-data center installation. Sometimes the root broker is combined with the authentication broker. In this
95
example the root broker and authentication broker are shown as the same component and are located in the London data center. In London, the root broker authenticates the authentication broker 1, also in London, and authentication broker 2 in Tokyo. The root broker does not authenticate clients.
There can be more than one authentication broker in a data center installation. Sometimes the authentication broker can be combined with the root broker. In this data center installation, there are two authentication brokers used. The authentication broker authenticates the master server, media server, GUI, and clients by establishing credentials with each. The authentication broker also authenticates a user when using a command prompt. In London, authentication broker 1 authenticates a credential with the master server, media server 1, GUI 1, and clients 1 and 5. All NetBackup servers and clients in Tokyo and London authenticate to authentication broker 1 in London. GUI 1 authenticates to authentication broker 1 in London. GUI 2 authenticates to authentication broker 2 in Tokyo.
There is only one authorization engine required in a data center installation. The authorization engine communicates with the master server and media server to determine permissions of an authenticated user. These permissions determine the functionality available to the user. The authorization engine also stores user groups and permissions. The authorization engine resides in London and communicates with the master server, and media server 1. The authorization engine also communicates over the WAN to authorize access to media server 2 in Tokyo. Note: The authorization engine resides on the master server as a daemon process. It is shown in the figure as a separate image for example only.
Tapes
Unencrypted data tapes are produced in the London data center and in the Tokyo data center. In London, the unencrypted tape is written for clients 1, 5 and 10 and stored on-site at the London data center. In Tokyo, the unencrypted tape is written for clients 10 and 11 and stored on-site at the Tokyo data center. Note that even though client 10 is located in Tokyo and is backed up in Tokyo, client 10 is also backed up in London.
96 Security deployment models Multi-data center with NBAC complete
Clients
Clients are located in both the London and Tokyo data centers. In London, client 1 is a standard NetBackup type. Client 5 is a web server type located in the DMZ. All client types are managed by the master server and have their data backed up to tape through media server 1. Client 5 communicates to NetBackup using NetBackup only ports through the internal firewall. Client 5 also receives connections from the Internet using http only ports through the external firewall. In Tokyo, client 10 is a standard NetBackup type. Client 11 is a web server type located in the DMZ. All client types are managed by the master server and have their data backed up to tape through media server 2. Client 11 communicates to NetBackup using NetBackup only ports through the internal firewall. Client 11 also receives connections from the Internet using http only ports through the external firewall
Internal firewalls
There are two internal firewalls in this multi-data center example. One internal firewall is located in London and the other is located in Tokyo. In London, the internal firewall allows NetBackup to access web server client 5 in the DMZ. In Tokyo, the internal firewall allows NetBackup to access web server client 11 in the DMZ. Only selected NetBackup ports and possibly other application ports are enabled for data communication through the internal firewall and into and out of the DMZ. Other ports, such as http, that are open in the External Firewall are not allowed to pass through the internal firewall.
DMZs
There are two Demilitarized Zones (DMZs) in this multi-data center example. One DMZ is located in London and the other is located in Tokyo. In London, the DMZ provides a safe area of operation for the web server client 5 that exists between the internal firewall and external firewall. The web server client 5 in the DMZ can communicate to NetBackup through the internal firewall using designated NetBackup ports. The web server client 5 can also communicate through the external firewall to the Internet using only http ports. In Tokyo, the DMZ provides a safe area of operation for the web server client 11 that exists between the internal firewall and external firewall. The web server client 11 in the DMZ can communicate to NetBackup through the internal firewall using designated NetBackup ports. The web server client 11 can also communicate through the external firewall to the Internet using only http ports.
97
External firewalls
There are two external firewalls in this multi-data center example. One external firewall is located in London and the other is located in Tokyo. In London, the external firewall allows external users to access the web server client 5 located in the DMZ from the Internet over http ports. NetBackup ports are open for web server client 5 to communicate through the internal firewall to NetBackup. The NetBackup ports are not allowed to pass through the external firewall to the Internet. Only the http ports of web server client 5 can pass through the external firewall to the Internet. In Tokyo, the external firewall allows external users to access the web server client 11 located in the DMZ from the Internet over http ports. NetBackup ports are open for web server client 11 to communicate through the internal firewall to NetBackup. The NetBackup ports are not allowed to pass through the external firewall to the Internet. Only the http ports of web server client 11 can pass through the external firewall to the Internet.
Internet
98 Security deployment models Multi-data center with all NetBackup security
Multi-data center with all NetBackup security
A multi-data center with all NetBackup security (Figure 2-24 on page 99) is defined as a medium to large group of hosts (greater than 50) that span two or more geographic regions and are connected by a Wide Area Network (WAN). In this example one data center is located in London and the other data center is located in Tokyo. Both data centers are connected through a dedicated WAN connection. This example combines all the previous examples together. It represents a very sophisticated environment in which there are differing requirements for a variety of clients. Client requirements can necessitate using encryption off host (such as an underpowered host, or a database backup). Client requirements can also necessitate using encryption on host due to the sensitive nature of the data on the host. Adding NBAC to the security mix allows segregation of administrators, operators, and users within NetBackup.
Highlights

NetBackup spanning two or more geographic regions through a WAN Please see the previous multi-data center sections for individual option highlights Most flexible and complex environment Careful design following a similar model will allow you to utilize the strengths of each option
Security deployment models Multi-data center with all NetBackup security
99
Figure 2-24

NetBackup parts for multi-data center with all security

The NetBackup parts used with all NetBackup security implemented include the following items.

London data center Tokyo data center WAN Master server Media servers GUIs Root broker Authentication brokers Authorization engine Tapes Transports Vaults off-site Clients Internal firewalls DMZs External firewalls Internet
London data center

The London data center contains the root broker, authentication broker 1, GUI 1, authorization engine, master server, media server 1, MSEO 1, clients 1 through 6, transport and vault off-site. The London data center also contains the encrypted data tape for clients 1, 2, 3, 6, and 7 and the unencrypted data tape for clients 4 and 5. The London data center connects to the Tokyo data center through a dedicated WAN connection.
Tokyo data center

The Tokyo data center contains the authentication broker 2, GUI 2, media server 2, MSEO 2, clients 7 through 12, transport and vault off-site. The Tokyo data center also contains the encrypted data tape for clients 7, 8, 9, and 12 and the
101
unencrypted data tape for clients 10 and 11. The Tokyo data center connects to the London data center through a dedicated WAN connection.
WAN
The dedicated Wide Area Network (WAN) link connects the London data center with the Tokyo data center. The WAN provides connectivity between the root broker and authentication broker 1 and authentication broker 2. In addition, the WAN provides connectivity between the root broker and authentication broker 1 and GUI 2 along with media server 2. The WAN connects the authorization engine to media server 2. The WAN connects the master server to GUI 2, media server 2, and clients 7 through 12. Finally the WAN connects media server 1 to client 7.
Master server
The master server, located in the London data center, communicates with the root broker and authentication broker 1, GUI 1, authorization engine, media server 1, and clients 1 through 6. The master server also communicates with GUI 2 and media server 2, and clients 7 through 12 in Tokyo.
Media servers
There are two media servers in this multi-data center example. Media server 1 is located in the London data center and media server 2 is located in the Tokyo data center. In London, media server 1 communicates with the master server, root broker and authentication broker 1, authorization engine, MSEO 1, and clients 1 through 6, and 7. Media server 1 writes unencrypted data to tape for clients 4 and 5 and encrypted data to tape for clients 1 through 6. In Tokyo, media server 2 communicates with the master server, root broker and authentication broker 1 and authorization engine in London through the WAN. Media server 2 also communicates with MSEO 2, GUI 2, and clients 7 through 12 in Tokyo. Media server 2 writes unencrypted data to tape for clients 10 and 11 and encrypted data to tape for clients 7, 8, 9, and 12.
GUIs
There are two GUIs in this multi-data center example. The GUI 1 is in London and GUI 2 is in Tokyo. These remote administration console GUIs receive credentials from the authentication brokers. The GUIs then uses the credentials to gain access to functionality on the media and master servers. In London, GUI 1 receives a credential from authentication broker 1. GUI 1 has access to functionality on the master server and media servers 1 and 2. In Tokyo, GUI 2
receives a credential from the authentication broker 2. GUI 2 has access to functionality on the master server and media servers 1 and 2.
Root broker
There is only one root broker required in a multi-data center installation. Sometimes the root broker is combined with the authentication broker. In this example the root broker and authentication broker are shown as the same component and are located in the London data center. In London, the root broker authenticates the authentication broker 1 also in London and the authentication broker 2 in Tokyo. The root broker does not authenticate clients.
There can be more than one authentication broker in a data center installation. Sometimes the authentication broker can be combined with the root broker. In this data center installation, there are two authentication brokers used. The authentication broker authenticates the master server, media server, GUI and clients by establishing credentials with each. The authentication broker also authenticates a user when using a command prompt. In London, authentication broker 1 authenticates a credential with the master server, media server 1, GUI 1, and clients 1 through 6. All NetBackup servers and clients in Tokyo and London authenticate to authentication broker 1 in London. GUI 1 authenticates to authentication broker 1 in London. GUI 2 authenticates to authentication broker 2 in Tokyo.
There is only one authorization engine required in a multi-data center installation. The authorization engine communicates with the master server and media servers to determine permissions of an authenticated user. These permissions determine the functionality available to a the user. The authorization engine also stores user groups and permissions. The authorization engine resides in London and communicates with the master server, and media server 1. The authorization engine also communicates over the WAN to authorize access to media server 2 in Tokyo. Note: The authorization engine resides on the master server as a daemon process. It is shown in the figure as a separate image for example only.
103
Tapes
Unencrypted and encrypted data tapes are produced in the London data center and in the Tokyo data center. In London, the unencrypted tape is written for clients 4 and 5 and stored on-site at the London data center. The encrypted tape is written for clients 1, 2, 3, 6, and 7, and is transported off-site to a vault in London for disaster recovery. In Tokyo, the unencrypted tape is written for clients 10 and 11 and stored on-site at the Tokyo data center. The encrypted tape is written for clients 7, 8, 9, and 12 and is transported off-site to a vault in Tokyo for disaster recovery protection. Note that even though client 7 is located in Tokyo and is backed up in Tokyo, client 7 is also backed up in London for even greater security and backup redundancy. Note: In order to decrypt the data, the key(s) used to encrypt the data must be made available.
Transports
There are two transports. One transport is located in London and the other is located in Tokyo. The transport truck in London moves the encrypted tape for clients 1, 2, 3, 6, and 7 off-site to a secure London vault facility. The transport truck in Tokyo moves the encrypted tape for clients 7, 8, 9, and 12 off-site to a secure Tokyo vault facility. Note that a backup copy of client 7 is vaulted both in London and in Tokyo. Note: If in the remote case a tape is lost during transport, the data center manager has potentially reduced the risk of a data breach through the use of client side data encryption.
Vaults off-site
Clients
Clients are located in both the London and Tokyo data centers. In London, clients 1 through 3 are MSEO encrypted types. Client 4 is a standard NetBackup type. Client 5 is a web server type located in the DMZ. Client 6 is a client side encrypted type also located in the DMZ. All client types are managed by the master server and have their data backed up to tape through media server 1. Client 5 communicates to NetBackup using NetBackup only ports through the internal firewall. Client 5 also receives connections from the Internet using http only ports through the external firewall. In Tokyo, clients 7 through 9 are MSEO encrypted types. Client 10 is a standard NetBackup type. Client 11 is a web server type located in the DMZ. Client 12 is a client side encrypted type also located in the DMZ. All client types are managed by the master server and have their data backed up to tape through media server 2. Note that client 7 is managed by both media server 1 and 2. Client 11 communicates to NetBackup using NetBackup only ports through the internal firewall. Client 11 also receives connections from the Internet using http only ports through the external firewall
Internal firewalls
There are two internal firewalls in this multi-data center example. One internal firewall is located in London and the other is located in Tokyo. In London, the internal firewall allows NetBackup to access web server client 5 and encrypted client 6 in the DMZ. In Tokyo, the internal firewall allows NetBackup to access web server client 11 and encrypted client 12 in the DMZ. Only selected NetBackup ports and possibly other application ports are enabled for data communication through the internal firewall and into and out of the DMZ. Other ports, such as http, that are open in the External Firewall are not allowed to pass through the internal firewall.
DMZs
There are two Demilitarized Zones (DMZs) in this multi-data center example. One DMZ is located in London and the other is located in Tokyo. In London, the DMZ provides a safe area of operation for the web server client 5 and encrypted client 6 that exist between the internal firewall and external firewall. The web server client 5 in the DMZ can communicate to NetBackup through the internal firewall using designated NetBackup ports. The web server client 5 can also communicate through the external firewall to the Internet using only http ports. In Tokyo, the DMZ provides a safe area of operation for the web server client 11 and encrypted client 12 that exist between the internal firewall and external firewall. The web server client 11 in the DMZ can communicate to NetBackup
105
through the internal firewall using designated NetBackup ports. The web server client 11 can also communicate through the external firewall to the Internet using only http ports.
External firewalls
There are two external firewalls in this multi-data center example. One external firewall is located in London and the other is located in Tokyo. In London, the external firewall allows external users to access the web server client 5 located in the DMZ from the Internet over http ports. NetBackup ports are open for web server client 5 to communicate through the internal firewall to NetBackup. The NetBackup ports are not allowed to pass through the external firewall to the Internet. Only the http ports of web server client 5 can pass through the external firewall to the Internet. In Tokyo, the external firewall allows external users to access the web server client 11 located in the DMZ from the Internet over http ports. NetBackup ports are open for web server client 11 to communicate through the internal firewall to NetBackup. The NetBackup ports are not allowed to pass through the external firewall to the Internet. Only the http ports of web server client 11 can pass through the external firewall to the Internet.
Internet
Chapter
Port security
This chapter on port security provides information on the communication that occurs between NetBackup parts using ports. It contains the following major sections:

Ports in general on page 108

NetBackup ports on page 108
Default NetBackup ports on page 109
Master server outgoing ports list on page 112
Media server ports list on page 115
EMM server ports list on page 117
Client outgoing ports list on page 120
Netware client outgoing ports list on page 122
Windows admin console or Java server outgoing ports list on page 124
Java console outgoing ports list on page 126
Configuring ports on page 127
Accept connections from non-reserved ports on page 127
Using random port assignments on page 129
Firewall connection options on a NetBackup server or client on page 130
Firewall connection options on media manager on page 134
Specifying NetBackup-Java connection options on page 135
Client attributes on page 135
Specifying port ranges on page 141
Miscellaneous port numbers on page 143
ICM port usage on page 144
108 Port security

Ports in general
NDMP port usage on page 145 Media Manager port usage on page 146 Port usage settings in NetBackup configuration - bp.conf on page 148 Configuring port usage client attribute settings - bpclient on page 153
Ports in general
A modern computer system is capable of running multiple applications simultaneously. Any application may have the requirement to either send or receive one or more packets of data to and from the network. In order to distinguish between application input and output flows of data, the operating system creates a separate input or output queue of data packets. These system queues are known within TCP/IP terminology as ports. NetBackup uses two classes of ports, commonly referred to as reserved ports or non-reserved ports.
Reserved ports
Reserved ports are those below 1024 and are (normally) only accessible to operating system components.
Non-reserved ports
Non-reserved ports are all those from 1024 and above that are accessible by user applications.
NetBackup ports
NetBackup uses TCP/IP connections to communicate between one or more TCP/IP ports. Depending on the type of operation and configuration on the environment, different ports are required to enable the connections. NetBackup has different requirements for operations such as backup, restore, and administration.
Call-back
For call-back information, refer to port information in the port chapter.
Port security Default NetBackup ports
109
Registered ports
Registered ports are those that are registered with the Internet Assigned Numbers Authority (IANA) and are assigned permanently to specific NetBackup services. For example, the port for the NetBackup client daemon, bpcd, is 13782. A system configuration file contains the default port numbers for each daemon. These files are as follows:

On UNIX systems, you can specify ports in the /etc/services file. On Windows systems, you can specify ports in the %systemroot%\System32\drivers\etc\services file.
Media Manager services include tape library control daemons. These daemons accept connections from daemons on other servers that share the same library. For more information, see the services file on the media server to determine the required ports for a specific library.
Dynamically allocated ports

Dynamically allocated ports are assigned, as needed, from ranges you can specify on NetBackup clients and servers. In addition to the range of numbers, you can configure the following for dynamically allocated ports:

NetBackup selects a port number at random from the allowed range. Or it starts at the top of the range and uses the first one available. Connections to bpcd on a client use reserved or non-reserved ports.
Overriding or modifying port numbers

Symantec suggests that you use the default port number settings for NetBackup services and Internet service ports. If you need to modify the port number for a daemon, make sure you modify the port number. It must be the same for all NetBackup master servers, media servers, and client systems that communicate with each other. When necessary, you can log a support call with Symantec Technical Services. Make the technical support representative aware of the use of non-standard ports throughout your NetBackup environment.
Default NetBackup ports

The following discusses NetBackup 6.5 NetBackup ports and port numbers.
110 Port security Default NetBackup ports
Default 6.5 NetBackup ports

The following sections show the NetBackup connections and ports used in 6.5 and in pre-6.5 systems. The following figures show the port connections between various NetBackup components. Figure 3-25 shows an example port connection and explains how the following figures represent the port connections. Figure 3-25 Port connections key
Port name Client Port Window
Destination port number Authentication Server
vrts-at-port/2821 Authenticates user or machine. Purpose
Destination
Source port number, taken from the client port window or the client reserved port window
Default port numbers for NetBackup 6.5

Table 3-2 lists the well known ports used within a NetBackup environment. Not all of the daemons are available in a base NetBackup installation. Some of them are enabled or used by add-on products, and the right-most column indicates which product uses the daemon. NetBackup 6.5 and later use additional ports when connected to NetBackup 5.1 and earlier. See the Default port numbers for NetBackup 4.5-5.1 section for more details. Table 3-2 Daemon or Process
VNETD
Port numbers for NetBackup 6.5 Port Product Number

13724 NetBackup
Purpose
Network daemon.
Port security Default NetBackup ports
111
Table 3-2 Daemon or Process

VOPIED
Port numbers for NetBackup 6.5 (Continued) Port Product Number

13783 NetBackup
Purpose
One-time Password user authentication daemon. It authenticates user names, hosts names, and group/domain names. On UNIX clients, this daemon can only be run in standalone mode. On Windows clients, it always runs under the supervision of BPINETD.EXE. Veritas Private Branch Exchange Service Veritas Authentication Service Veritas Authorization Service
VERITAS_PBX VRTS-AT-PORT
1556 2821
VxPBX VxAT VxAZ
VRTS-AUTH-PORT 4032
112 Port security Master server outgoing ports list
Master server outgoing ports list

The master server uses outgoing ports to the EMM server, media server, clients, Symantec product authentication and authorization service (shown as VxSS Server), Netware client, Java console, and admin console or Java Server. Figure 3-26 Master server outgoing ports
Port security Master server outgoing ports list
113
Figure 3-27
6.5 master server Client port window
6.5 master server minimal outgoing port connections - part 1
vnetd/13724 - Determines NetBackup version of media server. - Starts bpbrm for backups and restores. - Starts bptm to manage tape storage units. - Starts bpstsinfo to manage disk storage units. - Accesses or updates host properties for media server. veritas_pbx/1556 - Connect-back for job information. - Connect-back for resource information.
6.5 media server
Client port window
Client port window
veritas_pbx/1556 - Access information about device, media, and storage

databases.
vnetd/13724 - Determines NetBackup version of client. - Gets list of mount points for multistreamed backups. - Accesses or updates host properties for client.
EMM server
Client port window
6.5 Client
114 Port security Master server outgoing ports list
Figure 3-28
6.5 master server
6.5 master server minimal outgoing port connections - part 2
Client port window
veritas_pbx/1556 - Connect-back for activity monitor.
Administrative Console or Java Server
Client port window
veritas_pbx/1556 - connect-back for job monitor.
Java console
Client port window
vnetd/13724 - Determines NetBackup version of client. NetWare Client
Client reserved port

window
bpcd/13782 - Accesses or updates host properties for client.
Client port window
If using legacy security: vopied/13783 - Authenticates and authorizes user for administration.
Administrative Console or Java Server Client with legacy security
Client port window
vopied/13783 - Authenticates user for database backup, user backup, or restore. If NBAC is enabled: vrts-at-port/2821 - Authenticates user or machine.
Client port window
Authentication Server
Client port window
If NBAC is enabled: vrts-auth-port/4032 - Authorizes user for administration.
Authorization Server
Port security Media server ports list
115
Media server ports list

The media server uses outgoing ports to the EMM server, other media servers, clients, Symantec product authentication and authorization service (shown as VxSS Server), Netware client, and the admin console or Java Server. Figure 3-29 Media server outgoing ports
116 Port security Media server ports list
Figure 3-30
6.5 media server minimal outgoing port connections - part 1
6.5 media server Client port window vnetd/13724 - Accesses legacy policy information from bpdbm. - Accesses legacy job information from bpjobd. - Updates image catalog information to bpdbm. - Makes miscellaneous requests to bprd. Client port window veritas_pbx/1556 - Accesses job information. - Accesses resource information. Client port window vnetd/13724 - Establishes sockets to other media servers for duplication, disk staging, and synthetics. Client port window veritas_pbx/1556 - Accesses information about device, media, and storage databases. Client port window vnetd/13724 - Determines the NetBackup version of the client. - Establishes sockets to back up or restore a client. 6.5 media server
6.5 master server
EMM server
6.5 Client
Client port window Client reserved port window
bpcd/13782 - Establishes sockets to back up or restore a client. vnetd/13724 - Determines Net backup version of client. NetWare Client
Port security EMM server ports list
117
Figure 3-31
6.5 media server minimal outgoing port connections - part 2
6.5 media server
Client port window
If using legacy security: vopied/13783 - Authenticates and authorizes user for administration. If NBAC is enabled: vrts-at-port/2821 - Authenticates user or machine.
Administrative Console or Java Server
Client port window
Client port window
If NBAC is enabled: vrts-auth-port/4032 - Authorizes user for administration.
EMM server ports list

The EMM server uses outgoing ports to the Symantec product authentication and authorization service (shown as VxSS Server), media servers, master server, and the admin console or Java Server.
118 Port security

EMM server ports list
Figure 3-32
EMM outgoing ports
Port security EMM server ports list
119
Figure 3-33
Enterprise Media Manager (EMM) minimal outgoing port connections
EMM server
Client port window
veritas_pbx/1556 - Connect-back for information about device, media and storage databases. veritas_pbx/1556 - Connect-back for information about device, media and storage databases. veritas_pbx/1556 - connect-back for information about device, media and storage databases. If NBAC is enabled: vrts-at-port/2821 - Authenticates user or machine. vrts-auth-port/4032 - Authorizes user for administration.
6.5 master server
Client port window
6.5 media server Administrative Console or Java Server
Client port window
Client port window
Client port window
120 Port security Client outgoing ports list
Client outgoing ports list

The client uses outgoing ports to the Symantec product authentication and authorization service (shown as VxSS Server) and master server. Figure 3-34 Client outgoing ports
Port security Client outgoing ports list
121
Figure 3-35
6.5 client (non-NetWare) minimal outgoing port connections
6.5 Client Client port window vnetd/13724 - Makes backup, restore, and miscellaneous requests to bprd. vrts-at-port/2821 - Authenticates user or machine.
6.5 master server
Client port window
122 Port security Netware client outgoing ports list
Netware client outgoing ports list

The Netware client uses outgoing ports to the master server. Figure 3-36 Netware outgoing ports
Port security Netware client outgoing ports list
123
Figure 3-37
6.5 NetWare client minimal outgoing port connections
6.5 NetWare Client Client port window bprd/13720 - Makes backup, restore, and miscellaneous requests to bprd. 6.5 master server Client reserved port window vnetd/13724 - Connect back for bpcd requests from the master.
Client port window
vnetd/13724 - Connect back for bpcd requests from the media server.
6.5 media server
124 Port security Windows admin console or Java server outgoing ports list
Windows admin console or Java server outgoing ports list

The admin console or Java Server uses outgoing ports to the EMM server, master server, media server, and Symantec product authentication and authorization service (Shown as VxSS Server). Figure 3-38 Admin console outgoing ports
Port security Windows admin console or Java server outgoing ports list
125
Figure 3-39
Java server or Windows Administration Console minimal outgoing port connections
Administrative Console or Java Server Client port window Client port window veritas_pbx/1556 - Accesses job manager (nbjm). vnetd/13724 - Manages policies. - Manages host properties. - Starts manual backups and restores. 6.5 master server
Client port window
vnetd/13724 - Accesses devices. veritas_pbx/1556 - Accesses device, media, and storage unit databases.
media server
Client port window
EMM server
Client port window
vrts-at-port/2821 - Establishes user credentials for administration.
126 Port security Java console outgoing ports list
Java console outgoing ports list

The Java console uses outgoing ports to the master server and admin console or Java Server. Figure 3-40 Java console outgoing ports
Port security Configuring ports
127
Figure 3-41
Java console Client port window vnetd/13724
Java console minimal outgoing port connections
- Establishes sockets with the legacy job manager (bpjobd). Client port window veritas_pbx/1556 - Establishes sockets with the job manager (nbjm). Client port window vnetd/13724 - Establishes sockets with the Java server (bpjava).
6.5 master server
Java server
Configuring ports
This chapter describes: how to configure the various non-default port configurations that you might need in your environment to support firewalls and other features of your network. You can set the configuration options in this chapter: from both the graphical user interface (for Java or Windows) or from the command line (on UNIX or Windows). The instructions in this chapter describe how to set the configuration options using the graphical user interface. For information on setting configuration options from the command line, see Configuring port usage without a GUI on page 147.
Accept connections from non-reserved ports

The Accept connections from non-reserved ports setting: specifies that the NetBackup client service (bpcd) can accept remote connections from non-reserved ports, which are those with port numbers 1024 and greater. If this setting is not specified, bpcd requires remote connections to come from reserved ports, which are ports numbers less than 1024. The Accept connections from non-reserved ports setting is useful when NetBackup clients and servers are on opposite sides of a firewall. For NetBackup 5.1 and earlier, this setting is disabled by default, which has the following effects:

NetBackup does not accept remote connections from non-reserved ports. The source ports for connections to bpcd use reserved ports. If this setting is specified on a client/server, and you want to use non-reserved ports, the
128 Port security Accept connections from non-reserved ports
server connecting to the client/server must also be configured to use non-reserved ports for the client. For NetBackup 6.5 and later, this setting is enabled by default. If the system making the bpcd connection is NetBackup 6.5 or later, and the system accepting the bpcd connection is NetBackup 6.5 or later (other than the Netware client), the default is to always use non-reserved port numbers. If the system accepting the bpcd connection is NetBackup 5.1 or earlier or a Netware client, the default is to use reserved ports. To enable nonreserverd ports from the Java or Windows interface 1 2 3 In the NetBackup Administration Console, expand NetBackup Management > Host Properties > Master Servers. Double click the host you want to configure. Click Universal Settings. A display similar to the following appears: Universal settings
Figure 3-42
Check Accept connections from non-reserved ports.
Port security Using random port assignments
129
Using random port assignments
The following sections describe how to configure random port assignments in the NetBackup configuration and in the media manager configuration.
Random port assignments in the NetBackup configuration

The Use random port assignments setting specifies: when NetBackup requires a port number for communication with NetBackup on other computers, it can randomly choose one from those that are free in the allowed range. This is the default behavior. Example If the range is from 1023 through 5000, it chooses randomly from the numbers in this range. If this setting is changed from the default, NetBackup chooses numbers sequentially, starting with the highest number that is available in the allowed range. Example If the range is from 1023 through 5000, NetBackup chooses 5000, assuming it is free. If 5000 is used, NetBackup chooses port 4999. This setting is enabled by default. To disable random port assignments from the Java or Windows interface 1 2 3 4 In the NetBackup Administration Console, expand NetBackup Management > Host Properties > Master Servers. Double click the host you want to configure. Click Universal Settings. Uncheck Use random port assignments.
Random port assignments in the media manager configuration

The random ports setting for Media Manager works the same way as it does for the general NetBackup configuration. The Use random port assignments setting specifies that when Media Manager requires a port number for communication with Media Manager on other computers, it can randomly choose one from those that are free in the allowed range. This is the default behavior. Example If the range is from 1023 through 5000, it chooses randomly from the numbers in this range.
130 Port security

Firewall connection options on a NetBackup server or client
If this setting is changed from the default, Media Manager chooses numbers sequentially, starting with the highest number that is available in the allowed range. Example If the range is from 1023 through 5000, Media Manager chooses 5000, assuming it is free. If 5000 is used, Media Manager chooses port 4999. This setting is enabled by default. Note: Specify the same port selection for NetBackup as you do for Media Manager. That is, if you specify random ports in the NetBackup configuration, also specify random ports in the Media Manager configuration.
Firewall connection options on a NetBackup server or client

The connect options specify how connections are made between computers. You specify the settings on the computer that initiates the connection (source computer) for the server to which it connects (destination computer). Example If there is a firewall between the master server and the media servers, you can specify the settings from the master server (source computer) for each of the media servers (destination computers) to which the master server connects. You can define the connect options between the source computer and specific destination computers. If the source computer is running NetBackup 6.5 or later, you also can set default connection options applying to all other destination computers. To specify Firewall default connect options for a NetBackup 6.5 or later source computer from the Java or Windows interface 1 2 3 4 In the NetBackup Administration Console, expand NetBackup Management > Host Properties > Master Servers. Double click the host you want to configure. Click Firewall. Click Change in the Default Connect Options pane. A display similar to the following appears:
Port security Firewall connection options on a NetBackup server or client
131
Figure 3-43
Default connect options
You can set the following connection options from the display:

Ports (reserved versus non-reserved) BPCD connect-back Daemon connection port
If the source computer is a NetBackup client (not a server), only the Daemon
connection port setting apply.
The following sections describe these settings.
Ports
The use non-reserved ports setting determines whether the source computer connects to bpcd on destination computers using a reserved or a non-reserved source port number. By default, the use reserved ports setting is specified. This means that the source computer connects to bpcd on destination computers using a reserved port number. If you change the default, use non-reserved ports goes into effect. This means that the source computer connects to bpcd on destination computers using a non-reserved port number. In addition, if use non-reserved ports is specified, configure the host to allow connections on non-reserved ports. For reconfiguration information, see Accept connections from non-reserved ports on page 127.
132 Port security Firewall connection options on a NetBackup server or client
Note: This setting generally has no effect if both the source and destination computers are NetBackup 6.5 or later and the destination computer is not a Netware client. By default, non-reserved ports are always used in that case. See the note in the Daemon connection port description.
BPCD connect-back
The BPCD connect-back setting specifies: 1) whether the host can be connected to by another computer using the legacy bpcd random port call back method, or 2) by using the Veritas Network Daemon (vnetd). By default for NetBackup 5.1 or earlier, the BPCD connect-back is Random port. This means that the connection uses the legacy random port call-back method. If BPCD connect-back is VNETD port, other computers connect to the host using vnetd, which does not require random port call back. This is the default for NetBackup 6.5 and later. Note: This setting generally has no effect if both the source and destination computers are NetBackup 6.5 or later and the destination computer is not a Netware client. By default, call-back is not used in that case. See the note in the Daemon connection port description.
Daemon connection port

The Daemon connection port setting specifies one of the following methods for computers to use when connecting to the host:

Automatic (default for NetBackup 6.5 and later). Specifies that connections to the daemons on the host be made using vnetd if possible. If it is not possible to use vnetd, the connection is made using the daemon's legacy port number. VNETD only. Specifies that connections to the daemons on the host be made using vnetd only. If your firewall rules prevent connecting to the host using the legacy port number, make sure that vnetd is used. Daemon port only (default for NetBackup 5.1 and earlier). Specifies that connections to the host be made using only the legacy port number.
Port security Firewall connection options on a NetBackup server or client
133
Note: For NetBackup 5.1 and earlier, connections to bpcd are always made with the legacy bpcd port number. Connections to bpcd can be made with the vnetd port number if both the source and destination computers are NetBackup 6.5 or later and the destination computer is not a Netware client. When bpcd connections are made using the vnetd port number, the Ports and BPCD connect-back settings are ignored. The default in that case is to use non-reserved source port numbers, the vnetd destination port number, and no call-back.
Note: Connections to vopied, veritas_pbx, veritas-at-port, and veritas-auth-port are not affected by this setting. Those connections always use the legacy or IANA defined port numbers. To specify Firewall connect options for a source computer to apply to specific destination computers from the Java or Windows interface 1 2 3 4 In the NetBackup Administration Console, expand NetBackup Management > Host Properties > Master Servers. Double click the host you want to configure. Click Firewall. Click Add in the Hosts pane. Add a destination host (usually another NetBackup server) to the hosts list shown in the following figure.
134 Port security Firewall connection options on media manager
Figure 3-44
Master server properties - firewall
Select the appropriate values from the BPCD connect back, Ports, and Daemon connection port menu items. The values available in these menu items include the values available in the Default Connect Options described previously. You can also specify Use default connect options. This means that the value for the specified destination host uses the value from Default Connect Options instead.
Firewall connection options on media manager

In NetBackup 6.5 and later, the Media Manager defaults to the NetBackup connection options described above unless overridden by the vm.conf CONNECT_OPTION entries. For NetBackup 5.1 and earlier, Media Manager connection options must be specified in vm.conf. Unlike the NetBackup master servers or clients, there is no graphical user interface for changing the firewall connections for Media Manager. For information on changing the vm.conf file for Media Manager, see Configuring port usage without a GUI on page 147.
Port security Specifying NetBackup-Java connection options
135
Specifying NetBackup-Java connection options
Unlike the NetBackup master servers or clients, there is no graphical user interface to use to change the NBJAVA_CONNECT_OPTION. The /usr/openv/java/nbj.conf file on UNIX and the nbjava_install_path\java\setconf.bat file on Windows contain the configuration settings that you might want to change if you configure ports. These options are as follows: NBJAVA_CONNECT_OPTION=setting
NBJAVA_CLIENT_PORT_WINDOW=n m
For information on changing these settings, see one of the following manuals:

NetBackup Administrators Guide for UNIX and Linux, Volume I NetBackup Administrators Guide for Windows, Volume I
Client attributes
The Client Attributes tab lets you specify several connect options. These options all define how a master or media server can connect to a client. Example You can specify reserved or non-reserved ports, Note: If a master or media server is configured to connect to a client using non-reserved ports, use the procedure that follows: Specifying ports (reserved or non-reserved) on page 136, to configure that client to accept remote connections from non-reserved ports. To specify client attributes from the Java or Windows interface 1 2 3 In the NetBackup Administration Console, expand NetBackup Management > Host Properties > Master Servers. Double click the host you want to configure. Click Client Attributes. A display similar to the following appears:
136 Port security

Client attributes
Figure 3-45
Client attributes - main screen
The following sections describe how to enable or disable the following settings:

Specifying ports (reserved or non-reserved ports) Specifying a BPCD connect-back method Specifying a Daemon connection port
Specifying ports (reserved or non-reserved)

By default, a master or media server uses a reserved port when it connects to bpcd on a client. This means that the Reserved ports selection is in effect. You can use the following procedure to change this setting. To specify reserved or non-reserved ports 1 Make sure that you are in the Client Attributes display. For information on how to get to the Client Attributes display, see the procedure: To specify client attributes from the Java or Windows interface on page 135. Make sure that the client(s) you want to configure show in the Clients pane. To add a client, click Add... and type the name of the client you want to add in the dialog box that appears. When you are finished adding clients, click Close.
Port security Client attributes
137
3 4
Click the Connect Options tab. In the Ports dropdown list, select either Reserved ports, Non-reserved ports, or Use default connect options. The display for these options is as follows: The Ports dropdown list
Figure 3-46
Selecting Reserved ports specifies that master and media server use a reserved port when connecting to bpcd on this client. Selecting Non-reserved ports specifies that master and media servers use a non-reserved port when connecting to bpcd on the client. Selecting Use default connect options specifies that master and media servers use the CONNECT_OPTIONS or DEFAULT_CONNECT_OPTIONS. These options are defined on the master or media server that connects to the client.
5 6
Click Apply when you are finished specifying ports. Click OK to exit from the Client Attributes interface.
Note: By default, if both the server and the client are NetBackup 6.5 or later and the client is not Netware, this setting is not applicable. Non-reserved ports are always used in that case. See the following note in the description of the Daemon connection port setting.
138 Port security

Client attributes
Specifying a BPCD connect-back method

The BPCD connect-back method specifies how the client responds when a
master or media server connects to bpcd on the client.
By default, the client connects back to the master or media server on the VNETD
port number. This means that the VNETD port selection is in effect. You can use
the following procedure to change this setting.
To specify a BPCD connect-back method 1 Make sure that you are in the Client Attributes display. For information on how to get to the Client Attributes display, see the following procedure: To specify client attributes from the Java or Windows interface on page 135. Make sure that the client(s) you want to configure show in the Clients pane. To add a client, click Add... and type the name of the client you want to add in the dialog box that appears. When you are finished adding clients, click Close. Click the Connect Options tab. In the BPCD connect back dropdown list, select either Random port, VNETD port, or Use default connect options. This display is as follows: BPCD connect back dropdown list
3 4
Figure 3-47
Port security Client attributes
139
Selecting Random port specifies that the client connect back to the master and media server using a random port number. Selecting VNETD port specifies that the client connect back to the master and media server using the vnetd port number.
Selecting Use default connect options specifies that the client connect back to the master and media server the CONNECT_OPTIONS or DEFAULT_CONNECT_OPTIONS that are defined on the master or media server that connects to the client. Default. 5 6 Click Apply when you are finished specifying a method. Click OK to exit from the Client Attributes interface.
Note: By default, if both the server and the client are NetBackup 6.5 or later and the client is not Netware, this setting is not applicable. Connect back is not used in that case. See the following note in the description of the Daemon connection port setting.
Specifying a Daemon connection port

The Daemon connection port specifies which destination port the server uses to connect to the client. By default if both server and client are NetBackup 6.5 or later, the connection will be on the vnetd port number. All other server to client bpcd connections are on the legacy bpcd port number. You can use the following procedure to change this setting. To specify a Daemon connection port 1 Make sure that you are in the Client Attributes display. For information on how to get to the Client Attributes display, see the procedure: To specify client attributes from the Java or Windows interface on page 135. Make sure that the client(s) you want to configure show in the Clients pane. To add a client, click Add... and type the name of the client you want to add in the dialog box that appears. When you are finished adding clients, click Close. Click the Connect Options tab. In the Daemon connection port dropdown list, select either Automatic, VNETD port only, Daemon port only, or Use default connect options.
3 4
This display is as follows:
140 Port security

Client attributes
Figure 3-48
Client Attributes - daemon connection ports
Selecting Automatic specifies that the server attempts to connect to bpcd on the client using the vnetd port number. If that fails, the server attempts to connect to bpcd on the client using the legacy bpcd port number. Selecting VNETD only specifies that the server attempts to connect to bpcd on the client using the vnetd port number. Do not select this option if the client is NetBackup 5.1 or earlier or if the client is Netware. Selecting Daemon port only specifies that the server attempts to connect to bpcd on the client using the legacy bpcd port number. Selecting Use default connect options specifies: the port number used by the server to connect to bpcd on the client using the CONNECT_OPTIONS or DEFAULT_CONNECT_OPTIONS. These options are defined on the master or media server that connects to the client. Default.
5 6
Click Apply when you are finished specifying a method. Click OK to exit from the Client Attributes interface.
Port security Specifying port ranges
141
Note: For NetBackup 5.1 and earlier, connections to bpcd are always made with the legacy bpcd port number. Connections to bpcd can be made with: the vnetd port number if both the server and client are NetBackup 6.5 or later and the client is not Netware. When bpcd connections are made using the vnetd port number, the Ports and BPCD connect-back settings are ignored. The default in that case is to use non-reserved source port numbers, the vnetd destination port number, and no connect-back.
Specifying port ranges

The following sections describe how to specify the numbers for the ranges of ports. Note: For all port windows, if you specify a 0 in the From box, the software uses a non-reserved port of the operating systems choosing. To specify port ranges 1 2 3 In the NetBackup Administration Console, expand NetBackup Management > Host Properties > Master Servers. Double click the host you want to configure. Click Port Ranges. A display similar to the following appears:
142 Port security

Specifying port ranges
Figure 3-49
Port ranges
Use Table 3-3 as a guide when specifying ports. Table 3-3 Port
Client Port Window
Port ranges Purpose

Specifies the range of non-reserved source port numbers that this computer uses to connect to most NetBackup services.
Default range
0-0 The operating system chooses the port.
Client Reserved Port Window Server Port Window
Specifies the range of reserved source port numbers that this computer 512 - 1023 uses to connect to bpcd with the legacy bpcd destination port number. Specifies the range of non-reserved destination port numbers that 1024 - 5000 other computers use to connect to this computer for bpcd connect back. Specifies the range of reserved destination port numbers that other computers use to connect to this computer for bpcd connect back 512 - 1023
Server Reserved Port Window
4 5
Click Apply Click OK
The Client Reserved Port Window, Server Port Window, and Server Reserved Port Window settings are not applicable to NetBackup clients.
Port security Miscellaneous port numbers
143
By default, the Server Port Window and Server Reserved Port Window settings are not used for NetBackup 6.5 or later. They are not used unless connecting to bpcd on a NetBackup 5.1 or earlier Netware client. By default, Client Reserved Port Window setting is not used for NetBackup 6.5 or later. They are not used if connecting to a destination computer running NetBackup 6.5 or later that is not a Netware client.
Miscellaneous port numbers

The following sections describe the BPJAVA_PORT, VNETD_PORT, BPCD, and BPRD ports.
BPJAVA_PORT and VNETD_PORT

BPJAVA_PORT is the configured port for the bpjava_msvc daemon process. VNETD_PORT is the configured port for the vnetd daemon process. These ports are registered with IANA. Caution: Symantec does not recommend changing these ports. If the ports for these processes need to be changed, make the change on all NetBackup hosts in the relevant NetBackup cluster. This information is described in the NetBackup Installation Guide for UNIX or the NetBackup Installation Guide for Windows. In addition, specify the value in the corresponding nbj.conf option.
BPCD and BPRD ports

The BPCD port is the configured port for the bpcd daemon process. The BPRD port is the configured port for the bprd daemon process. These ports are registered with IANA. Caution: Symantec does not recommend changing these ports. If the ports for these processes need to be changed, make the change on all
NetBackup hosts.
On Windows hosts, use the following procedure to set the value for all Windows
computers. This procedure is used in addition to making the change in all the
relevant services files:
144 Port security

ICM port usage
To change the ports for BPCD and BPRD on Windows 1 2 3 4 5 On Windows, click through Start > All Programs > Veritas NetBackup > Backup, Archive, and Restore. In the Backup, Archive, and Restore window, click File > NetBackup Client Properties. Select the Network tab. Change the values. Click OK.
If the services file is not changed and the bpcd port is changed using the preceding procedure, the change is reflected in the NetBackup configuration. A difference exists between the value that is in the NetBackup configuration and the services file. Next time NetBackup Client Service is started on the computer, it automatically updates the services with the value that appears in the NetBackup configuration.
ICM port usage

Windows system administration console
By default, the NetBackup Windows administration console pings the computers it communicates with to ensure that they are alive before attempting to connect to them. If the ICMP protocol is blocked in a network, the NetBackup Windows administration console might no longer function. You can use the following procedure to disable the ping that the NetBackup Windows administration console performs by default. Note: For 6.5 release, ping by default is already disabled. For 5.x releases, use the following procedure to disable ping. To disable the ping on a NetBackup Windows administration console 1 2 3 4 Select the View menu. Select the Options menu item. When the dialog appears, select the Administration Console tab. On that tab, select the box for Disable ping connection checking.
Port security NDMP port usage
145
NDMP port usage

ICMP pinging NDMP
On UNIX systems, the NetBackup avrd process uses the Internet Control Message Protocol (ICMP) when it pings NDMP hosts to verify network connectivity. If a ping fails, NetBackup skips this particular device, which leaves the status of the drive as up. On Windows systems, NetBackup does not ping the NDMP device. It tries the connection. If the network experiences connectivity problems, this method can take longer as NetBackup waits for a timeout.
NDMP in a firewall environment

If you use an NDMP storage unit in a firewall environment, make sure you know the different types of NDMP backups to be performed. The backup type determines which ports need to be opened in the firewall. The following paragraphs describe the types of NDMP backups and how they pertain to firewall use. These backup types include local, 3-way and remote NDMP, remote NDMP and local and 3-way TIR.

For local operations, the DMA needs access to port 10,000 on the NDMP server. In this case, the one NDMP server is both the NDMP tape server and the NDMP data server. For 3-way and remote NDMP, the DMA needs access to port 10,000 on the NDMP tape server and the NDMP data server. There cannot be a firewall between the NDMP tape server and the NDMP data server. No firewall is needed because control is not required over the TCP/IP ports that are used for the data movement. For remote NDMP (5.0 / 5.1), a firewall is not suggested between: the DMA and the NDMP hosts because the DMA can be on the same computer as the NDMP tape server. You need an unlimited number of ports available to perform the data movement between the NDMP tape server and the NDMP data server. For local and 3-way TIR, the data requires an unlimited number of ports available because NetBackup has no control over the ports used.
146 Port security Media Manager port usage
Media Manager port usage

ACS storage server interface
ACSSEL
ACSSEL is an ACS robotic process. It is the ACS SSI Event Logger. It is modeled after the mini_el event logger provided by StorageTek, so its functional model differs slightly from other robotic test tools provided with Media Manager. By default, ACSSEL listens on socket name (or IP port) 13740. If this entry is specified in vm.conf, you can change the default. This entry is read and interpreted where acsd is running, and the format for this entry is as follows: ACS_SEL_SOCKET = socket_name
ACSSSI
ACSSSI is an ACS robotic process. By default, ACSSSI listens on unique, consecutive socket names starting as 13741. To specify socket names on an ACS library software host basic, add a configuration entry in vm.conf. This entry is read and interpreted on the host where acsd and acsssi are running, and the format for this entry is as follows: ACS_SSI_SOCKET = ASC_library_software_host socket_name Example ACS_SSI_SOCKET = Einstein 13750
Additional Media manager port information

The following sections describe known firewall problems that you might encounter when using NetBackup with certain other products.
ACS
Communication is required between the media server that has the ACS drives configured and the ACS server. But NetBackup has no control over the communication between these computers. The communication is handled via a RPC mechanism without a common port. It is not possible to define the ports that would need to be open if there were a firewall between the media server and the ACS server.
TLH
Communication is required between the media server that has the robotic control and the server that has IBM's Library Manager. This communication is through an unknown network port, and NetBackup has no control over that port
Port security Media Manager port usage
147
number. It is not possible to define the ports that would need to be open if there were a firewall between the media server and the IBM Library Manager server.
LMF
Communication is required between the media server that has the robotic control and Fujitsu's LMF server. This communication is through an unknown network port, and NetBackup has no control over that port number. It is not possible to define the ports that would need to be open if there were a firewall between the media server and Fujitsu's LMF server.
TLM
Communication is required between the media server that has the robotic control and ADICs DAS/SDLC server. NetBackup has no control over the communication mechanism and does not know which ports are used between the media server and ADICs DAS/SDLC server. It is not possible to define the ports that would need to be open if there were a firewall between the media server and ADICs DAS/SDLC server.
Configuring port usage without a GUI

The following sections summarize how to configure port usage settings without a GUI. This appendix is not intended to provide details on using commands to change settings. For more information on any of these commands or files, see the following resources:

NetBackup Administrators Guide for UNIX and Linux, Volumes I and II NetBackup Administrators Guide for Windows, Volumes I and II NetBackup Media Manager Administrators Guide for UNIX NetBackup Media Manager Administrators Guide for Windows NetBackup Commands for UNIX and Linux NetBackup Commands for Windows
148 Port security Port usage settings in NetBackup configuration - bp.conf
Port usage settings in NetBackup configuration -

bp.conf
This section describes the NetBackup configuration settings related to port usage. All of the NetBackup configuration settings are described in NetBackup Administrator's Guide for UNIX and Linux, Volume II in the Additional Configuration/NetBackup Configuration Options section. On UNIX or Linux systems, you can edit the /usr/openv/netbackup/bp.conf file directly to update several port usage settings for the local computers NetBackup configuration. Typically, you would use a text editor such as vi(1) to read and update the file. You can also use the bpgetconfig and bpsetconfig commands from UNIX, Linux, or Windows NetBackup servers to read and update NetBackup configuration for local or remote computers. The bpgetconfig(1M) and bpsetconfig(1M) commands are described in the NetBackup Commands for UNIX and Linux and the NetBackup Commands for Windows manuals. Typically, you would read the configuration with the bpgetconfig command and copy it into a temporary file, edit the configuration in the temporary file and then use the bpsetconfig command to update the configuration from the temporary file. Example You might issue the following commands to update the NetBackup configuration of the computer client1: bpgetconfig -M client1 > conf.txt
vi conf.txt # if UNIX or Linux
notepad conf.txt # if Windows
bpsetconfig -h client1 conf.txt
Port usage-related NetBackup configuration settings

ALLOW_NON_RESERVED_PORTS = YES | NO
Specifies if the NetBackup client daemon (bpcd) on the local computer can accept remote connections from non-reserved ports (port numbers 1024 or greater).

NO (default for NetBackup 5.1 and earlier) means that bpcd requires remote connections to come from reserved ports (port numbers less than 1024). YES (default for NetBackup 6.5 and later) means that bpcd allows remote connections to come from non-reserved ports (port numbers less than 1024).
Port security Port usage settings in NetBackup configuration - bp.conf
149
This option can be useful when NetBackup clients and servers are on opposite sides of a firewall. You should specify YES for this setting if NetBackup servers are configured via the DEFAULT_CONNECT_OPTIONS or CONNECT_OPTIONS settings or bpclient command line to connect to the local computers bpcd with non-reserved source port numbers. This setting can also be configured in the NetBackup Administration GUI by using the Host Properties > Universal Settings > Accept Connections on Non-reserved Ports checkbox.
RANDOM_PORT = YES | NO
Specifies whether NetBackup chooses source port numbers randomly or sequentially when it requires one for communication with NetBackup on other computers.

YES (the default) means that NetBackup chooses port numbers randomly from those that are free in the allowed range. Example If the range is from 1024 through 5000, it chooses randomly from the numbers in this range.
NO means that NetBackup chooses numbers sequentially, starting with the highest number that is available in the allowed range. Example If the range is from 1024 through 5000, NetBackup chooses 5000 (assuming it is free). If 5000 is used, port 4999 is chosen.
The allowed port ranges are determined by the CLIENT_PORT_WINDOW and CLIENT_RESERVED_PORT_WINDOW settings.
This setting can also be configured in the NetBackup Administration GUI via the
Host Properties > Port Ranges > Use random port assignments checkbox.
CLIENT_PORT_WINDOW = min max

Specifies the range of non-reserved source ports on this computer that are used for connecting to NetBackup on other computers. This setting applies to most NetBackup connection. The CLIENT_RESERVED_PORT_WINDOW setting applies when connecting to bpcd with the legacy bpcd destination port number with reserved source port numbers.

min is the minimum port number in the range. It should be 0 (zero) or a number between 1024 and 65535. max is the maximum port number in the range. It should be a number between min and 65535.
If min is 0 (zero), the operating system determines the source port number and max is ignored. The default is 0 0. Example The following command permits ports from 4800 through 5000: CLIENT_PORT_WINDOW = 4800 5000 This setting can also be configured in the NetBackup Administration GUI via Host Properties > Port Ranges > Client port window.
CLIENT_RESERVED_PORT_WINDOW = min max

Specifies the range of reserved source ports on this computer that are used for connecting to bpcd on other computers. This setting is applicable when connecting to bpcd with the legacy bpcd destination port number with reserved source port numbers.

If min is 0 (zero), the operating system determines the source port number and max is ignored. The default is 512 1023. Example The following command permits ports from 700 through 980: CLIENT_RESERVED_PORT_WINDOW = 700 980
This setting can also be configured in the NetBackup Administration GUI via Host Properties > Port Ranges > Client reserved port window.
SERVER_PORT_WINDOW = min max

Specifies the range of reserved destination ports on this computer that are used by bpcd on other computers when connecting back to this computer. This setting is applicable when connecting to bpcd with the legacy bpcd destination port number with non-reserved source port numbers with random port bpcd connect back.

Port security Port usage settings in NetBackup configuration - bp.conf
151
If min is 0 (zero), the operating system determines the source port number and max is ignored. The default is 1025 5000. Example The following command permits ports from 3000 through 7500: SERVER_PORT_WINDOW = 3000 7500
This setting can also be configured in the NetBackup Administration GUI via Host Properties > Port Ranges > Server port window.
SERVER_RESERVED_PORT_WINDOW = min max

Specifies the range of reserved destination ports on this computer that are used by bpcd on other computers when connecting back to this computer. This setting is applicable when connecting to bpcd with the legacy bpcd destination port number with reserved source port numbers with random port bpcd connect back.

min is the minimum port number in the range. Should be 0 (zero) or a number between 1 and 1023. max is the maximum port number in the range. Should be a number between min and 1023.
If min is 0 (zero), the operating system determines the source port number and max is ignored. The default is 512 1023. Example The following command permits ports from 700 through 980: SERVER_RESERVED_PORT_WINDOW = 700 980
This setting can also be configured in the NetBackup Administration GUI via Host Properties > Port Ranges > Server reserved port window.
CONNECT_OPTIONS = host 0|1|2 0|1|2 0|1|2|3 and DEFAULT_CONNECT_OPTIONS = 0|1 0|1 0|1|2
The CONNECT_OPTIONS and DEFAULT_CONNECT_OPTIONS configuration values determine how the local computer connects to services on other NetBackup systems. DEFAULT_CONNECT_OPTIONS is only available for NetBackup 6.5 and later. The values for CONNECT_OPTIONS are a host name followed by three digits. The values for DEFAULT_CONNECT_OPTIONS are three digits.
host is a remote NetBackup system that the local computer connects to. You may have multiple CONNECT_OPTIONS entries in the configuration. If a host is not specified in any CONNECT_OPTIONS entries, the values from the DEFAULT_CONNECT_OPTIONS entry are used. The first digit is the reserved versus non-reserved source port:

0 means that connections to bpcd from the local computer should use a reserved source port number selected from the CLIENT_RESERVED_PORT_WINDOW range. (Default.) 1 means that connections to bpcd from the local computer should use a non-reserved source port number selected from the CLIENT_PORT_WINDOW range. Be sure ALLOW_NON_RESERVED_PORTS = YES is set on the remote hosts that the local computer may connect to. 2 when specified in CONNECT_OPTIONS means that the value from DEFAULT_CONNECT_OPTIONS should be used instead. 0 means that connections to bpcd from the local computer, bpcd connects back to a random port number on the local computer that is selected from the SERVER_RESERVED_PORT_WINDOW range, or SERVER_PORT_WINDOW range on the server. (Default for 5.1 and earlier.) 1 means that connections to bpcd from the local computer, bpcd connects back to the vnetd port number on the server. (Default for 6.5 and later.) 2 when specified in CONNECT_OPTIONS means that the value from DEFAULT_CONNECT_OPTIONS should be used instead. 0 means that the local computer first attempts to connect to a NetBackup service using the vnetd destination port number. If that fails, the local computer will attempt to connect to the NetBackup service using the legacy destination port number for that service. (Default for 6.5 and later.) 1 means that connections to a NetBackup service from the local computer use the vnetd destination port number. 2 means that connections to a NetBackup service from the local computer use the legacy destination port number for the service. 3 when specified in CONNECT_OPTIONS means that the value from DEFAULT_CONNECT_OPTIONS should be used instead.
The second digit is bpcd call-back method:

The third digit is the legacy versus vnetd destination port:

Port security Configuring port usage client attribute settings - bpclient
153
Note: vnetd can only be used as the destination port if the remote host is NetBackup 6.5 or later and is not a NetWare client. If vnetd is used as the destination port, the settings from the first two digits are not applicable. In that case, the source port is from the non-reserved CLIENT_PORT_WINDOW range and no connect back is used. Example The connection options to most remote hosts from the local computer uses the NetBackup 5.1 defaults. However, connections to host
servers use theNetBackup 6.5 defaults:
CONNECT_OPTIONS = servers 0 1 0
DEFAULT_CONNECT_OPTIONS = 0 0 2
Example The DEFAULT_CONNECT_OPTIONS is restored to the defaults for NetBackup 6.5 and later: DEFAULT_CONNECT_OPTIONS = 0 1 0
These settings can also be configured in the NetBackup Administration GUI via the Host Properties > Firewall panel.
Configuring port usage client attribute settings bpclient

The bpclient command is used to update a variety of client attributes in a database on the NetBackup master server. The bpclient (1M) command is described in the NetBackup Commands for UNIX and Linux and the NetBackup Commands for Windows manuals. The -connect_options argument to bpclient sets three port usage attributes that NetBackup servers use when connecting to bpcd on the specified NetBackup client. To specify connection options to a client, first make sure the client is in the master servers database: bpclient -client name -add where name is the name of the client.
bpclient -client name -update -connect_options 0|1|2 0|1|2 0|1|2|3

This is the format of the bpclient command to update client connection attributes. The -connect_options argument is followed by three digits.
154 Port security Configuring port usage client attribute settings - bpclient
The first digit is the reserved versus non-reserved source port:

0 means that connections to bpcd from servers to the specified client should use a reserved source port number selected from the CLIENT_RESERVED_PORT_WINDOW range on the server. (Default for 5.1 and earlier servers.) 1 means that connections to bpcd from servers to the specified client should use a non-reserved source port number selected from the CLIENT_PORT_WINDOW range on the server. Be sure ALLOW_NON_RESERVED_PORTS = YES is set on the client. 2 means that the reserved versus non-reserved source port setting is determined by the CONNECT_OPTIONS and DEFAULT_CONNECT_OPTIONS on the server. (Default for 6.5 and later servers.) 0 means that for connections to bpcd from servers to the specified client, the client connects back to a random port number of the server selected from the SERVER_RESERVED_PORT_WINDOW range or SERVER_PORT_WINDOW range on the server. (Default for 5.1 and earlier servers.) 1 means that for connections to bpcd from servers to the specified client, the client connects back to the vnetd port number on the server. 2 means that the random port versus vnetd port setting is determined by the CONNECT_OPTIONS and DEFAULT_CONNECT_OPTIONS on the server. (Default for 6.5 and later servers.) 0 means that servers first attempt to connect to bpcd on the specified client using the vnetd destination port number. If that fails, servers then attempt to connect to bpcd on the specified client using the legacy bpcd destination port number. 1 means that connections to bpcd from servers to the specified client use the vnetd destination port number. 2 means that connections to bpcd from servers to the specified client use the legacy bpcd destination port number. (Default for 5.1 and earlier servers.) 3 means that the legacy bpcd versus vnetd destination port setting is determined by the CONNECT_OPTIONS and DEFAULT_CONNECT_OPTIONS on the server. (Default for 6.5 and later servers.)
The second digit is BPCD call-back method:

The third digit is the legacy bpcd versus vnetd destination port:

155
Note: vnetd can only be used as the destination port if the client is NetBackup 6.5 or later and is not a NetWare client. If vnetd is used as the destination port, the settings from the first two digits are not applicable. In that case, the source port is from the non-reserved CLIENT_PORT_WINDOW range and no connect back is used. Example The following commands set the legacy (pre NetBackup 6.5) client connect options for connections to client client1. You might find this command useful for older clients: bpclient -add -client client1
bpclient -update -client client1
-connect_options 0 0 2
Example The following command restores the NetBackup 6.5 client connect option defaults. You
might find this command useful after you
upgrade the client to 6.5:
bpclient -update -client client1
-connect_options 2 2 3
These settings can also be configured in the NetBackup Administration GUI via the Host Properties > Client Attributes > Connect Options tab.
Port usage settings in Media Manager configuration - vm.conf

For Media Manager, update port usage settings by editing the /usr/openv/volmgr/vm.conf file (UNIX or Linux) or the install_path\volmgr\vm.conf file (Windows). No GUI is available to changing these settings.
RANDOM_PORTS = YES | NO
The RANDOM_PORTS setting specifies how Media Manager chooses a source port to use when the Media Manager software on one computer needs to communicate with the Media Manager software on another computer. The default is YES.

YES means that source port number is selected randomly from the range defined by the CLIENT_PORT_WINDOW setting.
NO means that source port number is selected sequentially randomly from the range defined by the CLIENT_PORT_WINDOW setting. The media manager attempts the connection with the highest source port number in the range. If that source port does not work, the media manager tries the next highest source port number in the list until it finds a source port number that works.
CLIENT_PORT_WINDOW = min max

Where min and max are integers from 1024 to 65535 or 0 (zero). These values define the range of source ports used on out-going media manager connections. min defines the lowest source port number and max defines the highest source port number. If min is 0 or if max is less than min, then the media manager will let the operating system determine the source port number. The default is 0 0. Example This setting defines a source port range of 3000 to 8000: CLIENT_PORT_WINDOW = 3000 8000
CONNECT_OPTIONS = host 0 0 0|1|2

The CONNECT_OPTIONS setting specifies the destination port number to be used to connect to media manager services. You can specify multiple CONNECT_OPTIONS settings in the vm.conf file.

host is the host name of a computer with media manager services such as vmd, tshd, and tldcd. The first two digits are ignored. The third digit is the legacy media manager ports versus vnetd destination port:

0 means that the local computer first attempts to connect to the media manager service on the specified host using the vnetd destination port number. If that attempt fails, servers then attempt to connect to the media manager service on the specified host. The server uses the legacy media manager destination port number. 1 means that connections to the media manager service on from the local computer to the specified host use the vnetd destination port number. 2 means that connections to the media manager service from the local computer to the specified host use the legacy media manager destination port number. (Default for 5.1 and earlier servers.)
For NetBackup 6.5 and later, if no CONNECT_OPTIONS settings are specified in the vm.conf file, the media manager will defaults to the
157
DEFAULT_CONNECT_OPTIONS and CONNECT_OPTIONS settings defined in the NetBackup configuration. Example This setting forces media manager connections to server3 to use vnetd as the destination port: CONNECT_OPTIONS = server3 0 0 1
Chapter
Access control security

This chapter discusses access control security which includes how to set up and manage access to NetBackup. It contains the following major sections:

Access management components on page 160

Access management administration on page 160
NBAC installation and configuration on page 163
NBAC upgrade on page 168
Access management troubleshooting guidelines on page 192
Using the access management utility on page 218
Determining who can access NetBackup on page 219
160 Access control security Access management administration
Access management administration

Access to NetBackup can be controlled by defining user groups and granting explicit permissions to these groups. Configuring user groups and assigning permissions is done using Access Management in the NetBackup Administration Console. Note: In order for the NetBackup-Java Administration Console to function, the user must have permission to log in to the system remotely.
Note: If some media servers are not configured with access control, non-root/non-administrator users will not be able to manage those servers.
Access management components

NetBackup uses the Symantec Product Authentication and Authorization Service to implement core security. Symantec Product Authentication and Authorization Service is a set of shared infrastructure services. It is installed from one of the infrastructure common services CDs containing the software for your platform. The CDs are packaged as part of NetBackup. Note: NetBackup access management relies on the use of home directories. Please see the documentation for your operating system for more information on home directories.
Symantec Product Authentication and Authorization components

When you install Symantec Product Authentication and Authorization Service, the following services and client software are included:

Authentication (authentication server, authentication client) Authentication is the process of proving your identity to the Symantec Product Authentication and Authorization system. The authentication client communicates with the authentication broker service, which in turn validates your identity with the operating system by using the appropriate plugin. For more information on authentication or the authentication service (vxatd), see the Symantec Product Authentication and Authorization Administrators Guide. This guide is found on one of the infrastructure
Access control security Access management components
161
common services CDs containing Symantec Product Authentication and Authorization for your platform.

Authorization (authorization server, authorization client) Authorization is the process of verifying that an identity has permission to perform the desired action. NetBackup verifies permissions with the authorization service for most actions. For more information on the authorization service (vxazd), see the Symantec Product Authentication and Authorization Administrators Guide. This guide is found on one of the infrastructure common services CDs containing Symantec Product Authentication and Authorization for your platform.
Root broker
A Root Broker is a NetBackup server that has the Symantec Product Authentication Service installed and is configured to be a root broker. One root broker is always included in every NetBackup access management configuration. Note: Technically the root broker does not have to be a NetBackup server although it is recommended. The root broker acts as the most trusted certificate authority, implementing a registration authority for authentication brokers, as well as itself. While a root broker can authenticate an authentication broker, an authentication broker cannot authenticate a root broker or an authentication broker. In many cases, the root broker will be an authentication broker too. This chapter describes installing the Symantec Product Authentication and Authorization Service. Then it describes configuring the NetBackup server to be a root broker and an authentication broker (RB+ AB). For more information on the authentication and root broker, see the Symantec Product Authentication and Authorization Administrators Guide. This guide is found on one of the infrastructure common services CDs containing Symantec Product Authentication and Authorization for your platform.
An authentication broker is a server that has the Symantec Product Authentication Server installed. This machine is part of the root brokers private access domain. An authentication broker can authenticate clients, but not other brokers.
162 Access control security Access management components
Any member of the NetBackup security administrator user group can choose which authentication broker a client should contact for authentication of users. (See Example configuration containing Windows systems only on page 193 and Example configuration containing UNIX systems only on page 200 for a depiction of this configuration.) For example:

A Windows 2000 client uses a Windows authentication broker for authenticating Windows users. A UNIX client uses a UNIX authentication broker for authenticating users. For more information on authentication brokers, see the Symantec Product Authentication and Authorization Administrators Guide. This guide is found on one of the infrastructure common services CDs containing Symantec Product Authentication and Authorization for your platform.
Security administrator
The user who installs and configures Symantec Product Authentication and Authorization Service software for use with NetBackup Access Management specifies a user account that will be the first member of the NBU_Security Admin user group. This chapter refers to a member of the NBU_Security Admin group as a security administrator. Users can be added to the group, typically consisting of few members. Members of the NBU_Security Admin user group are the only users who can view the contents of Access Management > Users and Access Management > NBU User Groups in the NetBackup Administration Console. Security administrators are the only users allowed to create user groups, assign users to the groups, and define permissions for the groups. However, security administrators, by default, do not have permission to perform any other NetBackup administration activities. (See Security administrator (NBU_Security Admin) on page 224). Note: The administrator group (Windows) or root (UNIX) is always a member of the NBU_Security Admin group on the system where the Authorization daemon service runs. See the Symantec Product Authentication and Authorization Administrators Guide for information on this special identity.
Access control security NBAC installation and configuration
163
NBAC installation and configuration
For information on the NBAC installation sequence, refer to this procedure:
NBAC installation sequence on page 163

Symantec Product Authentication and Authorization component distribution on page 169 Installing and configuring access control on master servers on page 171
For detailed NBAC installation descriptions, refer to these procedures:
For information on the NBAC quick configuration sequence, refer to this procedure:

NBAC quick configuration sequences on page 163
NBAC installation sequence

Use the following NBAC installation sequence on any NetBackup machine that uses NetBackup Access Control. 1 Complete all NetBackup master server installations: a b c Complete RB + AB installation of Symantec Product Authentication server. Complete Symantec Product Authorization server installation. Configure master servers for NetBackup Access Control. See Installing and configuring access control on master servers on page 171.
Complete all NetBackup media server installations, then servers for NetBackup Access Control. See Installing and configuring access control on media servers on page 174. Complete all NetBackup client installations, then configure clients for NetBackup Access Control. See Installing and configuring access control on clients on page 177.
NBAC quick configuration sequences

Use the following NBAC quick configuration sequences (summary in Table 4-4) if you are familiar with the overall NBAC configuration and desire a quick reference. Refer to the NBAC quick configuration sequences as follows.

NBAC quick configure - master server from master server on page 164 NBAC quick configure - media server from master server on page 164
164 Access control security

NBAC quick configure - media server from media server on page 165 NBAC quick configure - client from master server on page 165 NBAC quick configure - client from client on page 165
If you desire to review a summary of the commands used in the NBAC quick configuration sequences, refer to the following:

NBAC quick configure - commands summary on page 166
Table 4-4
Configure: From: Run:
NBAC quick configure sequence summary

Master server Master server
bpnbat -AddMachine bpnbat -LoginMachine bpnbaz -SetupSecurity bpnbaz -AllowAuthorization Host properties
Media server Master server

bpnbat -LoginMachine bpnbaz -AllowAuthorization
Client Master server

bpnbat -AddMachine
Media servers
bpnbat -LoginMachine
Client
Configure:
Restart:
Host properties on master server --
--
Host properties on client --
--
NetBackup
NetBackup
--
NBAC quick configure - master server from master server

Use this NBAC quick configure sequence to configure a master server from a master server. Follow these steps: 1 Run: bpnbat bpnbat bpnbaz bpnbaz -AddMachine on page 166 -LoginMachine on page 166 -SetupSecurity on page 167 -AllowAuthorization on page 168
2 3
Configure the host properties. See Installing and configuring access control on master servers on page 171. Restart NetBackup
NBAC quick configure - media server from master server

Use this NBAC quick configure sequence to configure a media server from a master server. Follow these steps on the master server. 1 Run: bpnbat -AddMachine on page 166 bpnbaz -AllowAuthorization on page 168
165
NBAC quick configure - media server from media server

Use this NBAC quick configure sequence to configure a media server from a media server. Follow these steps on the media server. 1 2 3 Run: bpnbat -LoginMachine on page 166 Configure the host properties from the master server. See Installing and configuring access control on media servers on page 174. Restart NetBackup
NBAC quick configure - client from master server

Use this NBAC quick configure sequence to configure a client from a master server. Follow this step on the master server. 1 Run: bpnbat -AddMachine on page 166
NBAC quick configure - client from client

Use this NBAC quick configure sequence to configure a client from a client. Follow these steps on the client. 1 2 Run: bpnbat -LoginMachine on page 166 Configure the host properties. from the master server. See Installing and configuring access control on clients on page 177.

NBAC quick configure - commands summary

Table 4-5 summarizes the commands used in the NBAC quick configure sequences. Table 4-5 Command
bpnbat -AddMachine
NBAC quick configure command summary Description

The bpnbat -AddMachine command adds a host to the NBU private domain on the authentication broker. This command must be run on the host where the authentication broker is running. Symantec strongly recommends that this host be the same as the master server. The bpnbat -AddMachine command must be run as root or an administrator. This command adds hosts to the NBU_Machines private domain. If this domain has not yet been created, then bpnbat -AddMachine will do so. The hostname specified should be fully qualified. Non-fully qualified hostnames will be resolved to fully qualified hostnames if possible, but it is not an error if they do not resolve. The password used should be different for each host and should not be the same as any user's password. Running this command and specifying a host for a second time after a previously successful run will cause the host's password to be changed to the newly specified password. The bpnbat -LoginMachine command performs an authentication against the authentication broker. Symantec strongly recommends that the authentication broker runs on the master server. If this is the case, then the master server's hostname may be specified at the prompt for the authentication broker's hostname. The hostname should be fully qualified. If it is not, then bpnbat -LoginMachine will attempt to resolve the hostname to one that is fully qualified. If this step fails, try running bpnbat -ShowMachines on the authentication broker to determine the name generated for this host. The password specified should be the same as that used by bpnbat -AddMachine when adding this host. If you have forgotten the password, you can run bpnbat -AddMachine on the authentication broker again and specify a new password.
167
Table 4-5 Command

bpnbaz
-SetupSecurity

The bpnbaz -SetupSecurity command initializes the authorization server with information required by NBAC to perform authorization for user requests. It also adds a set of default groups given authorization for common NetBackup operations. This command must be run as root or administrator. This command gives authorization to the first user of NetBackup under NBAC. This user is added to the NBU_Admin, NBU_SAN Admin, and NBU_Security Admin groups. By being a member of each of these groups, the first user is given access to all NetBackup functionality under NBAC. The first user does not need to be root or administrator. When specifying the first user, you must supply a username and password, as well a domain name, domain type, and authentication broker. The domain name depends on the domain type. The domain types and corresponding domain names supported by NetBackup are:

unixpwd: Use the unixpwd file (i.e.,/etc/passwd) of the authentication broker to authenticate the user. The domain name is the fully qualified hostname of the authentication broker. This option is only available on authentication brokers running on a UNIX\Linux platform. nis: Use a NIS domain, recognized by the authentication broker host, to authenticate the user. The domain name should be the same as the NIS domain name (i.e., min.com). This option is only available on authentication brokers running on a UNIX\Linux platform. nisplus: Use a NIS+ domain, recognized by the authentication broker host, to authenticate the user. The domain name should be the same as the NIS+ domain name (i.e., min.com). This option is only available on authentication brokers running on a UNIX\Linux platform. WINDOWS: Use a Windows Active Directory or Primary Domain controller domain, recognized by the authentication broker host, to authenticate the user. The domain name should be the same as the Windows domain name used during login. This option is only available on authentication brokers running on a Windows platform. The authentication broker specified must recognize the domain name specified for the first user.

Table 4-5 Command
bpnbaz The bpnbaz -AllowAuthorization command grants authority -AllowAuthorization to a host to enquire to the Authorization Server about whether or not a user has authorization to perform a specified operation. This command must be run on the host running the Authorization Service. Symantec strongly recommends that you run the Authorization Service on the same host as the Master Server. The hostname specified should be fully-qualified; if it is not, then this command will attempt to resolve a fully-qualified name. It is not an error if a fully-qualified name cannot be obtained. If there is a failure, try running bpnbat -ShowMachines to determine what name the host was given. This command must be run as root or Administrator.
NBAC upgrade
Use the following NBAC upgrade sequence on any NetBackup machine that uses NetBackup Access Control. 1 2 3 Stop NetBackup. Upgrade Symantec Product Authentication and Authorization Client and/or Service. Upgrade NetBackup.
Including authentication and authorization databases in the NetBackup catalog backup

In NetBackup environments using the online, hot catalog backup method, no additional configuration is needed to include the Symantec Product Authentication and Authorization Service databases in the catalog backup.
169
In NetBackup environments using the offline, cold catalog backup method, one additional step is required:
Within the NetBackup Catalog Wizard or on the Files tab of the offline catalog configuration dialog, add the following directives for each host in the NBAC domain: [host:]nbat
[host:]nbaz
Note: If the master server using NBAC is a UNIX machine, Symantec recommends that you do not include the NetBackup master server configuration file (/usr/openv/netbackup/bp.conf) in the offline catalog backup file list. If bp.conf is included in the list, it must not be recovered until all other catalog recovery is completed.
Symantec Product Authentication and Authorization component distribution

The Symantec Product Authentication and Authorization components can be distributed throughout a configuration, as NetBackup can distribute master servers, media servers and clients. Note: It is required that the authentication broker and authorization server be installed on the master server.
170 Access control security NBAC installation and configuration
For specific Symantec Product Authentication and Authorization installation information, refer to the Symantec Product Authentication and Authorization Installation Guide. This guide is found on the Symantec Product Authentication and Authorization installation CD. For further information on Symantec Product Authentication and Authorization Yellow Book. This book provides information to help organizations securely deploy Symantec products in individual and multiple product environments and can be accessed on the web: http://www.symantec.com/enterprise/theme.jsp?themeid=yellowbooks. Table 4-6 Component requirements Required authentication component
authentication server (RB+AB)
NetBackup installation
Master server
Required authorization component

authorization server (non read-only) authorization client None None None None
Media server Client
authentication client authentication client
Windows Remote Administration Console (only) authentication client Java Windows Display Console (only)* Java Display Console authentication client authentication client
*The authentication client is required for all Java consoles. Concerning the Java Windows Display Console, the authentication client must be installed on the Windows host before installing the Java Windows Display Console. This ensures that the Windows Display Console is configured correctly to use the Symantec Product Authentication and Authorization component successfully.
Note: While possible to share the Enterprise Media Manager server between multiple master servers, this configuration is not supported when using access control. The EMM server must be bound to one master server. The following section topics describe procedures to verify that the components are correctly installed in a mixed environment:

Windows verification points on page 192 UNIX verification points on page 199 Verification points in a mixed environment with a UNIX master server on page 206 Verification points in a mixed environment with a Windows master server on page 210
171
Installing and configuring access control on master servers

The following procedures describe installing and configuring NetBackup Access Control on master servers in a NetBackup configuration. A master server requires authentication server and client software and authorization server and client software. Throughout this chapter, the configuration examples refer to the following host names: Table 4-7 Example host names Windows
Master servers Media servers Clients win_master win_media win_client
UNIX
unix_master unix_media unix_client
1 2
If this installation is an upgrade installation, stop NetBackup. Use one of the infrastructure common services CDs containing Symantec Product Authentication and Authorization for your platform. Install both the authentication server and client software on the master server. This master server is a RB + AB. (To install these on a Windows system, a custom installation is required.) See Installing the authentication service root broker on page 180 and the Symantec Product Authentication and Authorization Installation Guide. This guide is on the Symantec Product Authentication and Authorization installation CD. Use one of the infrastructure common services CDs containing the Symantec Product Authentication and Authorization software for your platform. Install the authorization server and client software on the master server. To do this installation, you must perform a custom installation. See Installing the authorization server on page 181 and the Symantec Product Authentication and Authorization Installation Guide. This guide is found on one of the infrastructure common services CDs containing the Symantec Product Authentication and Authorization software for your platform. Complete all NetBackup master server installations or upgrades. Create a machine account for the master server. Make sure that the Authentication and the Authorization services are running. See UNIX verification points on page 199 or Windows verification points on page 192.
4 5

The command in this step must be run as either root (UNIX) or as a member of the local administrator group (Windows). The command is run on the authentication broker, which is the master server. For more information about this step, see Adding a machine locally to the private domain. For more information about this step, see Configuring authentication for use by NetBackup on page 180. To add the master server locally to the private domain, run the following command on the master server: For UNIX based systems, bpnbat is located in directory /usr/openv/netbackup/bin/ For Windows-based systems, bpnbat is located in directory Install_path\NetBackup\bin\
bpnbat -addmachine
Machine Name: win_master
Password: *******
Password: *******
Operation completed successfully.
Note: Repeat this step for each alias or host name used by NetBackup. 6 Log in to the machine account for the master server. To create a credential for the master server, run the following command on the master server:
bpnbat -loginmachine
Does this machine use Dynamic Host Configuration Protocol
(DHCP)? (y/n)? n
Authentication Broker: win_master
Authentication port [Enter = default]:
Machine Name: win_master
Password: *******
For more information about this step, see Adding a machine locally to the
private domain on page 181.
For more information about this step, see Configuring authentication for
use by NetBackup on page 180.
7 Create the first Security Administrator (bootstrapping security). For UNIX based systems, bpnbaz is located in directory /usr/openv/netbackup/bin/admincmd For Windows-based systems, bpnbaz is located in directory Install_path\NetBackup\bin\admincmd on the master server. bpnbaz -setupsecurity win_master
Please enter the login information for the first Security

Administrator other than root/Administrator. This identity
is added to the security administrators group
173
(NBU_Security Admin), and to the netbackup administrators

group (NBU_Admin). It is also used to build the initial
security information.
Authentication type (NIS, NIS+, WINDOWS, vx, unixpwd): WINDOWS
Domain: domain1
Login Name: admin1
Password: ******
Processing - please be patient
For more information about this step, see Configuring the authorization server on page 182. 8 Add the master server as a host that is authorized to perform authorization checks. Again, this step is performed on the master server. bpnbaz -AllowAuthorization win_master
For more information about this step, see Configuring the authorization server on page 182. 9 Configure the Access Control host properties of the master server.

Set Symantec Product Authentication and Authorization to Automatic. Later, once all media servers and clients are configured for NBAC, you may set this to Required. (If some clients or media servers do not use NetBackup Access Control, you may leave this set to Automatic.) On the Symantec Product Authentication and Authorization tab, add the host to the network (win_master). (If the Symantec Product Authentication and Authorization property is set to Required, this tab is not available.) On the Authentication Domain tab, add authentication domain(s) and the host that is acting as the broker for the domain (domain1).
The broker is a machine using an operating system supporting the domain type and the specific domain that has the Symantec Product Authentication and Authorization service installed on it.
On the Authorization Service tab, specify the master server on which you installed the authorization service (win_master). For more information about this step, see Configuring access control host properties on page 183.

10 When the host properties is changed, recycle the server daemons for the changes to take effect.
Installing and configuring access control on media servers

The following steps describe installing and configuring NetBackup Access Control on media servers in a NetBackup configuration. A media server requires authentication client software and authorization client software. 1 2 If this installation is an upgrade installation, stop NetBackup. Use one of the infrastructure common services CDs containing Symantec Product Authentication and Authorization software for your platform. Install the authentication client software on the system.
175
Use one of the infrastructure common services CDs containing the Symantec Product Authentication and Authorization software for your platform. Install the authorization client software on the media server. Complete all NetBackup media server installations or upgrades. On the master server, create a machine account for the media server. Make sure that the authentication and the authorization services are running. See UNIX verification points on page 199 or Windows verification points on page 192. The command in this step must be run as either root (UNIX) or as a member of the local Administrator group (Windows) on the RB+AB. To add the media server locally to the private domain, run the following command on the master server: bpnbat is located in directory /usr/openv/netbackup/bin bpnbat is located in directory Install_path\NetBackup\bin
bpnbat -addmachine
Machine Name: win_media
Password: *******
Password: *******
4 5
For more information about this step, see Adding a machine locally to the
private domain.
Note: Repeat this step for each alias used by the media server. 6 Log in to the machine account for the media server.
To create a credential for the media server, run the following command on
the media server:
(DHCP)? (y/n)? n
Machine Name: win_media
Password: *******
Note: Repeat this step for each alias or host name used by NetBackup. For more information about this step, see Creating a credential for a
machine.
Add the media server as a host authorized to perform authorization checks. bpnbaz is located in directory /usr/openv/netbackup/bin/admincmd bpnbaz is located in directory Install_path\NetBackup\bin\admincmd
On the master server, run:
bpnbaz -AllowAuthorization win_media
For more information about this step, see Configuring the authorization server on page 182. 8 Set up the proper Access Control host properties for the media server. The properties are described in Configuring access control host properties on page 183. Open Access Control host properties for the media server (win_media) through the master server. In the NetBackup Administration Console, select NetBackup Management > Host Properties > Media Server > Select media server win_media > Access Control.

Set the Symantec Product Authentication and Authorization mode to Required. If some clients or media servers are not using NetBackup Access Control, set to Automatic. Add authentication domains based on the domains where your users are defined. Specify in the same root hierarchy the installed authentication servers and the authentication methods supported. For example, a Windows system configured for authentication using domain WINUSER, and a UNIX system configured for Authentication using the NIS domain my.company, the tab would look like the following:
177
On the Authorization Services tab, indicate the host that performs authorization for this media server. Configure Access Control on the master server (win_master) for the media server: On the Symantec Product Authentication and Authorization tab, add win_media to the Symantec Product Authentication and Authorization Network list as Required.
After the host properties are changed, recycle the server daemons on the media server for the changes to take effect.
Installing and configuring access control on clients

The following steps describe installing and configuring NetBackup Access Control on clients in a NetBackup configuration. A client requires authentication client software. 1 2 Make sure no backups are currently running. Using one of the infrastructure common services CDs containing Symantec Product Authentication and Authorization for your platform, install authentication client software on the system. Using bpnbat, register the client with the authentication broker.
For example, if registering a machine (win_client) with the authentication broker (win_master), run the following command on the authentication server (win_master). To add the client to the private domain, run the following command on the master server:
bpnbat -addmachine
Machine Name: win_client.min.com
Password: [any password]
Password: [enter password again]
To create a credential for the client, run the following command on the client (win_client):
(DHCP)? (y/n)? n
Authentication Broker: win_master.min.com
Name: win_client.min.com
Password: [same password as in step 3]
Set up the proper access control host properties for the client. The properties are described in Configuring access control host properties on page 183. a Open Access Control host properties for the client (win_client) through the master server. In the NetBackup Administration Console, select NetBackup Management > Host Properties > Clients > Select client win_client > Access Control.

Set Symantec Product Authentication and Authorization mode to Required or Automatic.
Note: You may need to set the Symantec Product Authentication and Authorization mode to Automatic to allow non-NBAC access to media or masters not configured with NBAC.

Add authentication domains based on the systems where you have installed authentication servers and the authentication methods supported. For example, given a Windows system configured for authentication using domain WINUSER, and a UNIX system
179
configured for authentication using the NIS domain my.company, the tab would look like the following:
Set up Access Control on the master server (win_master) for the client: On the Symantec Product Authentication and Authorization tab, add win_client.min.com to the Symantec Product Authentication and Authorization Network list as Required.
Establishing a trust relationship between the broker and the Windows remote console
To establish a trust relationship between the master server (broker) and the administration client: 1 From the master server, run the following command:
Install_path\VERITAS\NetBackup\bin\
admincmd>bpgetconfig USE_VXSS AUTHENTICATION_DOMAIN
>VXSS_SETTINGS.txt
Sample output of VXSS_SETTINGS.txt:

USE_VXSS = AUTOMATIC AUTHENTICATION_DOMAIN = <domain_name> "" WINDOWS <broker_host> 0
2 3
Copy VXSS_SETTINGS.txt to the administration client. Run the following command from the administration client:
C:\Program Files\VERITAS\NetBackup\bin\
admincmd>bpsetconfig "<absolute_path>\VXSS_SETTINGS.txt"
Running this command matches the settings on the administration client with those on the broker. It sets the administration client to log in automatically to the broker. 4 Launch the Administration Console from the administration client, a request to establish a trust with the broker should occur. Once the trust is agreed to, the administration console should be available.
Installing the authentication service root broker

Before the Symantec Product Authentication and Authorization services are installed (which creates a Root Broker and/or Authentication Broker) confirm the following conditions are true:

Make sure that you are root or administrator on the system where you plan to install the Symantec Product Authentication and Authorization software. If NetBackup is currently installed, shut down all NetBackup services before installing Symantec Product Authentication and Authorization software.
Install the Symantec Product Authentication and Authorization Root Broker software. Use one of the infrastructure common services CDs containing Symantec Product Authentication and Authorization software for your platform. Use the instructions in the Symantec Product Authentication and Authorization Installation Guide. The manual is found on the installation CD. Symantec recommends placing the root plus authentication broker on the NetBackup master server. This placement allows for more centralized administration of the NetBackup server and can facilitate upgrading to NetBackup Access Management. Configure the root broker as described in Configuring authentication for use by NetBackup on page 180.
Configuring authentication for use by NetBackup

Configure the authentication broker using the NetBackup command, bpnbat located in one of the following directories. UNIX and Linux: /usr/openv/netbackup/bin/ Windows: Install_path\VERITAS\NetBackup\bin\ Note: The following steps require a password that should not be a user or root or administrator password. The password must be at least five characters long, and match one another in both steps. However you do not need to use the same password each time the two steps are run for a new machine in the domain.
181
Adding a machine locally to the private domain

In order for the NetBackup master servers and media servers to communicate with the host (machine_name), add this machine to the authentication broker private database. You can add this machine by running the following command on the authentication server (typically on the master server):
bpnbat -addmachine
Machine Name: machine_name
Password: any_password
Password: Re-enter password
Where:
machine_name is the name of this machine.
any_password may be a unique password (at least five characters long) used
only for the purpose of registering this machine. However, the same
password must be used in both steps. It must be done when registering the
machine locally in the private domain. And it must be done in the next step,
when registering the host with NetBackup.
Creating a credential for a machine

To log the machine into the specified authentication broker, enter the following command on the host (machine_name) that needs to be logged in:
(DHCP)? (y/n)? n
Authentication Broker: broker
Authentication port [Enter = default]: broker_port
Name: machine_name
Password: same password as in step a
You do not currently trust the server: broker
Do you wish to trust it? (y/n) y
Continue to the next section for instructions on configuring authorization on the master server.
Installing the authorization server

Install the authorization software from one of the infrastructure common services CDs containing Symantec Product Authentication and Authorization software for your platform. Install according to the instructions in the Symantec Product Authentication and Authorization Installation Guide. The manual is found on the ICS.
Note: Symantec strongly recommends installing the authorization server on the master server. This installation ensures that the master and media servers are able to communicate with the authorization server at all times.
Configuring the authorization server

The bpnbaz -SetupSecurity command is used during authorization setup to perform two functions necessary for Access Management:

Create the object hierarchy that appears in the NetBackup Administration Console under Access Management. Set up default user groups and add the first identity to the security administration groups (NBU_Security Admin) NBU_Admin and SAN_Administration. UNIX and Linux: /usr/openv/netbackup/bin/admincmd Windows: Install_path\NetBackup\bin\admincmd
bpnbaz is located in one of the following directories:

Before running bpnbaz commands, check that both the authentication service daemon (vxatd) and the authorization service daemon (vxazd) are running. If necessary, start the authentication service daemon first, then the authorization service daemon. Use the Window Services since these do not appear in the NetBackup Activity Monitor.
Stopping authentication and authorization daemon services

Use the following commands for stopping the authentication and authorization daemons on UNIX and Linux:

Stopping authentication daemon: kill <vxatd process ids> Stopping authorization daemon: /opt/VRTSaz/bin/vrtsaz -stop
Starting authentication and authorization daemon services

Use the following commands for starting the authentication and authorization daemons on UNIX and Linux:

Starting authentication daemon: /opt/VRTSaz/bin/vxatd Starting authorization daemon: /opt/VRTSaz/bin/vrtsaz
Note: The user specified in the following command is set up as the first NetBackup security administrator.
183
On the machine where the authorization server software is installed and contains the authorization server, run:
bpnbaz -SetupSecurity master_server
Where: master_server is the host name of the NetBackup master server. This command asks for the user credentials. This user becomes the first NetBackup administrator and NetBackup security administrator. Note: While you must run as root or administrator, you do not need to specify root or administrator as the first user. The command bpnbaz -SetupSecurity must be run by root (UNIX) or Administrator (Windows). This process may take a number of minutes.
See step 7 on page 172 for an example of this command.
2 Allow authorization: Run the following command on the authorization server:
bpnbaz -AllowAuthorization server
This command must be run on the authorization server for each master or
media server that utilizes NetBackup Access Control.
When a new master or media server is added, the command is run on the
authorization server.
Where:
server is the host name of the master or media server where the
authorization client software is installed.
Note: bpnbaz -AllowAuthorization server must be run by root (UNIX) or administrator (Windows). 3 4 Start NetBackup daemons services on the machine(s). Continue with Configuring access control host properties on page 183 for instructions on configuring NetBackup Access Control host properties for the master server.
Configuring access control host properties

Use the following sections for configuring the access control host properties.
Note: You must set master server Symantec Product Authentication and Authorization property to Automatic until the clients are configured for Access Control. Then, if desired, change the Symantec Product Authentication and Authorization property on the master server to Required.
Using hostnames when adding machines

NBAC does not require the use of fully qualified hostnames when adding machines. However, commands accepting hostnames (bpnbat -AddMachine, bpnbat -LoginMachine, and bpnbaz -AllowAuthorization) will attempt to retrieve the fully-qualified hostname if a non-fully-qualified hostname is specified. For example, if a host unix_machine.min.com exists, and only unix_machine is specified for any of the above commands, then that command will attempt to resolve the name to unix_machine.min.com. To determine what name these commands have resolved, you can run bpnbat -ShowMachines. It lists the names of all hosts added to NetBackup's private domain in the authentication broker. It is always best to specify the fully qualified hostname when using these commands to make sure that the correct name is chosen. In addition, using fully qualified hostnames is more secure. It ensures the uniqueness of the name used by a machine. Symantec does recommend the use of fully qualified hostnames for NBAC.
Master server and media server host properties

The Access Control host properties are described in the following sections. The master and media server host properties are in the NetBackup Administration Console. Open NetBackup Management > Host Properties > Master Server or Media Server > Select server > Access Control.
Access control host properties dialog

Set the Symantec Product Authentication and Authorization to either Required or Automatic. A setting of Automatic takes into account that there may be hosts within the configuration that are not yet configured for NBAC. The server attempts to negotiate the most secure connection possible when talking to other
185
NetBackup systems. The Automatic setting should be used until all clients and servers are configured for NBAC.
When Automatic is used, you may specify machines or domains Required to use Symantec Product Authentication and Authorization or Prohibited from using Symantec Product Authentication and Authorization.
Symantec Product Authentication and Authorization tab

View the Access Control host properties, on the Symantec Product Authentication and Authorization tab. Add the master server to the Symantec
Product Authentication and Authorization Network list. Then set Symantec Product Authentication and Authorization to Required.
Each new NetBackup client or media server (version 5.0 or higher), added to the NetBackup master, needs to have the Access Control properties configured. These properties are configured on both itself and the master. This configuration can be done through the host properties on the master server.
Authentication domain tab

The Authentication Domain tab is used to define the following:

Which authentication servers support which authentication mechanisms What domains each supports.
Add the domain you wish users to authenticate against. Be sure to select the proper authentication mechanism. The following examples contain three authentication domains and three authentication types. Two are hosted on the authentication server UNIXBOX,
187
and a third Windows AD/PDC (Active Directory/Primary Domain Controller) hosted on WINMACHINE.
A UNIX domain unixbox.mycompany.com on the authentication server

UNIXBOX.
Notice that the authentication mechanism for this domain is PASSWD.
Note: When a UNIX authentication domain is used, enter the fully qualified domain name of the host performing the authentication.
A NIS domain NIS.MYCOMPANY.COM on the authentication server UNIXBOX.
Notice that the authentication mechanism for this domain is NIS. A Windows AD/PDC domain WINDOWS on the authentication server WINMACHINE. Notice that the authentication mechanism for this domain is WINDOWS.
189
Authorization Service tab

Within the Access Control host properties, on the Authorization Service tab, complete the properties for the authorization server. Specify the host name for the system running the authorization daemon service (typically the master). Specify the alternate port, if needed, for which this daemon service has been configured. The default listening port for the authorization daemon service is 4032.
Make any changes to the host properties and restart the daemon services.
Client host properties

Access the client host properties in the NetBackup Administration Console. Open NetBackup Management > Host Properties > Clients > Select client(s) > Access Control.
Access control host properties dialog for client

Select the NetBackup client in the host properties. (On the master server, in the NetBackup Administration Console, open NetBackup Management > Host Properties > Clients > Selected clients > Access Control.)
Set the Symantec Product Authentication and Authorization to Required or Automatic.
Symantec Product Authentication & Authorization tab for client

Select the NetBackup client in the host properties. This tab is only enabled in Automatic mode. It can be used to control which systems require or prohibit the
191
use of Symantec Product Authentication and Authorization on a per-machine basis. Note that both systems must have matching settings to communicate.
Authentication domain tab
Within the Access Control host properties, on the Authentication Domain tab,
add the list of domains a client can use to authenticate.
192 Access control security Access management troubleshooting guidelines
Access management troubleshooting guidelines
You can troubleshoot access management by using these verification points to determine if certain processes and functionality are operating correctly. These verification points include:

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 Other troubleshooting topics
Note: While possible to share the Enterprise Media Manager server between multiple master servers, this configuration is not supported when using Access Control. The EMM server must be bound to one master server.
Windows verification points

The following configuration procedures (and Figure 4-50) can help you verify that the master server, media server, and client are configured correctly for Access Control.

Master server verification points for Windows Media server verification points for Windows Client verification points for Windows
Access control security Access management troubleshooting guidelines
193
Figure 4-50
Example configuration containing Windows systems only
authentication NBU master server (Windows) win_server.min.com server Root Broker authorization Authentication Broker server Authorization Service Private Symantec Product Authentication and Authorization domain called: NBU_Machines@win_server.min.com contains the following host accounts: win_server.min.com win_media.min.com win_client.min.com
Media server (Windows) win_media.min.com authentication client, authorization client Windows User accounts authenticate via Windows authentication Broker win_media.min.com
Client (Windows) win_client.min.com authentication client win_client.min.com Note: Each machine has a private domain account that is created for it. Using these accounts allows NetBackup to more reliably identify machines as they communicate with each other.
Master server verification points for Windows

The following section describes procedures for:

Verify Windows master server settings Verify which machines are permitted to perform authorization lookups Verify that the database is configured correctly Verify that the vxatd and vxazd processes are running Verify that the host properties are configured correctly
Verify Windows master server settings

To determine the domain in which a host is registered (where the primary authentication broker resides), or to determine the name of the machine the certificate represents, run bpnbat with -whoami and specify the host credential file. For example:
bpnbat -whoami -cf
"c:\program
Files\veritas\netbackup\var\vxss\credentials\win_master"
Name: win_master.min.com
Domain: NBU_Machines@win_master.min.com
Issued by: /CN=broker/OU=root@win_master.min.com/O=vx
Expiry Date: Oct 31 20:17:51 2007 GMT
Authentication method: Veritas Private Security
If the domain listed is not NBU_Machines@win_master.min.com, consider running bpnbat -addmachine for the name in question (win_master). This command is run on the machine with the authentication broker that serves the NBU_Machines domain (win_master). Then, on the machine where we want to place the certificate (win_master), run: bpnbat -loginmachine
Note: As you determine when a users credentials expire, keep in mind that the output displays the expiration time in GMT, not local time.
Note: For the remaining procedures in this verification section, assume that the commands are performed from a console window and that the user identity in question has run bpnbat -login from that window. The user is an identity that is a member of NBU_Security Admin. This identity is usually the first identity with which the security was set up.
195
Verify which machines are present in AB.

Logged in as a member of the Administrators group run the following command: bpnbat -ShowMachines This command shows the machines for which you have run bpnbat -AddMachine.
Verify which machines are permitted to perform authorization lookups

Logged in as a member of the Administrators group run the following command: bpnbaz -ShowAuthorizers
This command shows that win_master and win_media (master and media servers) are permitted to perform authorization lookups. Note that both servers are authenticated against the same Private Domain (domain type vx), NBU_Machines@win_master.min.com. Note: Run this command by local administrator or by root. The local administrator must be a member of the NBU_Security Admin user group.
bpnbaz -ShowAuthorizers
==========
Type: User
Domain Type: vx
Domain:NBU_Machines@win_master.min.com
Name: win_master.min.com
==========
Type: User
Domain Type: vx
Domain:NBU_Machines@win_master.min.com
Name: win_media.min.com
If a master or media server is not on the list of authorized machines, run bpnbaz -allowauthorization server_name to add the missing machine.
Verify that the database is configured correctly

To make sure that the database is configured correctly, run bpnbaz -listgroups:
bpnbaz -listgroups
NBU_Operator
NBU_Admin
NBU_SAN Admin
NBU_User
NBU_Security Admin
Vault_Operator
If the groups do not appear, or if bpnbaz -listmainobjects does not return data, you may need to run bpnbaz -SetupSecurity.
Verify that the vxatd and vxazd processes are running

Use the Windows Task Manager to make sure that vxatd.exe and vxazd.exe are running on the designated host. If necessary, start them.
Verify that the host properties are configured correctly

In the Access Control host properties, verify that the Symantec Product Authentication and Authorization property is set correctly. (The setting should be either Automatic or Required, depending on whether all machines use Symantec Product Authentication and Authorization or not. If all machines do not use Symantec Product Authentication and Authorization, set it to Automatic. Host properties can also be verified by viewing USE_VXSS in the registry at:
HKEY_LOCAL_MACHINE\Software\VERITAS\NetBackup\CurrentVersion\config
In the Access Control host properties, verify that the listed authentication domains are spelled correctly and point to the proper servers (valid authentication brokers). If all domains are Windows-based, they should point to a Windows machine running the authentication broker.
Media server verification points for Windows

The following section describe procedures to:

Verify the media server Verify that the server has access to the authorization database Understand the Unable to load library message
Verify the media server

To determine which authentication broker the media server is authenticated against, run bpnbat -whoami with -cf for the media servers credential file. For example:
197
bpnbat -whoami -cf "c:\program

files\veritas\netbackup\var\vxss\credentials\win_media.min.com"
If the domain listed is not NBU_Machines@win_master.min.com, consider running bpnbat -addmachine for the name in question (win_media). This command is run on the machine with the authentication broker that serves the NBU_Machines domain (win_master). Then, on the machine where we want to place the certificate (win_media), run: bpnbat -loginmachine
Verify that the server has access to the authorization database

To make sure that the media server is able to access the authorization database as it needs, run bpnbaz -ListGroups -CredFile "machine_credential_file For example:
bpnbaz -ListGroups -CredFile "C:\Program
Files\VERITAS\NetBackup\var\vxss\credentials\win_media.min.com"
NBU_Operator
NBU_Admin
NBU_SAN Admin
NBU_User
NBU_Security Admin
Vault_Operator
If this command fails, run bpnbaz -AllowAuthorization on the master server that is the authorization server (win_master.min.com).
Unable to load library message

Verify the media server and that it has access to the proper database. This verification indirectly informs you that the Symantec Product Authentication and authorization client libraries for both authentication and authorization are properly installed. If either of these procedures fail with a message unable to load libraries, check to make certain the authentication and authorization client libraries are installed. See the Symantec Product Authentication and Authorization Installation Guide on the Symantec Product Authentication and Authorization installation CD for proper installation procedures. You may also verify that the authentication domains are correct by viewing the Access Control host properties for this media server.
Client verification points for Windows

The following section describes procedures to:

Verify the credential for the client Verify that the authentication client libraries are installed Verify correct authentication domains
Verify the credential for the client

To check that the credential for the client is indeed for the correct client and comes from the correct domain, run bpnbat -whoami with -cf for the clients credential file. For example:
files\veritas\netbackup\var\vxss\credentials\win_client.min.com
"
If the domain listed is not NBU_Machines@win_master.min.com, consider running bpnbat -addmachine for the name in question (win_client). This command is run on the machine with the authentication broker that serves the NBU_Machines domain (win_master). Then, on the machine where we want to place the certificate (win_client), run: bpnbat -loginmachine
Verify that the authentication client libraries are installed

Run bpnbat -login on the client to verify that the authentication client libraries are installed.
bpnbat -login
Authentication type (NIS, NIS+, WINDOWS, vx, unixpwd): WINDOWS
Domain: ENTERPRISE
Name: Smith
Password:
If the libraries are not installed, a message stating that the Symantec Product Authentication and Authorization Service libraries are not installed is displayed.This verification can also be done by looking at the Windows Add/Remove Programs.
199
Verify correct authentication domains

In the access control host properties or by using regedit, check that any defined authentication domains for the client are correct. Make certain the domains are spelled correctly. And make sure that the authentication brokers that are listed for each of the domains is valid for that domain type.
UNIX verification points

Use the following procedures (and Figure 4-51) to verify that the UNIX master server, media server, and client are configured correctly for access control:

Master server verification points for UNIX Media server verification points for UNIX Client verification points for UNIX
Figure 4-51
Example configuration containing UNIX systems only
authenticationNBU master server (UNIX) unix_master.min.com server Root Broker Authentication Broker authorization Authorization Service server Private Symantec Product Authentication and Authorization domain called: NBU_Machines@unix_master.min.com contains the following credentials: unix_master.min.com unix_media.min.com unix_client.min.com
Media server (UNIX) unix_media.min.com authentication client, authorization client UNIX User accounts authenticate via UNIX authentication Broker unix_media.min.com
Client (UNIX) unix_client.min.com authentication client unix_client.min.com Note: Each machine has a private domain account that are created for it. Using these accounts allows NetBackup to more reliably identify machines as they communicate with each other.
201
Master server verification points for UNIX

Use the following procedures for UNIX master server verification.

Verify UNIX master server settings Verify which machines are permitted to perform authorization lookups Verify that the database is configured correctly Verify that the vxatd and vxazd processes are running Verify that the host properties are configured correctly
Verify UNIX master server settings

Determine in what domain a host is registered (where the primary authentication broker resides), and determine the name of the machine the certificate represents. Run bpnbat with -whoami with -cf for the master servers credential file. For example:
bpnbat -whoami -cf
/usr/openv/var/vxss/credentials/unix_master.min.com
Name: unix_master.min.com
Domain: NBU_Machines@unix_master.min.com
Issued by: /CN=broker/OU=root@unix_master/O=vx
If the domain listed is not NBU_Machines@unix_master.min.com, or the file does not exist, consider running bpnbat -addmachine for the name in question (unix_master). Run this command on the machine that serves the NBU_Machines domain (unix_master). Then, on the machine where we want to place the certificate (unix_master), run: bpnbat -loginmachine
Note: When determining if a credential has expired, keep in mind that the output displays the expiration time in GMT, not local time.
Note: For the remaining procedures in this verification section, assume that the commands are performed from a console window. That window in which the user identity is in question has run bpnbat -login using an identity that is a member of NBU_Security Admin. This identity is usually the first identity with which the security was set up.
Verify which machines are present in AB.

Logged in as a member of the Administrators group run the following command:
bpnbat -ShowMachines This command shows which machines for which you have run bpnbat -AddMachine.
Verify which machines are permitted to perform authorization lookups

Logged in as root on the authorization broker, run the following command:
bpnbaz -ShowAuthorizers
==========
Type: User
Domain Type: vx
Domain:NBU_Machines@unix_master.min.com
Name: unix_master.min.com
==========
Type: User
Domain Type: vx
Domain:NBU_Machines@unix_master.min.com
Name: unix_media.min.com
This command shows that unix_master and unix_media are permitted to perform authorization lookups. Note that both servers are authenticated against the same vx (Veritas Private Domain) Domain, NBU_Machines@unix_master.min.com. If a master or media server is not part of the list of Authorized machines, run bpnbaz -allowauthorization <server_name> to add the missing machine.
Verify that the database is configured correctly

To make sure that the database is configured correctly, run bpnbaz -listgroups:
bpnbaz -listgroups
NBU_Operator
NBU_Admin
NBU_SAN Admin
NBU_User
NBU_Security Admin
Vault_Operator
If the groups do not appear, or if bpnbaz -listmainobjects does not return data, run bpnbaz -SetupSecurity.
Verify that the vxatd and vxazd processes are running

Run the ps command to ensure that vxatd and vxazd are running on the designated host. If necessary, start them. For example:
203
ps -fed |grep vx
root 10716 1 0 root 10721 1 0
Nov 11 ? Nov 11 ?
0:02 /opt/VRTSat/bin/vxatd
4:17 /opt/VRTSaz/bin/vxazd
See the Symantec Product Authentication and Authorization Administrators Guide for more details on how to start vxatd and vxazd.
Verify that the host properties are configured correctly

In the Access Control host properties, verify that the Symantec Product Authentication and Authorization property is set correctly. (The setting should be either Automatic or Required, depending on whether all machines use Symantec Product Authentication and Authorization or not. If all machines do not use Symantec Product Authentication and Authorization, set it to Automatic. In the Access Control host properties, verify that the authentication domains on the list are spelled correctly. Also make sure they point to the proper servers (valid authentication brokers). If all domains are UNIX-based, they should point to a UNIX machine running the authentication broker. This process can also be verified in bp.conf using cat.
cat bp.conf SERVER = unix_master SERVER = unix_media CLIENT_NAME = unix_master AUTHENTICATION_DOMAIN = min.com "default company NIS namespace" NIS unix_master 0 AUTHENTICATION_DOMAIN = unix_master "unix_master password file" PASSWD unix_master 0 AUTHORIZATION_SERVICE = unix_master.min.com 0 USE_VXSS = REQUIRED #
Media server verification points for UNIX

The following section describes the procedures for UNIX media server verification and let you:

Verify the media server Verify that the server has access to the authorization database Understand the Unable to load library message
Verify the media server

To determine which authentication broker the media server is authenticated against, run bpnbat -whoami with -cf for the media servers credential file. For example:
bpnbat -whoami -cf
/usr/openv/var/vxss/credentials/unix_media.min.com
Issued by: /CN=broker/OU=root@unix_master.min.com/O=vx
If the domain listed is not NBU_Machines@unix_master.min.com, consider running bpnbat -addmachine for the name in question (unix_media). This command is run on the machine with the authentication broker that serves the NBU_Machines domain (unix_master). Then, on the machine where we want to place the certificate, run (unix_master): bpnbat -loginmachine

To make sure that the media server is able to access the authorization database
as it needs, run bpnbaz -ListGroups
machine_credential_file
For example:
bpnbaz -ListGroups -CredFile

NBU_User
NBU_Operator
NBU_Admin
NBU_Security Admin
Vault_Operator
If this command fails, run bpnbaz -AllowAuthorization on the master server that is the authorization server (unix_master). Note that you need to run as root or administrator.

Verify the media server and that it has access to the proper database. This verification indirectly informs us that the Symantec Product Authentication and authorization client libraries for both authentication and authorization are properly installed. If either of these procedures fail with the message unable to load libraries, check to make certain the Authentication and Authorization client libraries are installed. See the Symantec Product Authentication and Authorization Installation Guide on the Symantec Product Authentication and Authorization installation CD. You may also verify that the authentication domains are correct. Do this verification viewing the Access Control host properties for this media server, or by cat(1)ing the bp.conf file.
205
Client verification points for UNIX

The following section describes procedures for UNIX client verification.

Verify the credential for the client Verify that the authentication client libraries are installed Verify correct authentication domains
Verify the credential for the client

bpnbat -whoami -cf
/usr/openv/var/vxss/credentials/unix_client.min.com
Name: unix_client.min.com
If the domain listed is not NBU_Machines@unix_master.min.com, consider running bpnbat -addmachine for the name in question (unix_client). This command is run on the machine with the authentication broker that serves the NBU_Machines domain (unix_master). Then, on the machine where we want to place the certificate (unix_client), run: bpnbat -loginmachine

bpnbat -login
Authentication Broker: unix_master.min.com
Authentication type (NIS, NIS+, WINDOWS, vx, unixpwd): NIS
Domain: min.com
Name: Smith
Password:
This verification can also be done by looking at /etc/vx/vss/*.loc to see where the libraries are installed, and verify they are in the location indicated:
cat /etc/vx/vss/*.loc
ProductInstallDir=/opt/VRTSat
ProductInstallDir=/opt/VRTSaz
ls -l /opt/VRTSat/*/opt/VRTSaz/*
Verify correct authentication domains

In the Access Control host properties or by using cat(1), check that any defined authentication domains for the client are correct. Make certain that the domains are spelled correctly. And make sure that the authentication brokers on the list for each of the domains are valid for that domain type. This process can also be verified in bp.conf using cat(1).
cat bp.conf SERVER = unix_master SERVER = unix_media CLIENT_NAME = unix_master AUTHENTICATION_DOMAIN = min.com "default company NIS namespace" NIS unix_master 0 AUTHENTICATION_DOMAIN = unix_master.min.com "unix_master password file" PASSWD unix_master 0 AUTHORIZATION_SERVICE = unix_master.min.com 0 USE_VXSS = REQUIRED
Verification points in a mixed environment with a UNIX master server

The following procedures (and Figure 4-52) can help you verify that the master server, media server, and client are configured correctly. These should be configured for a heterogeneous NetBackup Access Control environment. The master server is a UNIX machine.

Master server verification points for mixed UNIX master Media server verification points for mixed UNIX master Client verification points for mixed UNIX master
207
Figure 4-52
Example mixed configuration containing a UNIX master
authenticationNBU master server (UNIX) unix_master.min.com server Root Broker Authentication Broker authorization Authorization Service server Private Symantec Product Authentication and Authorization Host (Windows) domain called NBU_Machines@unix_master.min.com win_server.min.com contains the following credentials: authentication Authentication Broker unix_master.min.com
server
win_media.min.com win_server.min.com
win_client.min.com unix_media.min.com
unix_client.min.com
Windows hosts authenticate via Windows Authentication Broker Media server (Windows) win_media.min.com authentication client, authorization client See note. win_media.min.com
Client (Windows) win_client.min.com authentication client win_client.min.com
Media server (UNIX) unix_media.min.com authentication client, authorization client unix_media.min.com UNIX hosts authenticate via
UNIX authentication Broker
Client (UNIX) unix_client.min.com authentication client unix_client.min.com
Note: Each machine has a private domain account. Using these accounts allows NetBackup to more reliably identify machines as they communicate with each other.
Master server verification points for mixed UNIX master

For UNIX master servers, follow the same procedures as those listed in Master server verification points for UNIX on page 201.
Media server verification points for mixed UNIX master

Verify the UNIX media server
For UNIX media servers, follow the same procedures as those listed in Media server verification points for UNIX on page 203.
Verify the Windows media server

Check the machine certificate comes from the root authentication broker, which
is found on the UNIX master server (unix_master).
If there is a missing certificate, run the following commands to correct the
problem:
bpnbat -addmachine on the root authentication broker (in this example, unix_master) bpnbat -loginmachine (in this example, win_media)
bpnbat -whoami -cf "C:\program
For example:
Verify that a media server is permitted to perform authorization lookups

Make sure the media server is allowed to perform authorization checks by running bpnbaz -listgroups -CredFile. For example:
bpnbaz -listgroups -CredFile "C:\program
NBU_User
NBU_Operator
NBU_Admin
NBU_Security Admin
Vault_Operator
If the media server is not allowed to perform authorization checks, run bpnbaz -allowauthorization on the master server for the media server name in question.
209

Verify the Windows media server and that it can to perform authorization checks indirectly. This verification informs us that the Symantec Product Authentication and Authorization client libraries for both authentication and authorization are properly installed. If either of these procedures fail with a message unable to load libraries, check to make certain the authentication and authorization client libraries are installed. See the Symantec Product Authentication and Authorization Installation Guide on the Symantec Product Authentication and Authorization installation CD.
Verify authentication domains

Verify that the authentication domains are correct by viewing the Access Control host properties for this media server. You can also use regedit (or regedit32) directly on the media server in the following location:
HKEY_LOCAL_MACHINE\Software\VERITAS\NetBackup\CurrentVersion\config \AUTHENTICATION_DOMAIN
Cross platform authentication domains

Take extra care in mixed environments to ensure that the appropriate domain types point to the correct authentication brokers. In the example, note that the WINDOWS domains point to win_media.min.com.
Client verification points for mixed UNIX master

For UNIX client machines, follow the same procedures as those listed in Client
verification points for UNIX on page 205.
For Windows clients:
Verify the credential for the Windows client



files\veritas\netbackup\var\vxss\credentials\win_client.min.com

Run bpnbat -login on the client to verify that the authentication client libraries are installed. For example:
bpnbat -login
Authentication Broker: unix_master.min.com
Domain: min.com
Name: Smith
Password:
Verifying the Windows authentication broker

Make sure that the Windows authentication broker has mutual trust with the main UNIX authentication broker. Also, make sure the broker uses the UNIX broker as its root broker. See the Symantec Product Authentication and Authorization Installation Guide on the Symantec Product Authentication and Authorization installation CD for more information regarding these scenarios.
Verification points in a mixed environment with a Windows master server

The following procedures can help you verify that the master server, media server, and client are configured correctly. They should be configured for a heterogeneous NetBackup Access Control environment. The master server is a Windows machine.

Master server verification points for mixed Windows master Media server verification points for mixed Windows master Client verification points for mixed Windows master
211
Figure 4-53
Example mixed configuration containing a Windows master
authentication NBU master server (Windows) win_master.min.com server Root Broker Authentication Broker authorization Authorization Service server Private Symantec Product Authentication and Authorization MediaServer (UNIX) domain called NBU_Machines@win_server.min.com unix.media2min.com contains the following credentials: authentication Authentication Broker win_master.min.com server unix_media2.min.com unix_media2.min.com unix_media.min.com unix_client.min.com win_media.min.com win_client.min.com UNIX user accounts authenticate via UNIX Authentication Broker
Media server (UNIX) unix_media.min.com authentication client, authorization client See note. unix_media.min.com
Client (UNIX) unix_client.min.com authentication client unix_client.min.com
Media server (Windows) win_media.min.com authentication client, authorization client Windows user accounts authenticate via Windows authentication broker win_media.min.com
Client (Windows) win_client.min.com authentication client win_client.min.com Note: Each machine has a private domain account. Using these accounts allows NetBackup to more reliably identify machines as they communicate with each other.
Master server verification points for mixed Windows master

Follow the same procedures as those listed in the Master server verification points as those listed in Master server verification points for Windows on page 194.
Media server verification points for mixed Windows master

Verify the Windows media server
For Windows media servers, follow the same procedures as those listed in Media server verification points for Windows on page 196.
Verify the UNIX media server

Check that the machine certificate is issued from the root authentication broker, found on the Windows master server (win_master). To determine which authentication broker the media server is authenticated against, run bpnbat -whoami with -cf for the media servers credential file. For example:
bpnbat -whoami -cf

To make sure that the media server is able to access the authorization database it needs to perform authorization checks. Run bpnbaz -ListGroups -CredFile "/usr/openv/var/vxss/credentials/<hostname> For example:
bpnbaz -ListGroups -CredFile\
NBU_Operator
NBU_Admin
NBU_SAN Admin
NBU_User
NBU_Security Admin
Vault_Operator
If the media server is not allowed to perform authorization checks, run bpnbaz -allowauthorization on the master server for the media server name in question.
213

Verify the media server and that it has access to the proper database indirectly. This verification informs us that the Symantec Product Authentication and Authorization client libraries for both authentication and authorization are properly installed. If either of these procedures fail with a message unable to load libraries, check to make certain the authentication and authorization client libraries are installed. See the Symantec Product Authentication and Authorization Installation Guide on the Symantec Product Authentication and Authorization installation CD.
Cross platform authentication domains

You may also verify that the authentication domains are correct by viewing the Access Control host properties for this media server. Or, you may also verify by cat(1)ing the bp.conf file. Take extra care in mixed environments to ensure that the appropriate domain types point to the correct authentication brokers. In the example, note that the PASSWD and NIS domains point to unix_media2.min.com, which, in this example, is the UNIX authentication broker:
cat bp.conf
SERVER = win_master.min.com
MEDIA_SERVER = unix_media.min.com
MEDIA_SERVER = unix_media2.min.com
CLIENT_NAME = unix_media
AUTHENTICATION_DOMAIN = win_master "win_master domain" WINDOWS
win_master.min.com
0
AUTHENTICATION_DOMAIN = enterprise "enterprise domain" WINDOWS
win_master.min.com 0
AUTHENTICATION_DOMAIN = unix_media2.min.com "local unix_media2
domain" PASSWD unix_media2.min.com 0
AUTHENTICATION_DOMAIN = min.com "NIS domain" NIS
unix_media.min.com 0
AUTHORIZATION_SERVICE = win_master.min.com 0
USE_VXSS = REQUIRED
Client verification points for mixed Windows master

Verify the credential for the Windows client
For Windows clients, follow the same procedures as those listed in.Client verification points for Windows on page 198.
Verify the credential for the UNIX client


bpnbat -whoami -cf \

"/usr/openv/var/vxss/credentials/unix_client.min.com"
Name: unix_client.min.com

bpnbat -login
Authentication Broker: unix_media2.min.com
Domain: min.com
Name: Smith
Password:
You do not currently trust the server: unix_media.min.com, do
you wish to tr
ust it? (y/n):
y
Verify the UNIX authentication broker

Make sure that the UNIX authentication broker has mutual trust with the main Windows authentication broker, or make sure it uses the Windows broker as its root broker. See the Symantec Product Authentication and Authorization Installation Guide on the Symantec Product Authentication and Authorization installation CD for more information regarding this scenario.
Other troubleshooting topics

The following sections describe helpful topics when configuring Symantec Product Authentication and Authorization with NetBackup.

Verifying master server settings Establishing root credentials Expired credentials message Useful debug logs Uninstalling Symantec Product Authentication and Authorization Where credentials are stored How system time affects access control
215
Symantec Product Authentication and Authorization ports Stopping Symantec Product Authentication and Authorization Service daemons If you lock yourself out of NetBackup Using the nbac_cron utility
Verifying master server settings

Running bpnbat -whoami and specifying the machine credentials, tells in what domain a host is registered and the name of the machine the certificate represents.
bpnbat -whoami -cf
"c:\program
Files\veritas\netbackup\var\vxss\credentials\master.min.com"
Name: master.min.com
Domain: NBU_Machines@master.min.com
Issued by: /CN=broker/OU=root@master.min.com/O=vx
If the domain listed is not NBU_Machines@master.min.com, consider running bpnbat -addmachine for the name in question (master). The command is run on the machine that serves the NBU_Machines domain (master). Then, on the machine where you want to place the credentials, run: bpnbat -loginmachine
Establishing root credentials

If you have problems setting up either the authentication or authorization server, and the application complains about your credentials as root, ensure that the $HOME environmental variable is correct for root. Use the following command to detect the current value:
echo $HOME
This value should agree with roots home directory, which can be typically found in the /etc/passwd file. Note that when switching to root, you may need to use:
su -
instead of only su to correctly condition the root environment variables.
Expired credentials message

If your credential has expired or is incorrect, you may receive the following message while running a bpnbaz or bpnbat command:
Supplied credential is expired or incorrect. Please reauthenticate

and try again.
Run bpnbat -Login to update an expired credential.
Useful debug logs

The following logs are useful when debugging NetBackup Access Control: On the master: admin, bpcd, bprd, bpdbm, bpjobd, bpsched On the client: admin, bpcd See the NetBackup Troubleshooting Guide for instructions on implementing proper logging.
Uninstalling Symantec Product Authentication and Authorization

On UNIX:
Using installics, select the option for uninstalling authentication and
authorization. The following directories should be empty after uninstalling:
/opt/VRTSat and /opt/VRTSaz
/etc/vx/vss
/var/VRTSat and /var/VRTSaz
On Windows:
Use the Windows Add/Remove Programs panel from the Control Menu to
uninstall authentication and authorization. The \Veritas\Security
directory should be empty after uninstalling.
Where credentials are stored

NetBackup Symantec Product Authentication and Authorization credentials are
stored in the following directories:
UNIX:
User credentials: $HOME/.vxss
Machine credentials: /usr/openv/var/vxss/credentials/
Windows:
<user_home_dir>\Application Data\VERITAS\VSS
How system time affects access control

Credentials have a birth and death time. Machines with large discrepancies in system clock time view credentials as being created in the future or prematurely expired. Consider synchronizing system time if you have trouble communicating between systems.
217
Symantec Product Authentication and Authorization ports

Symantec Product Authentication and Authorization daemon services listen on ports 2821 for authentication (vxatd) and 4032 for authorization (vxazd). You can verify that the processes are listening with the following commands: Authentication: UNIX: netstat -an | grep 2821
Windows: netstat -a -n | find "2821"
Authorization: UNIX: netstat -an | grep 4032
Windows: netstat -a -n | find "4032"
Stopping Symantec Product Authentication and Authorization Service daemons

When the Symantec Product Authentication and Authorization services are stopped, stop authorization first, then stop authentication. UNIX: Use the following commands. To stop authorization: /opt/VRTSaz/bin/vrtsaz -stop To stop authentication use the term signal as shown in the example:
# ps -fed |grep vxatd root 16018 1 4 08:47:35 ? root 16019 16011 0 08:47:39 pts/2 # kill 16018 0:01 ./vxatd 0:00 grep vxatd
Windows: Use the Services utility that Windows provides, since these services do not appear in the NetBackup Activity Monitor.
If you lock yourself out of NetBackup

You can lock yourself out of the NetBackup Administration Console if Access
Control is incorrectly configured.
If this lock-out occurs, use vi to read the bp.conf entries (UNIX) or regedit
(Windows) to view the Windows registry in the following location:
HKEY_LOCAL_MACHINE\Software\VERITAS\NetBackup\CurrentVersion\config
You can look to see if the following entries are set correctly: AUTHORIZATION_SERVICE, AUTHENTICATION_DOMAIN, and USE_VXSS.
218 Access control security Using the access management utility
The administrator may not wish to use NetBackup Access Control or does not have the authorization libraries installed, make certain that the USE_VXSS entry is set to Prohibited, or is deleted entirely.
Using the nbac_cron utility

Use the nbac_cron.exe utility to create identities under which to run cron or
at jobs.
nbac_cron.exe is found in the following location:
UNIX: /opt/openv/netbackup/bin/goodies/nbac_cron
Windows: Install_path\netbackup\bin\goodies\nbac_cron.exe
nbac_cron options:
-SetupAt [-Port #]
-SetupCron [-Port #]
Either option sets up an authentication account. Optionally, specify a port number to use for authentication. -AddAt Create an at account for a user. -AddCron Create a cron account for a user.
Using the access management utility

Users that are assigned to the NetBackup Security Administrator user group
have access to Access Management mode in the GUI. Users that are assigned to
any other user group, including NetBackup Administrator, can see the Access
Management node. This node is visible in the NetBackup Administration
Console, but you cannot expand it.
If a user other than a Security Administrator tries to select Access Management,
an error message displays. Toolbar buttons and menu items specific to Access
Management are not displayed.
Upon successful completion, the default NetBackup user groups should display
in the NetBackup Administration Console under Access Management > NBU
User Groups.
To list the groups on the command line, run bpnbaz -ListGroups on the
machine where the authorization server software is installed.
UNIX:
bpnbaz is located in directory /usr/openv/netbackup/bin/admincmd
Windows:
Access control security Determining who can access NetBackup
219
bpnbaz is located in directory Install_path\NetBackup\bin\admincmd (You must be logged in as the Security Administrator by using bpnbat -login)
bpnbaz -ListGroups NBU_Operator NBU_Admin NBU_SAN Admin NBU_User NBU_Security Admin Vault_Operator Operation completed successfully.
The NetBackup user groups are listed. This verifies that the Security Administrator can access the user groups.
Determining who can access NetBackup

Access Management allows only one user group, by default, the NBU_Security Admin user group, to define the following aspects of NetBackup Access Management:

The permissions of individual users. See Individual users. The creation of user groups. See User groups.
First, determine which NetBackup resources your users need to access. (See
Permissions for NetBackup user groups on page 232 for resources and associated permissions.) The Security Administrator may want to first consider what different users have in common, then create user groups with the permissions that these users require. User groups generally correspond to a role, such as administrators, operators, or end users. Consider basing user groups on one or more of the following criteria:

Functional units in your organization (UNIX administration, for example) NetBackup resources (drives, policies, for example) Location (East Coast or West coast, for example) Individual responsibilities (tape operator, for example)
Note: Permissions are granted to individuals in user groups, not to individuals on a per-host basis. They can only operate to the extent that they are authorized to do so. No restrictions are based on machine names.
220 Access control security Determining who can access NetBackup
Individual users
NetBackup Access Management uses your existing OS-defined users, groups, and domains. As such, Access Management maintains no list of users and passwords. When members of groups are defined, the Security Administrator specifies existing OS users as members of user groups. Every authenticated user belongs to at least one authorization user group. By default, every user belongs to the user group NBU_Users, which contains all authenticated users.
Only users and OS groups display in the

console, not domains.
Note: Contents of Access Management visible only to members of the NBU_Security Admin user group.
221
Only users and OS groups display in the console, not domains.
All authenticated users are implicit members of the NBU_Users user group All other groups must have members defined explicitly. The NetBackup Security Administrator can delete manually added member to other groups. However, the Security Administrator may not delete the predefined implicit members of the NBU_Security Admin groups. OS groups and OS users may be added to an authorization group.
User groups
NetBackup Access Management is configured by assigning permissions to user groups, then assigning users to the user groups. Assigning permissions to groups is done rather than assigning permissions directly to individual users
223
Upon successful installation, NetBackup provides default user groups that complement how sites often manage the duties of NetBackup operation. The user groups are listed under Access Management > NBU User Groups. Keep in mind that the contents of Access Management are visible to members of the NBU_Security Admin group only. The Security Administrator may choose to use the default NetBackup user groups, or may choose to create custom user groups.
Default user groups

Users that are granted permissions in each of the default user groups relate directly to the group name. Essentially, an authorization object correlates to a node in the NetBackup Administration Console tree. The following sections describe each NetBackup default user group:
Operator (NBU_Operator)
The main task of the NBU_Operator user group is to monitor jobs. For example, members of the NBU_Operator user group might monitor jobs and notify a NetBackup administrator if there is a problem. Then the administrator can address the problem. Using the default permissions, a member of the NBU_Operator user group would probably not have enough access to address larger problems. Members of the NBU_Operator user group have permissions to allow them to perform some tasks such as moving tapes, operating drives, and inventorying robots.
Administrator (NBU_Admin)
By default, members of the NBU_Admin user group have full permission to access, configure, and operate any NetBackup authorization object (with some exceptions for SAN Administrators). In other words, members have all the capabilities that are currently available to administrators without Access Management in place. However, as members of this group, you do not necessary log on as root or administrator in the OS. Note: Members of the NBU_Admin user group cannot see the contents of Access Management, and therefore, cannot ascribe permissions to other user groups.
SAN Administrator (NBU_SAN Admin)
By default, members of the NBU_SAN Admin user group have full permissions to browse, read, operate and configure disk pools and host properties. These
permissions make sure that you can configure the SAN environment and NetBackups interaction with it.
User (NBU_User)
The NBU_User user group is the default NetBackup user group with the fewest permissions. Members of the NBU_User user group can only backup, restore, and archive files on their local host. NBU_User user group members have access to the functionality of the NetBackup client interface (BAR).
Security administrator (NBU_Security Admin)
Usually very few members exist in the NBU_Security Admin user group. The only permission that the Security Administrator possesses by default is that of configuring Access Control within Access Management. Configuring Access Control includes the following abilities:

To see the contents of Access Management in the NetBackup Administration Console To create, modify, and delete users and user groups To assign users to user groups To assign permissions to user groups
Vault operator (Vault_Operator)

The Vault_Operator user group is the default user group that contains permissions to perform the operator actions necessary for the Vault process.
Additional user groups

The Security Administrator (member of NBU_Security Admin or equivalent) can create user groups as needed. The default user groups can be selected, changed, and saved. Symantec does recommend that the groups be copied, renamed, then saved to retain the default settings for future reference.
User group configuration

The Security Administrator can create a new user groups. They can be created by clicking Actions > New Group or by selecting an existing user group and selecting Actions > Copy to New Group.
225
Creating a new user group

To create a new user group 1 2 3 4 As a member of the NBU_Security Admin user group (or equivalent), expand Access Management > NBU User Groups. Select Actions > New User Group. The Add New User Group dialog displays, opened to the General tab. Type the name of the new group in the Name field, then click the Users tab. For more information on users, see Users tab on page 226. Select the defined users that you wish to assign to this new user group. Then click Assign. Or, to include all the defined users in the group, click Assign All. To remove users from the assigned users list, select the user name, then click Remove. Click the Permissions tab on page 229. Select a resource from the Resources list and an Authorization Object. Then select the permissions for the object. Click OK to save the user group and the group permissions.
5 6 7
Creating a new user group by copying an existing user group

To create a new user group by copying an existing user group 1 2 3 4 5 As a member of the NBU_Security Admin user group (or equivalent), expand Access Management > NBU User Groups. Select an existing user group in the Details pane. (The pane on the left side of the NetBackup Administration Console.) Select Actions > Copy to New User Group. A dialog that is based on the selected user group displays, opened to the General tab. Type the name of the new group in the Name field, then click the Users tab. Select the defined users that you wish to assign to this new user group. Then click Assign. Or, to include all the defined users in the group, click Assign All. To remove users from the assigned users list, select the user name, then click Remove. Click the Permissions tab. Select a resource from the Resources list and Authorization Object, then select the permissions for the object. Click OK to save the user group and the group permissions. The new name for the user group appears in the Details pane.
6 7 8
Renaming user groups

Once a NetBackup user group has been created, the user group cannot be renamed. The alternative to directly renaming a user group is to follow these steps: copy the user group, give the copy a new name, ensure the same membership as the original, then delete the original NetBackup user group.
General tab
The General tab contains the name of the user group. If you create a new user group, the Name field can be edited.
Users tab
The Users tab contains controls to assign and remove users from user groups.
Defined users
The Defined Users list is a list of all users that are defined manually within other groups.
227
Assign button: Select a user in the Defined User list and click Assign to assign that user to a user group. Assign All button: Click Assign All to add all defined users to the user group.
Assigned users
The Assigned Users list contains defined users who have been added to the user group.

Remove button: Select a user in the Assigned Users list and click Remove to remove that user from the user group. Remove All button: Click Remove All to remove all assigned users from the Assigned User list.
Add new user

Click New User to add a user to the Defined Users list. After you add a user, the name appears in the Defined Users list and the Security Administrator can assign the user to the user group. (See To add a new user to a user group on page 229.)
Defining user groups and users

NetBackup authenticates existing users of the operating system rather than requiring that NetBackup users be created with a NetBackup password and profile.
Defining a user group

Users can belong to more than one user group and have the combined access of both groups.
User_Group_1 Users can belong in more than one user group Users
User_Group_2
Users
While users can be members of multiple user groups simultaneously, NetBackup does not allow user groups to be nested. For example, while members of a user group can belong to more than one user group, a user group cannot belong to another user group.
User_Group_1 Users User_Group_2 Nested user groups are not allowed
Users
Logging in as a new user

The File > Login as New User option (Windows) is available on the systems that are configured for access control. It is useful when employing the concept of operating with least privileges and an individual needs to switch to using an account with greater privilege.
229
Adding a new user to a user group

To add a new user to a user group 1 2 3 As a member of the NBU_Security Admin user group (or equivalent), expand Access Management > NBU User Groups. Double-click on the user group to which you wish to add a user. Select the Users tab and click Add User.
Enter the user name and the authentication domain. Select the domain type of the user: NIS, NIS+, PASSWD, Windows, or Vx. See the Symantec Product Authentication and Authorization Administrators Guide for more information on domain types. Select the domain type of the user:

NIS: Network Information Services NIS+: Network Information Services Plus PASSWD: UNIX password file on the authentication server Windows: Primary domain controller or Active Directory
Vx: Veritas private database For the User Type, select whether the user is an individual user or an OS domain. 5 Click OK. The name is added to the Assigned Users list.
Permissions tab
The Permissions tab contains a list of NetBackup authorization objects and configurable permissions that are associated with each object.
Authorization objects and permissions list

In general, an authorization object correlates to a node in the NetBackup Administration Console tree.
The Authorization Objects column contains the NetBackup objects to which

permissions can be granted.
The Permissions for DevHost column indicates the permission sets for which
the selected user group is configured. An authorization object may be granted
one of these permission sets:
Browse / Read Operate Configure
A lowercase letter in the Permissions for DevHost column indicates some (but not all) of the permissions in a permission set have been granted for the object.
231
Permissions list
Select an authorization object. Then place a check in front of a permission that you want to grant the members of the user group currently selected.
When a user group is copied to create a new user group, the permission settings are copied as well.
232 Access control security Permissions for NetBackup user groups
Permissions for NetBackup user groups
The permissions granted to each of the NBU User Groups correlate to the name of the authorization object. The NBU default User Groups include the NBU_Operator, NBU_Admin, NBU_SAN Admin, NBU_User, NBU_Security Admin, and Vault_Operator. To view specific user permissions: 1 2 In the NetBackup Administration Console, select NBU User Groups under the Access Management item. Double click on the appropriate NBU_Operator, NBU_Admin, NBU_SAN Admin, NBU_User, NBU_Security Admin, or Vault_Operator in the Security window. In the NBU_Operator window, select the Permissions tab. From the list, select the desired authorization object. Permissions for that object are displayed in the window on the right.
3 4
Authorization objects
The following tables show the authorization objects in the order that they appear in the Administration Console, NBU_Operator window. The tables also show relationships between the authorization objects and default permissions for each of the NBU user groups.

The X indicates that the specified user group has permission to perform the activity. The --- indicates that the specified user group does not have permission to perform the activity. Media permissions Policy permissions Drive permissions Report permissions NBU_Catalog permissions Robot permissions StorageUnit permissions DiskPool permissions BUAndRest permissions Job permissions
Access control security Permissions for NetBackup user groups
233
Service permissions HostProperties permissions License permissions VolumeGroup permissions VolumePool permissions DevHost permissions Security permissions FT Server permissions FT Client permissions Vault permissions ServerGroup permissions
Media permissions
The table shows the permissions that are associated with the Media authorization object. Table 4-8 Set
Browse Read Operate
Media permissions Activity

Browse Read
NBU_ NBU_Admin NBU_SAN NBU_User NBU_Security Vault_ Operator Admin Admin Operator
X X X X X X X X X X X X X ------------------------------------------------------------------X X X X X X X X X X X
Update bar codes X Eject Move Assign Deassign Update Database X X X X X -------
Configure
New Delete Expire
Note: X indicates that the user group has permission to perform the activity. --- indicates that the user group does not have permission to perform the activity.
Policy permissions
The table shows the permissions that are associated with the Policy authorization object. Table 4-9 Set
Browse Read Operate Configure
Policy permissions Activity

Browse Read Backup Activate Deactivate New Delete
NBU_ Operator
X X X ---------
NBU_Admin
X X X X X X X
NBU_SAN Admin
---------------
NBU_User NBU_Security Admin

-----------------------------
Vault_ Operator
---------------
Drive permissions
The table shows the permissions that are associated with the Drive authorization object. Table 4-10 Set
Browse Read Operate
Drive permissions Activity

Browse Read Up Down Reset
NBU_ Operator
X X X X X -----
NBU_Admin
X X X X X X X
NBU_SAN Admin
---------------

-----------------------------
Vault_ Operator
---------------
Configure
New Delete
235
Report permissions
The table shows the permissions that are associated with the Report authorization object. Reports include only the Access permission set, and does not include a Configure or Operate permission set. Table 4-11 Set
Browse Read
Report permissions Activity

Browse Read
NBU_ Operator
-----
NBU_Admin
X X
NBU_SAN Admin
-----

---------
Vault_ Operator
X X
NBU_Catalog permissions
The table shows the permissions that are associated with the NetBackup catalog authorization object. Table 4-12 Set
Browse Read Operate
NBU_Catalog permissions Activity

Browse Read Backup Restore Verify Duplicate Import Export
------------------------X X X X X X X X X X X X -------------------------------------------------------------------------------------------------
Configure New Delete Read Configuration Set Configuration
Table 4-12 Set
NBU_Catalog permissions Activity NBU_ NBU_Admin NBU_SAN NBU_User NBU_Security Vault_ Operator Admin Admin Operator
Robot permissions
The table shows the permissions that are associated with the robot authorization object. Table 4-13 Set
Robot permissions Activity

Browse Read Inventory New Delete
NBU_ Operator
X X X -----
NBU_Admin
X X X X X
NBU_SAN Admin
-----------

---------------------
Vault_ Operator
X X X X X
StorageUnit permissions
The table shows the permissions that are associated with the storage unit authorization object. Table 4-14 Set
Browse Read Configure
StorageUnit permissions Activity

Browse Read Assign New Delete
NBU_ Operator
X X -------
NBU_Admin
X X X X X
NBU_SAN Admin
-----------

---------------------
Vault_ Operator
-----------
237
Table 4-14 Set
StorageUnit permissions Activity NBU_ Operator NBU_Admin NBU_SAN Admin NBU_User NBU_Security Admin Vault_ Operator
DiskPool permissions
The table shows the permissions that are associated with the disk pool authorization object. Table 4-15 Set
Browse Read Operate
DiskPool permissions Activity

Browse Read New Delete Modify Mount Unmount
X X --------------X X X X X X X X --X X X X X X X X X -------------------------------------------------------
Configure Read Configuration Set Configuration
BUAndRest permissions
The table shows the permissions that are associated with the backup and restore authorization object. Table 4-16 Set
Browse
BUAndRest permissions Activity

Browse
NBU_ NBU_Admin NBU_SAN NBU_User NBU_Security Operator Admin Admin

X X X X ---
Vault_ Operator
---
Table 4-16 Set

Read Operate
BUAndRest permissions Activity

Read Backup Restore Alternate Client Alternate Server Admin Access Database Agent List
NBU_ NBU_Admin NBU_SAN NBU_User NBU_Security Operator Admin Admin

X X X X X ----X X X X X X X X X X X X --------X X X X --------X -----------------
Vault_ Operator
-----------------
Job permissions
The table shows the permissions that are associated with the Job authorization object. Table 4-17 Set
Browse Read Operate
Job permissions Activity

Browse Read Suspend Resume Cancel Delete Restart New
NBU_ Operator
X X X X X X X X
NBU_Admin
X X X X X X X X
NBU_SAN Admin
-----------------

---------------------------------
Vault_ Operator
X X X X X X X X
239
Service permissions
The table shows the permissions that are associated with the Service authorization object. Table 4-18 Set
Browse Read Operate
Service permissions Activity

Browse Read Stop
NBU_ Operator
X X X
NBU_Admin
X X X
NBU_SAN Admin
-------

-------------
Vault_ Operator
-------
* The Read and Browse permissions do not have an affect on the Services/Daemons tab. This information is harvested from the server using user level calls. The calls are used to access the process task list and is displayed to all users for informational purposes. ** If a user is not a member of the NBU_Admin user group, but is logged on as an OS administrator (Administrator or root), then:

The user is able to restart a service from within the NetBackup Administration Console or from the command line. The user is able to stop a service from within the NetBackup Administration Console but not from the command line.
** If a user is not a member of the NBU_Admin user group, but is logged on as an OS administrator (root). That user is able to restart a daemon from the command line only: /etc/init.d/netbackup start
If a user is a member of the NBU_Admin user group, but is not logged on as an OS administrator (Administrator), then:

The user is not able to restart a service from within the NetBackup Administration Console or from the command line. The user is not able to stop a service from within the NetBackup Administration Console but the user can use the command line. (For example, bprdreq -terminate, bpdbm -terminate, or stopltid.)
If a user is a member of the NBU_Admin user group, but is not logged on as an OS administrator (root). That user is not able to restart a daemon from the NetBackup Administration Console or from the command line.

HostProperties permissions
The table shows the permissions that are associated with the host properties authorization object. Table 4-19 Set
HostProperties permissions Activity

Browse Read New Delete
NBU_ Operator
X X -----
NBU_Admin
X X X X
NBU_SAN Admin
X X -----

X X ----X X -----
Vault_ Operator
X X -----
License permissions
The table shows the permissions that are associated with the License authorization object. Table 4-20 Set
License permissions Activity

Browse Read Assign New Delete
NBU_ Operator
-----------
NBU_Admin
X X X X X
NBU_SAN Admin
-----------

---------------------
Vault_ Operator
-----------
241
VolumeGroup permissions
The table shows the permissions that are associated with the volume group authorization object. Table 4-21 Set
VolumeGroup permissions Activity

Browse Read New Delete
NBU_ Operator
X X -----
NBU_Admin
X X X X
NBU_SAN Admin
---------

-----------------
Vault_ Operator
X X X X
VolumePool permissions
The table shows the permissions that are associated with the volume pool authorization object. Table 4-22 Set
VolumePool permissions Activity

Browse Read Backup Assign New Delete
NBU_ Operator
X X X -------
NBU_Admin
X X X X X X
NBU_SAN Admin
-------------

-------------------------
Vault_ Operator
X X ---------
DevHost permissions
The table shows the permissions that are associated with the device host authorization object. Note: Access to the Media and Device Management --> Credentials node in the GUI is controlled by the DevHost object.
Table 4-23 Set

Browse Read Operate
DevHost permissions Activity

Browse Read Stop Synchronize
NBU_ Operator
X X X X -----
NBU_Admin
X X X
NBU_SAN Admin
-------

-------------
Vault_ Operator
X X ---
Configure
New Delete
X X
-----
-----
-----
-----
Security permissions
The table shows the permissions that are associated with the security authorization object. Table 4-24 Set
Security permissions Activity

Browse Read Configure Security
NBU_ Operator
-------
NBU_Admin
-------
NBU_SAN Admin
-------

------X X X
Vault_ Operator
-------
243
FT Server permissions
The table shows the permissions that are associated with the FT Server authorization object. Table 4-25 Set
FT Server permissions Activity

Browse Read Modify Modify SAN Configuration
NBU_ Operator
X X -----
NBU_Admin
X X X ---
NBU_SAN Admin
X X X X

-----------------
Vault_ Operator
---------
FT Client permissions
The table shows the permissions that are associated with the FT Client authorization object. Table 4-26 Set
FT Client permissions Activity

Browse Read Discover Modify
NBU_ Operator
X X -----
NBU_Admin
X X X X
NBU_SAN Admin
X X X X

-----------------
Vault_ Operator
---------

Vault permissions
The table shows the permissions that are associated with the vault authorization object. Table 4-27 Set
Browse Read Operate
Vault permissions Activity

Browse Read Manage Containers Run Reports
NBU_ Operator
-------------
NBU_Admin
X X X X X X
NBU_SAN Admin
-------------

-------------
Vault_ Operator
---------
Configure
Modify Run Sessions
-----
-----
-----
ServerGroup permissions
The table shows the permissions that are associated with the server group authorization object. Table 4-28 Set
ServerGroup permissions Activity

Browse Read New Delete Modify
NBU_ Operator
X X -------
NBU_Admin
X X X X X
NBU_SAN Admin
-----------

---------------------
Vault_ Operator
-----------
Chapter
Data at rest encryption security

This chapter addresses data at rest encryption security, which is the encryption of information that is saved on disk or tape. Encrypted data saved on disk or tape is considered to be data at rest. To more fully understand the concept of data at rest encryption, refer to the encryption terminology section. This chapter contains the following major sections:

Data at rest encryption terminology on page 246

What data at rest encryption can and cannot do on page 247
Encryption security questions to consider on page 249
NetBackup data at rest encryption solutions on page 249
Option 1 - NetBackup client encryption on page 251
Installing encryption security on page 256
Configuring encryption security on page 259
Configuring NetBackup encryption on clients on page 263
Setting the encryption attribute in policies on page 266
Changing client encryption settings from the server on page 266
Configuration for standard encryption on page 267
Configuring from the server on page 267
Configuring encryption on clients on page 271
Setting the encryption attribute in policies on page 273
Changing client encryption settings from the server on page 273
Configuration for legacy encryption on page 274
246 Data at rest encryption security Data at rest encryption terminology
Configuring legacy encryption on clients on page 278 Setting legacy encryption attribute in policies on page 282 Changing client legacy encryption settings from the server on page 282 Additional legacy keyfile security for UNIX clients on page 283 Option 2 - Media server encryption on page 285 Option 3 - Third party encryption appliances and hardware devices on page 286
Data at rest encryption terminology

Asynchronous encryption
Asynchronous encryption are the encryption algorithms that uses both a public and private key.
Synchronous encryption
Synchronous encryption are the encryption algorithms that use the same key for both encryption and decryption. For the same key size, synchronous algorithms are faster and more secure than their asynchronous counterparts.
Initialization vector
The initialization vector is a seed value that is used to prime an encryption algorithm. Priming is done in order to obscure any patterns that would exist when using the same key to encrypt a number of data files. These files begin with the same pattern.
Advanced Encryption Standard (AES)

The advanced encryption standard (AES) is the synchronous encryption algorithm that replaced DES.
Data Encryption Standard (DES)

Data encryption standard (DES) is the accepted synchronous data encryption standard from the 1970's until 1998.
Public Key Encryption

Public key encryption uses asynchronous encryption.
Data at rest encryption security What data at rest encryption can and cannot do
247
What data at rest encryption can and cannot do

Computer performance impact of data encryption
Encryption algorithms, like data compressions algorithms, are very CPU intensive. Compressing data without the addition of computer hardware (either dedicated or shared), can impact computer and NetBackup performance.
Data compression must be performed prior to data encryption

Data compression algorithms look for data patterns in order to compress the data. Encryption algorithms scramble the data and remove any patterns. Therefore if data compression is desired, it must be done before the data encryption step.
Choice of an encryption algorithm

There exists a plethora of encryption algorithms and associated key sizes. What should a user choose for Data encryption? AES (Advanced Encryption Standard) has emerged as the standard for data encryption and supports 128, 192, or 256 -bit encryption keys.
AES became the standard

AES replaced the previous standard, DES which was deemed secure through about 1998. Then computer processing speed enhancements and parallel processing techniques finally showed DES to be vulnerable to attack in 10s of hours. At that point, the US Government solicited a replacement for DES. An algorithm called Rijndael (pronounced Rhine dahl), became the frontrunner. After about 5 years of peer review, and review by the US Government, a specific configuration of Rijndael became AES. In June 2003, the US Government announced that AES may be used for classified information. The design and strength of all key lengths of the AES algorithm (i.e., 128, 192 and 256) are sufficient to protect classified information up to the SECRET level. TOP SECRET information requires the use of either the 192 or 256 key lengths. The implementation of AES in products is intended to protect national security systems. Information must be reviewed and certified by NSA prior to their acquisition and use. For more information, refer to this web site: http://www.cnss.gov/Assets/pdf/cnssp_15_fs.pdf
248 Data at rest encryption security What data at rest encryption can and cannot do
Suggested key size

While generally the larger key the more secure, and the longer into the future the data will be secure. AES is one of the best choices because it is deemed secure with all three supported (128, 192, 256 bit) key sizes.
NIST FIPS 140

NIST (National Institute of Science and Technology) FIPS (Federal Information Processing Standard) 140 is a government program. This program certifies data encryption solutions for the federal government. The program requires that encryption solution providers: documenting their product from both a use and security interface perspective, then submit the product to an accredited 3rd party reviewer for validation. Upon successful review, the product is issued a validation certificate.
FIPS certification for my encryption solution

While FIPS certification may be required for use by the US government, and is a likely added level of comfort. It should not be the only criteria that is used to evaluate an encryption solution. Other things should be part of any decision making process.

FIPS certificates only apply to the named version of a product. And then only when the product is used in conformance with the FIPS Security Policy document that is submitted when the product was validated. Future product versions and non standard uses would be subject to questioned validation. The security of algorithms like AES is not in the obscurity of how they work. Rather the security is in the difficulty to deduce an unknown encryption key. The years of scrutiny and peer review for AES, have lead to mature implementations. In fact, tests exists for AES where specific keys and data sets are input, and verified against the expected output. Data encryption is much like automobile security. Most problems are related to lost / misplaced keys and not related to malfunctioning locks. Since misuse is more likely to lead to problems, the usability of an encryption product should be part of the consideration. Usability considerations include:

Encryption integration with the product Encryption integration with business processes. Appropriate encryption key granularity Recoverability
Data at rest encryption security Encryption security questions to consider
249
Appropriate encryption key granularity

This appropriate encryption key granularity is best explained with the example of home security. A single house key is convenient. I can enter my garage, front door, or back door all using the same key. This security is great until the key is compromised (i.e. key that is stolen by criminals). Then I need to change all the locks that used this key. The absurd extreme would be someone having a key for every drawer and cupboard in a house. Then a lost key would require the changing of on a single lock. The correct solution is probably somewhere in between. It is really important to understand your tolerance for a compromised or lost key from your business process perspective. A lost key implies all the data that is encrypted with that key is destroyed. A compromised key implies all the data that is encrypted with that key must be decrypted and re encrypted to become secure.
Encryption security questions to consider

The following questions are good to ask yourself when considering encryption security. There are no correct answer to each question. The answers depend upon your particular encryption needs.

How do I choose the best encryption? Why would I use encryption security? What protection do I need from possible inside attacks? What protection do I need from possible outside attacks? What are the specific areas of NetBackup that encryption security protects? Do I need to create drawings of NetBackup architecture showing encryption security at work? What are my deployment use cases for encryption security?
NetBackup data at rest encryption solutions

The following three NetBackup data at rest encryption options are also compared specifically in Table 5-29 on page 250.

Option 1 - NetBackup client encryption on page 251 Option 2 - Media server encryption on page 285 Option 3 - Third party encryption appliances and hardware devices on page 286
250 Data at rest encryption security NetBackup data at rest encryption solutions
Encryption options compared

The following table shows the three encryption options along with potential advantages and disadvantages for each. Table 5-29 Encryption options compared Potential advantage
The encryption key is on the client computer and not controlled by the NetBackup administrator
Encryption option
Option 1 NetBackup client encryption on page 251
Potential disadvantage
The encryption key on the client does not scale well to environments where each client must have a unique and individual encryption key.
Can be deployed without impacting the NetBackup master and media servers Can be deployed on a per client basis Encryption and compression taking place on the client can impact client performance
Option 2 - Media server encryption on page 285
Will not impact client computer performance
Master / Media server centralized Master / Media server keys centralized keys. Limited options for detailed Key Granularity Not tightly integrated with NetBackup configuration and operation Encryption and compression taking place on the media server can impact media server performance
Data at rest encryption security Option 1 - NetBackup client encryption
251
Table 5-29
Encryption options compared Potential advantage

Generally little (or no performance) impact due to added hardware.
Encryption option
Option 3 - Third party encryption appliances and hardware devices on page 286
Potential disadvantage
Generally NIST FIPS 140 certified. The Netbackup Compatibility lab tests some of these solutions. This testing is neither an endorsement or rejection or a particular solution. This effort verifies that basic functionality was verified when used with a specific version of Netbackup. No integration with NetBackup configuration, operation, or diagnostics. Disaster Recovery scenario provided by the Appliance or Device.
Option 1 - NetBackup client encryption

The NetBackup client encryption option is best suited for:

Clients that can handle the CPU burden for compression / encryption Clients that want to retain control of the data encryption keys Situations where the tightest integration of NetBackup and encryption is desired Situations where encryption is needed in terms of a per client basis
Running an encryption backup
Choosing encryption for a backup on page 252
252 Data at rest encryption security

Standard encryption backup process on page 252 Legacy encryption backup process on page 253 Standard encryption restore on page 254 Legacy encryption restore on page 255
Choosing encryption for a backup

When a backup is started, the server determines from a policy attribute whether the backup should be encrypted. The server then connects to bpcd on the client to initiate the backup and passes the Encryption policy attribute on the backup request. The client compares the Encryption policy attribute to the CRYPT_OPTION in the configuration on the client.

If the policy attribute is yes and CRYPT_OPTION is REQUIRED or ALLOWED, the client performs an encrypted backup. If the policy attribute is yes and CRYPT_OPTION is DENIED, the client performs no backup. If the policy attribute is no and CRYPT_OPTION is ALLOWED or DENIED, the client performs a non-encrypted backup. If the policy attribute is no and CRYPT_OPTION is REQUIRED, the client does not perform the backup.
Table 5-30 shows the type of backup that is performed for each condition: Table 5-30 Backup types performed for encryption methods Encryption policy attribute CRYPT_OPTION
REQUIRED ALLOWED DENIED
Yes
Encrypted Encrypted None
No
None Non-encrypted Non-encrypted
The following sections describe backup and restore operations for both standard encryption and legacy encryption methods.
Standard encryption backup process

The prerequisites for encrypting a standard backup are as follows:

The encryption software must be loaded onto the client. You load it either by running the bpinst -ENCRYPTION command on the server or by installing directly on the client.
253
Load the encryption software into the directory on the client that you specified in the CRYPT_LIBPATH configuration entry. A keyfile must exist. The keyfile is created when you run the bpkeyutil command from the server or from the client. The Encryption attribute must be selected on the NetBackup policy that includes the client. The client takes the latest key from the keyfile. For each file that is backed up, the following occurs:

If the prerequisites are met, the backup takes place as follows:

The client creates an encryption tar header. The tar header contains a checksum of the key and the cipher that NetBackup used for encryption. To write the file data that was encrypted with the key, the client uses the cipher that the CRYPT_CIPHER configuration entry defines. (The default cipher is AES-128-CFB.)
Note: Only file data is encrypted. File names and attributes are not encrypted.

The backup image on the server includes a flag that indicates whether the backup was encrypted.
Legacy encryption backup process

The prerequisites for encrypting a legacy backup are as follows:

Load the encryption software into the directory on the client that you specified in the CRYPT_LIBPATH configuration entry.
Note: In UNIX you can also use the bpinst -LEGACY_CRYPT command.

The encryption software must include the appropriate DES library, as follows:

For 40-bit DES encryption, libvdes40.suffix; the suffix is so, sl, or dll, depending on the client platform. For 56-bit DES encryption, libvdes56.suffix; the suffix is so, sl, or dll, depending on the client platform.
A keyfile must exist as specified with the CRYPT_KEYFILE configuration option. You create the keyfile when you specify a NetBackup pass phrase with the server bpinst command or the client bpkeyfile command.

You must select the Encryption attribute on the NetBackup policy that includes the client.
If the prerequisites are met and the backup is to be encrypted, the following occurs: 1 The client takes the latest data from its keyfile and merges it with the current time (the backup time) to generate a DES key. For 40-bit DES, 16 bits of the key are always set to zero. For each backed-up file, the following occurs:

The client creates an encryption tar header. The tar header contains a checksum of the DES that NetBackup used for encryption. The client writes the file data that was encrypted with the DES key.
Note: Only file data is encrypted. File names and attributes are not encrypted. 3 The server reads the file names, attributes, and data from the client and writes them to a backup image on the server. The server DOES NOT perform any encryption or decryption of the data. The backup image on the server includes the backup time and a flag that indicates whether the backup was encrypted.
NetBackup encryption restore

Standard encryption restore
The prerequisites for restoring a standard encrypted backup are as follows:

The encryption software must be loaded onto the client. A keyfile must exist. The keyfile is created when you run the bpkeyutil command from the server or from the client.
When the restore occurs, the server determines from the backup image whether the backup was encrypted. The server then connects to bpcd on the client to initiate the restore. The server sends to the client an encryption flag on the restore request. When backup takes place properly, the restore occurs as follows:

The server sends file names, attributes, and encrypted file data to the client to be restored. If the client reads an encryption tar header, the client compares the checksum in the header with the checksums of the keys in the keyfile. If the one of the keys checksum matches the headers checksum, NetBackup uses
255
that key to decrypt the file data. It uses the cipher that is defined in the header.

The file is decrypted and restored if a key and cipher are available. If the key or cipher is not available, the file is not restored and an error message is generated.
Legacy encryption restore

The prerequisites for restoring a legacy encrypted backup are as follows:

The legacy encryption software must be loaded on the client. The encryption software must include the 40-bit DES library. The name of the 40-bit DES library is libvdes40.suffix; the suffix is so, sl, or dll depending on the client platform. If the CRYPT_STRENGTH configuration option is set to DES_56, the encryption software must also include the 56-bit DES library. The name of the 56-bit DES library is libvdes56.suffix; the suffix is so, sl, or dll depending on the client platform. A keyfile must exist as specified with the CRYPT_KEYFILE configuration option. You create the keyfile when you specify a NetBackup pass phrase with the server bpinst command or the client bpkeyfile command.
The server determines from the backup image whether the backup was encrypted. The server then connects to bpcd on the client to initiate the restore. The server sends to the client an encryption flag and backup time from the backup image on the restore request. If the prerequisites are met, the following occurs:

The server sends file names, attributes, and encrypted file data to the client to be restored. The client takes its keyfile data and merges it with the backup time to generate one or more 40-bit DES keys. If the 56-bit DES library is available, the client also generates one or more 56-bit DES keys. If the client reads an encryption tar header, the client compares the checksum in the header with the checksums of its DES keys. If the checksum of a DES key matches the checksum in the header, NetBackup uses that DES key to decrypt the file data.
The file is decrypted and restored if a DES key is available. If the DES key is not available, the file is not restored and an error message is generated.
256 Data at rest encryption security Installing encryption security
Installing encryption security
In order to configure and run encrypted backups, the NetBackup Encryption software must be available on the NetBackup clients. You make it available either through a push installation from the NetBackup server or through direct local installation on the client. If you plan to push the installation, you must first install the encryption software on the server.
Installation prerequisites
If clients require encrypted backups, the servers to which they connect must run NetBackup 6.5 server software. For a list of the platforms on which you can install NetBackup Encryption, see the NetBackup Release Notes. When you install directly onto a NetBackup client, the client and NetBackup Encryption must be the same version (for example, 6.5).
Installing encryption on a UNIX NetBackup server

To install NetBackup encryption on a UNIX NetBackup server 1 If you install on a server that is part of a NetBackup cluster: Freeze the active NetBackup node so that migrations do not occur. For instructions on how to freeze the active node in your specific cluster environment, see the NetBackup High Availability Administrators Guide. Make sure that a license key for NetBackup Encryption has been registered on the NetBackup master server.
On a UNIX NetBackup master server, log in as root and use the following
command to list and add keys:
/usr/openv/netbackup/bin/admincmd/get_license_key
Note: Existing 40 -bit or 56-bit encryption license keys are valid for upgrades. 3 4 5 Log in as the root user on the UNIX NetBackup server where you want to install NetBackup Encryption. Insert the CD containing the Encryption software in the drive. Change your working directory to the CD directory:
cd /cd_directory
The cd_directory is the path to the directory where you can access the CD. On some platforms, it may be necessary to mount this directory. 6 To install NetBackup Encryption, run the installation script:
./install
Data at rest encryption security Installing encryption security
257
Since other NetBackup products are included on the CD, a menu of installation choices appears. Note: If you plan to push the encryption software to UNIX clients, you must select all applicable client platforms in step 7 of the encryption installation. 7 Select NetBackup Add-On Product Software. a b c d Select the NetBackup Encryption option. Enter q to quit the menu. When the process prompts whether the list is correct, answer y. By default, the encryption software that loads is the type that matches the server hardware type. You have the option to load software for other encryption client platforms. Select all platforms for which you intend to do a push client installation.
8 9
In a clustered environment, step 2 through step 7 must be executed on each node in the cluster. If you install on a server that is part of a NetBackup cluster: Unfreeze the active NetBackup node. For instructions on how to unfreeze the active node in your specific cluster environment, see the NetBackup High Availability Administrators Guide.
When you have completed your installation on the NetBackup master server, install the encryption software on the clients. For details, see Push installing from the NetBackup master server to a client on page 258.
Installing encryption on a Windows NetBackup server

NetBackup Windows server installations automatically include encryption software for UNIX clients (Windows client encryption software is included in the regular Windows client software installation). Use the following procedure to make sure that a license key for NetBackup Encryption has been registered on the NetBackup master server.

On the Windows master server, log in as an Administrator. Use the Help > License Keys menu in the administration console to list and add keys.
Note: Existing 40-bit encryption or 56-bit encryption license keys are valid for upgrades.
258 Data at rest encryption security Installing encryption security
When you have completed your encryption license verification on the NetBackup master server, install the encryption software on the clients. For details, see Push installing from the NetBackup master server to a client.
Push installing from the NetBackup master server to a client

Note: For Windows clients, no push installation is needed. The Encryption software is included automatically with the Windows NetBackup client installation. After you have installed the Encryption software on the NetBackup master server, you can push the Encryption software to UNIX clients. The instructions for the push installation can be found in each configuration section according to the encryption type you plan to use:

For standard encryption clients, see Pushing standard encryption software to NetBackup clients on page 260. For legacy encryption clients, see Pushing legacy encryption software to clients on page 275.
The client must allow server writes to install from the server. On a UNIX client, you must ensure that the bp.conf file does not include the DISALLOW_SERVER_WRITES parameter. After the software installs, configure the clients for encryption as described in the following sections.
Installing encryption locally on a NetBackup Windows client

No local installation is necessary for a NetBackup Windows client. The encryption software is automatically installed with the NetBackup Windows client installation. You can then configure the client encryption settings as described further in this section.
Installing encryption locally on a NetBackup UNIX client

Note: You can install NetBackup Encryption locally on IBM zSeries Linux clients. You must transfer the contents of the NetBackup Encryption CD image to a location that is readable by the virtual Linux environment. You can transfer the image by using FTP or NFS mounting commands.
Data at rest encryption security Configuring encryption security
259
To install locally on a UNIX NetBackup client 1 2 3 Log in as the root user on the UNIX NetBackup client where you want to install NetBackup Encryption. Insert the CD containing the NetBackup Encryption software in the drive. Change your working directory to the CD directory:
cd /<cd_directory>
The <cd_directory> is the path to the directory where you can access the CD. On some platforms, it may be necessary to mount this directory. 4 Run the installation script: ./install
Because other NetBackup products are included on the media, a menu of installation choices appears. Select NetBackup Add-On Product Software a b c 6 Select the NetBackup Encryption option. Enter q to quit the menu. When you are asked if the list is correct, answer y.
Configure the clients as described in the following sections.
Configuring encryption security

Configuring standard encryption on page 259 Configuring standard encryption from the server on page 260 Pushing standard encryption software to NetBackup clients on page 260
Configuring standard encryption

This section explains how to configure standard NetBackup encryption.
The configuration options that this section mentions are in the bp.conf file on
UNIX clients, and in the registry on Windows clients. The options are as follows:
CRYPT_OPTION CRYPT_KIND CRYPT_CIPHER
You can also use the NetBackup Administration Console to configure the options from the server. They are on the Encryption tab in the Client Properties dialog box. Refer to the NetBackup Administrators Guide for details.

Configuring encryption security
Configuring standard encryption from the server

You can configure most NetBackup clients for encryption by using two commands from the server: bpinst and bpkeyutil. Prerequisites include the following:

The NetBackup client software must be running on the platforms that support NetBackup Encryption (see the NetBackup Release Notes). The NetBackup clients must be running NetBackup 6.5 or later (for standard encryption). Note that standard encryption was available beginning with NetBackup 5.1.
Pushing standard encryption software to NetBackup clients

Pushing standard encryption prerequisites
Install the NetBackup encryption client software in a directory on the server. Installation is described in the Installing encryption security on page 256. The NetBackup configuration on the clients must allow server writes.

On a UNIX client, you must ensure that the bp.conf file does not include the DISALLOW_SERVER_WRITES parameter. On Microsoft Windows clients, you must allow server-directed restores, as follows:

Open the Backup, Archive, and Restore utility. Select File > NetBackup Client Properties. On the General tab of the NetBackup Client Properties dialog, select the Allow Server Directed Restores box.
If you do not want a client to allow server writes, you can do either of the following:

Temporarily change its configuration so writes are allowed Follow the procedure in Configuring NetBackup encryption on clients on page 263. For a Windows server, the full command path is:
install_path\NetBackup\bin\bpinst
Use the bpinst command to install the software.

For a UNIX server, the full command path is:

/usr/openv/netbackup/bin/bpinst
Refer to the bpinst command description in the NetBackup Commands guide for bpinst command options.
Data at rest encryption security Configuring encryption security
261
Generally, you specify client names in the bpinst command. By using the -policy_names option, you can specify policy names instead. This option affects all clients in the specified policies.
Pushing standard encryption software to clients

To push (copy) standard encryption software from NetBackup to clients, use the
-ENCRYPTION option on the bpinst command.
To install the encryption client software on client1 and client2, enter the
following command:
bpinst -ENCRYPTION client1 client2
To install the client software on all clients in the NetBackup policies policy1 and policy2, enter the following command:
bpinst -ENCRYPTION -policy_names policy1 policy2
For clustered environments:

You can push software to the inactive client node. This push is performed by the active cluster node. You must specify the host names of the individual nodes (not the virtual names) in the list of clients.
Note: For procedures on pushing legacy encryption software to clients refer to the section Pushing legacy encryption software to clients on page 275
Creating the NetBackup encryption keyfile on the clients

Creating the NetBackup keyfile

If the server is in a cluster and is also an encryption client, all nodes in the cluster must have the same keyfile. The bpkeyutil command sets up the cipher-based encryption keyfile and pass phrase on each NetBackup Encryption client.

For a Windows server, the full path to the command is as follows: install_path\NetBackup\bin\bpkeyutil
For a UNIX server, the full path to the command is as follows: /usr/openv/netbackup/bin/bpkeyutil
Note: For procedures on legacy encryption keyfile management refer to the section Managing legacy encryption keyfiles on page 279
262 Data at rest encryption security Configuring encryption security
Creating the NetBackup encryption keyfile

For each encryption client, run the following command:
bpkeyutil -clients client_name
You are prompted for a new pass phrase to add to that clients keyfile.
To set up several clients to use the same pass phrase, specify a comma-separated
list of client names, as follows:
bpkeyutil -clients client_name1,client_name2,...,client_namen
To create the keyfile, NetBackup uses the pass phrase you specify. NetBackup uses the pass phrase you specify to create the keyfile, as follows:

NetBackup uses a combination of the following two algorithms to create a key from the pass phrase that is up to 256 bits.

Secure hashing algorithm, or SHA1 Message digest algorithm, or MD5
NetBackup uses the NetBackup Private Key and 128-bit AES algorithm to encrypt the key. The key is stored in the keyfile on the client. At run time, NetBackup uses the key and a random initialization vector to encrypt the client data. The initialization vector is stored in the header of the backup image.
Previous pass phrases remain available in the file for restores of the backups that were encrypted with those phrases. Caution: You must ensure that pass phrases, whether they are new or were in use previously, are secure and retrievable. If a clients keyfile is damaged or lost, you need all of the previous pass phrases in order to recreate the keyfile. Without the keyfile, you cannot restore the files that were encrypted with the pass phrases. The keyfile must only be accessible to the administrator of the client machine. For a UNIX client, you must ensure the following:

The owner is root. The mode bits are 600. The file is not on a file system that can be NFS mounted.
Best practices for keyfile restoration

Even when an encrypted backup does not have a keyfile available, you may be able to restore the files.
Data at rest encryption security Configuring NetBackup encryption on clients
263
Manual retention
Manual retention is the most secure method for protecting your keyfile pass
phrases.
When you add a phrase by using the bpkeyutil command, complete manual
retention as follows:
Write the phrase on paper Seal the paper in an envelope Put the envelope into a safe.
If you subsequently need to restore from encrypted backups and you have lost the keyfile, do the following:

Reinstall NetBackup and NetBackup Encryption Use bpkeyutil to create a new keyfile by using the pass phrases from the safe.
Automatic backup
The automatic backup method is less secure, but it ensures that a backup copy of
your keyfile exists.
This method requires that you create a non-encrypted policy to back up the
keyfile. If the keyfile is lost, you can restore it from the non-encrypted backup.
The problem with this method is that a client's key file can be restored on a
different client.
If you want to prevent the keyfile from being backed up to a client, add the
keyfile's path name to the client's exclude list.
Configuring NetBackup encryption on clients

You can configure NetBackup Encryption on clients as explained in the following topics.
Managing NetBackup encryption configuration options

Three encryption-related configuration options for standard encryption exist on
a NetBackup client.
Ensure that the options are set to the appropriate values for your client.
CRYPT_OPTION = option
Defines the encryption options on NetBackup clients. The possible values for option follow:
denied|DENIED
264 Data at rest encryption security Configuring NetBackup encryption on clients
Specifies that the client does not permit encrypted backups. If the server requests an encrypted backup, it is considered an error.
allowed|ALLOWED
(the default value) Specifies that the client allows either encrypted or unencrypted backups.
required|REQUIRED
Specifies that the client requires encrypted backups. If the server requests an unencrypted backup, it is considered an error.
CRYPT_KIND = kind
Defines the encryption kind on NetBackup clients. The possible values for kind follow:
NONE
Neither standard encryption nor legacy encryption is configured on the client.

STANDARD
Specifies that you want to use the cipher-based 128-bit encryption or 256-bit encryption. This option is the default value if standard encryption is configured on the client.
LEGACY
Specifies that you want to use the legacy-based encryption, with 40-bit DES or 56-bit DES.
CRYPT_CIPHER = cipher
Defines the cipher type to use. It can be set to any of the following:
AES-128-CFB BF-CFB DES-EDE-CFB AES-256-CFB 128-bit Advanced Encryption Standard 128-bit Blowfish Two Key Triple DES 256-bit Advanced Encryption Standard
The default is AES-128-CFB.
Managing NetBackup encryption keyfile

Note: The keyfile must be the same on all nodes in a cluster. Use the bpkeyutil command to set up the cipher-based encryption keyfile and pass phrase on the NetBackup Encryption client.
For a Windows client, the full command path is as follows: install_path\NetBackup\bin\bpkeyutil

For a UNIX client, the full command path is as follows:
Data at rest encryption security Configuring NetBackup encryption on clients
265
/usr/openv/netbackup/bin/bpkeyutil
You are prompted to add a pass phrase for that client.
NetBackup uses the pass phrase you specify to create the keyfile, as follows:

Previous pass phrases remain available in the keyfile to allow restores of the backups that were encrypted by using those phrases. Caution: You must remember the pass phrases, including the old pass phrases. If a clients keyfile is damaged or lost, you need all of the previous pass phrases in order to recreate the keyfile. Without the keyfile, you cannot restore the files that were encrypted with the pass phrases. The keyfile must be accessible only to the administrator of the client machine. For a UNIX client, you must ensure the following:

Redirected restores of encrypted files

Redirected restores require special configuration changes to allow a restore. To restore an encrypted backup to another client 1 The server must allow redirected restores, and you (the user) must be authorized to perform such restores. Refer to the NetBackup Administrators Guide for details on redirected restores. Obtain the pass phrase that was used on the other client when the encrypted backup was made. Without that pass phrase, you cannot restore the files.
266 Data at rest encryption security Setting the encryption attribute in policies
Note: If the pass phrase is the same on both clients, skip to step 5. 3 4 To preserve your own (current) keyfile, move or rename it. Use the bpkeyutil command to create a keyfile that matches the other clients. When the bpkeyutil process prompts you for the pass phrase, specify the other clients pass phrase. Restore the files to the other client.
Note: After you restore the encrypted files from the client, rename or delete the keyfile that you created in step 4. Next, you move or rename the original keyfile to its original location or name. If you do not re-establish your keyfile to its original location and name, you may not be able to restore your own encrypted backups.
Setting the encryption attribute in policies

You must set the Encryption attribute in your NetBackup policy.

If the attribute is set, the NetBackup server requests that NetBackup clients in that policy perform encrypted backups. If the attribute is not set, the NetBackup server does not request that NetBackup clients in that policy perform encrypted backups.
You can use the Attributes tab of the policy in the NetBackup Administration Console to set or clear the Encryption attribute for a policy. Refer to the NetBackup Administrators Guide, Volume I for more information on how to configure policies.
Changing client encryption settings from the server

You change the encryption settings for a NetBackup client from the Client Properties dialog on the NetBackup server. To change the client encryption settings from the NetBackup server 1 2 3 Open the NetBackup Administration Console on the server. Expand the Host Properties node and select Clients. In the Clients list, double click the name of the client you want to change. The Client Properties dialog displays.
Data at rest encryption security Configuration for standard encryption
267
In the Properties pane, click Encryption to display the encryption settings for that client.
The settings on this dialog correspond to the options that are described in Managing NetBackup encryption configuration options on page 263. For additional explanation of the settings, click the Help button on the dialog, or refer to the NetBackup Administrator's Guide, Volume I.
Configuration for standard encryption

This section explains how to configure standard NetBackup encryption.
CRYPT_OPTION CRYPT_KIND CRYPT_CIPHER
You can also use the NetBackup Administration Console to configure the options from the server. They are on the Encryption tab in the Client Properties dialog box. Refer to the NetBackup Administrators Guide for details.
Configuring from the server

You can configure most NetBackup clients for encryption by using two commands from the server: bpinst and bpkeyutil. Prerequisites include the following:

The NetBackup client software must be running on the platforms that support NetBackup Encryption (see the NetBackup Release Notes). The NetBackup clients must be running NetBackup 6.0 or later (for standard encryption).

Prerequisites and notes
Install the NetBackup encryption client software in a directory on the server. It is
described in the Installing encryption security on page 256.
The NetBackup configuration on the clients must allow server writes.
268 Data at rest encryption security Configuring from the server


Temporarily change its configuration so writes are allowed Follow the procedure in Configuring NetBackup encryption on clients on page 263. For a Windows server, the full command path is as follows:
install_path\NetBackup\bin\bpinst
You use the bpinst command to install the software.

For a UNIX server, the full command path is as follows:

/usr/openv/netbackup/bin/bpinst
Refer to the bpinst command description in the NetBackup Commands guide for details on the options that are available with the bpinst command. Generally, you specify client names in the bpinst command. However, if you include the -policy_names option, you specify policy names instead. The option affects all clients in the specified policies.

To copy encryption software to NetBackup clients, use the -ENCRYPTION option
on the bpinst command.
To install the encryption client software on client1 and client2, enter the
following command:
bpinst -ENCRYPTION client1 client2
bpinst -ENCRYPTION -policy_names policy1 policy2
For clustered environments:

You can push software to the client is only allowed from the active node. Specify the host names of the individual nodes (not the virtual names) in the list of clients.
Data at rest encryption security Configuring from the server
269
Creating encryption keyfiles on clients

Notes

If the server is in a cluster and is also an encryption client, all nodes in the cluster must have the same keyfile. The bpkeyutil command sets up the cipher-based encryption keyfile and pass phrase on each NetBackup Encryption client.

For a Windows server, the full path to the command is as follows: install_path\NetBackup\bin\bpkeyutil
For a UNIX server, the full path to the command is as follows: /usr/openv/netbackup/bin/bpkeyutil
Creating keyfiles
For each encryption client, run the following command:
bpkeyutil -clients client_name
You are prompted for a new pass phrase to add to that clients keyfile.
To set up several clients to use the same pass phrase, specify a comma-separated
list of client names, as follows:
bpkeyutil -clients client_name1,client_name2,...,client_namen
To create the keyfile, NetBackup uses the pass phrase you specify. NetBackup uses the pass phrase you specify to create the keyfile, as follows:


Previous pass phrases remain available in the file for restores of the backups that were encrypted with those phrases.
270 Data at rest encryption security Configuring from the server
Caution: You must ensure that pass phrases, whether they are new or were in use previously, are secure and retrievable. If a clients keyfile is damaged or lost, you need all of the previous pass phrases in order to recreate the keyfile. Without the keyfile, you cannot restore the files that were encrypted with the pass phrases. The keyfile must only be accessible to the administrator of the client machine. For a UNIX client, you must ensure the following:

Best practices for keyfile restoration

Even when an encrypted backup does not have a keyfile available, you may be able to restore the files.
Manual retention
Manual retention is the most secure method for protecting your keyfile pass
phrases.
When you add a phrase by using the bpkeyutil command, complete manual
retention as follows:
Write the phrase on paper Seal the paper in an envelope Put the envelope into a safe.
If you subsequently need to restore from encrypted backups and you have lost the keyfile, do the following:

Reinstall NetBackup and NetBackup Encryption Use bpkeyutil to create a new keyfile by using the pass phrases from the safe.
Automatic backup
The automatic backup method is less secure, but it ensures that a backup copy of
your keyfile exists.
This method requires that you create a non-encrypted policy to back up the
keyfile. If the keyfile is lost, you can restore it from the non-encrypted backup.
The problem with this method is that a client's key file can be restored on a
different client.
Data at rest encryption security Configuring encryption on clients
271
If you want to prevent the keyfile from being backed up to a client, add the keyfile's path name to the client's exclude list.
Configuring encryption on clients

You can also configure NetBackup Encryption directly on clients as explained in the following topics.
Managing encryption configuration options

Three encryption-related configuration options for standard encryption exist on
a NetBackup client.
Ensure that the options are set to the appropriate values for your client.
denied|DENIED
allowed|ALLOWED
(the default value) Specifies that the client allows either encrypted or unencrypted backups.
required|REQUIRED
CRYPT_KIND = kind
Defines the encryption kind on NetBackup clients. The possible values for kind follow:
NONE

STANDARD
Specifies that you want to use the cipher-based 128-bit encryption or 256-bit encryption. This option is the default value if standard encryption is configured on the client.
LEGACY
Specifies that you want to use the legacy-based encryption, with 40-bit DES or 56-bit DES.
CRYPT_CIPHER = cipher
Defines the cipher type to use. It can be set to any of the following:
AES-128-CFB 128-bit Advanced Encryption Standard

Configuring encryption on clients
BF-CFB DES-EDE-CFB AES-256-CFB
128-bit Blowfish Two Key Triple DES 256-bit Advanced Encryption Standard
The default is AES-128-CFB.
Managing the NetBackup encryption keyfile

Note: The keyfile must be the same on all nodes in a cluster. Use the bpkeyutil command to set up the cipher-based encryption keyfile and pass phrase on the NetBackup Encryption client.

For a Windows client, the full command path is as follows: install_path\NetBackup\bin\bpkeyutil

For a UNIX client, the full command path is as follows: /usr/openv/netbackup/bin/bpkeyutil
You are prompted to add a pass phrase for that client.

NetBackup uses the pass phrase you specify to create the keyfile, as follows:

Previous pass phrases remain available in the keyfile to allow restores of the backups that were encrypted by using those phrases. Caution: You must remember the pass phrases, including the old pass phrases. If a clients keyfile is damaged or lost, you need all of the previous pass phrases in order to recreate the keyfile. Without the keyfile, you cannot restore the files that were encrypted with the pass phrases.
Data at rest encryption security Setting the encryption attribute in policies
273
The keyfile must be accessible only to the administrator of the client machine. For a UNIX client, you must ensure the following:

Setting the encryption attribute in policies

You must set the Encryption attribute on your NetBackup policy.

You can use the Attributes tab of the policy in the NetBackup Administration Console to set or clear the Encryption attribute for a policy. Refer to the NetBackup Administrators Guide, Volume I for more information on how to configure policies.
Changing client encryption settings from the server

You change the encryption settings for a NetBackup client from the Client Properties dialog on the NetBackup server. To change the client encryption settings from the NetBackup server 1 2 3 4 Open the NetBackup Administration Console on the server. Expand the Host Properties node and select Clients. In the Clients list, double click the name of the client you want to change. The Client Properties dialog displays. In the Properties pane, click Encryption to display the encryption settings for that client.
The settings on this dialog correspond to the options that are described in Managing NetBackup encryption configuration options on page 263. For additional explanation of the settings, click the Help button on the dialog, or refer to the NetBackup Administrator's Guide, Volume I.
274 Data at rest encryption security Configuration for legacy encryption
Configuration for legacy encryption
This section explains how to configure legacy NetBackup encryption.

CRYPT_OPTION CRYPT_STRENGTH CRYPT_LIBPATH CRYPT_KEYFILE
You can also use the NetBackup Administration Console to configure the options
from the server. They are on the Encryption tab in the Client Properties dialog
box.
Refer to the NetBackup Administrators Guide for details.
You can set the CRYPT_OPTION and CRYPT_STRENGTH options on the bpinst
-LEGACY_CRYPT command. The equivalent option settings are
-crypt_option, -crypt_strength, respectively.
Configuring legacy encryption from the server

You can configure most NetBackup clients for encryption by using the bpinst command from the server. Prerequisites for this method include the following:

The NetBackup client software must be running on a platform that supports NetBackup encryption. Refer to the NetBackup Release Notes for details on supported platforms. The NetBackup clients must be running NetBackup 6.0 or later (for standard encryption). If a clustered server is a client for NetBackup encryption, ensure that all nodes in the cluster have the same keyfile. For a Windows server, the bin directory is as follows:
install_path\NetBackup\bin
The bpinst command is loaded into the NetBackup bin directory on the server.

For a UNIX server, the bin directory is as follows:

/usr/openv/netbackup/bin
See the bpinst command description in the NetBackup Commands guide for details on the options that are available with the bpinst command. The following sections contain several examples of how to use bpinst.
Data at rest encryption security Configuring legacy encryption from the server
275
Normally, you specify client names in the bpinst command. However, if you include the -policy_names option, you specify policy names instead. The option affects all clients in the specified policies.
When clients have not been previously configured

If the clients have not been previously configured for encryption, ensure that you push the encryption libraries to the clients first with one bpinst command. Then you can configure the encryption pass phrase with separate bpinst commands, as in the following example:
bpinst -LEGACY_CRYPT -update_libraries clientname1
bpinst -LEGACY_CRYPT -passphrase_prompt clientname1
The pass phrase configuration can fail if you specify both arguments on the same command line. You must make the encryption libraries available on the client before you provide the pass phrase. For clustered environments:

You can push the software to the client only from the active node. Specify the host names of the individual nodes (not the virtual names) in the list of clients.
Pushing legacy encryption software to clients

Prerequisites
Install the NetBackup encryption client software in a directory on the server as
described in the Installing encryption security on page 256.
The NetBackup configuration on the clients must allow server writes.


Temporarily change its configuration so writes are allowed
276 Data at rest encryption security Configuring legacy encryption from the server
Follow the procedure in Configuring NetBackup encryption on clients on page 263.
Steps for pushing the legacy encryption software to clients

Use the -update_libraries option on the bpinst command to copy
encryption software from the server to NetBackup clients.
For example, to install the client software on client1 and client2, enter the
following command:
bpinst -LEGACY_CRYPT -update_libraries client1 client2
bpinst -LEGACY_CRYPT -update_libraries -policy_names policy1 policy2
In clustered environments:

You can push the software to the client only from the active node. Specify the host names of the individual nodes (not the virtual names) in the list of clients.
Pushing legacy encryption configuration to clients

You can use the -crypt_option and -crypt_strength options on the bpinst command to set encryption-related configuration on NetBackup clients.

The -crypt_option option specifies whether the client should deny encrypted backups (denied), allow encrypted backups (allowed), or require encrypted backups (required). The -crypt_strength option specifies the DES key length (40 or 56) that the client should use for encrypted backups.
To install the encryption client software and require encrypted backups with a 56-bit DES key, use the following command from the server:
bpinst -LEGACY_CRYPT -crypt_option required -crypt_strength des_56 \
-policy_names policy1 policy2
The example uses a UNIX continuation character (\) because it is long.

To allow either encrypted or non-encrypted backups with a 40-bit DES key, use
the following command:
bpinst -LEGACY_CRYPT -crypt_option allowed -crypt_strength des_40 \

client1 client2
In clustered environments:

You can push the configuration to the client only from the active node.
Data at rest encryption security Configuring legacy encryption from the server
277
Specify the host names of the individual nodes (not the virtual names) in the list of clients.
Pushing legacy encryption pass phrases to clients

To send a pass phrase to a NetBackup client, you can use the bpinst options -passphrase_prompt or -passphrase_stdin. The NetBackup client uses the pass phrase to create or update data in its keyfile. The keyfile contains data that the client uses to generate DES keys to encrypt backups.

If you use the -passphrase_prompt option, you are prompted at your terminal for a zero to 62 character pass phrase. The characters are hidden while you type the pass phrase. You are prompted again to retype the pass phrase to make sure that is the one you intended to enter. If you use the -passphrase_stdin option, you must enter the zero to 62 character pass phrase twice through standard input. Generally, the -passphrase_prompt option is more secure than the -passphrase_stdin option, but -passphrase_stdin is more convenient if you use bpinst in a shell script.
To enter a pass phrase for the client named client1 from a NetBackup server through standard input, you would enter commands like the following:
bpinst -LEGACY_CRYPT -passphrase_stdin client1 <<EOF
This pass phase is not very secure
This pass phase is not very secure
EOF
To enter a pass phrase for the client named client2 from a NetBackup server, you would enter commands like the following:
bpinst -LEGACY_CRYPT -passphrase_prompt client2
Enter new NetBackup pass phrase: ********************
Re-enter new NetBackup pass phrase: ********************
You may enter new pass phrases fairly often. The NetBackup client keeps information about old pass phrases in its keyfile. It can restore the data that was encrypted with DES keys generated from old pass phrases. Caution: You must ensure that pass phrases, whether they are new or were in use previously, are secure and retrievable. If a clients keyfile is damaged or lost, you need all of the previous pass phrases in order to recreate the keyfile. Without the keyfile, you cannot restore the files that were encrypted with the pass phrases. You must decide whether to use the same pass phrase for many clients. Using the same pass phrase is convenient because you can use a single bpinst command to specify a pass phrase for each client. You can also do redirected restores between clients when they use the same pass phrase.
278 Data at rest encryption security Configuring legacy encryption on clients
Note: If you want to prevent redirected restores, you should specify different pass phrases by entering a separate bpinst command for each client. For clustered environments:

You can push software to the client is only allowed from the active node. Specify the host names of the individual nodes (not the virtual names) in the list of clients.
Configuring legacy encryption on clients

You can configure NetBackup encryption directly on the client as explained in the following topics.
Managing legacy encryption configuration options

Five encryption-related configuration options exist on a NetBackup client. Ensure that these options are set to the appropriate values for your client. These are set if you run the bpinst -LEGACY_CRYPT command from the server to the client name.
denied|DENIED
allowed|ALLOWED
(The default value) Specifies that the client allows either encrypted or unencrypted backups.
required|REQUIRED
CRYPT_KIND = kind
Defines the encryption type on NetBackup clients. The possible values for kind follow:
NONE

LEGACY
Specifies the legacy encryption type, either 40-bit DES or 56-bit DES. This option is the default if the legacy encryption type is
Data at rest encryption security Configuring legacy encryption on clients
279
configured on the client, and the standard encryption type is not configured.
STANDARD
Specifies the cipher encryption type, which can be either 128-bit encryption or 256-bit encryption.
CRYPT_STRENGTH = strength
Defines the encryption strength on NetBackup clients. The possible values for strength follow:
des_40|DES_40
(The default value) Specifies 40-bit DES encryption.

des_56|DES_56
Specifies the 56-bit DES encryption.

CRYPT_LIBPATH = directory_path
Defines the directory that contains the encryption libraries on

NetBackup clients.
The default value on UNIX systems is as follows:
/usr/openv/lib/
The default value on Windows systems is as follows:

install_path\NetBackup\bin\
The install_path is the directory where NetBackup is installed and by default is C:\VERITAS.
CRYPT_KEYFILE = file_path
Defines the file that contains the encryption keys on NetBackup clients. The default value on Windows systems is as follows:
install_path\NetBackup\bin\keyfile.dat
The default value on UNIX systems is as follows:

/usr/openv/netbackup/keyfile
Managing legacy encryption keyfiles

Note: The keyfile must be the same on all nodes in a cluster. Each NetBackup client that does encrypted backups and restores needs a keyfile. The keyfile contains data that the client uses to generate DES keys to encrypt backups. You can use the bpkeyfile command on the client to manage the keyfile. Check the bpkeyfile command description in the NetBackup Commands guide for a detailed description. The first thing you need to do is to create a keyfile if it does not already exist. The keyfile exists if you set a passphrase from the bpinst -LEGACY_CRYPT command from the server to this client name. The file name should be the same
280 Data at rest encryption security Configuring legacy encryption on clients
as the file name that you specified with the CRYPT_KEYFILE configuration option.
For Windows clients, the default keyfile name is as follows:

install_path\NetBackup\bin\keyfile.dat
For UNIX clients, the default keyfile name is as follows:

/usr/openv/netbackup/keyfile
NetBackup uses a keyfile pass phrase to generate a DES key, and it uses the DES
key to encrypt a keyfile.
Generally, you use the keyfile pass phrase that is hard-coded into NetBackup
applications. However, for added security you may want to use your own keyfile
pass phrase.
Refer to Additional legacy keyfile security for UNIX clients on page 283 for
more details.
Note: If you do not want to use your own keyfile pass phrase, do not enter a new keyfile pass phrase. Instead, use the standard keyfile pass phrase and enter a new NetBackup pass phrase. You must decide what NetBackup pass phrase to use. The NetBackup pass phrase is used to generate the data that is placed into the keyfile. That data is used to generate DES keys to encrypt backups. To create the default keyfile on a UNIX client that is encrypted with the standard keyfile pass phrase, enter a command such as the following:
bpkeyfile /usr/openv/netbackup/keyfile
Enter new keyfile pass phrase: (standard keyfile pass phrase)
Re-enter new keyfile pass phrase: (standard keyfile pass phrase)
Enter new NetBackup pass phrase: ***********************
Re-enter new NetBackup pass phrase: ***********************
You may enter new NetBackup pass phrases fairly often. Information about old pass phrases is kept in the keyfile. This method lets you restore any data that was encrypted with DES keys generated from old pass phrases. You can use the -change_netbackup_pass_phrase (or -cnpp) option on the bpkeyfile command to enter a new NetBackup pass phrase. Suppose you want to enter a new NetBackup pass phrase on a Windows client. You would enter a command like the following:
bpkeyfile.exe -cnpp install_path\NetBackup\bin\keyfile.dat
Enter old keyfile pass phrase: (standard keyfile pass phrase)
Enter new NetBackup pass phrase: **********
Re-enter new NetBackup pass phrase: **********
Data at rest encryption security Configuring legacy encryption on clients
281
Caution: You must ensure that pass phrases, whether they are new or were in use previously, are secure and retrievable. If a clients keyfile is damaged or lost, you need all of the previous pass phrases in order to recreate the keyfile. Without the keyfile, you cannot restore the files that were encrypted with the pass phrases. The keyfile must only be accessible to the administrator of the client machine. For a UNIX client, you must ensure the following:

You must consider whether to back up your keyfile. For encrypted backups, such a backup has little value, because the keyfile can only be restored if the keyfile is already on the client. Instead, you can set up a NetBackup policy that does non-encrypted backups of the keyfiles of the clients. This policy is useful you require an emergency restore of the keyfile. However, this method also means that a client's keyfile can be restored on a different client. If you want to prevent the keyfile from being backed up, add the keyfile's path name to the client's exclude list.
Redirected restores of legacy encrypted files

If a server has allow redirected restores, you (the user) must be authorized to
perform such restores.
Refer to the NetBackup Administrators Guide for details on redirected restores.
To restore an encrypted backup that was created on another client: 1 Obtain the pass phrase that was used on the other client when the encrypted backup was made. Without that pass phrase, you cannot restore the files. Note: If the pass phrase is the same on both clients, skip to step 5. 2 3 To preserve your own (current) keyfile, move or rename it. Use the bpkeyutil command to create a keyfile that matches the other clients. When the bpkeyutil process prompts you for the pass phrase, specify the other clients pass phrase.
bpkeyfile -change_key_file_pass_phrase key_file_path
The key_file_path is the path for a new keyfile on your client. This keyfile matches the other clients.
282 Data at rest encryption security Setting legacy encryption attribute in policies
After you enter the command, bpkeyfile prompts you for the clients pass
phrase (obtained in step 2).
For more information on the bpkeyfile command, refer to the NetBackup
Commands guide.
4 Restore the files to the other client.
Note: After you restore the encrypted files from the client, rename or delete the keyfile that you created in step 4. Next, you move or rename the original keyfile to its original location or name. If you do not re-establish your keyfile to its original location and name, you may not be able to restore your own encrypted backups.
Setting legacy encryption attribute in policies

You must set the Encryption attribute in your NetBackup policy.

You can use the Attributes tab of the policy in the NetBackup Administration Console to set or clear the Encryption attribute for a policy. Refer to the NetBackup Administrators Guide, Volume I for more information on how to configure policies. You can also use the bpinst command to set or clear the Encryption attribute for NetBackup policies. This method is convenient if you want to set or clear the attribute for several policies. For example, to set the Encryption attribute for policy1 and policy2 from a NetBackup server, enter a command like the following:
bpinst -LEGACY_CRYPT -policy_encrypt 1 -policy_names policy1 policy2
The 1 parameter sets the encryption attribute (0 would clear it).
Changing client legacy encryption settings from the server

You can change the encryption settings for a NetBackup client from the Client Properties dialog on the NetBackup server.
Data at rest encryption security Additional legacy keyfile security for UNIX clients
283
To change the client encryption settings from the NetBackup server: 1 2 3 4 Open the NetBackup Administration Console on the server. Expand the Host Properties node and select Clients. In the Clients list, double click the name of the client you want to change. The Client Properties dialog displays. In the Properties pane, click Encryption to display the encryption settings for that client.
The settings on this dialog correspond to the options described in Managing

legacy encryption configuration options on page 278.
For additional explanation of the settings, click the Help button on the dialog, or
refer to the NetBackup Administrator's Guide, Volume I.
Additional legacy keyfile security for UNIX clients

This section applies only to UNIX NetBackup clients. The additional security is not available for Windows clients. Note: Symantec does not recommend using the additional keyfile security feature in a cluster. The keyfile for an encryption client is encrypted using a DES key that is generated from a keyfile pass phrase. By default, the keyfile is encrypted using a DES key that is generated from the standard pass phrase that is hard-coded into NetBackup. Using the standard keyfile pass phrase lets you perform automated encrypted backups and restores the same way you perform non-encrypted backups and restores. This method has potential problems, however, if an unauthorized person gains access to your clients keyfile. That person may be able to figure out what encryption keys you use for backups or use the keyfile to restore your clients encrypted backups. For this reason, you must ensure that only the administrator of the client has access to the keyfile. For extra protection, you can use your own keyfile pass phrase to generate the DES key to encrypt the keyfile. An unauthorized person may still gain access to this keyfile, but the restore is more difficult. If you use your own keyfile pass phrase, backups and restores are no longer as automated as before. Following is a description of what happens on a UNIX NetBackup client if you have used your own keyfile pass phrase.

Additional legacy keyfile security for UNIX clients
To start a backup or restore on a client, the NetBackup server connects to the

bpcd daemon on the client and makes a request.
Normally, bpcd is configured in the /etc/inetd.conf file on the client and is
initiated through the inetd daemon.
To perform an encrypted backup or restore, bpcd needs to decrypt and read the
keyfile.
If the standard keyfile pass phrase is used, bpcd can decrypt the keyfile
automatically and the normal inetd method can be used to initiate bpcd.
If you use your own keyfile pass phrase, bpcd can no longer decrypt the keyfile
automatically and the inetd method cannot be used. You must initiate bpcd as
a stand-alone program, as described in the following section.
Note: In a clustered environment, if you change the keyfile on one node, you must make the same change in the keyfile on all nodes.
Running bpcd as a stand-alone program

1 Edit the /etc/inetd.conf file to remove or comment out the bpcd entry. The bpcd entry looks something like the following:
bpcd stream tcp nowait root /usr/openv/netbackup/bin/bpcd bpcd
Force inetd to reread its configuration file. The method to force inetd to reread its configuration file varies from platform to platform. The easiest method is to reboot the machine. Use the -change_key_file_pass_phrase (or -ckfpp) option on the bpkeyfile command to change the keyfile pass phrase, as in the following example:
bpkeyfile -ckfpp /usr/openv/netbackup/keyfile
Enter old keyfile pass phrase: (standard keyfile pass phrase)
Enter new keyfile pass phrase: (standard keyfile pass phrase)
******
Re-enter new keyfile pass phrase: (standard keyfile pass
phrase) ******
If you type a carriage return at the prompt, NetBackup uses the standard keyfile pass phrase. 4 Initiate bpcd as a stand-alone program by entering the bpcd command with the -keyfile option. Enter the new keyfile pass phrase when prompted.
bpcd -keyfile
Please enter keyfile pass phrase: ******
bpcd now runs in the background, and waits for requests from the
NetBackup server.
Data at rest encryption security Option 2 - Media server encryption
285
You can change the keyfile pass phrase at any time with the bpkeyfile command and the -ckfpp option. The new keyfile pass phrase does not take effect until the next time you start bpcd. You can also change the NetBackup pass phrase that is used to generate the DES keys to encrypt backups. Change this phrase at any time with the bpkeyfile command and the -cnpp option. Note, however, that the new NetBackup pass phrase does not take effect until you kill the current bpcd process and restart bpcd.
Terminating bpcd
To terminate bpcd on UNIX clients, use the ps command to find its process
ID and issue the kill command for that process ID. Then use ps to verify
that bpcd has been terminated.
For most UNIX clients, you can use the -ef argument on the ps command,
as shown in the following example:
# ps -ef | grep bpcd

root 148 1 0 00:18:30 ? 0:00 bpcd
# kill 148
# ps -ef | grep bpcd
Option 2 - Media server encryption

NetBackup media server encryption is ideally suited for:

Media servers - that can handle the burden for compression / encryption NetBackup administrators - that want centralized and coarse key management granularity Situations where tight NetBackup operational integration is not needed Each device
Media server encryption administration

Note: The future plans are to include product pointers to the vendor web site for Vormetric. This information would include the Vormetric web site for version numbers, supported operating systems, and other necessary information. There would also be a pointer to the separate media kit and license information relating to the Vormetric product.
286 Data at rest encryption security Option 3 - Third party encryption appliances and hardware devices
Option 3 - Third party encryption appliances and hardware devices

Note: Future information will be added that relates to using HCL hardware encryption devices with NetBackup
Index
Symbols
172, 175, 213, 267
Numerics
40-bit DES key
library 253, 255
56-bit DES key
library 255
A
Access Control
nbac_cron.exe 218
access control
nbac_cron utility 218
user groups
Administrator 223
configuration 224
Default User 224
description 222
Operator 223
renaming user groups 226
Security Administrator 224
Vault Operator 224
Administrator Access Control user group 223
ALLOWED (encryption option) 263, 271, 278
alternate client restore (see redirected restore)
attribute for encryption 252, 266, 273, 282
authentication
port 217
authorization port 217
pushing software to clients (standard) 261, 268

bpkeyfile command
change_netbackup_pass_phrase option 280
changing key file pass phrase 284
introduction (standard) 253, 255
managing the key file (legacy) 279
bpkeyutil command
adding pass phrases 264, 272
creating the key file 262, 269
introduction 253
managing the key file 264, 272
redirected restore 266, 281
standard restore introduction 254
C
checksum of DES key
explanation, legacy encryption 254
explanation, legacy restore 255
explanation, standard encryption 253
explanation, standard restore 254
class
see policy
client_libraries option, see update_libraries option
clustered environments
additional key file security (legacy) 284
managing the key file (legacy) 279
managing the key file (standard) 264, 272
pushing configuration (legacy) 276
pushing software (legacy) 276
pushing software (standard) 261, 268, 278
cnpp option 280
configuration
and clustering (legacy) 274
and clustering (standard) 261, 269
options (legacy) 278
pushing to clients (legacy) 276
configuring
clients for encryption, from client (legacy) 278
clients for encryption, from client
(standard) 263, 271
clients for encryption, from server (legacy) 276
B
bpcd 254, 255
running 284
terminating 285
bpinst command 253, 255
for setting encryption attribute (legacy) 282
pushing configuration to clients (legacy) 276
pushing software to clients (legacy) 276
288
clients for encryption, from server

(standard) 260, 267
copying
encryption software to clients (legacy) 276
encryption software to clients (standard) 261,
268
CRYPT option 282
CRYPT_CIPHER option 264, 271
CRYPT_KEYFILE option 253, 255, 279, 280
CRYPT_KIND option 264, 271, 278
CRYPT_LIBPATH option 279
CRYPT_OPTION 252, 263, 271, 276, 278
CRYPT_STRENGTH option 255, 276, 279
standard
prerequisites for restoring 254
tar header 254
strength, defining (legacy) 279
tar header
legacy 254
standard 253
what is and isnt encrypted (legacy) 254
what is and isnt encrypted (standard) 253
Enterprise Media Manager server 170, 192
inetd.conf 284
installation
copying software to clients (legacy) 276
copying software to clients (standard) 261, 268
local on a client 258
on server for push to client 256
pushing configuration to clients (legacy) 276
pushing pass phrases to clients (legacy) 277
D
decryption
of key file (legacy) 284
overview (legacy) 255
overview (standard) 254
Default User Access Control user group 224
DENIED (encryption option) 263, 271, 278
DES
key checksum 254, 255
key checksum for standard encryption 253
K
key file 253, 254, 255
backing up (legacy) 281
bpkeyutil command 264, 272
creating (legacy) 279
creating (standard) 262, 269
defining (legacy) 279
encrypting (legacy) 279
encrypting with admins pass phrase
(legacy) 283
encrypting with admins pass phrase
(standard) 265, 272
explanation (legacy) 277
for redirected restore (standard) 266, 281
in a cluster (legacy) 279, 283, 284
in a cluster (standard) 264, 272
legacy 253
managing (standard) 264, 272
pass phrase (legacy) 284
E
EMM server 170, 192
encrypted backup, restoring (legacy) 281
encrypted backup, restoring (standard) 265
encryption
allow, deny, require 263, 271, 278
attribute, setting 266, 273
configuration options (legacy) 278
configuring from client (legacy) 278
configuring from client (standard) 263, 271
file containing keys for (legacy) 279
kind, defining (legacy) 278
kind, defining (standard) 264, 271
legacy
prerequisites 253
prerequisites for restoring 255
tar header 255
libraries, defining (legacy) 279
of key file (legacy) 283
policy attribute for, how to set 252, 266, 273,
282
L
libraries
defining for encryption (legacy) 279
M
managing key file (legacy) 279
289
managing key file (standard) 264, 272

Media 206
software to clients (standard) 261, 268
N
nbac_cron.exe 218
NBU_Admin Access Control user group 223
NBU_Operator Access Control user group 223
NBU_Security Admin Access Control user
group 224
NBU_User Access Control user group 224
NetBackup Access Control (NBAC)
nbac_cron.exe 218
user groups 222
Administrator 223
configuration 224
Default User 224
Operator 223
Vault Operator 224
R
redirected restore
of other clients backup (legacy) 281
of other clients backup (standard) 265
preventing (legacy) 278
REQUIRED (encryption option) 263, 271, 278
restore
S
Security Administrator Access Control user
group 224
setting encryption attribute 266, 273
T
tar header for legacy encryption 254, 255
tar header for standard encryption 253, 254
O
Operator Access Control user group 223
overview
of legacy encryption backup 253
of legacy restore 255
of standard encryption backup 252
of standard restore 254
U
user groups
Administrator 223
Default User 224
description 222
Operator 223
Vault Operator 224
P
pass phrase
for encrypting key file (legacy) 280, 283
for redirected restore (legacy) 281
for redirected restore (standard) 265
pushing to clients (legacy) 277
passphrase_prompt option 277
passphrase_stdin option 277
ports
authentication 217
authorization 217
ps command 285
pushing
configuration to clients (legacy) 276
pass phrases to clients (legacy) 277
software to clients (legacy) 276
Vault Operator User Access Control user group 224

Vault_Operator Access Control user group 224
VxSS authentication port 217
VxSS authorization port 217

290226

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

290226

Caricato da

Copyright:

Formati disponibili

Veritas NetBackup

Security and Encryption Guide

UNIX, Windows, Linux

Veritas NetBackup Security and Encryption Guide

Licensing and registration

Increasing NetBackup security

Security deployment models

and media servers ................................................................................ 54

Client outgoing ports list ..................................................................................120

Access control security

Access management components ................................................................... 160

Drive permissions ......................................................................................234

Data at rest encryption security

Installing encryption security ......................................................................... 256

Media server encryption administration ...............................................285

Increasing NetBackup security

NetBackup security implementation levels on page 14

14 Increasing NetBackup security NetBackup security implementation levels

NetBackup security implementation levels

The NetBackup security happens at the following levels:

Increasing NetBackup security NetBackup security implementation levels

16 Increasing NetBackup security NetBackup security implementation levels

Data center level

Increasing NetBackup security NetBackup security implementation levels

NetBackup security parts

Master server security

Media server security

18 Increasing NetBackup security NetBackup security implementation levels

NetBackup access control (NBAC)

Increasing NetBackup security NetBackup security implementation levels

20 Increasing NetBackup security NetBackup security implementation levels

Increasing NetBackup security NetBackup security implementation levels

Data over the wire security

22 Increasing NetBackup security NetBackup security implementation levels

Demilitarized zone (DMZ)

Increasing NetBackup security NetBackup security implementation levels

Example firewalls and DMZ

Combined world, enterprise, and data center levels

24 Increasing NetBackup security

Combined world, enterprise, and data level

Increasing NetBackup security NetBackup security implementation types

NetBackup security implementation types

Security implementation type Characteristics

Security deployment models

Standard NetBackup security on page 28

MSEO (Media Server Encryption Option) security on page 29

Client side encryption security on page 30

NBAC on master, media server, and GUI security on page 31

26 Increasing NetBackup security

Security implementation types Complexity Security deployment models

Security implementation type Characteristics

All NetBackup security on page 33

Operating system security

Increasing NetBackup security NetBackup security vulnerabilities

NetBackup security vulnerabilities

28 Increasing NetBackup security Standard NetBackup security

Standard NetBackup security

Increasing NetBackup security MSEO (Media Server Encryption Option) security

MSEO (Media Server Encryption Option) security

30 Increasing NetBackup security Client side encryption security

Client side encryption security

NBAC on master, media server, and GUI security

32 Increasing NetBackup security NBAC complete security