VXSS Yello Page

Symantec Product
Authentication and
Authorization
Securely deploy Symantec products using the
appropriate deployment configuration for your
enterprise environment
The roles of Symantec Product Authentication

and Authorization Service in your enterprise
Overview of the Symantec Product Authentication
and Authorization Service
Guidelines and best practices for deploying
Symantec products with Authentication and
Authorization Service
Technical information illustrating multiple product
deployment environments using tested UNIX, Linux,
and Windows use cases
Verify Symantec Product Authentication
and Authorization setup
in your enterprise
Symantec Product Authentication and Authorization
The software described in this book is furnished under a license agreement and may be used
only in accordance with the terms of the agreement.
Documentation version 1.0
Legal Notice
Copyright © 2007 Symantec Corporation.
All rights reserved.
Symantec, the Symantec Logo, and Symantec Yellow Book 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.
Microsoft, Windows, Active Directory, Excel, JScript, Outlook, PowerPoint, SharePoint, and
Windows server are trademarks or registered trademarks of Microsoft Corporation.
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.
THE 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 NON-INFRINGEMENT,
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
as defined in FAR 12.212 and subject to restricted rights as defined in FAR Section 52.227-19
"Commercial Computer Software - Restricted Rights" and DFARS 227.7202, "Rights in
Commercial Computer Software or Commercial Computer Software Documentation", as
applicable, and any successor regulations. Any use, modification, reproduction release,
performance, display or disclosure of the Licensed Software and Documentation by the U.S.
Government shall be solely in accordance with the terms of this Agreement.
Symantec Corporation
20330 Stevens Creek Blvd.
Cupertino, CA 95014
http://www.symantec.com
Acknowledgments
Symantec thanks the following people for their contribution to the Symantec Yellow Book™:
Principal Authors
Aloysius Lau
Hoang Nguyen
The principal authors and Symantec would like to thank the following contributors:
Bruce Naegel
Don Ross
John Richardson
Kurt Papke
Jose Iglesias
William Browning
Tom Stephens
Kyle Gleed
Don Brinkley
Aaron Christenson
Trung Nguyen
Chris Leffel
Rangan Doreswamy
Larry Vaught
John Belz
David Hartman
Sreekanth Vadapalli
Barry McGuckin
Eric Delaney
Tao Ni
Xiao Yin
Fan Yang
Hai Sheng Kang
Robert Robinson
Gaurav Khanna
Daniel Sronchaiprasith
Pawan Sood
Kenneth Howe
Eddie Chao
Linda Greene
Stephen England
Kathryn Cheng
Fran Heddings
Tom Dewan
Mette Wadleigh
Patrick Carri
Contents
Chapter 1 Introduction
About this Yellow Book .................................................................. 13
Difference between product guides and this Yellow Book ............... 14
How this Yellow Book helps users .............................................. 14
Who should use this Yellow Book .................................................... 14
Scope of this document ................................................................. 15
Symantec products covered in this Yellow Book edition ................. 16
About future editions of this Yellow Book .................................... 17
Topics to be covered in future editions ........................................ 18
About acronyms and definitions ...................................................... 18
About authentication and authorization ........................................... 22
Customer benefits ........................................................................ 23
Chapter 2 Overview of the Symantec Product Authentication

Service
Authentication service overview ..................................................... 27
Authentication hierarchy ............................................................... 28
Authentication principal ......................................................... 28
Authentication components .......................................................... 29
Root broker ........................................................................... 29
Authentication broker ............................................................. 30
Authentication plug-ins and mechanisms ................................... 30
Authentication entities ............................................................ 32
Authentication user interface ................................................... 32
Authentication broker communications port ............................... 32
How the authentication process works ............................................. 33
Acquiring a product credential ................................................. 34
Authentication expiry ................................................................... 36
Chapter 3 Overview of the Symantec Product Authorization

Service
Authorization service overview ....................................................... 37
Authorization service components .................................................. 38
Authorization service .............................................................. 39
6 Contents
Authorization client ............................................................... 39

Access control information data repository ................................. 39
Master authorization service .................................................... 40
Local authorization service ...................................................... 40
Resource management application ............................................ 40
Authorization group or namespace ............................................ 41
Authorization user interface .................................................... 41
Authorization service communication port ................................. 41
Access control policy ..................................................................... 41
Access control lists ....................................................................... 42
How the authorization process works ............................................... 42
Chapter 4 How authentication and authorization are used

across Symantec products
Introduction ................................................................................ 43
Implementing one authentication hierarchy in your enterprise ............. 44
Using the authentication service for secure communication ................ 44
Upgrading authentication service in your enterprise ..................... 45
Assimilating authentication service into your enterprise ..................... 46
NetBackup ............................................................................ 46
NetBackup Operations Manager ................................................ 46
Veritas Storage Foundation ...................................................... 47
CommandCentral ................................................................... 47
Symantec License Inventory Manager ........................................ 48
Using the authorization service for access control .............................. 48
NetBackup ............................................................................ 49
Chapter 5 Deployment guidelines and best practices

Multiproduct deployment approach ................................................. 51
Application server .................................................................. 54
Management server ................................................................ 54
Management agent and client ................................................... 55
Broker architecture determination ................................................... 55
Root and authentication broker placement .................................. 59
Isolated root broker ................................................................ 61
Multiple root brokers .............................................................. 62
Brokers in different time zones ................................................. 63
Broker availability .................................................................. 63
Root broker consolidation ........................................................ 64
Planning for authentication and authorization in your enterprise
environment ......................................................................... 66
Authentication and authorization administration .............................. 69
Contents 7
Authentication administrator responsibilities .............................. 69

Authorization administrator responsibilities ............................... 70
Platform-specific considerations ............................................... 71
Authentication and authorization service installation ................... 72
Authentication and authorization service upgrade ....................... 75
Backup and recovery of authentication and authorization .................... 77
Authentication data ................................................................ 78
Authorization data ................................................................. 79
Empirical use cases ....................................................................... 79
UNIX/Linux use cases ............................................................. 79
Windows use cases ................................................................. 80
How to use the use cases .......................................................... 80
Product troubleshooting tips .......................................................... 80
Chapter 6 Symantec solution: UNIX/Linux use cases

Deploy Symantec products on UNIX/Linux ....................................... 83
Determine broker infrastructure ............................................... 85
NetBackup use case ...................................................................... 87
Deployment platforms and operating systems ............................. 89
Application server .................................................................. 89
NetBackup management servers ............................................... 89
Add a media server to a master server ........................................ 97
NetBackup management client ................................................. 97
Enable access control on a NetBackup master server ..................... 99
Enable access control on a NetBackup media server .................... 108
Enable access control on a NetBackup client .............................. 117
Environment with existing authentication hierarchy ................... 123
Upgrade NetBackup and shared components ............................. 123
CommandCentral Storage and Service use case ................................ 124
Deployment platforms and operating systems ............................ 125
Application server ................................................................ 125
CommandCentral management server ...................................... 125
CommandCentral Management agents ..................................... 132
CommandCentral-related upgrade ........................................... 135
Symantec License Inventory Manager use case ................................. 136
SLIM management server ...................................................... 138
SLIM management agents ...................................................... 140
SLIM-related upgrade ............................................................ 142
8 Contents
Storage Foundation use case ......................................................... 143

Storage Foundation-related upgrade ......................................... 147
Chapter 7 Symantec solution: Windows use cases

Deploy Symantec products on Windows .......................................... 149
Determine a broker infrastructure ................................................. 151
Symantec License Inventory Manager use case ................................. 153
Deploy the Symantec License Inventory Manager management
server on Windows ......................................................... 155
Deploy SLIM management agents on Windows ........................... 156
Symantec License Inventory Manager-related upgrade ................ 158
NetBackup use case ..................................................................... 158
NetBackup management servers .............................................. 161
Adding a media server to the master server ............................... 168
Installing and upgrading the NetBackup management client on
Windows ....................................................................... 168
Enabling access control on a NetBackup master server ................ 170
Enabling access control on a NetBackup media server .................. 177
Enable access control on a NetBackup client .............................. 185
Environment with an existing authentication hierarchy ............... 190
Upgrading NetBackup and shared components ........................... 190
NetBackup Operations Manager use case ........................................ 191
NetBackup Operations Manager management server ................... 192
NOM-related upgrade ............................................................ 197
CommandCentral Storage and Service use case ................................ 197
CommandCentral Management servers ..................................... 198
Installing a CommandCentral management agent ....................... 203
CommandCentral-related upgrade ........................................... 204
Storage Foundation use case ......................................................... 205
Contents 9

Storage Foundation-related upgrade ......................................... 208
Appendix A Storage Foundation common procedures

Enabling a VCS cluster with authentication service ........................... 211
Setting up a VCS cluster with authentication service on
UNIX/Linux ................................................................... 212
Configuring a VCS cluster to use authentication service ............... 213
Using Storage Foundation Management Server to manage VCS
clusters ......................................................................... 213
Setting up a VCS cluster with authentication service on Windows
.................................................................................... 215
Re-establishing the authentication service for a node in a VCS
cluster ................................................................................ 216
Setting up a Storage Foundation Management Server with
authentication service ........................................................... 220
Using SFMS Web-based interface to administer managed
hosts ............................................................................ 221
Common Veritas Volume Manager and Veritas File System
procedures .......................................................................... 222
Appendix B Infrastructure Core Services common procedures

About Infrastructure Core Services ................................................ 225
Private Branch Exchange ....................................................... 226
About Symantec Product Authentication Service ........................ 228
About Symantec Product Authorization Service ......................... 233
Upgrading authorization ........................................................ 235
Verify authentication setup .......................................................... 235
Verify authorization setup ............................................................ 237
Add a new authentication broker ................................................... 238
Backup and restore authentication data .......................................... 239
Backup and restore authorization data ........................................... 241
Appendix C NetBackup common procedures

NetBackup access control parameters ............................................. 243
Verify NetBackup access control setup on the master server ............... 246
About shared Veritas products and processes ............................. 246
Verify NetBackup authorization database .................................. 251
Verify NetBackup access control setup on media servers .................... 254
10 Contents
Shared Veritas products and processes ..................................... 254

Media Server valid credential verification ................................. 255
Media servers accessible to the authorization database ................ 256
Verify NetBackup access control setup on clients .............................. 258
Shared Veritas product .......................................................... 258
Client has valid credentials ..................................................... 258
Authentication client libraries ................................................ 259
Client authentication domains ................................................ 260
Using a remote administrative client to manage the master
server ................................................................................. 261
Replacing the root broker on the NetBackup master server ................. 262
NetBackup storage units .............................................................. 267
NetBackup policies ..................................................................... 268
Successful NetBackup backup and restore ....................................... 269
NetBackup and authorization ....................................................... 270
NetBackup tape device drivers ....................................................... 273
NetBackup Java Windows administration console ............................. 274
NetBackup access control troubleshooting tips and messages .............. 275
Turn off NetBackup access control ........................................... 275
Unable to load libraries .......................................................... 276
Optional VxSS libraries not initialized ...................................... 276
Library Initialization failed. Access denied (188) (MM status
188) ............................................................................. 276
Unable to connect to authorization server ................................. 277
Appendix D CommandCentral Storage/Service common

procedures
Verifying the CommandCentral Storage server setup ......................... 279
Verifying the CommandCentral Service server setup ......................... 282
Verifying the CommandCentral agents setup ................................... 284
Add and modify access by user accounts ......................................... 285
Replacing the root broker on the CommandCentral server .................. 285
Troubleshooting tips ................................................................... 293
Appendix E Symantec License Inventory Manager common

procedures
Verifying the SLIM server setup .................................................... 295
Verification procedures for Windows and UNIX .......................... 296
Verifying the SLIM agent setup ..................................................... 297
Replacing the root broker on the SLIM server ................................... 300
Demoting a root broker .......................................................... 301
SLIM troubleshooting tips ............................................................ 306
Contents 11
Log files .............................................................................. 306

Product directory structure .................................................... 307
Java runtime environment debugging ....................................... 307
Troubleshooting steps for Sybase ASA ...................................... 307
Troubleshooting steps for Tomcat (VRTSweb) ............................ 308
Set the debugging level of the Tomcat server ............................. 309
Debug the access point .......................................................... 309
Debug the push installation .................................................... 309
Troubleshooting steps for Service Management Framework ......... 310
Error: Failed to get database connection .................................... 311
Error: Authentication manager was not initialized ...................... 311
Error: Agent not running ....................................................... 311
Error: Access point fails to start ............................................... 311
Error: Access point fails connect to server ................................. 311
Error: Retries Exceeded. Could not connect to
HOST_NAME:RootSMF .................................................... 311
Error: SLIM Web Console does not display on VRTSweb
console ......................................................................... 312
Embedded access point is down ............................................... 312
Agent-server communication failure ........................................ 312
Server time-out during a force poll queue .................................. 313
Index
12 Contents
Chapter 1
Introduction
This chapter includes the following topics:
■ About this Yellow Book
■ Who should use this Yellow Book
■ Scope of this document
■ About acronyms and definitions
■ About authentication and authorization
■ Customer benefits
About this Yellow Book

You can use this book to learn about the Symantec Product Authentication Service
(authentication) and the Symantec Product Authorization Service (authorization)
and how to integrate them with multiple Symantec software products. This book
describes general security concepts, public key infrastructure (PKI) security
concepts, the Symantec approach to implementing authentication and
authorization, and how to implement these solutions in your environment.
This book contains the following topics:
■ Overview of the Symantec Product Authentication Service and Authorization
Service
■ Integration of the authentication service and authorization service across
Symantec products
■ Deployment guidelines and best practices
■ Technical information regarding multiple Symantec product environments,
illustrated by Linux, UNIX, and Windows use cases
14 Introduction
Who should use this Yellow Book
Difference between product guides and this Yellow Book

Every Symantec product includes user guides that describe the procedures that
integrate the product with the authentication and authorization services. However,
the user guides do not contain information on how those products behave when
they are deployed with other Symantec products.
In a multiple product environment, authentication and authorization services are
shared among many Symantec products. Each product may have a different
requirement for use with authentication and authorization. This Yellow Book
illustrates, with tested and certified use cases, approaches for deploying multiple
Symantec products along with authentication and authorization. These approaches
enable you to implement a variety of product configurations, across multiple
operating systems, in a single, secure environment.
Note: This Yellow Book is not a replacement for product documentation. Refer to
the appropriate installation, administration, and user guides for detailed
information about your Symantec product.
How this Yellow Book helps users

This book provides deployment guidelines, best practices, and use cases that can
help you plan and implement authentication and authorization across Symantec
products. You can choose a deployment configuration suitable for your
environment.
You can begin by deploying a single Symantec product with authentication and
authorization (if used by the product) to establish the infrastructure for your
environment. You can then sequentially add other Symantec products with
authentication and authorization by following the use cases.
Who should use this Yellow Book

There are three primary groups who can benefit by reading this Yellow Book. At
an enterprise level, the first group includes chief information officers (CIOs), chief
security officers, and security architects. The second group includes security
administrators and application administrators. The third group includes system
programmers.
Refer to Table 1-1 to learn about which chapters of this book pertain to you, based
on your job function.
Introduction 15
Scope of this document
Table 1-1 Applicable sections to read
Role What to read
Chief Information Individuals who are responsible for the security infrastructure within an enterprise and
Officers the deployment of authentication and authorization services should read the first five
chapters of this book.
Security Officers
In Chapter 1, the Customer benefits section describes the value that authentication and
Security Architects
authorization add to the security of your organization.
Chapter 2 provides an overview of authentication.
Chapter 3 provides an overview of authorization.
Chapter 4 discusses the integration approach that is used by Symantec products that
integrate with authentication and authorization.
Chapter 5 defines the deployment guidelines and best practices that are suggested by
Symantec Corporation when deploying multiple products within an enterprise with
authentication and authorization enabled.
Security Security administrators and Symantec application administrators are typically responsible
administrators for the deployment of Symantec products in their enterprise.
Application Chapter 3 and Chapter 4 provide information to understand the integration of authentication
administrators and authorization across Symantec products.
Chapter 5 describes approaches that give security and application administrators an

understanding of how to plan and deploy Symantec products in their enterprise
environments.
Chapter 6 provides UNIX and Linux user cases.
Chapter 7 provides Windows use cases.
Refer to the appendixes for common verification procedures that can help you to verify
your environment.
System programmers System programmers who are responsible for process automation should refer to the
appropriate use case chapters and appendixes for specific information on how to implement
authentication and authorization for the Symantec products that are deployed in their
environments. The appendixes contain common verification procedures for implementing
particular Symantec products.

As Symantec becomes familiar with the deployment complexity and architectural
demands on Symantec Product Authentication and Authorization Services within
an enterprise, we can share the guidelines and best practices that have been proven
and certified in the Symantec product testing lab. This Yellow Book disseminates
16 Introduction
this testing information to our customers so that they can use our best deployment
scenarios in their own enterprises by following the documented procedures.
Figure 1-1 lists the Symantec products that integrate with authentication and
authorization. As new Symantec products complete their integration with
authentication and authorization services, they will be illustrated in a future
edition of this Yellow Book.
Figure 1-1 Products that use one or more Common Core Services
Symantec products covered in this Yellow Book edition

Each edition of this Yellow Book applies to the Symantec products that are certified
to successfully integrate with Symantec Product Authentication and Authorization
Services.
In this Yellow Book edition, management servers (such as NetBackup Master/Media
and CommandCentral) and authentication and authorization are configured as
standalone applications without clustering (high availability) functionality. The
high availability (HA) capability of these applications will be illustrated in a future
edition. Veritas Cluster Server is illustrated in this edition.
Table 1-2 lists the products documented in this edition.
Introduction 17
Table 1-2 Symantec products addressed in this edition
Common core services Management server Application server Management agent/client
Authentication NBU SFCFS CC Storage & CC Service
CC Storage & CC Service SF Oracle RAC SLIM
SLIM SFWHA NBU
NOM VCS
Authorization NBU
See “About acronyms and definitions” on page 18.
About future editions of this Yellow Book

Future editions of this Yellow Book will contain information on additional
Symantec products. The high availability functionality in management servers
(such as NetBackup and Veritas Application Director), and its integration with
high availability authentication and authorization services, will be added. The
failover capability of these management servers are configured by using Veritas
Cluster Server.
Table 1-3 lists products and product versions that are scheduled to be certified
to successfully implement authentication and authorization services.
Table 1-3 Symantec products to be addressed in future editions
Common core services Management server Application server Management agent/client
Authentication NBU (6.5, 6.0MP5, SFCFS CC Storage & CC Service

5.1MP6, & 5.0MP7)
SF Oracle RAC VAD
CC Storage
SFWHA NBU
CMC
VCS
PureDisk
VAD
SFMS
VBR
Authorization NBU (6.5, 6.0MP5, CC Storage

5.1MP6, & 5.0MP7)
CC Storage
See “About acronyms and definitions” on page 18.

18 Introduction
About acronyms and definitions
Topics to be covered in future editions

The following topics will be covered incrementally in future Yellow Book editions:
■ Quantifying root broker and authentication broker performance
■ Configuring with a firewall (authentication, authorization, and PBX ports)
■ Disaster recovery involving authentication and authorization
■ Using authentication and authorization with Veritas Volume Replicator
■ Integrating authentication and authorization into a VMware environment
■ Configuring authentication and authorization across Solaris zones

Table 1-4 lists acronyms that are used in this Yellow Book and their definitions.
Table 1-4 Acronym list
Acronym Definition
AT Symantec Product Authentication Service (also referred to as "authentication service")
AZ Symantec Product Authorization Service (also referred to as "authorization service")
CSF Common Service Framework (the distribution name for these products is ICS)
DSU Disk Storage Unit
FQHN Fully Qualified Host Name (synonymous with FQDN—Fully Qualified Domain Name); for example,
jupiter.universe.com
GSSAPI Generic Security Service Application Program Interface
ICS Infrastructure Core Services (distribution name for AT, AZ, PBX, and SMF)
LDAP Lightweight Directory Access Protocol
MP Maintenance Pack (a Veritas product patch release)
NBAC NetBackup Access Control (VxSS integration with NBU)
NBU NetBackup - NBU and NetBackup are synonymous in this document
NOM NetBackup Operations Manager
PAM Pluggable Authentication Modules

Introduction 19
Table 1-4 Acronym list (continued)
Acronym Definition
PBX Veritas Private Branch Exchange version 1.2
Symantec Private Branch Exchange version 1.3
PDR The root private domain repository stores information about all registered authentication brokers
(used only by the root broker)
PKI Public Key Infrastructure
RDBMS Relational Database Management System
SAN Storage Area Network
SF UNIX/Linux Veritas Storage Foundation products, including VxVM, VxFS, and VVR
SFCFS Veritas Storage Foundation Cluster File System
SFDB2 Veritas Storage Foundation for DB2
SFMS Veritas Storage Foundation Management Server
SF Oracle Veritas Storage Foundation for Oracle
SF Oracle RAC Veritas Storage Foundation for Oracle RAC (Real Application Cluster)
SFW Windows Storage Foundation products, including VxVM and VVR
SFWHA Veritas Storage Foundation High Availability on Windows
SLIM Symantec License Inventory Manager
SMF Service Management Framework (SLIM is the consumer)
SSL Secure Socket Layer protocol (each encrypted transaction generates a session key which is 128
bits)
SSO Shared Storage Option (in the NetBackup context)
Single Sign-On (in the authentication context)
VAD Veritas Application Director
VBR Veritas Backup Reporter
VCS Veritas Cluster Server
VPAS Veritas Process Automation Server
VVR Veritas Volume Replicator

20 Introduction
Table 1-4 Acronym list (continued)
Acronym Definition
VxFS Veritas File System
VxSS Veritas Security Services (synonymous with authentication service plus authorization service
VxVM Veritas Volume Manager
Table 1-5 is an alphabetical list of each special term used in this Yellow Book
followed by its definition.
Table 1-5 Terms and definitions
Term Definition
application client A program that accesses a Symantec service or function that is provided by another
program, called a Symantec application service.
application server A Symantec application that is deployed on a computer that serves a specific purpose
for an enterprise. Synonymous with application service.
See “Application server” on page 54.
application service A program that is contacted by, and provides services to, a Symantec application
client. Synonymous with application server.
authentication mechanism The method by which authentication is conducted for the principals within a specific
namespace that is defined by a domain type.
See “Authentication plug-ins and mechanisms” on page 30.
authentication plug-in A component that is used by the authentication broker to validate the identities
within a particular domain.
authentication principal An entity that has the ability to authenticate to Symantec Product Authentication
Service with a unique identity.
See “Authentication principal” on page 28.
backup Refers to the process of copying and saving files, directories, raw partitions, or file
systems to secondary storage such as tapes or disks.
broker An agent whose function is to validate identities by using the appropriate plug-in.
certificate A type of electronic identification card (such as a passport or a driver's license)

that verifies the identity of its holder, and binds the principal's name to that
principal's public key.
Introduction 21
Table 1-5 Terms and definitions (continued)
Term Definition
certificate authority Issues a product credential to the requesting authentication principal based on a
validity check from the registration authority.
cluster A set of hosts that share a set of disks with software coordination.
credential An entitlement to be recognized as an authenticated principal. A valid credential

includes a certificate and the principal’s private key.
login Logons performed on UNIX and Linux platforms.
logon The procedure used to gain access to an operating system or Web console of an
application.
management agent See management client.
management client The client binaries of a management server that is deployed on a client computer
to manage that client computer. Synonymous with management agent.
See “Management agent and client” on page 55.
management server An application server that manages distributed agent/client computers.
See “Management server” on page 54.
master node A cluster node that is responsible for certain Cluster Volume Manager activities.
Only one node in a given cluster can act as the master node.
master server A NetBackup server that provides administration and control for backups and
restores for all clients within a master and media server configuration.
media manager NetBackup software that manages the storage devices and removable media.
media server A NetBackup server that provides storage within a master server and media server
cluster. The master server can also be a media server. A media server that is not
the master server is called a remote media server.
NetBackup A distributed backup and restore application.
node A computer within a cluster.
registration authority An application that determines whether authentication principals are valid.
remote media server A media server that is not the master server.
resource management A Symantec product whose resources are protected by Symantec Product
application Authentication and Authorization Services. An example of a Symantec product
would be NetBackup.
22 Introduction
About authentication and authorization
Table 1-5 Terms and definitions (continued)
Term Definition
restore The process of retrieving saved files, directories, raw partitions, or file systems to
a system for online access.
self-signed certificate A digital identity (certificate) that is signed by its creator, usually a root broker or
certificate authority. See certificate.
storage area network A fibre channel-based network that connects the servers and the storage devices.
The storage devices are attached to the network, and they are visible to all of the
servers on the network.
About authentication and authorization

Authentication is the act of proving whether an entity is who or what it declares
itself to be. An entity can be an application process that runs on a computer, a
user, or an application Web console. The authentication process is conducted on
an intranet of an enterprise through the use of a logon procedure. The logon
procedure is used to gain access to a Symantec application. The logon procedure
requires a valid user ID and password. To ensure that a user is authentic, a valid
combination of the user’s previously declared password and ID must be provided
for the user to be granted access.
For example, an enterprise can use the NISPLUS mechanism to authenticate users
to access a CommandCentral Web console. On the logon screen, a user must enter
a valid ID and password in the NISPLUS authentication domain. Assuming a valid
user named Bob wants to access the application through the Web console, the
validation of the Bob’s identity is as follows:
Authentication: Who are you?

Bob: I am Bob.
Authentication: Prove yourself.
Bob: OK. Here are materials to prove that I am Bob.
Authentication: You have proven yourself and I am convinced. Here is
a certificate to indicate that I believe you are Bob. Combine it with
your private key to make a valid credential to access the application.
The materials that are used in the preceding example could be a user name and
a password.
To enable intranet users to securely and privately exchange sensitive and
privileged information, users must be authenticated through the Symantec Product
Authentication Service by using the authentication mechanisms that are already
established within an enterprise. Successfully authenticated users communicate
Introduction 23
Customer benefits
through the secure channel and are coupled with the public-key infrastructure
(PKI) technology (by using public and private keys) for the secure communication
to take place. PKI is the default standard on the Internet to authenticate and
transmit data, such as credit card numbers and online bill payments between
consumers and e-commerce institutions.
In the Symantec PKI implementation, authorization is always preceded by
authentication. Authorization is the act of checking what an entity can do based
on predefined rules, then granting permissions on these critical resources to the
entity. Assuming a valid user named Bob wants to do NetBackup policy
manipulation, the granting of Access Control is as follows:
Bob: I have proven that I am Bob and I want to

manage NetBackup policies.
Authorization: I believe that you are Bob. Now, let me
consult the rules to see if you are allowed to perform NetBackup
policy manipulations.
Authorization: OK. Access Control on policy management is
now granted to you.
For example, suppose user Bob is also responsible for managing the NetBackup
application. The NetBackup administrator grants the policy manipulation privilege
only to Bob. After Bob successfully authenticates to the NetBackup application,
Bob is allowed only to create, delete, or modify NetBackup policies, and perform
backups and restores. Bob will not be able to manage other NetBackup tasks such
as device discovery, new volume pool creation, or other administrative tasks.
Customer benefits
Most Symantec products require users to have either administrator (Windows)
or root (UNIX/Linux) access privileges to perform installation, configuration, and
upgrade operations. Administrator and root are considered superusers of their
respective operating systems, and these users have the ability to change or modify
the entire system’s configuration. Users who are responsible for managing these
Symantec products are required to log on as one of these superusers as well.
Symantec products can be deployed on different platforms (UNIX/Linux and
Windows) or installed across multiple systems on the same platform in a data
center. Therefore, many individuals with different roles could be involved in
managing the deployed Symantec products.
For example, NetBackup product management could be divided into administrators,
security administrators, users, and operators. Enterprises typically assign a specific
individual or group of individuals to be responsible for a specific Symantec product.
For example, the application administrators who are responsible for the NetBackup,
24 Introduction
Customer benefits
CommandCentral, and Symantec License Inventory Manager products could be

three separate individuals.
Giving superuser privileges to all the individuals who manage Symantec products
can increase the chance of exposing the password of the superuser, and render
the systems vulnerable to malicious attacks. For example, a legitimate individual
may inadvertently write down the superuser password, and this information can
be obtained by an unauthorized employee. To reduce the risk of unauthorized
access or change to systems, the number of individuals who should be given
superuser privilege should be limited and detected by the security policy that is
established within your enterprise.
Using authentication services, a user without superuser privileges can manage a
Symantec product that typically requires a superuser to manage. To accomplish
this task, Symantec products should be enabled with the Symantec Product
Authentication and Authorization Services. Certain Symantec products, such as
Symantec License Inventory Manager (SLIM), are always installed with the
Symantec Product Authentication Service enabled.
Other Symantec products, such as NetBackup, by default, are not installed with
Symantec Product Authentication and Authorization Service enabled, and
additional configuration steps must be conducted to enable this functionality.
Throughout this Yellow Book, information on Symantec product integration with
Symantec Product Authentication and Authorization Services, deployment
guidelines and best practices, and UNIX/Linux and Windows use cases are
presented to illustrate the benefits that are provided by Symantec Product
Authentication and Authorization Services.
Symantec Product Authentication and Authorization offers the following
enterprise benefits:
■ Allow authenticated and authorized users to manage Symantec products
without superuser privileges. After granting the appropriate privileges of a
Symantec product to a user, such as Bob, that user could then perform the
tasks that only the superuser was able to perform. At the operating system
level, user Bob is only an ordinary user.
■ Limit the Operating System superuser access to a small number of individuals.
Users granted sufficient privileges can manage Symantec products. Therefore,
fewer individuals within the enterprise would need superuser access.
■ Assign a user to be an administrator for each Symantec product. In an
enterprise where separation of duties is required, users Bob, Gohan, and Bulma
could be assigned to exclusively manage NetBackup, Symantec License
Inventory Manager, and CommandCentral, respectively. At the Operating
System level, these three people are non-privileged users.
Introduction 25
Customer benefits
■ Grant application roles (administrators, operators) to users selectively. To

restrict the privilege of a night shift NetBackup operator to only be able to
launch backup jobs, the NetBackup administrator assigns the appropriate role
to the operator’s login.
■ Use existing mechanisms (such as NIS, NISPLUS, UNIXPWD, Windows, or
LDAP) to authenticate users. In the logon session, the non-privileged user only
needs to pick the right authentication mechanism and the associated
authentication domain. NIS, NISPLUS, and UNIXPWD are applicable to
UNIX/Linux platforms. The Windows mechanism is specific to the Windows
platform. LDAP, when configured correctly, could authenticate UNIX/Linux
and Windows clients and users residing on UNIX/Linux and Windows. This
eases user management and does not require the enterprise administrator to
manage users separately across all Symantec products.
Authentication service is implemented by using PKI technology that uses public

and private key pairs to produce valid users' credentials. All messages are
encrypted with a session key and transmitted by using the secure sockets layer
(SSL) protocol. A user’s public key certificate is accessible openly over the network,
but the private key is exclusively known to the credential’s requestor. The
requestor’s private key is not transmitted over the network. In order for the
requestor to read the encrypted message, the encrypted message is first decrypted
by using the SSL session key and the requestor's private key must be used to read
the message.
Because the private key is not accessible on the network, the following types of
threats are avoided by those Symantec products that use Symantec Product
Authentication Services:
■ Casual network snooping (including secretly capturing passwords or other
confidential information, for example)
■ Communication replay attacks on your intranet
■ Session hijacking
Symantec products, such as CommandCentral, Symantec License Inventory
Manager, and NetBackup Operations Manager, have Web-based interfaces that
can access these application servers by using this secure protocol. Symantec
Product Authentication Service also offers single sign-on functionality for the
Symantec products that implement this service.
26 Introduction
Customer benefits
Chapter 2
Overview of the Symantec
Product Authentication
Service
■ Authentication service overview
■ Authentication hierarchy
■ Authentication components
■ How the authentication process works
■ Authentication expiry
Authentication service overview

The Symantec Product Authentication Service is deployed as a hierarchy of
components consisting of a root broker at the top level, one or more authentication
brokers, and including multiple authentication entities.
The root broker implements the functionality associated with a registration
authority. The registration authority is the entity that sends requests to the root
broker to determine whether authentication entities (principals) are valid.
Authentication brokers implement the certificate authority functionality, which
follows a security model similar to the public key infrastructure (PKI). The
authentication brokers issue and sign the certificates that are used to prove the
identities of entities (such as computers, users, and services) that interact with
Symantec products. The certification authority issues the product credentials to
28 Overview of the Symantec Product Authentication Service
Authentication hierarchy
the requesting authentication entities (principals) based on the registration

authority's validity check.
All communications between brokers and entities use the secure socket layer (SSL)
protocol.
Authentication hierarchy
The authentication hierarchy is the physical arrangement, or structure, of the
Symantec Product Authentication Service components in your environment,
including the root broker, authentication broker, authentication principal, and
authentication entities. At the top level, the root broker can exist by itself or
co-exist with an authentication broker. The following figure illustrates a typical
authentication hierarchy.
Figure 2-1 lists the authentication hierarchy.
Figure 2-1 Authentication hierarchy
Authentication principal
An authentication principal is any entity that can authenticate to the Symantec
Product Authentication Service with a unique identity.
Overview of the Symantec Product Authentication Service 29
Authentication components
An authentication principal is a logical term that typically represents a human

user, but which can also be any of the following:
■ A computer
■ A service
■ A process (such as a command line interface)
Authentication principals are authenticated based upon their identities. Most
Symantec applications are represented by authentication principals, however,
identities that are associated with the authentication principals are distinct from
the operating system login account identities.
Symantec Product Authentication Service consists of the following components:
■ Root broker
■ Authentication broker
■ Authentication plug-ins and mechanisms
■ Authentication entities
■ Authentication user interface
■ Authentication broker communications port
Root broker
The root broker is the first broker that is established. The root broker resides at
the top level of the authentication hierarchy. The root broker vouches for itself
with a self-signed root certificate and is the most trusted certification authority.
The root broker implements a registration authority to validate authentication
brokers, and has a private domain repository with authentication principals that
represent authentication brokers.
Figure 2-2 shows a root broker that is deployed on a host machine, which contains
a private domain repository that may contain one or more authentication brokers.
Figure 2-2 Root broker private domain repository
Authentication broker
An authentication broker differs from a root broker in that is serves as both an
intermediate registration authority and as a certification authority. As a
registration authority, it determines whether authentication principals are valid.
As a certification authority, it issues product credentials to the requesting
authentication clients (such as users or services) based on the registration
authority's validity check of client's authentication principals.
The certificate of an authentication broker is signed by the root broker. The
authentication broker authenticates only clients and it cannot authenticate other
authentication brokers. The authentication broker resides one level below the
root broker in the authentication hierarchy.
Figure 2-3 shows an authentication broker that is installed on a host machine and
contains a private domain for one of the application services provisioned by the
product.
Figure 2-3 Authentication broker private domain repository
Authentication plug-ins and mechanisms

An authentication plug-in is a component that is used by the authentication broker
to validate the identities within an authentication domain. A plug-in exists for
each supported authentication mechanism. A mechanism is a method by which

authentication is conducted for the authentication principals within a specific
namespace that is defined by a domain type (such as NIS, NISPLUS, Windows NT,
LDAP, or UNIXPWD). Plug-ins and domain types are synonymous and they have
one-to-one mapping with authentication mechanisms. An authentication
mechanism encapsulates all the details of the authentication algorithm that is
specific to each domain type. For example, the NIS plug-in can validate identities
with a NIS login and password combinations against a NIS database.
The following plug-ins are supported in various versions of the authentication
service:
■ NIS – NIS v2 (formerly called YP – Yellow Pages)
■ NISPLUS (NIS+) – NIS v3
■ UNIXPWD – Password on UNIX and Linux systems
■ LDAP – OpenLDAP and iPlanet implementations
■ GSSAPI – Generic Security Service Application Program Interface
■ NT – Windows NT domains and Active Directory (SSPI)
■ VX – Symantec Private Domain (used internally by the authentication service)
Not all plug-ins exist on all platforms. For example, NIS, NISPLUS, and UNIXPWD
are available only on UNIX and Linux systems. The NT plug-in is available only
on Windows. So an authentication broker that is configured on a UNIX system
cannot use a Windows specific plug-in to authenticate users on Windows. A
Symantec application client is typically required to authenticate against only one
or two domains.
Table 2-1 lists the plug-ins supported by the Symantec Product Authentication
Service versions on UNIX/Linux platforms.
Table 2-1 Plug-ins supported on UNIX/Linux
Authentication NIS NIS+ UNIXPWD VX LDAP GSSAPI PAM
4.1
4.2
4.3
Table 2-2 lists the plug-ins that are supported by the Symantec Product
Authentication Service versions on Windows.
Table 2-2 Plug-ins supported on Windows
Authentication Windows NT VX LDAP GSSAPI
4.1
4.2
4.3
Authentication entities
An authentication entity is any Symantec application that sends an authentication
request to the authentication service.
Application service
An application service is a program that is contacted by, and provides services
to, a Symantec application client. The authentication service validates its identity.
Application client
An application client is a program that accesses a Symantec service or function
that is provided by another program called a Symantec application service. An
example of a secured application client is the NetBackup Operations Manager
GUI. A Symantec application client uses the authentication service to validate
the identity of the user of that client.
Authentication user interface

The Symantec Product Authentication Service provides a management utility
(vssat) for the product administrator. To see the list of options that are available
in the vssat utility, from the command line, type vssat --help. On UNIX/Linux,
type man vssat to display the manual pages. The authentication service also
provides a graphical user interface.
On UNIX/Linux, the vssat utility is available in the /opt/VRTSat/bin directory.
On Windows, the default directory for vssat.exe is C:\Program
Files\VERITAS\Security\Authorization\bin.
Authentication broker communications port

The default port number that is used by the root broker or authentication broker
is 2821. You can use the vssat utility to change the default value.
How the authentication process works
Starting with version 4.3, the authentication service can be configured to use
Private Branch Exchange (PBX). In this configuration, the port that is used by the
authentication service is 1556 (the same port that is used by PBX).

For the application client and application service to communicate securely, the
client and service entities must first be vouched for by the authentication broker
through a secure communication channel.
The authentication broker validates the authentication principals that are
associated with these entities, then issues credentials to each of them.
After these principals are authenticated, an SSL encrypted connection is
established between the Symantec application client and the Symantec application
service. The client and service interact over the SSL connection, sending and
receiving messages as necessary until the client terminates the communication.
The root broker for the authentication broker can be installed on a remote system,
or on the same system as the authentication broker. Credentials that are delivered
to the client and service must contain the electronic signature of the root broker
through the intermediary authentication broker.
Figure 2-4 provides a high-level concept of the authentication process.
Figure 2-4 Authentication process flow
Symantec Product Authentication Service uses the secure sockets layer (SSL)
technology to provide secured communication among the Symantec application
client, the authentication broker, and the Symantec application service. During
the authentication process, the client uses the SSL layer for communicating with
the authentication broker to request a product credential.
The secure sockets layer is a public key protocol that was originally created by
Netscape and used for secure communications between clients and servers over
the Web. When using an SSL connection, all communication between client and
service is encrypted by the sender and decrypted by the receiver.
The protocol can offer both client authentication and service authentication. Each
encrypted transaction generates a session key, which can be up to 128 bits. The
longer the session key, the stronger the security.
Acquiring a product credential

On a system with an application client, a user on client A sends authentication
materials to the authentication broker. Materials include the public part of
credential, name, authentication domain, and possibly other material.
The authentication broker is an intermediate certification authority and it has a
credential that is signed by the root broker.
The authentication broker validates the user (identity) by selecting the appropriate
plug-in. The plug-in talks to the OS mechanisms or the VX authentication domain
type. The authentication broker determines that the user on client A is valid and
signs the public part of the credential for the user.
Figure 2-5 illustrates the credential request that the user on client A sends to the
authentication broker.
Figure 2-5 Client credential request
A credential, in a form similar to a passport or ID card, is created which vouches

for the identity of the user (holder). The credential is then sent back to the user
on client A through the SSL communication channel.
Figure 2-6 illustrates the process by which the signed public credential is sent to
the requesting authentication client.
Figure 2-6 Authentication broker response
A valid authentication (product) credential is then constructed by combining the

signed public credential with the user's own private key. The authentication
credential entitles the user (security principal) to be recognized as a valid identity
by Symantec products.
The authentication credential is stored and managed by the credential manager
on the system (client A) where the user resides. The authentication credential is
a single sign-on credential that is valid for all Symantec applications that
participate in a single sign-on environment.
Figure 2-7 illustrates the public key infrastructure (PKI) protocol where the user's
private key (including the user's name) is bound with the certificate created and
signed by the authentication broker.
Figure 2-7 illustrates the process by which the credential is sent to the
authentication client.
Figure 2-7 Authentication credential

Authentication expiry
Authentication expiry
Each certificate that the Symantec Product Authentication Service issues has a
validity period. After a credential expires it is no longer usable, and the credential
must be reacquired. There are different types of certificates, and each type has
its own validity period.
Table 2-3 lists authentication entities and their corresponding validity periods.
Table 2-3 Default expiry periods
Entity Default expiry period
Root Broker 8 years
Authentication Broker 8 years
Service Principal 2 years
User Principal 1 year
Authorization Service 2 years
NetBackup System 1 year
NetBackup Login Session 24 hours
Web Session 8 hours
CommandCentral Web Session 30 minutes

Chapter 3
Overview of the Symantec
Product Authorization
Service
■ Authorization service overview
■ Authorization service components
■ Access control policy
■ Access control lists
■ How the authorization process works
Authorization service overview

Symantec Product Authorization Service (authorization service) is an access
control decision-making service. After authentication validates the identities of
entities (principals) working with Symantec software applications, the
authorization service is used to make access control decisions. The authorization
service determines which entities have permission to perform specific tasks on
specific resources. A resource is a uniquely-identified object. For example, a
NetBackup resource can be a tape library or a volume pool.
The authorization service works within the policies that are established by a
security product administrator. An administrator can view, set, or modify a policy
through the application user interfaces. These authorization policies are recorded
in a database. Access decisions are made by consulting this database. After making
38 Overview of the Symantec Product Authorization Service
Authorization service components
an access decision, authorization allows each Symantec application to enforce

the decision.
Figure 3-1 shows a high-level overview of the authorization process.
Figure 3-1 Authorization overview

Symantec Product Authorization Service contains the following components.
■ Authorization service
■ Authorization client
■ Access control information data repository
■ Master authorization service
Overview of the Symantec Product Authorization Service 39
■ Local authorization service

■ Resource management application
■ Authorization group or namespace
■ Authorization user interface
■ Authorization service communication port
Authorization service
The authorization service makes access control decisions for authentication
entities (principals) after validating their identities. The authorization service
component enables a product security administrator to create and manage the
access control entries and other aspects of the Symantec Product Authorization
Service.
Authorization client
An authorization client runs on a host that requests an access control decision
from the authorization service. For example, on a host that has a NetBackup media
server, the authorization client uses the main authorization database on the
master server to allow the media server to perform an authorization check.
Access control information data repository

The data repository is a database that maintains the master copy of the
authorization service. The database contains the information required to make
authorization decisions. This information includes data on the resources that are
advertised by Symantec resource management applications (service access control
information), and data on the resources that are used by authorization
(administration access control information).
Figure 3-2 shows the structure of this type of data repository.
Figure 3-2 Authorization data repository
Master authorization service

The Master authorization service holds and maintains the central access control
information data repository. In a distributed authorization environment, where
local authorization servers exist, certain information from the master ACL data
repository is periodically copied to, and synchronized with, the Local Authorization
Server.
Local authorization service

The local authorization service is the host that holds and maintains a read-only
copy of access control information, which has been imported from the master
access control information data repository. Periodically, the local information is
synchronized with the information in the master repository.
Resource management application

This component is a Symantec product whose resources are being protected by
Symantec Product Authorization Service. Resource management applications are
made up of application clients and application services. They perform the following
tasks, related to the Symantec Product Authorization Service:
■ Advertise the existence of the resource they want to protect. This is necessary
because authorization does not have its own discovery function.
Overview of the Symantec Product Authorization Service 41
Access control policy
■ Ask the authorization service to make an access control decision for the
required service requests, and then enforce the decision by applying predefined
rules or policies.
Authorization group or namespace

A collection of entities (such as users). Entities in a namespace can use different
authentication domains. For example, user vegeta can employ the UNIXPWD
domain type, while user trunk employs the NISPLUS domain type. Any
authenticated entity is then granted the authorization privileges based on the
policy that is defined for the group.
Authorization user interface

The Symantec Product Authorization Service provides a management utility
(vssaz) for the product administrator. To see the list of options that are available
in the vssaz utility, from the command line, type vssaz --help. On UNIX/Linux,
type man vssaz to display the manual pages. The authorization service also
provides a graphical user interface.
On UNIX/Linux, the vssaz utility is available in the /opt/VRTSaz/bin directory.
On Windows, the default directory for vssaz.exe is located at C:\Program
Files\VERITAS\Security\Authorization\bin.
Authorization service communication port

The Symantec Product Authorization Service default communication port number
is 4032. You should specify this port number when you connect to the authorization
service.
Access control policy

An access control policy (ACP) is a set of rules that define how application resources
are to be protected from unauthorized use. Specifically, the policy states the
permissions that an authenticated entity (such as user) can have over secured
objects. For NetBackup, the ACP is defined as individual permission groups or
namespaces. NetBackup predefines five namespaces (such as NBU_Operator and
NBU_Admin). The security administrator assigns entities to each namespace. When
an authenticated entity tries to use a secured object, the resource management
application (such as NetBackup) invokes the decision-making service of
authorization. The authorization service determines the access rights of the entity
and returns its decision to the application to be enforced.
Access control lists
See “NetBackup and authorization” on page 270.
Access control lists

An access control list (ACL) is a collection of zero or more entries within an access
control policy (or permission namespaces). Each entry associates an authenticated
entity with a specific permission to perform tasks as defined by the access control
policy. For example, the entities that are assigned to the NetBackup NBU_Operator
permission namespace have only the ability to mount or unmount tapes.
NBU_Admin permission namespace allows the assigned entities to have
NetBackup’s administrative privileges.
How the authorization process works

For Symantec management applications that are integrated with Symantec Product
Authorization, the product's security administrator determines which Symantec
application resource to protect. The security administrator then configures the
access control rules for the resources that are used by the protected applications.
When an entity wants to use a protected application resource, it goes through the
following authorization steps:
1 The user logs on, is authenticated, and allowed to start accessing a resource
management application.
2 The resource management application requests permission for an entity
(principal) to access a resource.
3 The authorization service consults established access control policy, and
checks the access control list to see whether the requested access is allowed.
4 The authorization service passes its decision back to the protected application.
5 The resource management application enforces the decision made by
Authorization.
Chapter 4
How authentication and
authorization are used
across Symantec products
■ Introduction
■ Implementing one authentication hierarchy in your enterprise
■ Using the authentication service for secure communication
■ Assimilating authentication service into your enterprise
■ Using the authorization service for access control
Introduction
Deploying a Symantec product that is integrated with the Symantec Product
Authentication Service requires the setup of an authentication hierarchy tree
with a root broker and an authentication broker. When Symantec products that
are integrated with the authentication service are deployed together, an
authentication broker is set up for each product in the authentication hierarchy
tree. Private domain repositories (root and authentication domains) are created
by the root broker and the respective authentication brokers.
Deploying a Symantec product that is integrated with the authorization service
requires the setup of an authorization service server. The authorization server is
typically configured on the same system as the resource management application
(such as NetBackup master management server) that uses the authorization
service.
44 How authentication and authorization are used across Symantec products
Implementing one authentication hierarchy in your enterprise
Implementing one authentication hierarchy in your

enterprise
The authentication hierarchy to which the authentication brokers belong should
also be planned according to the needs of your enterprise. Ideally, one
authentication hierarchy is sufficient and preferred. Within an authentication
hierarchy, authentication brokers can be set up across UNIX/Linux and Windows
platforms.
The root broker in the authentication hierarchy holds the absolute power on
registration and certification and it has the ultimate authority over the validity
of a certificate that is issued by an authentication broker to an authenticating
entity. Authentication brokers are the intermediary registration and certification
authorities. Their role is to authenticate client entities that must communicate
with the products' application services.
Authentication brokers that are created in separate authentication hierarchies
maintain distinct root certificates. Certificates that are from different
authentication hierarchies are not compatible. A secure communication channel
between an application client and an application service cannot be established
when the authentication broker used by the client and service are not descended
from the same root. Therefore, it is not possible for a mutual entity on a system
with the application client to access a Symantec application service.
For this reason, only one authentication hierarchy should be used throughout
your enterprise. If a root broker is created implicitly through the installation of
a product server (either management or application), you are creating a new
authentication hierarchy that is incompatible with any existing hierarchies.
See Figure 2-4 on page 33.
Using the authentication service for secure

communication
The Symantec Product Authentication Service vouches for the identities of the
application client and application service and issues certificates to these entities.
After a valid product credential is established by these entities, a secure
communication channel is created between the requesting client and the
application service. The application client can be on the system with the application
service, or on a different system.
It is recommended that each Symantec management server that is integrated
with authentication services configures an authentication broker on the same
system as the management server. To exclusively configure an authentication
How authentication and authorization are used across Symantec products 45
Using the authentication service for secure communication
broker for a management server (such as NetBackup or CommandCentral), typically

a dedicated system with the management server and an authentication broker is
set up. All the management servers that are illustrated in this Yellow Book have
an accompanying authentication broker.
Besides the authentication broker, a Symantec management server must also
create one or more private authentication domains. For example, NetBackup
creates the NBU_Machines private domain that is used to hold all the NetBackup
related authentication principals (clients, master, and media). Authentication
entities (such as users) that want to establish a login session must authenticate
to the authentication broker that created the NBU_Machines private domain, or
to another authentication broker that resides in the same authentication hierarchy.
Other Symantec products, such as CommandCentral, have created the cc_users
authentication domain for the CommandCentral users to login.
Upgrading authentication service in your enterprise

On the system that has a product's management server, you can install
management agents or clients of another management server. For example, on
the system with a NetBackup management server, you can install the
CommandCentral management agent. The management server and management
agents or clients may require a different version of the authentication service.
Upgrading authentication service for a Symantec product may involve a
compatibility issue for other Symantec products. Before you upgrade the
authentication, verify that the new version is compatible with the other Symantec
products that are installed on the system. It is a good practice to maintain a test
environment in your data center and use it for testing new software releases or
maintenance packs before you deploy the software to your production
environment.
Different versions of the authentication service may be required by a management
server and management agents or clients that are deployed on a system. In this
situation, the highest version of the authentication service should be used on the
system. An approach to deploy authentication service across Symantec products
is described in Chapter 5. Deployment guidelines and best practices that are
common and applicable to most enterprises are illustrated. For specific product
use cases, refer to Chapter 6 (UNIX/Linux) and Chapter 7 (Windows) for detailed
information.
Assimilating authentication service into your enterprise
Assimilating authentication service into your

enterprise
The tables in the following sections list the authentication plug-ins that are
supported by Symantec products. Enterprises that support one or more of these
authentication mechanisms make it possible to deploy Symantec authentication
services. This allows the application servers and clients of the Symantec products
that are integrated with authentication services to reuse the authentication
infrastructure for existing users and groups in your enterprise.
NetBackup
NetBackup is integrated with the following common core services product. Refer
to the use case chapters to find out which specific version of this product has been
tested.
■ Authentication
Table 4-1 lists plug-ins supported by NetBackup on Windows and UNIX/Linux
platforms.
Table 4-1 Plug-ins supported by NetBackup
NBU UNIX/Linux Windows LDAP GSSAPI PAM
NIS NISPLUS UNIXPWD NT
6.0MP4
NetBackup Operations Manager

NetBackup Operations Manager is integrated with the following common core
services product.
Refer to the use case chapters to find out which specific version of this product
has been tested.
■ Authentication
Table 4-2 lists plug-ins supported by NetBackup Operations Manager on Windows
and UNIX platforms.
Assimilating authentication service into your enterprise
Table 4-2 Plug-ins supported by NetBackup Operations Manager
NOM UNIX Windows LDAP GSSAPI PAM
6.0MP4
Veritas Storage Foundation

Veritas Storage Foundation is integrated with the following common core services
product. Refer to the use case chapters to find out which specific version of this
product has been tested.
■ Authentication
Table 4-3 lists plug-ins supported by Veritas Storage Foundation on UNIX/Linux.
Table 4-3 Plug-ins supported by Veritas Storage Foundation on UNIX/Linux
SFCFS UNIX/Linux Windows LDAP GSSAPI PAM

SF Oracle NIS NISPLUS UNIXPWD NT
RAC
VCS
4.1MP1
5.0
Table 4-4 lists plug-ins supported by Veritas Storage Foundation on Windows.
Table 4-4 Plug-ins supported by Veritas Storage Foundation on Windows
SFWHA UNIX/Linux Windows LDAP GSSAPI PAM
4.3MP1
CommandCentral
The following version of CommandCentral Storage and Service is integrated with
the following common core services product. Refer to the use case chapters to
find out which specific version of this product has been tested.
■ Authentication
Table 4-5 lists plug-ins supported by CommandCentral Storage.
Using the authorization service for access control
Table 4-5 Plug-ins supported by CommandCentral Storage
CC UNIX/Linux Windows LDAP GSSAPI PAM

Storage
4.2FP1
4.3
Table 4-6 lists plug-ins supported by CommandCentral Storage.
Table 4-6 Plug-ins supported by CommandCentral Service
CC UNIX/Linux Windows LDAP GSSAPI PAM

Service
4.2FP1
Symantec License Inventory Manager

The following version of Symantec License Inventory Manager (SLIM) is integrated
with the following common core services product. Refer to the use case chapters
to find out which specific version of this product has been tested.
■ Authentication
Table 4-7 lists plug-ins supported by SLIM.
Table 4-7 Plug-ins supported by Symantec License Inventory Manager
SLIM UNIX/Linux Windows LDAP GSSAPI PAM
4.0.4

The Symantec Product Authorization Service is an access control service. After
the authentication service validates the identities of entities (principals) working
with Symantec products, the authorization service determines whether the
validated entities have the authority to perform tasks on protected resources.
The authorization service works within the authorization policies that are
established by the product's security administrator. An administrator who wants
to view, set, or modify policy can do so through the product user interface. The
authorization service provides a database to record the authorization policies
against which access decisions are made. After making an access decision, the
authorization service allows each Symantec application to enforce that decision.
NetBackup
In this Yellow Book edition, the capability of the authorization service is
demonstrated through NetBackup Access Control. The NetBackup management
server creates a private authentication domain, SERVICES, that holds the
authentication principal for NetBackup's authorization related activities. An
approach to deploy authorization service with NetBackup is described in Chapter
6, UNIX/Linux use cases, and Chapter 7, Windows use cases. Guidelines and best
practices that are common and applicable to most enterprises are illustrated.
■ Authorization
Refer to the use case chapters to find out which specific version of this product
has been tested.
Chapter 5
Deployment guidelines and
best practices
■ Multiproduct deployment approach
■ Broker architecture determination
■ Planning for authentication and authorization in your enterprise environment
■ Authentication and authorization administration
■ Backup and recovery of authentication and authorization
■ Empirical use cases
■ Product troubleshooting tips
Multiproduct deployment approach

Deploying Symantec products with Symantec Product Authentication and
Authorization requires careful analysis and planning. Your business requirements
should dictate the basis of both the security architecture and the implementation
approach. It is recommended that you take time to translate these requirements
into a master scheme with both short-term and long-term plans and deliverables.
A phased approach has proven to be effective in the deployment of Symantec
Product Authentication and Authorization.
This chapter contains framework and configuration information you can use as
guidelines when you design and create an implementation plan for your enterprise.
Refer to the following sections for an example of how an enterprise designs a
high-level plan and then translates it into a diagram.
52 Deployment guidelines and best practices

The following Symantec products are targeted for deployment and are illustrated
with the authentication and authorization products:
■ NetBackup
■ NetBackup Operations Manager
■ CommandCentral
■ Storage Foundation with Veritas Cluster Server
■ Symantec License Inventory Manager
Figure 5-1 shows generic enterprise security deployment scenarios.
Deployment guidelines and best practices 53
Figure 5-1 Generic enterprise security deployment scenario
The objective is to design a phased approach to the implementation of all Symantec

products in an enterprise with authentication and authorization enabled. Issues
to consider include defining the number of authentication domains, whether one
root broker is sufficient, the number of authentication brokers, and the distribution
of application servers and management agents/clients.
Application server
In this context, an application is a group of computer programs that work together
to perform specific tasks or functions. Examples of Symantec applications that
are covered in this current Yellow Book edition include Storage Foundation
products, NetBackup, CommandCentral, and Symantec License Inventory Manager.
See Table 1-3 on page 17.
Symantec applications use the services that are supplied by the computer operating
system and other supporting Symantec applications, such as Symantec Product
Authentication and Authorization Service.
An application server is a computer that is connected to a company’s intranet
and that has a specific Symantec application running on the system. An application
server generally provides services to client computers. Therefore, application
server and application service are synonymous and used interchangeably
throughout this document.
On systems that have the application server installed, the management client or
agents are also likely to be installed. The roles of these clients or agents are to
manage the application resources that are present on these systems.
To deploy VCS and enable with authentication service, VCS requires that an
authentication broker be configured on each node in the VCS cluster. The root
broker can be configured on one of the VCS nodes or on a remote system.
Management server
An application server with the added responsibility of managing client computers
is called a management server. NetBackup, NetBackup Operations Manager,
CommandCentral, and Symantec License Inventory Manager are all considered
to be management servers. A management server manages the client computers
that connect to the same intranet. Each of these management servers manages a
specific type of information for the clients.
For example, NetBackup manages client’s data by providing backup and recovery
functionality for the clients. NetBackup Operations Manager manages NetBackup
Master Servers.
In the context of this Yellow Book, Storage Foundation products (SF, SFCFS, SF
for Oracle RAC) are not considered to be management servers because SF does
not manage client computers. This Yellow Book does not recommend deploying
multiple management servers, such as NetBackup or CommandCentral, on a single
system in a production environment; all management servers are typically installed
by themselves on separate systems. Systems where NetBackup Operations Manager
is deployed must have either NetBackup management client, master, or media
Broker architecture determination
server installed. For convenience, NOM may be installed and configured on the
same system as the NetBackup master management server.
On a system that has a management server (such as SLIM, NetBackup, or
CommandCentral), an authentication broker is required and should be configured
to point to either a local root broker or an existing authentication hierarchy on a
remote system. Each of these management servers requires an authentication
broker to be present on the same system as the management server.
Management agent and client

For a management server to manage a client computer, the product’s client or
agent portion of the software must be installed on the client’s computer. A client
must be associated with a specific management server by performing the necessary
configuration either during or after the installation.
NetBackup refers to its clients as client. The other Symantec products refer to
NetBackup clients as agent. On a client computer, it is permissible to have
NetBackup client, CommandCentral and License Inventory Manager agents
installed.
On systems that have either management agents or clients installed, typically,
the client component of the Symantec Product Authentication and Authorization
should be sufficient. However, it is permissible to configure a SLIM management
agent on a system that has the NetBackup management server.

In an authentication hierarchy tree, there is only one root broker that resides at
the top level, and is validated with a self-signed credential. Each root broker is
uniquely identified by a 40-byte electronic signature called a root hash. You can
use the command vssat showbrokerhash to view the root hash. Root brokers
cannot have the same root hash.
A root broker can be installed and configured on a UNIX/Linux or Windows
platform. The root broker authenticates a group of authentication brokers, signs
their certificates, and maintains the root private domain repository (PDR) to track
these authentication brokers.
There may be a number of authentication brokers in the authentication hierarchy

tree one level below the root broker. The authentication broker serves as an
intermediary (between the root and the authenticating entities) registration
authority and a certification authority that can authenticate management servers,
management agents, or clients, users, and application services.
An authentication broker cannot authenticate other authentication brokers. Each
authentication broker has an authentication PDR that stores the management
server domains such as NetBackup, VCS, CommandCentral, and others. Associated
with each authentication broker are various plug-ins (such as NIS, NISPLUS, or
Windows NT).
Figure 5-2 shows an authentication broker configured on UNIX and Windows,
respectively, that authenticates with a platform-specific plug-in (such as NISPLUS
and Windows NT).
Most of the management servers that are illustrated in this Yellow Book require
an authentication broker to be configured on the same system as the management
server. An authentication broker can be installed and configured on UNIX/Linux
or Windows platforms. As depicted in the following figure, you can have a root
broker on Windows or UNIX/Linux, and authentication brokers on UNIX/Linux
and Windows. Each authentication broker is configured with a platform-specific
plug-in (such as NISPLUS or Windows NT) to authenticate users.
Figure 5-2 shows root broker with heterogenous authentication brokers.
Figure 5-2 Root broker with heterogenous authentication brokers
The business requirements of an enterprise have been formulated into a high-level

layout.
In this example, a pilot project is initiated by an enterprise to decide the security
infrastructure, and to choose an approach to implement all the Symantec products
with Symantec Product Authentication and Authorization. The management
servers are implemented on systems that run Windows. Application servers,
management agents or clients are deployed on systems that run Windows, HP-UX,
and Red Hat operating systems.
Symantec License Inventory Manager is the first Symantec product to be deployed.

The SLIM installation script installs and configures a root broker plus an
authentication broker on the same system as the SLIM management server. All
the SLIM users accessing the SLIM Web console should be authenticated by using
a SLIM authentication principal. SLIM server has management agents deployed
on Windows, HP-UX and Red Hat platforms.
Next, NetBackup is installed and configured. For the NetBackup management
server, the master server is configured on Windows, and it has Media servers on
Windows, HP-UX, and Red Hat. On the client side, (management agents or clients)
application servers are configured on Windows, HP-UX, and Red Hat. An
authentication broker is configured on the system that has the master management
server and possibly on other systems that have media servers. These
Authentication brokers all point to an existing authentication hierarchy that is
created by the SLIM deployment.
Similarly, CommandCentral is deployed. The CommandCentral management
server is on Windows. On the client side, management agents/client application
servers are deployed on Windows, HP-UX, and Red Hat. On the systems that have
the NetBackup and CommandCentral management servers, respectively, an
authentication broker is configured on each system that points to an existing
authentication hierarchy that is created by the SLIM deployment.
The security architect of the enterprise has decided on the single authentication
hierarchy approach. All the authenticating entities (such as users) on UNIX/Linux
management agents and clients should be assigned to authentication brokers that
are configured on UNIX/Linux platforms. Similarly, all authenticating entities on
Windows will be assigned to authentication brokers that are configured on
Windows.
On UNIX/Linux, authenticating entities (such as users) on management agents
and clients are assigned to use one of the plug-ins (such as UNIXPWD, NIS, or
NISPLUS). Similarly, a Windows plug-in (such as Windows NT) is assigned to the
authenticating entities that reside on Windows management agents and clients.
To anticipate future growth, multiple authentication brokers are set up to evenly
distribute the management agents and clients to the available authentication
brokers.
You could set up additional authentication brokers on systems that have the
NetBackup Media servers.
In the previous figure, for example, suppose that in your enterprise, NetBackup
management server has a media server on Windows, HP-UX, and Red Hat. On
each of these systems, the Symantec Product Authentication and Authorization
Service client components are required.
Promoting the authentication client on these systems to an authentication broker

should be straightforward. You can then use the authentication brokers that are
configured on NetBackup media servers to authenticate the users on NetBackup
management clients, or some other management agents on the same platform.
For example, all the authenticating entities (such as users) on the HP-UX
NetBackup management clients are to be authenticated by the authentication
broker that is configured on the HP-UX media server. Similarly, all the users on
Red Hat NetBackup management clients can be assigned to the authentication
broker on Red Hat media server.
In the current edition of this Yellow Book, all the demonstrations are illustrated
by using a single root broker (either on UNIX/Linux or Windows). In the
UNIX/Linux use cases chapter, the root broker is configured on Solaris, and
authentication brokers are configured on Solaris, AIX, and Windows. In the
Windows use cases chapter, the root broker is configured on Windows, and
authentication brokers are configured on Red Hat, HP-UX, and Windows.
Root and authentication broker placement

In an enterprise that deploys Symantec products on heterogenous platforms (such
as Windows, Solaris, and Red Hat), it is recommended that the root broker be
placed on the platform that gets used the most. If 65 percent of the systems are
running Windows, then Windows is the preferred platform on which to deploy
the root broker. Other factors may also determine the physical placement of the
root broker.
See “Isolated root broker” on page 61.
After a root broker is successfully deployed, you need to configure an
authentication broker on Windows and another authentication broker on
UNIX/Linux to meet the demand of authenticating entities in a heterogeneous
environment. For example, the authenticating entities that are on Windows would
most likely be assigned to an authentication broker on Windows. Refer to the
following figure for an illustration of how you can place the root and authentication
brokers.
Figure 5-3 shows root and authentication broker placement.
Figure 5-3 Root and authentication broker placement
In an enterprise that has a large number of authenticating entities (such as users)

dispersed over many management agents and clients, it is recommended that you
configure multiple authentication brokers to spread these authenticating entities
over the authentication brokers for load balancing. If an authentication broker
on a system is authenticating too many users and a catastrophic hardware failure
occurs on the system, all the users will be without an authentication broker. In
addition, the authentication broker's latency increases as demand on the
authentication broker goes up.
When deciding the number of authentication brokers to configure, it should be
based on the number of mechanisms (plug-ins) that are used in the enterprise. If
an enterprise users NISPLUS, UNIXPWD, and Windows (NT) mechanisms, an
authentication broker should be setup on a separate system for each of these
plug-ins. Each of these systems could also have a Symantec product (such as
NetBackup media server) configured.
It is also recommended to base the allocation on the usage of the authentication
plug-in. If a majority use a NISPLUS plug-in, it is ideal to have multiple
authentication brokers on UNIX/Linux configured with the NISPLUS plug-in to
share the load. For example, if there are four production systems in a data center
with over three thousand NISPLUS users on each system, it is best to configure
an authentication broker on four separate systems and assign users on each of
the production systems to one of the authentication brokers.
Isolated root broker

On the system where the root broker is configured, there is no authentication
broker. This configuration allows an enterprise to isolate the root broker to a
secure system that is accessible to selected individuals with high privileges.
Figure 5-4 shows isolated root broker configuration.
Figure 5-4 Isolated root broker configuration
For the enterprises that want overall control over the creation of authentication
brokers, this configuration should provide added security to the environment. It
is not recommended to set up trust between the isolated root broker and another
root broker in the enterprise. Setting up trust between these two root brokers
may defeat the purpose of having a root broker on a secure system.
Multiple root brokers

It is recommended that every management server be configured on a system by
itself. The advantage to this configuration is that each management server incurs
a different load on the system, and a system failure would only disable the
management server on which it resides. Therefore, it is typical for an administrator
to configure the NOM management server on one system, and the NBU
management server on another. The administrator of the authentication service
would typically configure a root plus authentication broker on each system that
has a management server. The NOM management server could be configured on
UNIX, and the NBU management server could be configured on Windows.
Figure 5-5 shows management servers with private root broker.
Figure 5-5 Management servers with private root broker
Every root broker has a unique electronic signature. The authentication principals
that are established in one authentication hierarchy are not recognized in another
authentication hierarchy. For the NOM to manage the NBU Master server, a trust
(NBU trusting NOM) must be established between these two root hierarchies.
Establishing trust between root hierarchies can be problematic, and requires
advanced knowledge on the authentication product, and an understanding of the
configuration to perform all the steps correctly. After the trust has been
established at the root level, all the authenticating entities of the NBU
authentication hierarchy must be made aware of the NOM’s root electronic
signature by setting up trust and re-authenticating.
With initial planning, the administrator of authentication services of a hypothetical
enterprise has decided to use the layout illustrated in the following figure.
The authentication administrator installs the NOM management server on a
system with an authentication broker that points to an existing authentication
hierarchy. The NOM and NBU are now under the same authentication hierarchy,
which eliminates all the trust and re-authenticating activities. Therefore, the
possibility of forgetting to re-authenticate authenticating entities has been
eliminated.
At enterprise C, a business decision requires that NBU and CommandCentral
Storage management servers be installed and configured on separate systems
with a different authentication hierarchy. No interaction is expected or permitted
between entities in these root hierarchies. In this situation, the scenario depicted
in the following figure would be appropriate.
Brokers in different time zones

Root brokers and authentication brokers can span different time zones. The
authentication and authorization service performs all of its operations relative
to Greenwich Mean Time (GMT). The system time on your root brokers and
authentication brokers must be within five minutes of each other. You can have
the root broker located in Los Angeles and authentication brokers in Shanghai or
Singapore. It is important that the time zone and clock on the systems that have
either the root or authentication broker are configured correctly according to the
local time zone.
Broker availability
Without the root broker, you cannot create new authentication brokers and
establish trust between different authentication hierarchies. You can still use the
authentication brokers when the root broker is not available. The following figure
depicts a root broker that maintains a group of authentication brokers.
An administrator must be proactive on the status of the root broker and
authentication brokers. When a user fails to authenticate or log on to the Web
console, the first step is to verify the existence of the brokers.
Without the authentication broker, management agents or clients that are assigned
to that authentication broker can no longer obtain a new authentication certificate.
Credentials that were cached on the management agent or client would continue
to function until they expire.
Authentication brokers are used more frequently than the root broker. It would
be ideal to have multiple authentication brokers that are configured with the same
authentication plug-in as backup. When a hardware failure occurs on a system
that has an authentication broker, the authenticating entities (such as users) on
the affected authentication clients can be reassigned to other authentication
brokers that support the same plug-in.
For example, users on NetBackup management clients are authenticated by
authentication brokers that are distributed over multiple media servers. When a
failure occurs on one media server, users on the affected management clients can
be reassigned to an authentication broker that supports the same plug-in on
another media server.
To determine if the system already has a root broker configured, refer to the
following section for instructions and procedures.
See “Verify authentication setup” on page 235.
Root broker consolidation

Symantec products that have management servers should be deployed on separate
systems. The installation scripts that are distributed by SLIM and CommandCentral
typically configure a new authentication hierarchy (root plus authentication
brokers) on the system where these products are installed. This creates the
possibility of inadvertently having multiple authentication hierarchies in your
enterprise.
Having the authentication service of the SLIM and CommandCentral management
servers configured in two separate authentication hierarchies has undesirable
consequences. For example, when deploying the SLIM and CommandCentral
management agents on the same system, it is ambiguous which authentication
hierarchy the system should derive its authentication principal from. Because a
system can only hold an authentication credential from one root broker at a time,
there may be an authentication failure.
This section describes the procedures for consolidating multiple authentication
hierarchies into one.
In the following figure, SLIM and CommandCentral management servers are
configured with separate root brokers.
In the following figure, the SLIM management server is on UNIX (Solaris), and
the CommandCentral management server is on Windows.
The two root brokers can then be consolidated into one authentication hierarchy.
To consolidate the two root hierarchies into one, the authentication hierarchy
created by the CommandCentral management server should be kept intact, and
the SLIM authentication broker should be merged into the CommandCentral
management server authentication hierarchy. To merge the authentication broker
that is created for the SLIM management server on Solaris into the authentication
hierarchy that is created for the CommandCentral management server on
Windows, refer to the following section.
See “Replacing the root broker on the SLIM server” on page 300.
After the consolidation, the hierarchy is merged as shown in Figure 5-6.
Figure 5-6 Consolidated authentication hierarchy
After the SLIM authentication broker has been moved into the CommandCentral
management server authentication hierarchy, all the SLIM management agents
that were authenticated by this authentication broker must be re-authenticated
Planning for authentication and authorization in your enterprise environment
to use the electronic signature of the root broker in the CommandCentral

authentication hierarchy. The re-authentication must be performed on each
system that has the SLIM management agent. Therefore, when consolidating root
hierarchies, it is easier to move the authentication hierarchy that has the least
number of authentication brokers, and management agents or clients.
In the NetBackup and CommandCentral appendixes, similar procedures are
provided for these Symantec products to replace the local root broker with a root
broker on a remote host.
Planning for authentication and authorization in your

enterprise environment
In an enterprise or data center, some Symantec products may already be deployed
with Symantec Product Authentication and Authorization Service. The objective
of this section is to describe various scenarios and the approaches to deploying
multiple Symantec products with the authentication and authorization service
enabled in those scenarios.
For a list of the Symantec products that are covered in this edition and future
Yellow Book editions, refer to the following tables.
Typical enterprise scenarios
1 An enterprise is ready to deploy its first Symantec product. Information that
is presented in this and other chapters demonstrates the approach, guidelines,
and best practices to deploy the product with authentication and authorization
service enabled.
2 Several Symantec products are already deployed in the enterprise. Some of
the Symantec products (such as SLIM and CommandCentral) have been
deployed with Symantec Product Authentication. Other Symantec products
(such as NetBackup and VCS) are also deployed in the enterprise, but have
not been activated with the authentication and authorization (NetBackup
only) service. An approach is shown in this scenario to illustrate the
integration of Symantec Product Authentication and Authorization with
NetBackup and VCS.
3 Several Symantec products have been deployed in the enterprise, but none
of the deployed Symantec products are activated with authentication or
authorization. This scenario is similar to the NetBackup and VCS products
described in the previous scenario except that the authentication hierarchy
does not exist yet.
4 An enterprise has already deployed a Symantec product that is targeted in
the current edition (such as NetBackup) and the second edition (such as the
Veritas Application Director, VAD) together. If VAD is already configured
with authentication service, the approach is to place the authentication
brokers that are needed by the management servers (such as NetBackup) in
the authentication hierarchy created by the VAD. Otherwise, a new
authentication hierarchy will be created with an authentication broker for
the NetBackup.
For all scenarios, it is important that your enterprise formulates a project plan
and transforms it into a diagram similar to the one in the following figure.
In scenario number 1, assume that you already created the diagram. Next, prioritize
the Symantec products in the order of importance with respect to your business
requirements and then install them. It is highly recommended that you install
each management server on a system by itself. You can place the root broker on
the system where the first Symantec product with a management server is
installed. If your enterprise requires that the root broker be isolated to a separate
system, you should install and configure the root broker before you install the
first management server. In the cited figure, the first Symantec product listed is
SLIM and it is installed first with a root broker plus authentication broker.
The next Symantec management servers to install are NetBackup and
CommandCentral. On the systems where NetBackup and CommandCentral are
installed, the authentication brokers on these systems should belong to the
authentication hierarchy that is created by SLIM and located on the same system
as SLIM. After you have configured a management server and verified that it
works, you can begin the management client/agent installation. The application
server (such as SF Oracle RAC) that is enabled with authentication service should
have an authentication broker configured on each node of the cluster, and should
reside in the authentication hierarchy that is configured on the system with the
SLIM. Refer to the Windows use case chapter (Chapter 7) and the product
appendixes for complete illustration.
Certain Symantec products (such as SLIM) use the authentication service for
authenticating SLIM users. The SLIM installation script automatically configures
an authentication broker. The installation script automatically configures the
root broker plus authentication broker on the system where the SLIM server is
installed.
Other Symantec products (such as NetBackup) require that the authentication

and authorization service be installed and configured separately after NetBackup
has been configured. A future version of NetBackup may change its installation
script to mimic the installation approach that is used by SLIM.
In scenario number 2, Symantec SLIM and CommandCentral management servers
are already installed and configured on separate systems. Presumably, these
management servers are enabled with the authentication service. NetBackup
management server is installed and configured on a standalone system but without
the authentication and authorization functionality. To enable the NetBackup with
authentication and authorization, refer to the NetBackup UNIX/Linux use cases
or Windows use cases.
See “NetBackup use case” on page 87.
In the UNIX/Linux use case, NetBackup uses a local root broker. In the Windows
chapter, NetBackup uses a remote root broker that is configured in an
authentication hierarchy that is created by another Symantec management server.
VCS application server is installed on a two-node cluster with SF for Oracle RAC
and the configuration did not enable authentication service. To enable the VCS
with authentication, refer to the Storage Foundation section in the UNIX/Linux
use cases chapter for instructions and procedures.
See “Storage Foundation use case” on page 143.
On Windows, to enable SFWHA with authentication service after the product is
installed, refer to the Storage Foundation section in the Windows use cases chapter.
See “Storage Foundation use case” on page 205.
In scenario number 3, start with the Symantec product that would benefit the
most from the functionality that is offered by the authentication and authorization
service. Deploy the root broker on the system where the Symantec product is
installed or on a separate system as required by the enterprise’s business decision.
An authentication broker is configured on the system that has the Symantec
product. Refer to Chapter 6 (UNIX/Linux), Chapter 7 (Windows), and appendixes
for instructions and procedures for enabling Symantec products with
authentication and authorization.
It is possible that an enterprise has configured a local root broker for each of the
Symantec management servers. For example, NetBackup, CommandCentral and
SLIM are configured with a local root broker. To consolidate all the root brokers
into one authentication hierarchy, refer to the root broker consolidation section
and the procedures listed in the NetBackup, CommandCentral, and SLIM
appendixes.
Authentication and authorization administration
For scenario number 4, refer to Chapter 6 (UNIX/Linux), Chapter 7 (Windows),

and appendixes for instructions and procedures for enabling Symantec products
with authentication and authorization.

These are the typical tasks for administrators who are responsible for managing
the Symantec Product Authentication and Authorization. The following list is not
exhaustive:
■ Ensure that the authentication and authorization products are configured
according to each product’s specifications and meet the business requirements
established for your enterprise.
■ Regularly backup the operation data that is generated by these products. Verify
that the recovered data is usable and valid.
■ Define an upgrade procedure for the authentication and authorization products.
The upgrade is determined by the compatibility between the new version of
the authentication and authorization and the existing consuming Symantec
products. The consuming Symantec products that are already configured on
a system must be able to work with the upgraded version.
■ Monitor the critical services and avoid disruption to availability either directly
(the designated authentication broker has stopped) or indirectly (the
authorization could not authenticate because the authentication broker that
is needed by the authorization service is no longer available).
Authentication administrator responsibilities

Symantec Product Authentication maintenance consists of maintaining the
authenticating clients, the root broker, and all the authentication brokers that
are deployed in the enterprise.
One of the most important duties for an authentication administrator is to ensure
that the operational data of the root and authentication brokers are backed up
regularly by using a backup schedule that is designed by the enterprise.
See “Backup and recovery of authentication and authorization” on page 77.
The authentication administrator must decide the authentication domains that
the authentication entities (such as users) should use and therefore the
authentication brokers they should contact. An authentication domain is associated
with a specific authentication plug-in. For example, an authentication broker is
configured with an authentication domain that supports the NISPLUS plug-in.
For a user on NetBackup management client to use the NISPLUS plug-in, the
NetBackup administrator should use the product configuration tool (jnbSA on
UNIX/Linux and Administrative Console on Windows) to assign the user to contact

an authentication broker that has the NISPLUS authentication domain configured.
Setting up new authentication brokers and renewing authentication broker
credentials are the responsibility of the authentication administrator.
After a root broker is configured and working, it typically requires little
maintenance other than performing regular backups. To reinstall the root broker
that has an existing authentication broker and client hierarchy requires an
elaborate recovery process. This process requires a functional configuration of
the root broker that likely must be restored from backup.
An authentication administrator must ensure that all the authentication brokers
are available to their clients all the time. An authentication broker is contacted
by clients whenever a user or an application on a client system needs to
authenticate or renew a credential.
In an enterprise, authentication and credential renewal are normally the
responsibility of the application administrators who manage the Symantec
management servers such as (NetBackup, CommandCentral, and SLIM) that are
configured with the authentication product. If the administrators for these
Symantec products are different individuals, they must work together to define
a process to address the new installation and upgrade issues especially when the
authentication product is installed on a system that is shared by a management
server and agent/client of another Symantec product.
To verify that the Symantec products are configured with authentication, refer
to the server authentication procedures listed in the NetBackup, CommandCentral,
and SLIM appendixes.
Authorization administrator responsibilities

Symantec Product Authorization maintenance consists of maintaining the
authorization server, the access control information data repository, and
authorization clients that are deployed in the enterprise.
One of the most important duties for an authorization administrator is to ensure
that the access control information data repository of the authorization service
is backed up regularly by using a backup schedule that is designed by the
enterprise. The Backup and Recovery section in this chapter has detailed
procedures for performing the backup and recovery for the authorization product.
The authorization administrator must ensure that the authorization groups,
access control list, and permission sets are defined and maintained correctly. The
authorization administrator must work with other Symantec product
administrators to ensure that the service of an authentication broker is always
available and that the service provided by the authorization product is available
to other Symantec products (such as NBU) that need it.
To verify that NetBackup is configured with authorization, refer to the NetBackup
appendix.
Platform-specific considerations
In this edition of the Yellow Book, the authentication and authorization services
are illustrated on Windows, Red Hat, Solaris, AIX, and HP-UX. Refer to the use
cases chapters for the operating system version that is used on each platform.
The installation guide distributed with the authentication and authorization
product include platform-specific information. To find out if the version of the
operating system installed on a system in your enterprise is supported by the
authentication and authorization, consult the product installation guide.
To authenticate a logon session that uses material such as user name and password,
Symantec Product Authentication Service needs an authentication plug-in that
should be available on the system or configured in the enterprise. A plug-in could
be the password security that is available on a system or the NISPLUS in the
enterprise. The authentication service supports many plug-ins that can be used
to authenticate entities (such as users). Some of these plug-ins are available on
UNIX/Linux exclusively and others are available only on Windows. Symantec
Product Authentication has a proprietary plug-in named VX and it is used
exclusively to authenticate services, daemons (processes), and clients of Symantec
products.
See “Assimilating authentication service into your enterprise” on page 46.
UNIX and Linux operating systems

Mechanisms such as NIS, NISPLUS, and UnixPWD are specific to UNIX and Linux
and will not work on Windows. In order for the Symantec Product Authentication
to use NIS or NISPLUS as the authentication plug-in, this service must be already
configured in the enterprise by the system administrator. On these platforms,
the UNIX password is the basic authentication plug-in that is available to the
Symantec Product Authentication for authenticating users. An authentication
broker uses the password mechanism that is on the same system as the broker,
and not a password file on any system.
Other plug-ins such as LDAP and GSSAPI are supported by Symantec Product
Authentication on these platforms. However, a Symantec management server
such as NetBackup must support these plug-ins before they can be used to
authenticate NetBackup users.
The setup of NISPLUS, LDAP and other mechanisms is outside the scope of this
Yellow Book. System administrators should refer to the appropriate product
documentation to configure these mechanisms and to verify that they work before
integrating these mechanisms with Symantec Product Authentication.
Windows operating system

Symantec Product Authentication supports the Windows NT (nt) plug-in. The nt
plug-in uses the Security Services Provider Interface (SSPI) on Windows. This
plug-in works with all the Symantec products that run on this platform to allow
for unified logon. On Windows, the authentication service supports LDAP and
GSSAPI.
Authentication and authorization service installation

Before you install the Symantec Product Authentication and Authorization Service
on a system, it is important that you read the appropriate Symantec product
installation guide and release notes to ensure that the system configuration meets
the operating system version and patch requirements.
The Symantec Product Authentication and Authorization Service has server and
client components. These components can be installed separately. On a system,
it is permissible to install the Client component of the Symantec Product
Authentication and Authorization. To install either the service/client or client
portion of the Symantec Product Authorization, the Authentication’s Client
component must be already installed or installed at the same time. The Symantec
Product Authorization depends on the Symantec Product Authentication. Client
installations do not require any product configuration. A system that has only
the service component is not a valid installation. The installation of the service
automatically installs the client component on most platforms. Some platforms,
such as Linux, may require the client component to be installed explicitly.
On systems that have Symantec management servers, the service and client
components of the Symantec Product Authentication are also installed. Each
management server requires an authentication broker (at the minimum) to be
configured on the local system. On systems that have either management agents
or clients, only the client component of the Symantec Product Authentication is
required.
On systems that have application servers, it is common to find either management
agents or clients (and possibly both). An application server (such as VCS) needs
an Authentication broker configured on each node of the cluster. On these systems,
application servers use the service and client components of the Symantec Product
Authentication. Management agents or clients would continue to use the client
component.
Certain management servers, such as NetBackup, use the Symantec Product

Authorization for Access Control. On a system that has this management server,
the service and client components of the Symantec Product Authorization are
installed. A NetBackup Media Server that is configured on a stand-alone system
also needs the client component of the Symantec Product Authentication and
Authorization.
When you install Symantec Product Authentication and Authorization, you should
first attend to the systems that are targeted for the management servers. Systems
that have application servers should be visited next and then followed by the
systems that have management agents and clients.
Refer to use cases chapters and follow the orders of installation illustrated for
various Symantec products.
Installing authentication service

Symantec Product Authentication can be installed in one of the following scenarios:
■ Install the root broker. The service and client components are installed. On
the same system where the root broker is installed, it is also permissible to
install an authentication broker.
■ Install an authentication broker on the system where a prominent Symantec
management server is planned. In this case, the root broker is remote on
another system. The Service and Client components are installed.
■ Install only the Symantec Product Authentication client (depending on the
Symantec application) on the system. Only the client component is installed.
Symantec Product Authentication Service (version 4.3 and later) can be configured
to use Symantec Product Private Branch Exchange (PBX). Before you enable PBX
for the authentication service, you must install and configure PBX.
Root broker installation

Installation of the Symantec Product Authentication with a root broker is usually
done by using one of the following methods:
■ Use the installation script that is distributed by the Symantec Product
Authentication to install and configure the root broker.
■ The installation script of a consuming Symantec product (such as SLIM) installs
the Symantec Product Authentication Service and configures the root broker
plus the authentication brokers.
In the version of NetBackup that is used in this Yellow Book edition, the Symantec
Product Authentication is not integrated with the NetBackup installation script.
Therefore, to prepare a system with the right brokers for NetBackup’s
implementation, the installation script distributed by the Symantec Product

Authentication must be used.
The installation script of other consuming Symantec products (such as SLIM)
install the Symantec Product Authentication Service and unconditionally configure
a root plus authentication broker on the local system. When in doubt, always refer
to the SLIM installation guide for up-to-date information. Other Symantec products
(such as NOM) have similar restrictions. Refer to the Windows use cases chapter
for installation procedures.
Authentication broker installation

The authentication broker mode installs an authentication broker on a machine
without the root broker. Select this option if a root broker is already installed
separately somewhere and there is a need to add a new authentication broker into
the existing authentication hierarchy.
Installation of the Symantec Product Authentication with an authentication broker
is usually done by using one of the following methods:
■ Use the installation script that is distributed by the Symantec Product
Authentication to install and configure an authentication broker
■ The installation script of a consuming Symantec product (such as
CommandCentral) installs the Symantec Product Authentication Service and
configures an authentication broker
In both installation methods, a remote root broker is assumed to be available and
the preparatory steps for the new authentication broker have been completed on
the system with the root broker. Refer to the use case chapters and follow the
illustrated installation procedures.
Client installation
The installation script that is distributed by the Symantec Product Authentication
is usually used to install the Authentication Client component. The Authentication
Client component can be installed without installing the service component.
The authentication client component is on systems that have either management
clients or agents.
Installing authorization service

Authorization depends on authentication. Therefore, before installing the
authorization service, the minimum requirement of the authentication service
(which is the client component) must be already installed and configured. The
authentication client component is usually present on systems that have either

management clients or agents.
The authorization service can be installed in either of the following scenarios:
■ Install the authorization service. The service and client components are
installed.
■ Install only the client (depending on the Symantec application) component on
the system.
Authorization service installation

Use the installation script that is distributed with the Symantec Product
Authorization Service to install and configure it.
The authorization service should be installed on the same machine as the
management server that needs it. Having the authorization service and
management server located on the same machine removes the overhead of network
latency that could occur if these two applications are located on two separate
systems.
The master copy of the authorization access control list repository is always found
on the system where the authorization service is configured. It is permissible for
a system with the authorization client component to keep a local copy of the access
control list repository. This setup can be established in an environment that has
a NetBackup media server that communicates securely with a master server on
two separate systems.
See “Verify authorization setup” on page 237.
Client installation
The installation script that is distributed by the authorization service should be
used to install the authorization client component. The authorization client
component can be installed without installing the service component. A system
that has the NetBackup Media server is required to install the authorization client
component.
Authentication and authorization service upgrade

All the Symantec products that are illustrated in this document use the shared
installation of the Symantec Product Authentication and Authorization Service.
A shared installation refers to a product (such as authentication or authorization)
that is installed and used by all the products.
On a system, different Symantec applications such as NetBackup management
server, SLIM management agent, and CommandCentral management agent could
be installed. Each of these Symantec applications requires a specific version of
the authentication service. Symantec products that require a later version of the
authentication service would cause the version on the system to be upgraded. In
this situation, the latest version of the authentication service should be used on
the system. On the system that already has a more recent version of the
authentication service, the installation script should skip the installation task.
Symantec Product Authentication and Authorization provide compatibility
between different versions of the product. It is permissible to have NetBackup
management server configured with Authentication version 4.2 to work with a
NetBackup management client on other systems that have Authentication version
4.3. A management agent or client with Authentication version 4.2 and a
management server that has Authentication version 4.3 is also a valid
configuration.
Authentication service upgrade

Upgrade of the authentication product is normally done through the installation
script that is distributed by using the Symantec Product Authentication Service
or one of the Symantec products.
On a system, before you upgrade the authentication service that is used by multiple
Symantec products, it is always prudent to test and verify that the new version
is compatible with all the existing consuming products before the upgrade is
performed on a production system.
The authentication service is usually installed or upgraded on a system by the
Symantec application that needs it. For example, a system has version 4.2 of
authentication service installed for the NetBackup management server. It is typical
to install other Symantec management agents or clients on a system with a
Symantec management server. The SLIM management agent uses version 4.3 of
the authentication service and installing the SLIM management agent on the
system would cause the authentication service to be upgraded from version 4.2
to 4.3.
Note: On a system that has multiple Symantec products that use authentication
service, the latest version of the authentication service should be installed. Later
versions (such as 4.3) of the authentication service are compatible with Symantec
products that were shipped with an earlier version (such as 4.2).
If the authentication service is to be upgraded on the system, the administrator

must perform the following tasks before conducting the upgrade:
■ Perform a full backup for the authentication product.
See “Backup and recovery of authentication and authorization” on page 77.
Backup and recovery of authentication and authorization
■ There should not be any authentication activities initiated from the system
while the authentication product is being upgraded. Shut down all the Symantec
applications that use the authentication service.
■ After the upgrade is complete, verify that the authentication components and
all the consuming Symantec products are working. Refer to the appropriate
product appendix in this book for detailed procedures on the verification steps.
It is important the authentication service administrator keep track of all the
Symantec products that use authentication on a system. Chapter 4 lists all the
Symantec products that are used with authentication. To determine if a Symantec
product installed on a system is enabled with authentication, refer to the respective
verification procedures provided for each Symantec product in the appendixes.
The combinations between versions 4.2 and 4.3 of the Symantec Product
Authentication Service is verified and tested in scenarios used in first edition
Yellow Book.
Authorization service upgrade

In the first edition Yellow Book, among all the consuming Symantec products that
are targeted, only NetBackup consumes the authorization service. Therefore,
during the process of upgrade, other than ensuring that the authorization service
functions correctly and that NetBackup also works with the upgraded version of
the authorization service, there is not much else to check.
Backup and recovery of authentication and

authorization
Symantec Product Authentication and Authorization has operational data that
is needed to ensure the proper working of these Symantec products. The
operational data is generated by each product over the course of its operation.
For the authentication product, operational data could be credential information
managed by the registration authority and credential manager. For the
authorization product, the access control list data repository contains a database
that stores all the permission sets. The operational data of these products needs
to be backed up regularly by using a backup schedule that is suitable to your
enterprise.
The operational data is present on systems that have the service and client
components installed and configured. The operational data of these products
needs to be backed up regularly. The backup schedules for the systems that have
the Symantec Product Authentication and Authorization should be part of the
overall backup infrastructure for your enterprise’s backup and recovery strategy.
Backup and recovery of authentication and authorization
On systems that have only the client component installed, backing up the product’s
binaries and libraries should be sufficient. It is safe to keep one backup copy of
the client component of a given product version. For example, ten systems on the
same platform have the client component of the Symantec Product Authentication
version 4.2.2.22 installed. Backing up the authentication client component from
one of these systems should be sufficient.
The backup and recovery procedures that are used in your enterprise must be
verified through a successful restore, followed by proving that the recovered data
can be used by the product. The ability to use the recovered data from a backup
is the key indicator to your backup strategy. As an example, the following steps
should be used as guide when implementing a backup and recovery strategy.
See “Successful NetBackup backup and restore” on page 269.
■ Authentication and authorization products are installed and configured on a
system.
■ A full backup for these products has been taken.
■ Shut down the original system and build another system (on the same platform
and operating system) with the same host name.
■ Recover the backup to the new system.
■ Verify that the services that were hosted in the original system are now
available through the new system.
Keeping track of all the systems in production environment that have

authentication and authorization products is a manual process. Administrators
who are responsible for these Symantec products should take charge and verify
that the critical components on all of these systems are being backed up.
Authentication data
On systems that have the root broker and authentication brokers, the operational
data, service and client components should be backed up. The authentication
product binaries and libraries should be included as part of the backup as well.
The operational data that is used by the root broker includes the registration
information, private domain repositories, and credential stores. Each
authentication broker also has operational data (which includes the private domain
repositories that are created by the Symantec application servers). Backup of this
data must be performed on a regular basis on all the systems that have the
authentication brokers.
It is important to keep track of all the production systems in your enterprise that
have the root broker and authentication brokers. To help with maintenance and
Empirical use cases
administration, keep an up-to-date topology layout of all the systems in your

enterprise similar to that shown in the following figure.
There could be other applications on the same systems that need backup. Refer
to the following section for the actual steps and backup application to use.
See “Backup and restore authentication data” on page 239.
Authorization data
On the systems that have the authorization service, the access control list
repository and client components should be backed up. The authorization product
binaries and libraries should be included as part of the backup as well.
It is important to keep track of all the production systems in your enterprise that
have the authorization service. Keeping an up-to-date topology layout of all the
systems in your enterprise should help in maintenance and administration.
There could be other applications on the same systems that need backup. Refer
to the following section for the actual steps and backup application to use.
See “Backup and restore authorization data” on page 241.
Empirical use cases

To support the guidelines and best practices described in this chapter, deployment
scenarios are transformed into use cases that have been tested and verified in the
Symantec’s product testing lab. These use cases have been tried on both
UNIX/Linux and Windows platforms. Important procedures pertaining to the
integration of the Symantec Product Authentication and Authorization and the
consuming Symantec products are described in the UNIX/Linux and Windows
use cases chapters, respectively.
UNIX/Linux use cases

The UNIX/Linux use case chapter is for enterprises that have the majority of their
Symantec products deployed on UNIX/Linux platforms (Solaris, AIX, HP-UX, and
Red Hat). The Symantec application server, management server, and management
agent/client are validated on one of these UNIX/Linux platforms successfully. It
is a common occurrence to have both UNIX/Linux and Windows platforms in an
enterprise. To make the test environment more realistic and resemble a real
environment in an enterprise, the application server, management agent/client,
and NetBackup Media server on Windows are added to this test environment. In
Product troubleshooting tips
the UNIX/Linux use cases chapter, the documented procedures are applicable to
all the UNIX/Linux platforms unless otherwise noted.
Windows use cases

The Windows use cases chapter is targeted for enterprises that have chosen
Windows as their primary deployment platform. The application server,
management server, and management agent/client are validated on the Windows
platform. For enterprises that have mixed platforms, the use cases in this chapter
also include the Symantec products that are deployed on UNIX/Linux platforms.
The application server, management agent/client, and NetBackup Media server
that are deployed on UNIX/Linux are managed by the management servers on
Windows. The document procedures that are listed for the UNIX/Linux use cases
apply to other UNIX/Linux platforms (Solaris, AIX, HP-UX, Red Hat) unless
otherwise noted.
How to use the use cases

In the use cases chapters, beside the Symantec Product Authentication and
Authorization, the approach is to deploy one Symantec product at a time. All the
Symantec products that are illustrated can be deployed independently of each
other. The ultimate goal is to demonstrate an environment that has all of the
Symantec products installed and configured together with the authentication and
authorization enabled.
The information presented in the use cases chapters can best be used to guide an
application administrator to do the following:
■ Enable the authentication and authorization capabilities for an already installed
Symantec product (such as NetBackup).
■ Install and configure a new Symantec product into an existing enterprise
environment with the authentication and authorization capabilities enabled.
Some of the Symantec products in the existing enterprise environment may
have the authentication and authorization already configured.

In the last section of this document, there are appendixes devoted to an individual
or group of Symantec products. The information in the appendixes includes the
verification steps for Symantec products that are configured with authentication
and authorization, relocating the root broker, authentication operating procedures,
and troubleshooting tips.
All the Symantec products that are covered in this Yellow Book edition have been
qualified on UNIX/Linux and Windows platforms. Platform specific information
is available in the product appendixex.
Chapter 6
Symantec solution:
UNIX/Linux use cases
■ Deploy Symantec products on UNIX/Linux
■ NetBackup use case
■ CommandCentral Storage and Service use case
■ Symantec License Inventory Manager use case
■ Storage Foundation use case
Deploy Symantec products on UNIX/Linux

In this use case, a predominantly UNIX/Linux-based enterprise has purchased
the following Symantec products to meet the growing demands of the company’s
computing capacity and capability:
■ NetBackup
■ CommandCentral Storage and Service
■ Storage Foundation for Oracle and Storage Foundation for Oracle RAC
Included with the purchase were Symantec core services products, such as Private
Branch Exchange, Symantec Product Authentication Service and Symantec Product
Authorization Service, and Common Core Services. One or more of these core
services products are used by the Symantec products listed above. After being
installed on a system, these core services products are shared by any Symantec
products that need them.
84 Symantec solution: UNIX/Linux use cases
See “Multiproduct deployment approach” on page 51.

Figure 6-1 shows the deployment of Symantec products on Unix and Linux
platforms.
Figure 6-1 Deployment of Symantec Products on Unix/Linux
The approach chosen by the implementation team is to deploy these Symantec

products to their enterprise data center in three major phases. A new management
Symantec solution: UNIX/Linux use cases 85
server and the accompanying application server, and management agents or

clients are added in each phase.
The enterprise is also security conscious and the corporate security architect
decided to implement these Symantec products with authentication or
authorization. To help the enterprise security architect and security
implementation team achieve the objectives listed in the Customer Benefits section
in Chapter 1, this chapter provides step-by-step instructions on how to individually
configure these Symantec products with authentication and authorization
capabilities.
See Determine broker infrastructure for details on the layout for the authentication
brokers.
Determine broker infrastructure

Before starting the implementation, the enterprise security team developed the
broker schema and laid the foundation for the root and authentication brokers.
All the management servers listed in Figure 6-1 need an authentication broker
configured on the systems where the management servers are located.
Using the deployment guidelines and best practices discussed in Multiproduct
deployment approach, the enterprise security team maps the Symantec products
previously listed products into the authentication hierarchy listed in the following
figures.
Figure 6-2 shows the placement of root and authentication brokers on Unix/Linux.
Figure 6-2 Placement of root and authentication brokers on Unix/Linux
The information depicted in the previous figure is used to guide the

implementation team on the deployment of the Symantec products that are
enabled with authentication and authorization. In this environment, only one
authentication hierarchy is set up. The authentication root broker is installed and
configured on the same system as the NetBackup management server. All the
management servers (such as NetBackup, SLIM, and CommandCentral) are installed
and configured on separate systems with respective authentication brokers. After
NetBackup use case
the root broker is configured, the authentication broker can be configured on

other management servers in any order. In this use case, the CommandCentral,
SLIM, and Storage Foundation servers are configured sequentially. The following
use cases serve as templates with which you can compare your environment and
then implement the appropriate authentication solution. The basic sequence in
which you install each of these Symantec products does not vary by use case. Only
the individual tasks that are required to configure these Symantec products for
each use case vary. Refer to the following figure for an example use case.
NetBackup use case

Figure 6-3 shows the deploying NetBackup management servers and client.
Figure 6-3 Deploying NetBackup management servers and client
NetBackup uses the authentication mechanism that is provided by the Symantec

Product Authentication Service to authenticate ordinary users who access the
NetBackup subsystems. After obtaining valid authentication credentials, ordinary
users are then permitted to perform product management through the product
administrative Web console and execute privileged NetBackup commands from
the command line. One or more Authentication brokers are set up with the
appropriate plug-ins to authenticate NetBackup users (including the administrator)
and services (NetBackup media servers and clients). The Authorization service is
also set up on the system where the NetBackup master server is configured. After
a user has acquired a valid authentication credential, the access control
functionality that is provided by the Symantec Product Authorization is used to
NetBackup use case
decide the operations (examples are policies and storage-units manipulation) that
an ordinary user is permitted to do.
Typically, these Symantec products are installed on the system in the following
order:
■ Storage Foundation
■ Infrastructure Core Services (Private Branch Exchange, Symantec Product
Authentication and Symantec Product Authorization). Authentication and
authorization products are required to enable NetBackup Access Control
■ Management agents from other Symantec products (such as CommandCentral
or the Symantec License Inventory Manager)
NetBackup provides backup and recovery services for the systems that are deployed
throughout the enterprise that have valuable data on them. NetBackup has
management servers (master and media) and management client (or simply client)
components. A NetBackup policy is configured on the Master server for a client
that has data to be backed up. A backup is usually initiated from the master server.
During the backup, a client reads the data from the system and sends it to the
media server which stores it to a storage unit for safe keeping. Usually, a
NetBackup management client is deployed on the systems that have SLIM,
CommandCentral, Storage Foundation and other Symantec products installed.
It is highly recommended that you install and configure NetBackup and the
NetBackup Operations Manager (NOM) master management server on a system
reserved exclusively for this management server. After the master server is
configured, the installation of media management servers can proceed. NetBackup
management clients are usually installed last. To verify that the setup is functional,
initiate a backup from the master server for a client by using one of the media
servers and restore the backup to a different client.
On the system that has the NetBackup master management server, an
authentication broker and the authorization service are also configured. Additional
authentication brokers may be required and configured on systems with media
servers. Typically, each authentication broker is configured for an authentication
domain with specific plug-in. When adding new authentication brokers to an
existing authentication hierarchy, extra preparatory steps must be performed for
these brokers from the system with the existing root broker.
Unlike other Symantec products, configuring NetBackup and enabling NetBackup
with Access Control (authentication and authorization) require two separate
configuration procedures. Access Control is added to NetBackup after the
NetBackup use case
management servers (master and media) and management clients have been
configured and functional.
A large enterprise may need multiple NetBackup master servers configured for
different backup and recovery purposes. Procedures and configuration instructions
that are provided here for NetBackup can be repeated when you add new NetBackup
management servers (master and media) and clients with Access Control.
Deployment platforms and operating systems

In this use case chapter, procedures primarily use Solaris as the platform on which
NetBackup management servers (master and media) and clients are deployed and
verified. However, the NetBackup master management server also manages
NetBackup media management servers and management clients that are
configured on AIX and Windows operating systems.
Application server
On UNIX/Linux platforms, the binaries and data files for the NetBackup media
servers and agents are installed in the /usr/openv directory. The /usr/openv
directory is typically a mount point for a VxFS file system that is created on a
Veritas Volume Manager volume. VxFS and Volume Manager are distributed
through the Symantec application server products such as Storage Foundation,
Storage Foundation Cluster File System, or Storage Foundation for Oracle RAC.
Typically, the Symantec Storage Foundation application server is also installed
on the system.
See “Common Veritas Volume Manager and Veritas File System procedures”
on page 222.
NetBackup management servers

The versions of NetBackup and the shared infrastructure core services components
NetBackup depends on are listed in the tables depicted in the Master and Media
sections, respectively. Starting from NetBackup version 6.0 release, before you
install NetBackup on a system with either a master or a media server, you must
install and configure the Private Branch Exchange (PBX). Prior to configuring
either master or media server for access control (enable authentication and
authorization), the Symantec Product Authentication and Authorization must
also be installed on the system. On a system that has the NetBackup master
management server, it is preferable to have a local authentication broker and
authorization service configured. On a system with a NetBackup media
NetBackup use case
management server, only the client portion of the Symantec Product

Authentication and Authorization is required.
To add a master server to an enterprise or add a new media server to an existing
master server, you can repeat the procedures in this section on each new system.
Master server
It is highly recommended that the NetBackup master server gets installed on a
system that merely has this management server active and running. The following
table shows the specific version of the common core service (PBX) that is used by
the NetBackup master server.
Table 6-1 explains NetBackup master server dependency on Private Branch
Exchange.
Table 6-1 NetBackup master server dependency on Private Branch Exchange
NetBackup Private Branch Exchange
1.2 1.3
6.0MP4
The following procedure illustrates the installation of a NetBackup 6.0 master

management server on Sun hardware that runs the Solaris 9 operating system.
This master management server also manages NetBackup media servers and
clients that are configured on Windows, Solaris, and AIX. A valid product license
key is required to install the NetBackup master management server and the key
must be entered during the NetBackup installation.
The NetBackup installer checks for the presence of the PBX shared component
and verifies that the PBX service is started. For PBX installation instructions, refer
to the following section.
See “Installing and configuring Private Branch Exchange” on page 226.
The NetBackup installer does not configure authentication or authorization. The
system should already have a Storage Foundation product installed and configured.
NetBackup use case
To install and configure a NetBackup master management server on Solaris

1 Log on to the system where you will install the NetBackup master management
server (neptune.universe.com). Using the instructions described earlier in
the Application server section, prepare a Veritas file system and mount it at
the /usr/openv directory. It may also be necessary to create another Veritas
file system and mount it at /neptune-disk as storage unit for storing the
backup images.
2 Invoke the install script to install the NetBackup master management server.
The NetBackup installation files can be accessed through a mount point, in
a local or CD/DVD file system. Refer to the NetBackup UNIX/Linux installation
guide for instructions on how to access installation files through CD/DVD
distribution media.
# cd /
# ls <mnt>/NB_60_Solaris_20050906a
install* solaris/
# <mnt>/NB_60_Solaris_20050906a/install
Installing NetBackup Server Software

Do you wish to continue? [y,n] (y)
Enter license key: <NetBackup Master management server keys>
Would you like to use "neptune.universe.com" as the

configured name of the NetBackup server? [y,n] (y) y
Is neptune.universe.com the master server? [y,n] (y)

Do you have any media servers? [y,n] (n) n
Enter the Enterprise Media Manager server
(default: neptune.universe.com):
Do you want to start the NetBackup bprd process so

backups and restores can be initiated? [y,n] (y)
File /usr/openv/tmp/install_trace.22417 contains a

trace of this install. That file can be deleted after
you are sure the install was successful.
NetBackup use case
3 To prepare for the push installation, install the client binaries of the platforms
that are deployed on management clients. For example, management clients
are deployed on Solaris and AIX. So, choose RS6000 and Solaris clients and
install these binaries on the master management server.
# cd <mnt>/NB_60_CLIENTS_20050906a
# ./install
Installing NetBackup Client Software
RS6000
Solaris
Is this the list you wish to use? [y,n] (y)
# cd /usr/openv/netbackup/client
# ls
Solaris/ RS6000/
# cat /usr/openv/netbackup/bin/version
NetBackup-Solaris9 6.0GA
4 To install the Add-On options, invoke the respective NetBackup install script
to install the additional options.
5 Verify that the NetBackup and the Private Branch Exchange processes are
running.
# /usr/openv/netbackup/bin/bpps -x
6 To configure various subsystems within the NetBackup product, launch the

jnbSA GUI tool and use the Getting Started wizard as a guide to the setup.
# /usr/openv/netbackup/bin/jnbSA -d <display> \
-l /tmp/jnbSA.log.1 -lc &
7 On the Veritas NetBackup jnbSA Console, Activity Monitor, select Services

and Processes to verify that the services and NetBackup processes are online.
8 Verify that the operating system can see the tape libraries and devices on a
system.
See “NetBackup tape device drivers” on page 273.
9 Create a storage unit and policy on the master management server.
See “NetBackup storage units” on page 267.
See “NetBackup policies” on page 268.
NetBackup use case
The NetBackup software on the master management server is usually the first
NetBackup system to be upgraded.
To upgrade a NetBackup master management server on Solaris
1 Before upgrading the NetBackup master server software, stop the NetBackup
management server. Use the following commands to stop and start NetBackup
master management server:
# /usr/openv/netbackup/bin/goodies/netbackup stop
# /usr/openv/netbackup/bin/goodies/netbackup start
2 Log in to the master management server and change to the directory with
the NetBackup maintenance pack distribution:
# cd /usr/openv/tmp/60_4_M
3 List the contents of the directory as follows:
# ls
...
VrtsNB_CLT_60_4_M.tar.Z
VrtsNB_60_4_M.solaris.tar.Z
VrtsNB_JAV_60_4_M.tar.Z
4 The maintenance pack is typically in tar format. Extract the tar files in a
directory and specify the pack to install. Specifying NB_CLT_60_4_M
automatically upgrades the server (NB_60_4_M) before the client.
# ./Vrts_pack.install
There are 3 packs available in /usr/openv/tmp/60_4_M:
(* denotes installed pack)
NB_60_4_M
NB_CLT_60_4_M
NB_JAV_60_4_M
Enter pack name (or q) [q]: NB_CLT_60_4_M
NetBackup use case
5 After the upgrade completes, verify that the NetBackup master management
server was upgraded. Start the NetBackup master management server if it
has not being started.
NetBackup-Solaris9 6.0MP4
6 If the NBAC was enabled on the master management server, after upgrading
NetBackup, the Verify NetBackup access control setup on the master server
procedure listed in Appendix C should be used to ensure the master
management server is working.
On the system that has the NetBackup master management server configured,
management agents of other Management Servers could be deployed. These
agents may or may not have the authentication enabled. As an example, SLIM
and CommandCentral Service Agents are likely to be found on the same
system as the NetBackup master management server.
Media servers
The NetBackup media management server is dependent on the service provided
by the Private Branch Exchange (PBX), and the service provided by this shared
component must be online before you install the NetBackup media management
server. The following table depicts the version of NetBackup and the version of
the PBX shared component that is currently used by the NetBackup media server.
Table 6-2 explains NetBackup media server dependency on Private Branch
Exchange.
Table 6-2 NetBackup media server dependency on Private Branch Exchange
1.2 1.3
6.0MP4
Before installing NetBackup media management servers, it is assumed that the

NetBackup master management server was already configured and is functioning.
In this setup, a media management server is configured on AIX, Solaris, and
Windows, respectively, for the NetBackup master management server that is
configured on Solaris. Having multiple media servers in an enterprise allows many
backup or recovery jobs to occur concurrently. Typically, a media management
server is assigned to the management client on the same platform—an AIX client
NetBackup use case
interacting with a media server on AIX. It is a supported configuration to have

management clients on Windows interacting with media management server
configured on Solaris platform.
This installation session illustrates the installation for NetBackup 6.0 on an AIX
5.3 operating system. A maintenance pack is then applied on top of the 6.0 release
to upgrade NetBackup to a later version. You can use this procedure to install
media management server on other UNIX/Linux platforms.
To install and configure a NetBackup media management server on Solaris
1 Log on to the system (triton.universe.com) where the NetBackup media
management server would be installed. Using the instructions described
earlier in the Application server section, prepare a Veritas file system and
mount it at the /usr/openv directory. It may also be necessary to create
another Veritas file system and mount it at /triton-disk as storage unit for
storing the backup images.
2 Invoke the install script to install the NetBackup media management server.
The NetBackup installation files could be accessed through a mount point,
either a local or CD/DVD file system. Refer to the NetBackup UNIX/Linux
installation guide for instructions on how to access installation files through
CD/DVD distribution media.
# cd /
# ls <mnt>/NB_60_AIX_Tru64_20050906a
alpha_5/ install* rs6000/
# <mnt>/NB_60_AIX_Tru64_20050906a/install
Installing NetBackup Server Software
Enter license key: <NetBackup Master/Media management server keys>
Would you like to use "triton.universe.com" as the configured

name of the NetBackup server? [y,n] (y) y
Is triton.universe.com the master server? [y,n] (y) n

What is the fully qualified name of the master server?
neptune.universe.com
Enter the Enterprise Media Manager server
(default: neptune.universe.com):
File /usr/openv/tmp/install_trace.1918 contains a

trace of this install. That file can be deleted after
you are sure the install was successful.
NetBackup use case
3 Add the following line to the AIX platform /etc/inittab file:
veritas:2:wait:/etc/rc.veritas.aixscript
4 Verify that the NetBackup and the Private Branch Exchange processes are
running.
5 On the Veritas NetBackup jnbSA Console, Activity Monitor, select Services

and Processes, and then verify that the services and NetBackup processes
are online.
6 To configure storage devices for a media server, use the Configure Storage
Devices wizard on the master management server.
7 Before performing the Storage Devices configuration for the media
management server, the physical devices must be already connected to the
system with the media server. Verify that the operating system can see the
tape libraries and devices on a system.
See “NetBackup tape device drivers” on page 273.
8 Create a storage unit for the media management server.
9 After the installation is complete, verify that the bp.conf configuration file
on the media management server is correct.
# cat /usr/openv/netbackup/bp.conf
SERVER = neptune.universe.com
SERVER = triton.universe.com
CLIENT_NAME = triton.universe.com
EMMSERVER = neptune.universe.com
10 To upgrade NetBackup on a system with media management server, the same

upgrade procedure that is used in the Master server section should be used.
The NetBackup software on a media management server is upgraded after
the master management server has been upgraded. If the NBAC was enabled
on a media management server, after upgrading the NetBackup software, the
Verify NetBackup access control setup on media servers procedure listed in
Appendix C should be used to ensure the media management server is working.
Refer to the corresponding NetBackup use case section in Chapter 7 for
procedures and steps to install and configure NetBackup media management
servers on Windows platforms.
NetBackup use case
Add a media server to a master server

This step is to be performed on the system where the NetBackup master
management server is configured. The host to be added as the media management
server should have the NetBackup media server software installed already.
On the NetBackup Administration Console, go to the NetBackup Management,
Host Properties, Master Server. Highlight the master server, right click and choose
properties. When the Master Server Properties: neptune.universe.com screen
appears, click the Servers Properties, and then click Add. In the Add a new server:
field, enter the host name of the new media server triton.universe.com (an AIX
system), and then click Add. This procedure is used to add either a Windows or
UNIX/Linux (such as Solaris or Red Hat) media server on a UNIX/Linux master
server.
On the NetBackup Administration Console, launch the Configure Storage Devices
wizard to configure devices and storage unit for the new media management
server (triton.universe.com).
The addition of a NetBackup 5.1MP6 (or later) media server to a NetBackup 6.0MP4
(or any 6.0 version) master server is a supported configuration.
NetBackup management client

The NetBackup Management Client does not depend on the Private Branch
Exchange shared component. On UNIX/Linux, to install the NetBackup
management client and add it to a master management server, follow these
procedures and steps.
During the installation of the NetBackup master or media management server,
management client binaries of the platforms that are deployed in the enterprise
are usually installed on the system. In this setup, NetBackup client software is
installed on the management client systems through the push install utility that
is provided by NetBackup.
NetBackup use case
To install a NetBackup client on a management client system

1 Verify that the NetBackup client software is installed on the NetBackup
management server (either master or media). In this setup, the push install
is initiated from the master management server. This installation session
illustrates the push installation for NetBackup 6.0MP4 release.
2 Log on to the system (bianca.universe.com) where the NetBackup
management client would be installed, create a Veritas file system, and then
mount it on the /usr/openv directory. You can extend the size of the file
system while the file system is mounted.
See “Common Veritas Volume Manager and Veritas File System procedures”
on page 222.
Temporarily insert a line “+ +” in the ~root/.rhosts file on the system of
the management client to facilitate the push install. After the push install is
complete, remove the “+ +” line that you added to the .rhosts file.
3 Log on to the system with the master management server, create a NetBackup
policy, and then add the host name of the management client. A management
client must be present in a NetBackup policy for the push install to work.
Navigate to the /usr/openv/netbackup/bin directory. This directory is where
the NetBackup push installation script is located. To push the NetBackup
client binaries from the master (neptune.universe.com) to a Solaris
management client (bianca.universe.com), run the following script:
# install_client_files rsh bianca.universe.com
4 Log on to the system with the management client (bianca.universe.com)

and verify the content of the bp.conf file.
SERVER = oberon.universe.com
CLIENT_NAME = bianca.universe.com
Typically, the NetBackup software on a management client is upgraded after the

master and media management servers that are associated with this management
client have been upgraded.
NetBackup use case
To upgrade a NetBackup client on a management client system

1 The push install facility that is available in NetBackup is used to perform the
upgrade of the NetBackup software on a management client. Assume the new
NetBackup maintenance client software has been installed on the system
that has the master management server.
2 Log on to the system of the NetBackup management client. Temporarily insert
the line “+ +” into the ~root/.rhosts file on the system of the management
client to facilitate the push install. After the push install is complete, remove
the “+ +” line that you added to the .rhosts file.
3 Log on to the system with the NetBackup master management server. Assume
that the host name of the management client is in a NetBackup policy.
# /usr/openv/netbackup/bin/admincmd/bpplclients
Hardware OS Client
---------- ------------ --------------
Solaris Solaris9 bianca.universe.com
# echo 'Solaris Solaris9 bianca.universe.com' > /tmp/sc
4 Navigate to the /usr/openv/netbackup/bin directory where the NetBackup

push installation file is located. To upgrade the NetBackup client binaries
from the master (neptune.universe.com) to a Solaris management client
(bianca.universe.com), run the following script:
/usr/openv/netbackup/bin# update_clients \
-Install_Client_Bins -ClientList /tmp/sc
5 Log on to the system with the management client (bianca.universe.com)

and verify the new version of the NetBackup client software.
Refer to the corresponding NetBackup use case section for procedures to install
and configure a NetBackup management client on Windows.
Enable access control on a NetBackup master server

Before you enable NetBackup with Access Control (NBAC), it is a prerequisite to
have the master management server (and possibly all the media and client) set
up and operational. To verify that the NetBackup configuration is working, a
NetBackup use case
successful backup and restore initiated from the master for a client by using a
specific media server should be a good indicator.
For the backup and restore procedures, refer to the Successful NetBackup backup
and restore section in Appendix C for details. This approach is helpful in terms
of fault isolation. For example, if backup and restore work fine without the NBAC,
but fail to work with NBAC enabled, then the troubleshooting effort should be
directed at the NBAC configuration.
The following table shows the specific version of the common core services
(authentication and authorization) that are used by the NetBackup master
management server.
Table 6-3 explains NetBackup master server dependency on authentication and
authorization.
Table 6-3 NetBackup master server dependency on authentication and

authorization
NetBackup Authentication service Authorization service
4.1 4.2 4.3 4.1 4.2 4.3
6.0MP4
Other Management Agents, such as CommandCentral Storage and Service, that

are installed on the same system as the master management server can be enabled
with authentication and use the same common core services components.
To set up the NBAC functionality on the master management server, the following
procedures have been tested and proven to work with the configuration that is
described in this use case chapter. The first portion of the procedures is done from
the command line. The jnbSA console is used to complete the second portion of
the setup.
NetBackup use case
To enable Access Control on a NetBackup master server

1 A NetBackup master management server has been installed and configured
on a UNIX system (neptune.universe.com) running the Solaris 9 operating
system. Procedures are provided to enable the NBAC on the master
management server. These procedures can be used for adding master
management servers on other UNIX/Linux platforms.
2 Install and configure the authentication and authorization products on the
system that has the master management server.
In this configuration, a root plus authentication broker is configured on the
system that has the NetBackup master management server. Authentication
brokers for other management servers should be created in this authentication
hierarchy. Refer to the Install and configure authentication section in
Appendix B for the installation procedures.
On the system where the NetBackup master management server is installed,
the authorization server is configured also. The authorization product should
be installed after the authentication product. To install the authorization
product, refer to the Install and configure authorization section in Appendix
B for the installation procedures.
NetBackup use case
3 Create the authentication domain, NBU_Machines, for the NetBackup

management server. Suppose the NetBackup master management server is
configured on system neptune.universe.com with the Solaris 9 operating
system.
# /usr/openv/netbackup/bin/bpnbat -addmachine
Does this machine use Dynamic Host
Configuration Protocol (DHCP)? (y/n) n
Authentication Broker: neptune.universe.com
Authentication port[ Enter = default]:
Machine Name: neptune.universe.com
Password: <pick a password for neptune>
Operation completed successfully.
# /opt/VRTSat/bin/vssat listpd --pdrtype ab

Domain Name NBU_Machines@neptune.universe.com
# /opt/VRTSat/bin/vssat listpdprincipals \
--pdrtype ab \
--domain NBU_Machines@neptune.universe.com
Principal Name: admin
Principal Name: neptune.universe.com
# /usr/openv/netbackup/bin/bpnbat -ShowMachines
NetBackup use case
4 Obtain a valid credential for the master management server.
# /usr/openv/netbackup/bin/bpnbat -loginmachine
Machine Name: neptune.universe.com
# /usr/openv/netbackup/bin/bpnbat -whoami -cf \

/usr/openv/var/vxss/credentials/neptune.universe.com
Name: neptune.universe.com
Domain: NBU_Machines@neptune.universe.com
Issued by: /CN=broker/OU=root@neptune.universe.com/O=vx
Expiry Date: Dec 7 19:46:51 2007 GMT
Authentication method: VERITAS Private Security
NetBackup use case
5 Create a user at the operating system level to set up the security. To create
a group and user on Solaris and HP-UX, execute the following commands.
AIX has mkgroup and mkuser. Red Hat has lgroupadd and luseradd.
# groupadd vxss
# useradd -u 35004 -g vxss -d /usr/vxss -m \
-s /bin/ksh -c "VxSS" vxss
# passwd -r files vxss
New Password:<vxss password>
# /usr/openv/netbackup/bin/admincmd/bpnbaz \
-SetupSecurity neptune.universe.com \
-Server neptune.universe.com
Please enter the login information for the first Security
Administrator other than root/Administrator. This identity
will be added to the security administrators group
(NBU_Security Admin), and to the netbackup administrators
group (NBU_Admin). It will also be used to build the initial
security information.

Authentication type (NIS, NIS+, NT, vx, unixpwd): unixpwd
Domain: neptune.universe.com
Login Name: vxss
Password: <vxss password>
Processing - please be patient
NetBackup use case
6 The Domain is derived from the Authentication type. To find the Domain for
unixpwd Authentication type, use the following command.
# /opt/VRTSat/bin/vssat showallbrokerdomains
Broker Name: neptune.universe.com
Broker Port: 2821
Domain Name: neptune.universe.com
Domain Type: unixpwd
**************************************
Broker Port: 2821
Domain Name: universe.com.
Domain Type: nisplus
7 Add the master management server as the host that is authorized to perform
Authorization check.
-AllowAuthorization neptune.universe.com \
-server neptune.universe.com
# /usr/openv/netbackup/bin/admincmd/bpnbaz -ShowAuthorizers
Type: User
Domain Type: vx
Domain:NBU_Machines@neptune.universe.com
Enable Access Control from the NetBackup Administration Console

1 To start the second portion of the NBAC configuration, invoke the jnbSA GUI
administrative tool and login as user root.
# /usr/openv/netbackup/bin/jnbSA -d <disdplay> \
-l /tmp/log.1 -lc &
2 Expand the Host Properties and click the Master Servers, and then select
neptune.universe.com as the master server by clicking the host. In the Status
column, it should show Connected. Click Actions (at the top) and select
Properties... On the Properties… screen, select the Access Control (third from
the bottom). In the Veritas Security Services (VxSS) box, choose Automatic
(others are Required and Prohibit).
See “NetBackup access control parameters” on page 243.
NetBackup use case
3 On the Authentication Domains tab, click Add and a dialog box appears. Enter
neptune.universe.com as the Domain: and choose UNIXPWD as the
Authentication Mechanism. In the Broker: field, enter neptune.universe.com
as the authentication broker and a description for this Authentication Domain.
Click Add to insert the authentication domain. As the authentication
mechanism, unixpwd is always available on UNIX/Linux systems. The
authentication broker resides on the system neptune.universe.com. To add
another authentication domain that uses NISPLUS plug-in, enter the domain
name universe.com. in the Domain, NIS+ in the Authentication Mechanism,
and neptune.universe.com in the Broker: field. Repeat this procedure for
each authentication domain supported in the enterprise.
4 On the Authorization Service tab, in the Host field, enter
neptune.universe.com. The authorization server is configured on the system
that is entered in the Host: field. Save the changes, and then exit the jnbSA.
5 For the changes to take effect, stop and start the NetBackup master
management server.
NetBackup use case
6 Add the vxss and root users to the privileged NetBackup security groups –
NBU_Security Admin and NBU_Admin. Without adding these users to these
privileged groups, when logging in to the jnbSA as these users, only the client
privilege is accessible. To execute bpnbaz -adduser, a valid session must be
acquired by first running the bpnbat -login command.
# /usr/openv/netbackup/bin/bpnbat -login
Login Name: root
# /usr/openv/netbackup/bin/bpnbat -whoami
Name: root
Authentication method: UNIX passwd
-adduser "NBU_Security Admin" \
unixpwd:neptune.universe.com:root
-adduser "NBU_Admin" \
unixpwd:neptune.universe.com:root
-adduser "NBU_Admin" unixpwd:neptune.universe.com:vxss
Operation completed successfully
NetBackup use case
7 Use the procedures listed in the NetBackup access control setup verification
on the master server section in Appendix C to verify that the NetBackup
master management server is set up correctly. The NetBackup and
Authorization section in Appendix C has instructions on how to grant
NetBackup administrator privileges to ordinary users such as vxss. Without
bpnbat -login, operations that attempt to access the NetBackup subsystems
fail with the following error message:
# /usr/openv/netbackup/bin/admincmd/bpnbaz -listgroups
Supplied credential is expired or incorrect.
Please reauthenticate and try again. (25)
8 Invoke the jnbSA and login as user vxss or root. To verify a user’s credential,
within jnbSA, click Help (at the top), and then click Current NBAC User. For
NetBackup access control troubleshooting tips, refer to the following section.
See “NetBackup access control troubleshooting tips and messages” on page 275.
Enable access control on a NetBackup media server

Before attempting to enable the NetBackup Access Control (NBAC) on a media
management server, it is a prerequisite to have the media management server,
the master that manages this media server and all the clients that use this media
server, set up and operational. To verify that the NetBackup configuration is
working, a successful backup and restore initiated from the master for a client by
using this media server should be a good indicator. For the backup and restore
procedures, refer to the Successful NetBackup backups and restores section in
Appendix C for details. This approach is helpful when comes to fault isolation.
For example, if the backup and restore by using this media server works fine
without the NBAC, but failed to work with NBAC enabled, then the troubleshooting
effort should be directed at the NBAC configuration.
The following table shows the specific version of the common core services
(authentication and authorization) that are used by the NetBackup media
management server.
Table 6-4 explains NetBackup media server dependency on authentication and
authorization.
NetBackup use case
Table 6-4 NetBackup media server dependency on authentication and

authorization
NetBackup Authentication client Authorization client
4.1 4.2 4.3 4.1 4.2 4.3
6.0MP4
Other Management Agents, such as CommandCentral Storage and SLIM, that are
installed on the same system as the media management server can be enabled
with authentication and use the same common core services components.
On the system that has a NetBackup media management server configured, the
media server needs the client portion of the authentication and authorization
software to be installed. However, the following situationswould require an
authentication broker to be configured on the system that has a NetBackup media
management server. Even though an authentication broker is available locally,
the NetBackup media management server must be authenticated by a remote
authentication broker configured on the system where the master management
server resides.
In this setup, the NetBackup master management server is configured on Solaris.
One of the master's media management servers is configured on Windows. A
media server can back up the management clients on platforms that are the same
or different than itself. The Windows media server is used to back up NetBackup
management clients that are deployed on Windows. To authenticate users on a
Windows management client by using the WINDOWS plug-in, an authentication
broker with the WINDOWS domain type must be set up. Ideally, this authentication
broker should be set up on the Windows system where the media management
server is configured. Similarly, on other UNIX/Linux systems that have media
management servers, authentication brokers can be set up with specific plug-ins
to authenticate the users that reside on various UNIX/Linux management clients.
See “Installing and configuring authentication” on page 229.
See “Add a new authentication broker” on page 238.
In this setup, the NetBackup master management server has media management
servers deployed on Windows, Solaris, and AIX operating systems. The Solaris
media management server uses the authentication broker that is configured on
the master management server (neptune.universe.com). Another management
agent, such as CommandCentral, is installed on the same system as the Solaris
media management server. A local authentication broker may be configured to
authenticate the CommandCentral users that reside on the Solaris system. In this
scenario, the NetBackup media management server on Solaris uses the remote
NetBackup use case
authentication broker on neptune.universe.com and not the local authentication

broker.
To set up the NBAC functionality on the media management server, the following
procedures have been tested and proven to work with the configuration that is
described in this use case chapter. The first portion of the procedures is done from
the command line. The NetBackup jnbSA is used to complete the second portion
of the setup. Some of the steps described here will have to be done on the system
with the master management server.
To enable Access Control on a media management server
1 A NetBackup media management server has been installed and configured
on a UNIX system (triton.universe.com) running AIX 5.3 operating system.
This media server is associated with the master management server that is
configured on a UNIX system (neptune.universe.com) that runs the Solaris
9 operating system. Procedures are provided to enable the NBAC on the media
management server. These procedures can be used for adding media
management server configured on other UNIX/Linux platforms. You can
enable NBAC on a Windows media management server (with either
UNIX/Linux or Windows master server).
See “To enable access control on a NetBackup media server” on page 179.
2 To enable NBAC on a media management server configured on a dedicated
system, install the client portion of the authentication and authorization
service on the system. The client portion of the authorization service should
be installed on the system that has the media management server. The
authorization service should be installed after the authentication service.
NetBackup use case
3 On the master management server – neptune.universe.com, enter the

following command to create an authentication principal for the system that
has the media management server:
Machine Name: triton.universe.com
--pdrtype ab --domain NBU_Machines@neptune.universe.com
Principal Name: triton.universe.com
triton.universe.com
4 On the system with the new media management server, triton.universe.com,

type the following command to obtain the machine credential for the system
triton.universe.com:
Machine Name: triton.universe.com
Password: <pick a password for triton>
# /usr/openv/netbackup/bin/bpnbat -whoami \
-cf /usr/openv/var/vxss/credentials/triton.universe.com
Name: triton.universe.com
NetBackup use case
5 On the master management server, neptune.universe.com, type the following

command to authorize the system with the media management server to
perform authorization check:
-AllowAuthorization triton.universe.com \
-Showauthorizers -server neptune.universe.com
Type: User
Domain Type: vx
Name: triton.universe.com
6 On the master management server – neptune.universe.com, enter the

following command to start the second portion of the NBAC configuration
and invoke the jnbSA GUI administrative tool and login as user root:
-l /tmp/log.1 -lc &
7 Expand Host Properties, and then click Media Servers. select

triton.universe.com as the media server by clicking the host. The Status
column should display Connected. Click Actions (at the top), and then select
Properties... On the Properties… screen, select the Access Control (last one
on the list). In the Veritas Security Services (VxSS) box, choose Automatic
8 Click the Authentication Domains tab, click Add and a dialog box appears.
Enter neptune.universe.com as the Domain: and choose UNIXPWD as the
Authentication Mechanism. In the Broker: field, enter neptune.universe.com
and a description for this Authentication Domain. The authentication broker
resides on the system neptune.universe.com. The media management server
that is configured on triton.universe.com uses the remote authentication
broker that is configured on the maser management server
(neptune.universe.com).
9 Click the Authorization Service tab and enter neptune.universe.com in the
Host: field. The media server uses the global authorization database that is
configured on the system neptune.universe.com.
NetBackup use case
10 Save the changes, and then exit the jnbSA. For the changes to take effect,
stop and start the NetBackup media management server.
11 On the media management server triton.universe.com, enter the following

command to verify that the NetBackup configuration file on
triton.universe.com was updated:
CLIENT_NAME = triton.universe.com
EMMSERVER = neptune.universe.com
AUTHENTICATION_DOMAIN = neptune.universe.com ""
PASSWD neptune.universe.com 0
AUTHORIZATION_SERVICE = neptune.universe.com 0
USE_VXSS = AUTOMATIC
NetBackup use case
12 Log in to the NetBackup via the CLI and verify that the expiry period by
entering the following command:
Login Name: root
Password: <root password on triton>
Name: root
Domain: netptune.universe.com
13 Invoke the jnbSA and login as user root. To verify a user’s credential, within
jnbSA, click Help (at the top), and then click Current NBAC User. A jnbSA
session is valid for 24 hours.
-l /tmp/log.2 -lc &
You can enable NBAC on a Windows media management server (with the master
server on UNIX/Linux) If the environment has a Windows master management
server and UNIX/Linux media management server, refer to the following section.
NetBackup use case
To enable NBAC on a Windows media management server with a master server on

UNIX/Linux
1 On a Windows system (oberon.universe.com) with Windows Server 2003
Enterprise Edition SP1 operating system, a NetBackup media management
server is configured. The Windows media management server must be
operational before you enable the NBAC functionality. At a minimum, a
successful backup and restore must be performed for a client by using this
media management server.
2 Authentication plug-ins such as UNIXPWD and NISPLUS are not applicable
on Windows. Users on the Windows media management server are not able
to use the authentication brokers that are configured on UNIX/Linux with
these plug-ins. Therefore, an authentication broker (either remote or local)
must be configured on Windows with the platform specific authentication
domain and plug-in (WINDOWS) to authenticate Windows users.
3 On the master management server neptune.universe.com, use the following
command to create an authentication principal for the Windows system that
has the media management server:
Machine Name: oberon.universe.com
Password: <pick a password for oberon>
--pdrtype ab --domain NBU_Machines@neptune.universe.com
Principal Name: oberon.universe.com
triton.universe.com
oberon.universe.com
NetBackup use case
4 On the system with the Windows media management server

oberon.universe.com, enter the following command to obtain the machine
credential for the system oberon.universe.com:
C:\Program Files\VERITAS\NetBackup\bin>bpnbat \
-loginmachine
Machine Name: oberon
C:\Program Files\VERITAS\NetBackup\bin>bpnbat -whoami

-cf ..\var\vxss\credentials\oberon.SUN.universe.com
Name: oberon.universe.com
Expiry Date: Jan 23 07:59:01 2008 GMT
5 On the master management server neptune.universe.com, enter the following

command to authorize the system with the media management server to
perform authorization check:
C:\Program Files\VERITAS\NetBackup\bin\admincmd>bpnbaz
-allowauthorization oberon -server neptune.universe.com

command to start the second portion of the NBAC configuration, invoke the
jnbSA GUI administrative tool, and log in as user root:
-l /tmp/log.1 -lc &
NetBackup use case
7 Expand Host Properties, and then click Media Servers, select oberon (FQHN
is oberon.universe.com) as the media server by clicking the host. In the
Status column, it should show Connected. Click Actions (at the top) and select
SUN as the Domain: and choose WINDOWS as the Authentication Mechanism.
In the Broker: field, enter oberon and a description for this Authentication
Domain. The authentication broker resides on the system
oberon.universe.com.
9 On the Authorization Service tab, in the Host field, enter

neptune.universe.com. Save the changes, and then and exit the jnbSA. For
the changes to take effect, stop and start the NetBackup media management
server.
For information on verification and troubleshooting, refer to the following

sections:See “Verify NetBackup access control setup on media servers” on page 254.
Enable access control on a NetBackup client

Before you enable the NetBackup Access Control (NBAC) on a NetBackup
management client, the management client must be managed by the master and
media management servers. To verify that the NetBackup configuration is working,
a successful backup and restore initiated from the master for a client using this
media server should be a good indicator.
This approach is helpful for fault isolation. For example, if backup and restore by
using this management client is successful without NBAC, but fails with NBAC
enabled, you can direct your troubleshooting effort at NBAC configuration.
Table 6-5 shows the specific version of the common core service (authentication)
that is used by the NetBackup management client.
NetBackup use case
Table 6-5 NetBackup client dependency on authentication
NetBackup Authentication client
4.1 4.2 4.3
5.1MP6
6.0MP4
Other Management Agents, such as CommandCentral Storage and Service, that

are installed on the same system as the management client can be enabled with
authentication and use the same common core services components.
Even though the NetBackup management client only needs the client portion of
the authentication product, other Symantec management servers or agents that
are installed on the same system as the NetBackup management client can install
an authentication broker. The NetBackup management client is authenticated by
a remote authentication broker that is configured on the system with the master
management server. Other Symantec management servers or agents may require
a more recent version of the Symantec Product Authentication.
To set up the NBAC functionality on a management client, the following procedures
have been tested and proven to work with the configuration that is described in
this use case chapter. The first portion of the procedures is done from the
command line. The NetBackup jnbSA is used to complete the second portion of
the setup. Some of the steps described here will have to be done on the system
with the master management server.
A NetBackup management client has been installed and configured on a UNIX
system (bianca.universe.com) that runs the Solaris 9 operating system. This
NetBackup client is managed by the master management server that is configured
on a UNIX system (neptune.universe.com) that runs the Solaris 9 operating
system. Procedures are provided to enable the NBAC for this NetBackup
management client. These procedures can be used for adding NetBackup
management clients on other UNIX/Linux platforms.
NetBackup use case
To enable NBAC for a management client

1 Install the Symantec Product Authentication Service client software on the
system that has the management client.
2 On the master management serverneptune.universe.com, to enable the
NBAC for a management client, create an authentication principal for the
system where the NetBackup management client is installed. Repeat this step
for each management client that is to be enabled with the NBAC. In this
example, an authentication principal is added for the system
bianca.universe.com in the NetBackup NBU_Machines private domain
repository.
Machine Name: bianca.universe.com
Password: <pick a password for bianca>
# /opt/VRTSat/bin/vssat listpdprincipals --pdrtype ab \

--domain NBU_Machines@neptune.universe.com
Principal Name: bianca.universe.com
triton.universe.com
bianca.universe.com
NetBackup use case
3 On the management client bianca.universe.com, use the following command

to obtain the credential for the system bianca.universe.com:
Machine Name: bianca.universe.com

/usr/openv/var/vxss/credentials/bianca.universe.com
Name: bianca.universe.com

command to use the jnbSA to modify the Access Control properties for a
NetBackup management client.
-l /tmp/log.1 -lc &
5 Expand Host Properties, and then click Clients., select bianca.universe.com

as the management client by clicking the host. In the Status column, it should
show Connected. Click Actions (at the top) and select Properties... On the
Properties… screen, select the Access Control (second one from the bottom
of the list). In the Veritas Security Services (VxSS) box, choose Automatic
neptune.universe.com as the Domain and choose UNIXPWD as the
Authentication Mechanism. In the Broker field, enter neptune.universe.com
and a description for this Authentication Domain. The management client is
using the authentication broker residing on the system
neptune.universe.com.
NetBackup use case
7 Repeat the steps listed above for each NetBackup management client that
wants the NBAC capability.
8 Save the changes and exit the jnbSA. For the changes to take effect, stop and
start the NetBackup management server.
NetBackup use case
9 On the NetBackup management client bianca.universe.com, enter the

following command to verify that the /usr/openv/netbackup/bp.conf
configuration file on the management client was updated:
SERVER = oberon.universe.com
CLIENT_NAME = bianca.universe.com
AUTHENTICATION_DOMAIN =
neptune.universe.com "" PASSWD neptune.universe.com 0
AUTHENTICATION_DOMAIN =
SUN "" WINDOWS oberon.universe.com 0
Login Name: root
Name: root
Invoke the jnbSA and login as user root.

To verify the use's web credential, within jnbSA,
click Help (at the top) and select Current NBAC User.
A single jnbSA session is valid for 24 hours.
-l /tmp/log.2 -lc &
NetBackup use case
10 To enable NBAC on a Windows management client (ophelia.universe.com)

with master server on UNIX/Linux, follow the steps and procedures listed in
this section. The differences are the values in the Domain, Authentication
Mechanisms, and the Broker: fields. For a Windows management client, the
Domain: should be set to SUN (Windows Active Directory), the Authentication
Mechanisms: should be set to WINDOWS, and the Broker: should be set to
oberon.universe.com.
11 The NBAC configuration for NetBackup management client is now complete.

Use the procedures listed in the NetBackup access control setup verification
on clients section in Appendix C to verify that the NetBackup management
client is setup correctly. In Appendix C, the NetBackup access control
troubleshooting tips section has a list of common errors and resolutions tips.
See “Enable access control on a NetBackup media server” on page 108.
Environment with existing authentication hierarchy

In an enterprise where NetBackup is to be deployed with access control, suppose
an authentication hierarchy has already been created for another Symantec
product. When installing the Symantec Product Authentication for NetBackup,
you can install and configure an authentication broker by using the existing
authentication hierarchy that is configured on a remote system. Refer to the Add
a new authentication broker section in Appendix B for detailed procedures. If a
new authentication hierarchy is inadvertently configured also for NetBackup, the
NetBackup authentication hierarchy can be consolidated with an existing
authentication hierarchy. To consolidate the root broker, refer to the Replace the
root broker on the NetBackup master server section in Appendix C for detailed
procedures on how to assimilate an authentication broker from one authentication
hierarchy into another.
Upgrade NetBackup and shared components

The NetBackup installation is used to install and upgrade the NetBackup software
on systems that have either management client, master, or media management
server. The NetBackup installation does not involve the upgrade of those common
core services components (AT and AZ) that are used by NetBackup Access Control.
If upgrading to a specific NetBackup version also calls for the upgrade of the
shared components, the respective product installation script that is provided by
the shared products should be used to perform the upgrade.
After the upgrade of NetBackup software is complete, verify that NetBackup is
able to work with the shared products that are configured on the system.
CommandCentral Storage and Service use case
If one or more of the shared products are upgraded, while the NetBackup software
remains unchanged, the proper operation of NetBackup must also be verified
through the backup and restore procedures. If there are other Symantec agents
installed on the same system as NetBackup, ensure that the new version of the
shared components are able to work with the management agents that are already
present on the system. Most of the time, it is prudent to test the configuration in
a test environment before deploying the new version of the shared components
to the production environment. The following table shows the verified upgrade
configurations.
Table 6-6 explains allowable upgrade paths for shared components with NetBackup.
Table 6-6 Allowable upgrade paths for shared components with NetBackup
NetBackup PBX Authentication Authorization

1.2 -> 1.3 4.2 -> 4.3 4.2 -> 4.3
6.0MP4

CommandCentral uses the authentication mechanism that is provided by the
Symantec Product Authentication to authenticate the users who access the
CommandCentral Web administrative console. An Authentication broker is set
up with the appropriate authentication domain and plug-ins that are made
available to the CommandCentral Web console for authenticating users. After the
CommandCentral products have been configured, accessing the CommandCentral
Web console requires a valid user login and password that must be authenticated
through the cc_users authentication domain and plug-in.
order:
■ Storage Foundation.
■ Infrastructure Core Services (Private Branch Exchange and Authentication).
■ CommandCentral Storage and Service.
■ Management client or agents from other Symantec products (such as
NetBackup, Symantec License Inventory Manager).
Figure 6-4 depicts the deployment of the CommandCentral servers in an enterprise.
Figure 6-4 Deploying CommandCentral management servers and agent

In this use case chapters, the CommandCentral (CC) storage and service
management servers are deployed on the Solaris platform. The CC management
servers on Solaris manage the storage and service management agents that are
deployed on Solaris and Windows platforms.
Application server
On a UNIX platform, CommandCentral binaries are installed in the /opt/VRTS*
directories. CC products create data files and also generate temporary files. It is
ideal to store all the data and temporary files in a directory relative to
/var/VERITAS (or some user defined directory). The /var/VERITAS directory is
typically a mount point of a Veritas file system (VxFS) created on a Veritas Volume
Manager (VxVM) volume. The VxFS and VxVM products are distributed through
the Symantec application servers such as SF, SFCFS, or SF Oracle RAC. Before the
CC products are installed, typically, the Symantec SF application server is installed
on the system. To create a Veritas file system and mount it at /var/VERITAS, refer
to the Common Storage Foundation procedures section in Appendix A for
instructions on how to create a VxFS file system on a VxVM volume.
CommandCentral management server

In this setup, the CommandCentral (CC) management servers (Storage and Service)
are deployed on a dedicated Solaris system. CC management servers are dependent
on Symantec Product Authentication. The authentication product is used to
authenticate users accessing the CC Web console through a valid authentication

domain and plug-in.
In this use case, both Storage and Service management servers use version 4.2 of
the Authentication product. On the system where these management servers are
to be installed, you should configure an authentication broker in the authentication
hierarchy created on the system where the NetBackup management server is
configured. To add a new authentication broker into an existing authentication
hierarchy, refer to the Add a new authentication broker section in Appendix B for
detailed procedures.
A system that is configured with CommandCentral storage and service
management servers can have Management Agents or Client of other Management
Servers deployed as well. These Agents or Clients may or may not have the
authentication enabled. As an example, NetBackup management client could be
installed on the system that has the CC Storage management server.
Storage management server

The version of the CommandCentral Storage (CC Storage) product that is used in
this Yellow Book edition is listed in the following table. This version of the CC
Storage is dependent on the infrastructure provided by the Authentication (AT)
component. On the systems that have CC Storage management server, this shared
component must be installed and configured. This shared component could be
manually installed and configured on the system first or let the CC installer
automatically install the authentication product. CC Storage management server
uses the Web Server Service for console logon.
that is used with the storage management server.
Table 6-7 Storage management server dependency on shared component
CommandCentral Storage Authentication Client
4.1 4.2 4.3
4.2FP1
4.3
A valid product license key is required to install the CC Storage management

server. To install and configure storage management server on Solaris, follow
these procedures and steps.
This install session illustrates the installation for CC Storage 4.2FP1 release on
Solaris 10 operating system.
To install and configure a CommandCentral storage management server

1 Log on to the system (cressida.universe.com) where the CC Storage
management server is to be installed. Using the instructions described earlier
in the Application server section, prepare a Veritas file system and mount it
at the /var/VERITAS directory.
2 Invoke the installccs script to install the CC Storage management server.

The CC installation files could be accessed through a mount point, either a
local or CD/DVD file system. Refer to the CC UNIX installation guide for
instructions on how to access installation files through CD/DVD distribution
media.
# cd <mnt>/CC4.2FP1/sunos
# ls
installccs* uninsallccs*
# ./installccs
1) CommandCentral Storage Management Server
3) CommandCentral Storage Web Engine
Choose the Storage Management Server and

Storage Web Engine components for installation.
For the storage management server configuration,
pick the option with both Operations and Data modules.
Where should the Data Module create this

temporary store? (/var/VERITAS)
Install Operations Module: Yes

Install Data Module: Yes
Data Module temporary dir: /var/VERITAS/ccs_data
Where should CommandCentral packages be installed? (/opt)

Where should CommandCentral databases be installed?
A directory named 'ccs_data' will be created within to
store data. (/var/VERITAS)
Please enter a CommandCentral Storage license key,

or <Return> to enter an evaluation key: <Storage key>
Do you want to start CommandCentral processes now? [y,n,q] (y)

Starting CommandCentral processes...
Starting VERITAS Enterprise Administrator...
Starting VERITAS Trap Service...
Starting CommandCentral Database...
Starting CommandCentral Alert Manager...
Starting VERITAS SAN Access Layer...
Starting CommandCentral Alarm Service...
Starting CommandCentral Importer...
Starting VERITAS SICL...

Starting CommandCentral Data Module...
Done starting CommandCentral processes...
3 Verify that the following CommandCentral authentication domains are present

on the system cressida.universe.com.

Domain Name cc_users@cressida.universe.com
Domain Name ccstr_services@cressida.universe.com
4 After CommandCentral Storage is installed and configured, verify that the

CC Storage management server is functional and working correctly.
See “Verifying the CommandCentral Storage server setup” on page 279.
The system that has the CC Storage management server is usually the first system
to be upgraded.
On a system that has the CC Service 4.2FP1 installed, upgrading CC Storage from
4.2FP1 to 4.3 is not supported. The CC Storage installation script makes this check
and would exit when such a condition is detected.
To upgrade a CommandCentral storage management server
1 Log on to the storage management server (cressida.universe.com), and
then locate the CommandCentral Storage 4.3 management server software.
2 Invoke the installccs script to upgrade the CC Storage management server.
The CC Storage installation files could be accessed through a mount point,
either a local or CD/DVD file system. Refer to the CC UNIX installation guide
for instructions on how to access installation files through CD/DVD
distribution media.
# cd <mnt>/ CCS_4.3/4.3.0017.0/sunos
# ls installccs uninstallccs
installccs* uninstallccs
# ./installccs
Service management server

The version of the CommandCentral Service (CC Service) product that is used in
Service is dependent on the infrastructure provided by the Authentication (AT)
and Private Branch Exchange (PBX) components. These shared components could
be manually installed and configured on the system first or let the CC installer
automatically install and configure these shared products. CC Service management
server also uses the Web Server Service for console logon.
Table 6-8 shows the specific version of the common core services (authentication
and PBX) that are used with the Service management server.
Table 6-8 Service management server dependency on shared components
CommandCentral Storage Authentication service Private Branch

Exchange
4.1 4.2 4.3 1.2 1.3
4.2FP1
A valid product license key is required to install the CC Service management

server. To install and configure CC Service management server, follow these
procedures and steps. This install session illustrates the installation for CC Service
4.2FP1 release on Solaris 10 operating system.
To install and configure a CommandCentral server management server

1 Log on to the system (cressida.universe.com) where the CC Service
management server is to be installed. Using the instructions described earlier
in the Application server section, prepare a Veritas file system and mount it
at the /var/VERITAS directory.
2 Invoke the installccs script to install the CC Service management server. The
CC installation files can be accessed through a mount point, either a local or
CD/DVD file system. Refer to the CC UNIX installation guide for instructions
on how to access installation files through CD/DVD distribution media.
# ls
installccs* uninsallccs*
# ./installccs
1) CommandCentral Service Server and Web Engine
Installation dir: /opt

Database dir: /var/VERITAS/ccs_data
DB temp dir: /var/VERITAS/ccs_data
The CommandCentral Service Server and Web Engine
external address has been set to: cressida.universe.com
The CommandCentral Service Automation Server port has
been set to: 60389
VERITAS Web Server port: 8181
Do you want to start CommandCentral processes now? [y,n,q] (y)

Starting VERITAS Enterprise Administrator...
Starting VERITAS Trap Service...
Starting CommandCentral Database...
Starting CommandCentral Alert Manager...
Starting CommandCentral Alarm Service...
Starting CommandCentral Web Engine...
Starting CommandCentral Importer...
Starting VERITAS SICL...
Starting CommandCentral Service Server and Web Engine...
Done starting CommandCentral processes...
3 When the configured authentication broker is saved and restored after the
CC Service is installed, enter the corresponding component number to add
or remove it from the restore queue, or '3' when you are finished making
selections.
Files/directories detected, available for restore:

1) VxSS Authentication configuration
2) Select all
3) Finished with selections
4 Verify that the following CommandCentral authentication domains are present

on the system cressida.universe.com.

Domain Name ccsvc_services@cressida.universe.com
5 After CommandCentral Server is installed and configured, verify that the CC

Storage management server is functional and working correctly.
See “Verifying the CommandCentral Service server setup” on page 282.
Version 4.2FP1 is the last release of the CommandCentral Service product. The
CommandCentral Service View Builder functionality is renamed to Veritas Backup
Reporter, which is distributed with the NetBackup product. The CommandCentral
Service Metering Collector and CommandCentral Service Metering Controller are
renamed to Veritas Process Automation Server.
CommandCentral Management agents

In this setup, the CommandCentral (CC) management agent is deployed on Solaris
running the Solaris 9 operating system. These CC management agents are
configured to report to the CC management servers configured in the previous
section.
that is used with the Storage and Service management agents.
Table 6-9 CommandCentral agents dependency on shared component
4.1 4.2 4.3
4.2FP1
Table 6-9 CommandCentral agents dependency on shared component

(continued)
4.1 4.2 4.3
4.3
On Solaris, use the following procedures and steps to install a CC management

agent and configure it to report to a CC management server configured on Solaris.
The installation procedure that is illustrated on Solaris for CC management agent
is identical on other UNIX/Linux platforms.
To install the CommandCentral storage management agents

1 Navigate to the directory that has the CC management agent installation
files. The directory can be in a file system mounted on a CD-ROM/DVD drive
or a Network File System.
2 Install the CC Storage agent.
# cd <mnt>/ CCS_4.3/4.3.0017.0/unix_agent
# ls *install*
installccs* uninstallccs*
# ./installccs
2) CommandCentral Storage Agent
Choose CommandCentral Storage Agent,

Install both Operations and Data Modules,
Install support for Array Management to install.
Where should the Data Module create this temporary store? \

(/var/VERITAS)
Install Operations Module: Yes

Enable Array Management: Yes
Install Data Module: Yes
Data Module temporary dir: /var/VERITAS/ccs_data

Would you like to configure a CommandCentral Storage Management
Server for this Agent? [y,n,q] (y)
Please specify the CommandCentral Storage Management Server
hostname to configure: cressida.universe.com
Would you like to enable switch exploration
for this Agent? [y,n,q] (n) y
Installation dir: /opt

Server to configure: cressida.universe.com

3 Install the CC Service agent.
Components available for installation:
3) CommandCentral Service Agent

Would you like to configure a CommandCentral Service Server
and Web Engine for this Agent to report to? If no host name
is given, the following command will need to be
run after installation: /opt/VRTSccsva/bin/ccsvcagentauth \
-server server_to_connect_to [y,n,q] (y)
Please specify the CommandCentral Service Server and
Web Engine hostname to configure: cressida.universe.com

Starting CommandCentral Service Agent...
4 After CommandCentral Server management agents are installed and

configured, verify that the CC Storage management agents are functional
and working correctly.
See “Verifying the CommandCentral agents setup” on page 284.

When installing the CommandCentral (CC) product in an enterprise that already
has the authentication hierarchy, it is much preferred to create a new
authentication broker in the existing authentication hierarchy for the CC
management servers.
If a root broker was also configured during the CC install and there is a need to
replace the CC root broker with the existing authentication hierarchy, refer to
the Replace the root broker on the CommandCentral server section in Appendix
D for detailed procedures on how to assimilate an authentication broker from one
authentication hierarchy into another.
CommandCentral-related upgrade
The CC installation is used to install and upgrade the CC software on systems that
have either management agent, storage or service management server. The CC
installation does not involve the upgrade of those common core services
Symantec License Inventory Manager use case
components (AT and PBX) that are used by CC management servers. If upgrading
to a specific CC Storage version also calls for the upgrade of the shared
components, the respective product installation script that is provided by the
shared products should be used to perform the upgrade.
After the upgrade of CC software is complete, verify that the CC product works
with the shared products that are configured on the system.
If one or more of the shared products are upgraded, while the CC software remains
unchanged, the proper operation of the CC product must also be verified through
the normal uses. If there are other Symantec agents or client installed on the same
system as the CC product, ensure that the new versions of the shared components
are able to work other management client or agents that are already present on
the system. Most of the time, it is prudent to test the configuration in a test
environment before deploying the new version of the shared components to the
production environment.

The SLIM product uses the authentication mechanism that is provided by the
Symantec Product Authentication to authenticate users accessing the SLIM Web
administrative console. An Authentication broker is set up with the appropriate
plug-ins and made available to the SLIM Web console for authenticating users.
After the SLIM product has been configured, users in the slim_users private
domain repository should be able to log on to the SLIM Web console.
order:
■ Storage Foundation. It is optional to install the Symantec application server.
■ Infrastructure Core Services (Private Branch Exchange, Authentication, and
Service Management Framework).
■ Management client or agents from other Symantec products (such as
NetBackup, CommandCentral)
The SLIM product is used to collect licensing information of other Symantec
products that are installed on various systems. SLIM product has a management
server and management agent. The management agent collects the licensing
information and reports it to the management server, which stores the licensing
data in a central repository. Usually, the SLIM management agent is deployed on
systems that have NetBackup, CommandCentral, Storage Foundation and other
Symantec products installed.
Figure 6-5 explains deploying Symantec License Inventory management server

and agent.
Figure 6-5 Deploying Symantec License Inventory management server and

agent
It is highly recommended that the SLIM management server gets installed and
configured on a system without other management servers. After the management
server is configured and functional, the installation of management agent can
proceed.
The version of the SLIM product that is used in this Yellow Book edition is listed
in the following table. This SLIM version is dependent on the infrastructure
provided by the Authentication (AT), Private Branch Exchange (PBX) and Service
Management Framework (SMF) core services components. On systems that have
SLIM management server, access points, and management agents, these shared
components must be installed and configured. These shared components can be
manually installed and configured on the system first or let the SLIM installer
automatically install them. SLIM management server uses the Web Server Service
for console logon.
Table 6-10 shows the specific version of the common core services (authentication,
PBX, and SMF) that are used by the NetBackup media management server.
Table 6-10 Symantec License Inventory Manager shared component

dependencies
SLIM AT Server PBX SMF
4.1 4.2 4.3 1.2 1.3 1.2 1.3
4.0.4
The installer of this SLIM version automatically configures a root plus

authentication brokers on the system for the SLIM management server. To replace
the root broker with an existing authentication hierarchy, refer to the Replace
the root broker on the SLIM server section in Appendix E for detailed procedures.
In this SLIM version, the SLIM management server is supported only on Solaris.

In this use cases chapter, the SLIM management server and agents are primarily
deployed and verified on the Solaris and AIX platforms. A SLIM management
server that is configured on Solaris is able to work with management agents that
are deployed on Windows and others UNIX/Linux platforms. In this setup,
management agents that are installed on AIX and Windows platforms are also
configured to report to the SLIM management server on Solaris.
Application server
The SLIM management server and agent can be installed on respective systems
and they do not depend on the existence of Symantec application server such as
SF or SFCFS to be installed first.
SLIM management server collects the licensing information on systems that have
Storage Foundation, NetBackup, and CommandCentral across UNIX/Linux and
Windows platforms.
SLIM management server

In this setup, the SLIM management server is deployed on a dedicated Solaris
system that runs the Solaris 9 operating system. Common core services products
that SLIM depends on are also installed by the SLIM installation script. The
common core services products include Authentication, Private Branch Exchange,
Service Management Framework, and Web Server Service. Users who access the
SLIM Web console must be authenticated through a valid authentication domain
and plug-in.
A valid product license key is required to install the SLIM management server.
To install and configure SLIM management server on Solaris

1 Navigate to the directory that has the SLIM installation files. The directory
can be in a file system that is mounted on a CD-ROM or DVD drive or a
Network File System.
cd <path>/Server/Solaris
# ls install
install
# ./install
If you agree enter "YES", otherwise enter "NO".

YES
1. Symantec License Inventory Manager Server
2. Symantec License Inventory Manager Access Point
Continuing Installation
Please indicate your choice [1|2] :1
Enter license key :<enter SLIM server license key>
Enter the system names separated by spaces on which to install

SYMClms: belinda.universe.com
2 Symantec License Inventory Manager is made up of the following packages,

shown on the following screen:
Installing VRTSdbms3 3.0.21.0

on belinda.universe.com........................ done 1 of 4 steps
Installing VRTSjre 1.4
Installing VRTSweb 4.2
Installing SYMClms 4.0.21.15
3 The SLIM installation script checks for the common core services components
(PBX, AT, and SMF) on the system before installing the SLIM product. These
shared components are installed for the SLIM product if they are not present,
or if older versions of the same components are found on the system.
4 A log file is created during the installation. Look in the log file and verify that
there are no error messages or non-zero return codes.
5 The SLIM installation script configures a root plus authentication broker on

the local system for the SLIM management server. Move the authentication
broker that is created for the SLIM management server into another
authentication hierarchy. After the authentication broker is migrated to an
existing authentication hierarchy, the SLIM root broker should cease to exist.
See “Verifying the SLIM server setup” on page 295.
6 After the SLIM product has been installed and configured, the verification
procedures listed in the Verify SLIM server setup section in Appendix E should
be used to ensure that the SLIM management server is functional and working
correctly.
SLIM management agents

A system that has the SLIM Management Server configured can have Management
Agents or Client of other Management Servers deployed as well. These Agents or
Clients may or may not have the authentication enabled. As an example, NetBackup
management client can be installed on the system that has the SLIM management
server.
In this setup, the SLIM management agent is deployed on a Solaris 9 operating
system. This SLIM management agent is configured to report to the SLIM
management server that is configured in the previous section. UNIX/Linux
management agents are assigned to an authentication broker that is configured
on the respective UNIX/Linux platforms.
To install and configure SLIM management agent
1 Navigate to the directory that has the SLIM installation files. The directory
can be in a file system that is mounted on a CD-ROM or DVD drive or a
Network File System.
# cd <path>/Agent/Solaris
# ls -l *install*
-rwxr-xr-x 1 root root 2051 Jul 12 2006 install_lma*
-rwxr-xr-x 1 root root 2055 Jul 12 2006 uninstall_lma*
# ./install_lma
Enter the system names separated by spaces on which to install
LIM:juliet.universe.com
2 Symantec License Inventory Agent is made up of the following package:
SYMClma Symantec License Inventory Agent

3 Choose any additional languages to install on the system.

4 The SLIM installation script checks for the common core services components
(PBX, AT, and SMF) on the system before installing the SLIM management
agent. These shared components will be installed for the SLIM product if they
are not present or older versions of the same components are found on the
system.
5 On the Symantec License Inventory Agent Configuration screen, specify the
following configuration data. The Server/Access Point is the name of the
system (assuming belinda is the name of the host) that has the SLIM
management server configured.
Find the root hash on the system where the root broker is located. The
slim_agent is the authentication principal created in the slim_services private
domain repository located on the system belinda.universe.com.
Are you ready to configure LIM on juliet.universe.com? [y, n, q] (y)
Enter the Access Point/Server hostname:belinda.universe.com

Do you want to enable security? [y, n] (n) y
Do you want to configure security at this time? [y, n] (y)
Enter the Authentication Broker hostname: (belinda.universe.com)

Enter the TCP/IP port number for Authentication Broker
belinda.universe.com: (2821)
Enter the certificate hash code for Authentication Broker
belinda.universe.com: (5a08f7de42debf522cd8afaecca02b35bb37d8c4)
Enter the Access Point/Server user name: (slim_agent)
Enter the Access Point/Server user
domain name: (slim_services@belinda.universe.com)
Enter the Access Point/Server user domain type: (vx)
Do you want to start Symantec License Inventory Agent
processes now? [y, n] (y)
6 Look in the log file that is created during the installation, and verify that
there are no error messages or non-zero return codes.
7 Verify that the SLIM management agent is recognized by the Service

Management Framework.
# /opt/VRTSsmf/bin/vxservice --list --processname ICS

vxservice version 1.3.9.0
Symantec Corporation
Copyright 2005 Symantec Corporation. All rights reserved.
Getting the process and service list for process ICS
Process Name: ICS
Service Name: lma
8 To remove the SLIM management agent package (SYMClma), navigate to the

directory that has the SLIM installation files, and then invoke the uninstall
script.
# cd <path>/Server/Solaris
# ./uninstall_lma
9 After a SLIM management agent is installed successfully, verify that the SLIM
management agent is configured to report to the correct SLIM management
server.
See “Verifying the SLIM agent setup” on page 297.
It is possible to add a SLIM management agent on Windows and report to a SLIM
management server on Solaris. To add a Windows SLIM management agent, the
procedures and steps listed in the SLIM management agents section in Chapter
7 should be used.
A system that has the SLIM management agent installed could have management
agents or clients of other management servers installed as well. These other agents
or clients may or may not have the authentication enabled. As an example,
CommandCentral storage agent can be installed on the system that has the SLIM
management agent.

When installing the SLIM product in an enterprise that already has the
authentication hierarchy, the root broker that is configured by the SLIM product
can be replaced and point to the existing root broker on another system.
SLIM-related upgrade
SLIM upgrade typically involves one or more of the following components:
Storage Foundation use case
■ SLIM component itself (management server or agents)

■ One or more of the common core services components (PBX, AT, and SMF) on
which SLIM depends
Before upgrading the SLIM component on the system, stop the SLIM service. To
upgrade the SLIM management server, follow the instructions in the SLIM
installation guide or release notes that come with the SLIM product. New releases
may have additional steps that require the SLIM administrator to perform during
the upgrade. On the systems that have the SLIM management agents, the upgrade
can proceed after the SLIM management server has been successfully upgraded.
After the upgrades, verify the SLIM server and SLIM agent setup to ensure that
the SLIM management server is able to pull licensing information through the
management agents.
Usually, the upgrade of the SLIM component on a system does not affect the
common core services components SLIM depends on. However, the SLIM
administrator should always consult the SLIM documentation that comes with
the upgrade to make the final determination.
Because SLIM depends on the common core services to upgrade one or more of
these components, the SLIM management server and the affected core services
must be stopped first. You should perform the upgrade for these core services
and verify that these services are started successfully. You should also stop and
start other core services, even though those shared components were not upgraded.
You should start the SLIM management server and verify the successful logon to
the SLIM Web console.
If an upgrade is required for the Symantec Product Authentication Service, refer
to the following section for further information related to the Authentication
shared component prior to the upgrade.
See “ Authentication and authorization service upgrade” on page 75.
The startup and shutdown procedures for the SLIM and core services components
are included in the Replace the root broker on the SLIM server section of Appendix
E.

The following Veritas Storage Foundation products are used throughout this
section:
■ Storage Foundation, which consists of Veritas Volume Manager, Veritas File

System, and optionally, Veritas Volume Replicator.
■ Storage Foundation for Windows, which consists of Veritas Volume Manager,
and optionally, Veritas Volume Replicator.
■ Storage Foundation Cluster File System (SFCFS) which consists Veritas File
System, Veritas Cluster Server (VCS), and the cluster functionality (shared
volumes) of Veritas Volume Manager.
■ Storage Foundation for Oracle RAC, which consists of SFCFS plus the Veritas
add-on functionality for use with Oracle databases.
On the systems where these application servers are deployed, management agents
or client of other management servers are installed. For example, on a VCS cluster
with SF Oracle RAC, on each node of the VCS cluster, the following management
client and agents could be present.
Figure 6-6 shows deploying Storage Foundation.
Figure 6-6 Deploying Storage Foundation
■ NetBackup management client

■ CommandCentral Storage or Service management agent
■ Symantec License Inventory Manager management agent
These management client and agents are set up to report to the respective
management servers that are illustrated in this use case chapter. Refer to the
respective product use case section for instruction on how to set up a management
agent or client on a system.

In this use case chapter, the Storage Foundation products (SF, SFCFS and SF Oracle
RAC) are deployed on UNIX (Solaris, AIX) and Windows (SFW) platforms.
Application server
Storage Foundation uses the authentication product to authenticate users who
access the VCS configuration data and the Veritas Enterprise Administrative
console. Users must be authenticated through the Symantec Product
Authentication when they access the Veritas Enterprise Administrator console.
that is used with Storage Foundation.
Table 6-11 Storage Foundation dependency on shared component
Storage Foundation Authentication service
4.1 4.2 4.3
4.1MP1
5.0
Throughout this use case chapter, the Storage Foundation product is installed on
a single system with a Veritas management server, such as NetBackup, SLIM, or
CC. Storage Foundation is not integrated with Symantec Product Authentication
Service. It is possible for Storage Foundation to be installed on the system with a
management client such as NetBackup and management agents such as CC and
SLIM. This installation procedure is interactive and requires that you provide
values to the prompts. A valid product license key is required to install Storage
Foundation.
To install and upgrade Storage Foundation on a Solaris 9 system

1 Navigate to the directory that has the SF distribution files and invoke the
installer script.
2 Change directory to where the installation files are located.
# cd <mnt>/cd1
# ls
file_system/ volume_manager/ installer
# ./installer
3 To upgrade the Storage Foundation, navigate to the directory that has the
distribution files.
# cd <mnt>/4.1MP1
# ./install_vp
Most of the time, SFCFS or SF for Oracle RAC is installed on a set of systems that
share a set of hardware resources, such as storage. On each of the systems, the
management client (NetBackup) and the management agents (CC and SLIM) are
installed. These management client or agents report to their respective
management servers that are configured on separate systems, respectively.
Versions 4.1MP1 on Solaris and 5.0 (and later) on UNIX/Linux platforms are
integrated with Symantec Product Authentication.
To install and upgrade Storage Foundation Cluster File System 5.0 on a VCS cluster
running AIX 5.3
1 Navigate to the directory that has the SFCFS distribution files and invoke the
installer script. The following session illustrates the sample installation and
configuration steps pertaining to the SFCFS and Symantec Product
Authentication:
# cd <mnt>/dvd1
# ls
installer
storage_foundation_cluster_file_system/
# ./installer -rsh
2 Enter the system names, separated by spaces, on which to install the product.
Enter the Storage Foundation license key.
3 The authentication portion of the configuration is illustrated as follows:
Would you like to configure SFCFS to use

Symantec Security Services? [y,n,q] (n) y
Security Menu
1) Configure security completely automatically
2) Provide AB credentials using BLOBs
3) Provide AB credentials without using BLOBs
Select the Security option you would like to perform [1-3,q,?] (1)
Enter the name of the VxSS Root Broker system: neptune.universe.com
4 After the installation and configuration is complete and all the systems have
been restarted, run the following commands to verify the authentication
configuration:
# /opt/VRTS/bin/hastatus -sum
Group System Probed AutoDisabled State
B VxSS larissa Y N ONLINE
B VxSS ariel Y N ONLINE
# /opt/VRTSat/bin/vssat showbrokermode
Broker mode is : 1
5 Additional verification information is available in the Appendix A.

6 To upgrade SFCFS, in the directory that has the installation files, invoke the
install_vp script to begin the upgrade.

When you install the SFCFS or SF for Oracle RAC in an enterprise that already
has the authentication hierarchy, you should use existing root broker and create
new authentication brokers in the existing authentication hierarchy.
Storage Foundation-related upgrade

After the upgrade of SFCFS/SF Oracle RAC is complete, verify that the Storage
Foundation application server works with the shared products that are configured
on the system.
If one or more of the shared products are upgraded, while the storage foundation
software remains unchanged, the proper operation of the storage foundation
(with Authentication enabled) product must be verified through the normal uses.
If there are other Symantec agents installed on the same systems as the storage
foundation product, ensure that the new version of the shared components work
with the management agents that are already present on the system. Most of the
time, it is prudent to test the configuration in a test environment before deploying
the new version of the shared components to the production environment.
Chapter 7
Symantec solution:
Windows use cases
■ Deploy Symantec products on Windows
■ Determine a broker infrastructure
■ Symantec License Inventory Manager use case
■ NetBackup use case
■ NetBackup Operations Manager use case
■ CommandCentral Storage and Service use case
■ Storage Foundation use case
Deploy Symantec products on Windows

In this use case, a predominantly Windows-based enterprise has purchased the
following Symantec products to meet the growing demands of the company’s
computing capacity and capability:
■ NetBackup
■ NetBackup Operations Manager
■ Storage Foundation HA on Windows
150 Symantec solution: Windows use cases
Deploy Symantec products on Windows
Included with the purchase were Symantec core services products, such as Private
Branch Exchange, Authentication, or Authorization and Service Management
Framework. One or more of these core services products are used by the Symantec
products. After the core services products are installed on a system, they are
shared by any Symantec products that need them.
Figure 7-1 shows a high-level deployment layout.
Figure 7-1 Deployment of Symantec products on Windows

Symantec solution: Windows use cases 151
Determine a broker infrastructure
The approach chosen by the implementation team is to deploy these Symantec

products into the enterprise data center in three major phases. A new management
server and the accompanying application server, management agents, clients are
added in each phase.
The enterprise is security conscious, so the corporate security architect has decided
to implement these Symantec products with Symantec Product Authentication
and Authorization. To help the enterprise security architect and security
implementation team achieve the objectives listed in the Customer Benefits section
in Chapter 1, this chapter provides step-by-step instructions on how to individually
configure these Symantec products with authentication and authorization
capabilities.
See Determine a broker infrastructure for details on the layout for the

Before starting the implementation, the enterprise security team developed the
broker schema and laid the foundation for the root and authentication brokers.
All the management servers listed in Figure 7-1 need an authentication broker
configured on the systems where the management servers are located.
Using the deployment guidelines and best practices discussed in Multiproduct
deployment approach, the enterprise security team maps the Symantec products
depicted in Figure 7-1 into an authentication hierarchy illustrated in Figure 7-2.
Figure 7-2 Placement of root and authentication brokers on Windows
The information that is depicted in Figure 7-2 is used to guide the implementation
team on the deployment of the Symantec products enabled with authentication
and authorization.
In this environment, only one authentication hierarchy is set up. The Symantec
Product Authentication root broker is installed and configured on the same system
as the Symantec License Inventory Manager. All the management servers (such
as SLIM, NBU/NOM and CommandCentral) are installed and configured on separate
systems with their respective authentication brokers.
After the root broker is configured, the authentication broker can be configured
on other management servers in any order. In this use case, the NBU/NOM,
CommandCentral and Storage Foundation servers are configured sequentially.
The following use cases serve as templates with which you can compare your
environment and then implement the appropriate authentication solution. The
basic sequence in which you install each of these Symantec products does not
vary by use case. The individual tasks that are required to configure these
Symantec products for each use case can vary.

In this use case, the Symantec License Inventory Manager (SLIM) uses Symantec
Product Authentication mechanism to authenticate users accessing the SLIM Web
administrative console. An Authentication broker is set up with the appropriate
plug-ins and made available to the SLIM Web console to authenticate users. After
SLIM is configured, users in the slim_users private domain repository are able to
log on to the SLIM Web console.
order:
■ Storage Foundation. Installing the Symantec application server is optional.
■ Infrastructure Core Services (Private Branch Exchange, Authentication, and
Service Management Framework).
■ Symantec License Inventory Manager.
■ Management client or agents from other Symantec products, such as NetBackup
or CommandCentral).
The Symantec License Inventory Manager collects licensing information from
the other Symantec products that are installed on various systems in the
enterprise. SLIM consists of a management server and a management agent. The
management agent collects the licensing information and reports it to the
management server. The management server stores the licensing data in a central
repository. The SLIM management agent is typically deployed on systems that
have NetBackup, CommandCentral, Storage Foundation, and other Symantec
products installed.
Figure 7-3 shows the deployment of SLIM in an enterprise.
Figure 7-3 Deploying Symantec License Inventory management server and

agent
It is highly recommended that you install and configure the SLIM management
server on a system without other management servers installed. After the
management server is configured and functional, you can install the management
agent.
The SLIM product versions used in this Yellow Book edition are listed in Table 7-1.
This SLIM version is dependent on the infrastructure that is provided by the
Symantec Product Authentication Service (AT), Private Branch Exchange (PBX),
and the Service Management Framework (SMF) core services components. On
systems that have the SLIM management server, access points, and management
agents, these shared components must be installed and configured. You can install
and configure these shared components manually, or you can let the SLIM installer
automatically install them. SLIM management server uses the Web Server Service
for console logon.
Table 7-1 Symantec License Inventory Manager shared component

dependencies
SLIM Authentication service PBX SMF
4.1 4.2 4.3 1.2 1.3 1.2 1.3
4.0.4
The installer of this SLIM version automatically configures a root broker plus
authentication broker on the system for the SLIM management server.

The SLIM management server and agents are deployed and verified primarily on
the Windows platform. A SLIM management server that is configured on Windows
is able to work with management agents that are deployed on UNIX and Linux
platforms. In this setup, the management agents that are installed on HP-UX and
Red Hat platforms are configured to report to the SLIM management server on
Windows.
Application server
The SLIM management server and agent can be installed on their respective
systems. They do not require the installation of a Symantec application server
such as Storage Foundation for Windows or Storage Foundation HA for Windows.
The SLIM management server can collect the licensing information from any
systems that have Storage Foundation, NetBackup, and CommandCentral installed
across UNIX/Linux and Windows platforms.
Deploy the Symantec License Inventory Manager management server

on Windows
In this use case, the SLIM management server is deployed on a dedicated Windows
system that runs the Windows Server 2003 Enterprise Edition SP1 operating
system. The shared core services products on which SLIM depends are installed
by the SLIM installation script. The shared core services products include
Authentication, Private Branch Exchange, Service Management Framework, and
Web Server Service. Any user who accesses the SLIM Web console must be
authenticated through a valid authentication domain and plug-in. A valid product
license key is required to install the SLIM management server.
To deploy the SLIM management server on Windows
1 Navigate to the directory that contains the Symantec License Inventory
Manager installation media and locate the setup file, subtypes.
2 Double-click subtypes. The Choose Setup Language dialog displays. Use this
window to select additional languages to install.
3 Click I accept the terms in the license agreement radio button, and then click
Next.
4 On the Symantec License Inventory Manager – InstallShield Wizard panel,
highlight the Symantec License Inventory Server, type the license key in the
Enter license key field, and then click Next.
5 Check each check box that corresponds to each language that you want to
install, and then click Next.
6 In the Ready to Install Program window, click Install.
7 In the InstallShield Wizard Completed window, click Finish.
8 Go to Control Panel > Add or Remove Programs and verify that the SLIM
management server, Private Branch Exchange, Authentication, and Service
Management Framework were installed successfully.
A system that has the SLIM Management Server configured could have
Management agents or client of other Management Servers deployed as well.
These agents or clients may or may not have the authentication enabled. As an
example, a NetBackup management client could be installed on the system that
has the SLIM management server.
Deploy SLIM management agents on Windows

In this use case, the SLIM management agents are deployed on the following
systems:Windows running Windows Server 2003 Enterprise Edition SP1, HP
running HP-UX 11.23 (either PA-RISC or IA64) and Red Hat running EL 4.0 on
32-bit mode. These SLIM management agents are configured to report to the same
SLIM management server. SLIM Management agents on Windows are assigned
to an authentication broker that is configured on Windows. On HP-UX and Red
Hat platforms, the SLIM management agents are authenticated by authentication
brokers that are configured on HP-UX and Red Hat, respectively.
On Windows, you can install a SLIM management agent and configure it to report
to a SLIM management server that is configured on Windows.
1 Navigate to the directory that has the SLIM installation files and click
setup.exe.
2 Select the setup language and any additional languages to install on the
system.
3 On the Symantec License Inventory Agent Configuration screen, specify the
following configuration data. The Server/Access Point is the name of the
system (in this example, mercury) that has the SLIM management server
configured.
Server/Access Point hostname mercury

Enable Security Yes
Configure Security at this time Yes
Start agent after Install Yes
4 Copy the root hash file from the system with the root broker to the local
system on which you want to install the SLIM agent. The username is the
slim_agent authentication principal that is created in the slim_services private
domain repository that is located on the system mercury (on Windows, use
the short host name and not an FQHN such as mercury.universe.com). In
this example, all the Windows systems belong to the Windows private domain
named sun.
Authentication Broker Hostname mercury

Authentication Broker Port Number 2821
Authentication Broker Hash c:\TEMP\root_hash
Access Point/Server username slim_agent
Access Point/Server
domain name slim_services@mercury.sun.universe.com
Access Point/Server domain Type vx
Follow the prompts.

5 Click Install to install the SLIM management agent, and then click Finish.
6 Go to Control Panel, and then select Add or Remove programs to verify that
the SLIM management agent, Private Branch Exchange, Authentication, and
Service Management Framework were installed successfully.
7 After a SLIM management agent is installed successfully, verify that the SLIM
management agent is configured to report to the correct SLIM management
server.
To install a SLIM management agent on HP-UX or Red Hat, and configure it to
report to the SLIM management server on Windows, refer to the following section:
See “SLIM management agents” on page 140.
A system with the SLIM management agent installed can also have management
agents or clients of other management servers installed. These other agents or
clients may not have the authentication enabled. For example, the
CommandCentral storage agent may be also installed on the system that has the
SLIM management agent.

When you install the SLIM product in an enterprise that already has the
authentication hierarchy, you should consolidate the root broker that is configured
by the SLIM product with the existing authentication hierarchy. Whether to keep
the existing root broker, or the root broker configured by SLIM, is a decision that
is specific to the enterprise. Nevertheless, it is highly recommended that one
NetBackup use case
authentication hierarchy be used throughout the enterprise. If you keep the

existing root broker, you must replace the root broker that is created by the SLIM
installation with the existing root broker on another system.
Symantec License Inventory Manager-related upgrade

A Symantec License Inventory Manager upgrade typically involves one or more
of the following components:
■ Symantec License Inventory Manager (management server or agents)
■ One or more of the shared core services components on which the Symantec
License Inventory Manager depends
Before you upgrade the SLIM component on the system, you must stop the SLIM
service. To upgrade the SLIM management server, you must follow the instructions
in the SLIM installation guide. A new release may have additional steps that are
required during the upgrade. On systems that have the SLIM management agents,
you can upgrade the agents after you upgrade the SLIM management server.
Usually, the upgrade of the SLIM component on a system does not affect the
shared core services components on which SLIM depends. However, it is a good
idea to consult the SLIM documentation that comes with the upgrade before
making the final determination.
SLIM is dependent on the shared core services. To upgrade one or more of these
components, you must first halt the SLIM management server and the affected
core services. You must upgrade these core services and verify that these services
started successfully. Also, you must stop and start the other core services even
though those shared components were not upgraded. You can start the SLIM
management server and verify successful logon to the SLIM Web console.
See “ Authentication and authorization service upgrade” on page 75.
NetBackup use case

In this use case, NetBackup uses the authentication mechanism that is provided
by the Symantec Product Authentication Service to authenticate ordinary users
accessing the NetBackup subsystems. After obtaining valid authentication
credentials, ordinary users can perform product management through the
NetBackup use case
product’s administrative Web console and execute privileged NetBackup commands

from the command line. One or more Authentication brokers are set up with the
appropriate plug-ins to authenticate NetBackup users (including the administrator)
and services (NetBackup media servers and clients). The Authorization service is
also set up on the system where the NetBackup master server is configured. After
a user has acquired a valid authentication credential, the access control
functionality that is provided by the Symantec Product Authorization is used to
decide which operations the user is permitted to do, for example, policies and
storage unit manipulation.
order:
■ Storage Foundation (this is optional unless Veritas Volume Manager is
required).
■ Infrastructure Core Services (Private Branch Exchange, authentication and
authorization). Authentication and authorization products are required for
enabling NetBackup Access Control.
■ NetBackup.
■ Management agents from other Symantec products (for example,
CommandCentral, Symantec License Inventory Manager).
NetBackup provides backup and recovery services for the systems that are deployed
throughout the enterprise. NetBackup has management servers (master and
media) and management client (or simply client) components. You can configure
a NetBackup policy on the Master server for a client that contains data to back
up. A backup is typically initiated from the master server. During the backup, a
client reads the data from the system and sends it to the media server and then
to a storage unit. Usually, the NetBackup management client is deployed on the
systems that have SLIM, CommandCentral, Storage Foundation, and other
Symantec products installed.
Figure 7-4 depicts the deployment of NetBackup in an enterprise.
NetBackup use case
Figure 7-4 Deploying NetBackup management server and clients
It is highly recommended that you install and configure the NetBackup and
NetBackup Operations Manager (NOM) master management server on a system
that is reserved exclusively for this management server. After you configure the
master server, you can install the media management servers. You install the
NetBackup management clients last. To verify that the setup is functional, you
can initiate a backup from the master server for a client using one of the media
servers and restore the backup to a different client.
Referring to Figure 7-2, on the system that has the NetBackup master management
server, an authentication broker and the authorization service are also configured.
Additional authentication brokers may be required and configured on systems
that have media servers. Typically, each authentication broker is configured for
an authentication domain with a specific plug-in. When you add new authentication
brokers to an existing authentication hierarchy, you must perform preparatory
steps for these brokers from the system with the existing root broker.
The configuration of NetBackup and with Access Control (authentication and
authorization) requires two separate configuration procedures. You must add the
Access Control capability to NetBackup after the management servers (master
and media) and management clients are configured and functional.
A large enterprise may need multiple NetBackup master servers configured for
different backup and recovery purposes. The following procedures and
configuration instructions for NetBackup can be repeated when adding new
NetBackup management servers (master and media) and clients with Access
Control.
NetBackup use case

Windows is the primary platform on which the NetBackup management servers
(master and media) and clients are deployed and verified. The NetBackup master
management server also manages, in addition to the Windows platform, the
NetBackup media management servers and management clients that are
configured on UNIX and Linux platforms with HP-UX and Red Hat operating
systems.
Application server
On Windows, by default, the binaries and data files for the NetBackup management
servers and clients are installed in the C:\Program Files directory on their
respective systems. To install the NetBackup product on a separate Microsoft file
system that uses Veritas Volume Manager, you must first install a Symantec
application server such as Storage Foundation for Windows or Storage Foundation
HA for Windows.
NetBackup management servers

The versions of the NetBackup product and the shared infrastructure core services
components on which NetBackup depends are listed in the tables contained in
the Master server and Media servers sections below. Starting with the NetBackup
6.0 release, Private Branch Exchange is required by the NetBackup master and
media servers. On Windows, the NetBackup installer automatically installs PBX
on a system (if it is not yet installed) with either a master or media server. Before
you configure a master server or a media server for access control (enable
authentication and authorization), you must first install Symantec Product
Authentication and Authorization on the system. On a system with the NetBackup
master management server, you must first configure a local authentication broker
and authorization service. On a system with a NetBackup media management
server, only the client portion of Symantec Product Authentication and
Authorization is required.
Note: To add a master server to an enterprise or to add a new media server to an

existing master server, you can repeat the procedures in this section on each new
system.
NetBackup use case
Master server
It is recommend that you install the NetBackup master server on a system on
which only this management server is active and running.
Table 7-2 shows the version of the NetBackup product and the corresponding
version of the Private Branch Exchange shared component that is used by the
NetBackup master server.
Table 7-2 NetBackup master server dependency on Private Branch Exchange
1.2 1.3
6.0MP4
The NetBackup master management server is installed on a Windows Server 2003

Enterprise Edition SP1 operating system. This master management server also
manages NetBackup media servers and clients that are configured on Windows,
HP-UX, and Red Hat. You must enter a valid license key during the NetBackup
installation. The NetBackup installer checks for the presence of the PBX shared
component and verifies that the PBX service is started. See the Install and
configure Private Branch Exchange section in Appendix B for installation
instructions. The NetBackup installer performs neither authentication nor
authorization related configuration.
To install and configure a NetBackup master management server on Windows
1 In Windows Explorer, navigate to the directory that has the NetBackup
installation files, and then click launch.exe.
2 On the Veritas NetBackup for Windows screen, select the NetBackup
Installation and Install Server Software options.
3 On the License Agreement screen, click accept.
4 On the NetBackup Installation Type screen, select Typical installation and
choose the Install to this computer only option.
5 On the NetBackup License Key and Server Type screen, enter the NetBackup
license key. The license key determines the options (master, media, or remote
administrative console) that are available for the installation.
NetBackup use case
6 On the NetBackup System Names screen, in the Master Server Name: field,
enter the host name (short form) of the system on which to install the
NetBackup master management server. Specify additional servers in the
Additional Servers field. In this use case, the host name for the NetBackup
master management server is jupiter (the FQHN is jupiter.universe.com).
Master Server Name: jupiter

Additional Servers:
7 On the NetBackup Enterprise Media Manager (EMM) screen, enter the host
name of the system on which to locate the EMM database as shown below. In
this use case, the EMM database is installed on the same system as the
NetBackup master server.
Enterprise Media Manager Server: jupiter
8 On the Ready to Install the Program screen, click Install to begin the
installation of the NetBackup master management server. The Installing
NetBackup screen displays the progress of each installation step, including
Validating install, Copying new files, Starting services, and Creating
NetBackup template policies.
9 On the System Validation Complete screen, to add additional NetBackup
license keys, click the Add keys and enter more license keys. In this setup, a
tape library is shared (SSO) among all the media management servers and a
license key is required to enable the SSO option. The configuration of
NetBackup involves the following tasks:
■ Configure Storage Devices
■ Configure Volumes
■ Configure the Catalog Backup
■ Create a Backup Policy
On the NetBackup Administrative Console screen, NetBackup provides
configuration wizards to assist a NetBackup administrator with these
configuration tasks. Before performing the Storage Devices configuration,
the physical devices must be already connected to the system. The
device-drivers software that is distributed by the NetBackup product must
be installed on the system before you invoke the Configure Storage Devices
configuration wizard.
If the system already has the tape devices attached and has met the conditions
that are listed for the Storage Devices, check the Launch NetBackup
Administrative Console now check box to start the NetBackup configuration.
NetBackup use case
Otherwise, defer the configuration tasks. Click Finish to exit the System
Validation Complete screen.
10 On the NetBackup Administrative Console, Activity Monitor, select the
Services and Processes to verify that the services and NetBackup processes
are online.
11 To verify that the operating system can see the tape libraries and devices on
a system, see the NetBackup Tape Device Drivers section in Appendix C for
verification procedures.
12 To create a storage unit on the master management server, see the NetBackup
storage units section in Appendix C for details.
13 From the Control Panel, select Add or remove programs and verify that
NetBackup was installed.
14 To install the Java Windows Administration Console on the same system as
the NetBackup master management server, see the NetBackup Java Windows
Administration Console section in Appendix C for detailed procedures.
To upgrade the NetBackup master server software
1 Before you upgrade the NetBackup master server software, stop the NetBackup
management server. Use the following commands to stop and start NetBackup
master management server.
C:\Program Files\VERITAS\NetBackup\bin> bpdown

C:\Program Files\VERITAS\NetBackup\bin> bpup
2 Locate the NetBackup maintenance pack distribution. In Windows Explorer,

navigate to the directory with the NetBackup installation files, and then click
setup.exe.
3 On the NetBackup Installation Type screen, chooseInstall to this computer
only, and then follow the instructions on the screen.
4 On the Ready to Install the Program screen, click Install to start the
installation.
5 On the Installing NetBackup screen, the version of the maintenance pack and
the installation status is displayed.
6 On the System Validation Complete screen, click Finish.
7 Go to Control Panel, Add or remove programs and verify that the maintenance
pack was installed on the system.
NetBackup use case
8 If NetBackup Access Control (NBAC) was enabled on the master management

server, after upgrading NetBackup, verify the NBAC setup.
See “Verify NetBackup access control setup on the master server” on page 246.
9 Start the NetBackup master management server.
On the system that has the NetBackup master management server configured,
management agents of other Management Servers can be deployed. These agents
may have the authentication enabled. As an example, on the system that has the
NetBackup Master Server, SLIM, and CC Service Agents are likely to be found on
the same system.
Media servers
The version of the NetBackup media management server that is used in this Yellow
Book edition is dependent on the service that is provided by the Private Branch
Exchange. The service that is provided by the PBX shared component must be
online before you install the NetBackup media management server.
Table 7-3 depicts the version of NetBackup and the version of the PBX shared
component that is used by the NetBackup media server.
Table 7-3 NetBackup media server dependency on Private Branch Exchange
1.2 1.3
6.0MP4
Before you install the NetBackup media management servers, it is assumed that
the NetBackup master management server has already configured and functional.
In this setup, a media management server is configured on Windows, HP-UX and
Red Hat, respectively, for the NetBackup master management server that is
configured on Windows. Having multiple media servers in an enterprise allows
many backup or recovery jobs to occur concurrently. Typically, a client is assigned
to a media server on the same platform–an HP-UX client interacting with a media
server on HP-UX. It is a supported configuration to have management clients on
Red Hat interacting with a media management server that is configured on an
HP-UX platform.
This installation session illustrates the installation for the NetBackup 6.0 release.
A maintenance pack must be applied to the 6.0 release to upgrade the NetBackup
product to the most recent version.
NetBackup use case
To install and configure a NetBackup media management server on Windows

1 In Windows Explorer, navigate to the directory that has the NetBackup
installation files and select launch.exe.
Installation and Install Server Software options.
3 On the License Agreement screen, click accept.
pick the Install to this computer only option.
5 On the NetBackup License Key and Server Type screen, enter the NetBackup
license key. The license key determines the options (master, media, or remote
administrative console) that are available for the installation.
6 On the NetBackup System Names screen, in the Media Server Name field,
enter the host name (short form) of the system where the NetBackup media
management sever is to be installed. In the Master Server Name: field, enter
the host name (short form) of the system where the NetBackup master
management server is to be installed. Specify additional servers in the
Additional Servers field. In this use case, the host name for the NetBackup
media and master management servers are leda and jupiter (the FQHNs
are leda.universe.com and jupiter.universe.com), respectively.
Media Server Name: leda

Additional Servers:
7 On the NetBackup Enterprise Media Manager (EMM) screen, enter the host
name of the system where the EMM database is located. In this use case, the
EMM database is installed on the system that has the NetBackup master
management server.
Enterprise Media Manager Server: jupiter
installation of the NetBackup media management server.
NetBackup use case
9 On the System Validation Complete screen, to add additional NetBackup

license keys, click the Add keys and enter more license keys. In this setup, a
tape library is shared (SSO) among all the media management servers and a
license key is needed to enable the SSO option.
Before you perform the Storage Devices configuration for the media
management server, the physical devices must be already connected to the
system with the media server. The device-drivers software that is distributed
by the NetBackup product must be installed on the system before you invoke
the Configure Storage Devices configuration wizard.
If the system already has the tape devices attached and has met the conditions
listed for the Storage Devices, check the Launch NetBackup Administrative
Console now check box to start the NetBackup configuration. Otherwise, defer
the configuration tasks.
Click Finish to exit the System Validation Complete screen
10 On the NetBackup Administrative Console, Activity Monitor, select the
Services and Processes to verify that the services and NetBackup processes
are online.
11 To verify the operating system could see the tape libraries and devices on a
system, refer to the NetBackup Tape Device Drivers section in Appendix C
for verification procedures.
12 To create a storage unit for the media management server, refer to the
NetBackup storage units section in Appendix C for details.
13 From the Control Panel, select Add or Remove Programs and verify that
NetBackup was installed.
14 After the installation is complete, verify that the media's master management
server in the registry is correct. Click Start > Run, and then type regedit.
Verify that the Server registry entry points to the correct master management
server:
HKEY_LOCAL_MACHINE\Software\VERITAS\NetBackup\CurrentVersion\config
If there is a need to install the Java Windows Administration Console on the system
with a media management server, refer to the NetBackup Java Windows
Administration Console section in Appendix C for detailed procedures.
To upgrade the NetBackup software on the a system with media management
server, the same procedure that is used in the Master server section should be
used. The NetBackup software on a media management server is upgraded after
the master management server has been upgraded. If the NBAC was enabled on
a media management server, after upgrading the NetBackup software, the Verify
NetBackup use case
NetBackup access control setup on media servers procedure listed in Appendix C

should be used to ensure the media management server is working.
See the corresponding NetBackup use case section in Chapter 6 for procedures
and steps to install and configure a NetBackup media management server on UNIX
and Linux.
Adding a media server to the master server

This step is to be performed on the system where the NetBackup master
management server is configured. The host to be added as the media management
server should have the NetBackup media server software installed already.
On the NetBackup Administration Console, go to the NetBackup Management,
Host Properties, Master Server. Highlight the master server, right click and choose
properties. The Master Server Properties: jupiter screen appears, click Servers
Properties, and then click Add. In the Add a new server: field, enter the host name
of the new media server leda, and then click Add. This same procedure is used to
add either a Windows or UNIX/Linux (like HP-UX and Red Hat) media server on
a Windows master server.
On the NetBackup Administration Console, launch the Configure Storage Devices
wizard to configure devices and storage units for the new media management
server (leda).
The addition of a NetBackup 5.1MP6 (or later) media server to a NetBackup 6.0MP4
(or any 6.0 version) master server is a supported configuration.
Installing and upgrading the NetBackup management client on

Windows
The NetBackup management client does not depend on the Private Branch
Exchange shared component.
You can apply a maintenance pack to the 6.0 release to upgrade the NetBackup
product to the most recent version.
To install NetBackup management client on Windows
1 In Windows Explorer , navigate to the directory that has the NetBackup
installation files, and then click launch.exe.
2 Choose NetBackup Installation, Install Client Software, Pick Typical and
Install to this computer only.
NetBackup use case
3 Enter the host name (in short format, such as callisto) in the Client Name for
the NetBackup client, and the host name (such as jupiter) in the Master
Server Name: for the master management server. Additional Servers is
optional. Follow the instruction on the screen and verify that the installation
completed successfully.
Client Name: callisto

Additional Servers:
4 From the Control Panel, select Add or remove programs, and then verify that
the NetBackup Client has been installed.
5 After the installation is complete, verify that the client's master management
server in the registry is correct. Click Start > Run, and then type regedit.
Verify that the Server registry entry points to the correct master management
server:
6 You may want to Install Java Windows Administration Console on the system
that has NetBackup client software for remote management. Refer to the
NetBackup Java Windows Administration Console section in Appendix C for
installation procedures.
The upgrade of the NetBackup client software on a management client is done
through these procedures and steps. Typically, the NetBackup software on a
management client is upgraded after the master and media management servers
that are associated with this management client have been upgraded.
To upgrade the NetBackup management client on Windows
1 Locate the NetBackup maintenance pack distribution. On Window Explorer,
navigate to the directory that has the NetBackup installation files, and then
click setup.exe.
2 Click Install to this computer only, and then follow the instructions on the
screen. Verify that the installation Finish successfully.
3 In the Add or remove programs, verify that the maintenance pack has been
installed on the system.
4 If NetBackup Access Control (NBAC) was enabled on a management client,
after upgrading NetBackup, use the Verify NetBackup access control setup
on clients procedure listed in Appendix C to ensure that the master
management server is working.
NetBackup use case
See the corresponding section in the NetBackup use case section in Chapter 6 for
procedures and steps to install and configure a NetBackup management client on
UNIX/Linux.
Enabling access control on a NetBackup master server

Before you enable NetBackup Access Control (NBAC) on the master management
server, the master management server (and possibly all the media and client)
must be set up and functional.
To verify that the NetBackup configuration is working, a successful backup and
restore initiated from the master for a client using this media server should be a
good indicator.
This approach is helpful for the fault isolation. For example, if backup and restore
is successful without NBAC, but fails with NBAC enabled, you can direct your
troubleshooting effort at the NBAC configuration.
In Table 7-4, cells that have the checkmark depict the specific version of the shared
core services (authentication and authorization) that are used by NetBackup
master management server.
Table 7-4 NetBackup master server dependency on authentication and

authorization
NetBackup Authentication service Authorization service
4.1 4.2 4.3 4.1 4.2 4.3
6.0MP4
Other Management agents, such as CC Storage and Service, which are installed
on the same system as the master management server, can be enabled with
authentication. Management agents can use the same shared core services
components.
To set up the NBAC functionality on the master management server, the following
procedures have been tested and proven to work using the configuration described
in this use case chapter. The first portion of the procedures is done from the
command line. The NetBackup Administration console is used to complete the
second portion of the setup.
To enable Access Control on the master management server, one of the preparation
steps is to install and configure authentication and authorization on the system
that has the master management server.
NetBackup use case
In this configuration, only an authentication broker is configured on the system

for the NetBackup master management server. The authentication broker is set
up to use an existing authentication hierarchy that is already configured on the
system with the SLIM management server. To add a new authentication broker
into an existing authentication hierarchy, refer to the Add a new authentication
broker section in Appendix B. Refer to the Install and configure authentication
section in Appendix B for the installation procedures.
Note: On the root broker, when adding the NetBackup principal for the new
authentication broker, the host name (either FQHN like jupiter.universe.com
or short name like jupiter) should be used as the principal name. This
authentication principal that names a convention is required by the NetBackup
release that is used in this Yellow Book edition.
On the system where the NetBackup master management server is installed, the
authorization server is configured also. Due to the dependency between
authentication and authorization, authorization should be installed after the
authentication service. To install the authorization shared component, refer to
the Install and configure authorization section in Appendix B for the installation
procedures.
To enable Access Control on a NetBackup master server
1 A NetBackup master management server has been installed and configured
on a Windows system (jupiter.universe.com) running Windows Server
2003 Enterprise Edition SP1 operating system. Procedures are provided to
enable the NBAC on the master management server.
2 Verify that the NetBackup management server is online.
C:\Program Files\VERITAS\NetBackup\bin> bpps

NetBackup use case
3 Create the authentication domain, NBU_Machines, for the NetBackup

management server. Suppose NetBackup master management server is
configured on system jupiter.universe.com running Windows Server 2003
Enterprise Edition SP1 operating system. In this setup, the system named
jupiter belongs to the private domain named SUN on the Windows Active
Directory. The Windows private domain name is added to the Fully Qualified
Host Name for the authentication broker.
C:\Program Files\VERITAS\NetBackup\bin> bpnbat \

-addmachine
Does this machine use
Dynamic Host Configuration Protocol (DHCP)? (y/n) n
Authentication Broker: jupiter
Authentication port[ Enter = default]: Machine Name: jupiter
Password: <pick a password for jupiter> Password: ******
C:\Program Files\VERITAS\Security\Authentication\bin> vssat \

listpd --pdrtype ab
Domain Name NBU_Machines@jupiter.SUN.universe.com

listpdprincipals --pdrtype ab -domain \
NBU_Machines@jupiter.SUN.universe.com
Principal Name: jupiter.sun.universe.com
NetBackup use case
4 Obtain a valid credential for the master management server.
C:\Program Files\VERITAS\NetBackup\bin> bpnbat -loginmachine

Authentication port[ Enter = default]: Machine Name: jupiter
Password: <pick a password for jupiter>
C:\Program Files\VERITAS\NetBackup\bin> bpnbat -whoami -cf \

..\var\vxss\credentials\jupiter.sun.universe.com
Name: jupiter.sun.universe.com
Domain: NBU_Machines@jupiter.sun.universe.com
Issued by: /CN=jupiter.universe.com/ \
OU=root@mercury.sun.universe.com/O=vx
5 Create an ordinary user at the operating system level to set up the security.
An ordinary user (goku) is created in the Windows Active Directory.
C:\Program Files\VERITAS\NetBackup\bin\admincmd> bpnbaz \

-SetupSecurity jupiter -Server jupiter
Please enter the login information for the first Security
Administrator other than root/Administrator. This identity
will be added to the security administrators group
(NBU_Security Admin), and to the netbackup administrators
group (NBU_Admin). It will also be used to build the initial
security information.

Authentication type (NIS, NIS+, WINDOWS, vx, unixpwd): WINDOWS
Domain: SUN
Login Name: goku
Password: <goku password>
Processing - please be patient Operation completed successfully.
NetBackup use case
6 To find the Domain for WINDOWS (nt) Authentication type, use the following
command:

showallbrokerdomains
Broker Name: jupiter.SUN.universe.com
Broker Port: 2821
Domain Name: SUN
Domain Type: nt
7 Add the following master management server as the host that is authorized
to perform Authorization check:

-AllowAuthorization jupiter \
-server jupiter
To start the second portion of the NBAC configuration, log on to the system that
has the NetBackup master management server enabled with NBAC and invokes
the NetBackup Administration Console through Start, NetBackup Administration
Console.
To enable Access Control from the NetBackup Administration Console server
1 Expand the Host Properties and click the Master Servers, select jupiter as the
master server by clicking the host. In the Status column, it should show
Connected. Click Actions (at the top) and select Properties... On the
Properties… screen, select the Access Control (third from the bottom). In the
Veritas Security Services (VxSS) box, choose Automatic.For the usage on the
VxSS tab, Required, Prohibit and Automatic, refer to the NetBackup access
control parameters section in Appendix C for explanation.
Enter SUN as the Domain: and choose WINDOWS as the Authentication
Mechanism. In the Broker: field, enter jupiter as the authentication broker
and a description for this Authentication Domain. Click Add to insert the
authentication domain. As the authentication mechanism, WINDOWS is
always available on Windows systems. The authentication broker is residing
on the system jupiter.universe.com. To add another authentication domain,
specify the values for the Domain, Authentication Mechanisms, and Broker.
Repeat this procedure for each authentication domain that is supported in
the enterprise.
NetBackup use case
3 Click the Authorization Service tab, and then type jupiter in the Host field.
The authorization server is configured on the system that is entered in the
Host field.
4 Save the changes, and then exit the NetBackup Administration Console. For
the changes to take effect, stop and start the NetBackup master management
server.

NetBackup use case
5 Add the goku and Administrator users to the privileged NetBackup security
groups, NBU_Security Admin and NBU_Admin. "Without adding these users
to these privileged groups, when logging in to the NetBackup Administrator
Console as these users, only the client’s privilege is accessible. To execute
the bpnbaz -adduser, a valid session must be acquired by first performing
a bpnbat -login.
C:\Program Files\VERITAS\NetBackup\bin> bpnbat -login

Domain: SUN
Login Name: administrator
Password: <pick a password for jupiter>
C:\Program Files\VERITAS\NetBackup\bin> bpnbat -whoami

Name: administrator
Domain: SUN
Issued by: /CN=jupiter/OU=root@mercury.SUN.universe.com/O=vx
Authentication method: Microsoft Windows
C:\Program Files\VERITAS\NetBackup\bin\admincmd> bpnbaz -adduser \

"NBU_Security Admin" nt:SUN:administrator

"NBU_Admin" nt:SUN:administrator

"NBU_Admin" nt:SUN:goku
6 Verify that the NetBackup master management server is set up correctly.

See “Verify NetBackup access control setup on the master server” on page 246.
NetBackup use case
7 Without invoking bpnbat -login, operations attempting to access the

NetBackup subsystems would fail with this error message.
C:\Program Files\VERITAS\NetBackup\bin\admincmd> bpnbaz -listgroups

Supplied credential is expired or incorrect. Please reauthenticate
and try again. (25)
8 Log on to the Windows system as either vxss or root. Invoke the NetBackup
Administration Console and verify the user’s Web credential, within
Administration Console, click Help (at the top) and select Current NBAC User.
Enabling access control on a NetBackup media server

Before you enable NetBackup Access Control (NBAC) on a media management
server, the media server must already be configured and associated with a master
server. The master server uses this media server for backing up and restoring
NetBackup clients.
To verify that the NetBackup configuration is working, you can use a media server
to run a successful backup and restore that is initiated from the master for a client.
This approach is helpful for fault isolation. For example, if backup and restore is
successful without NBAC, but fails with NBAC enabled, you can direct your
troubleshooting effort at NBAC configuration.
Table 7-5 shows the specific version of the shared core services (authentication
and authorization) that are used by the NetBackup media management server.
Table 7-5 NetBackup media server dependency on authentication and

authorization
NetBackup Authentication client Authorization client
4.1 4.2 4.3 4.1 4.2 4.3
6.0MP4
Other Management Agents such as CC Storage and SLIM that are installed on the
same system as the media management server can be enabled with authentication
and using the same shared core services components.
On the system that has a NetBackup media management server configured, the
media server needs only the client portion of the authentication and authorization
software installed. However, the following situations would require an
NetBackup use case
authentication broker to be configured on the system that has a NetBackup media

management server. Even though an authentication broker is available locally,
the NetBackup media management server should use a remote authentication
broker that is configured on the master management server.
The NetBackup master management server is configured on Windows and it has
media servers that are configured on HP-UX and Red Hat to back up those
management clients. To authenticate users on HP-UX by using the NISPLUS
plug-in (for example), an authentication broker with the NISPLUS plug-in must
be set up. Ideally, this authentication broker should be set up on the same system
as the media management server on HP-UX to authenticate those users on HP-UX.
Similarly, an authentication broker with the UNIXPWD plug-in could be set up
on the system with the Red Hat operating system to authenticate those Red Hat
users that want to use the UNIXPWD plug-in.
The NetBackup master management server has a media management server. Both
servers are on Windows. The media management server uses the authentication
broker that is configured on the master management server. Another management
agent such as SLIM is installed on the same system as the media management
server. The SLIM agent may require a local authentication broker to be present.
In this scenario, the NetBackup media management server does not use the local
To set up the NBAC functionality on the media management server, the following
procedures have been tested and proven to work using the configuration described
in this use case chapter. The first portion of these procedures is done from the
command line. The NetBackup Administration console is used to complete the
second portion of the setup.
A NetBackup media management server has been installed and configured on a
Windows system (leda.universe.com) that runs Windows Server 2003 Enterprise.
This media server is associated with a master management server that is
configured on a Windows system (jupiter.universe.com) that runs the Windows
Server 2003 Enterprise operating system. Procedures are provided to enable the
NBAC on the media management server. These procedures can be used for adding
a media management server that is configured on other Windows platforms.
See “Enable access control on a NetBackup media server” on page 108.
To enable NBAC on a media management server that is configured on a dedicated
system, you must install the client portion of the authentication and authorization
products on the system. The client portion of the authorization product should
be installed on the system that has the media management server. Due to the
NetBackup use case
products dependency between authentication and authorization, authorization

should be installed after the authentication product.
To enable access control on a NetBackup media server
1 Procedures described in this setup must be executed on the master
management server – jupiter.universe.com.
2 Create an authentication principal for the system that has the media
management server.

-addmachine
Machine Name: leda
Password: <pick a password for leda>
Password: <pick a password for leda>

listpdprincipals --pdrtype ab \
--domain NBU_Machines@jupiter.sun.universe.com
Principal Name: leda.sun.universe.com
C:\Program Files\VERITAS\NetBackup\bin> bpnbat -ShowMachines

jupiter.sun.universe.com
leda.sun.universe.com
NetBackup use case
3 Procedures described in this step must be executed on the system with the
new media management server: leda.universe.com. Obtain the machine
credential for the system leda.universe.com.

-loginmachine
Machine Name: leda
Password: *****

..\var\vxss\credentials\leda.sun.universe.com
Name: leda.sun.universe.com
Issued by: /CN=broker/OU=root@mercury.sun.universe.com/O=vx
4 Procedures described in this step must be executed on the master management

server: jupiter.universe.com. Authorize the system with the media
management server to perform authorization check:

-AllowAuthorization leda -server jupiter

-Showauthorizers -server jupiter
Type: User
Domain Type: vx
Name: leda.sun.universe.com

server – jupiter.universe.com. To start the second portion of the NBAC
configuration, log on to the system as either administrator or a NBAC enabled
user, go to Start menu and launch the NetBackup Administration Console.
NetBackup use case
6 Expand the Host Properties, click Media Servers, and then select leda as the
media server by clicking the host. The Status column should show Connected.
7 In Click Actions (at the top) and select Properties... On the Properties… screen,
select the Access Control.
8 In the Veritas Security Services (VxSS) box, choose Automatic For the usage
on the VxSS tab, Required, Prohibit and Automatic, refer to the NetBackup
access control parameters section in Appendix C.
9 Click the Authentication Domains tab, and then click Add.
10 Enter SUN as the Domain, and then select WINDOWS as the Authentication
Mechanism.
11 In the Broker field, type jupiter, and type a description for this Authentication
Domain. The authentication broker resides on the system
jupiter.universe.com.
The media management server that is configured on leda.universe.com

uses the remote authentication broker that is configured on the maser
management server (jupiter.universe.com).
12 Click the Authorization Service tab, and then type jupiter in the Host field.
The media server uses the global authorization database that is configured
on the system jupiter.universe.com.
13 Save the changes, and then exit the Administration Console. For the changes
to take effect, stop and start the NetBackup media management server.

14 Procedures described in this step must be executed on the media management

server: leda.universe.com.
15 Click Start > Run, and then type regedit.
16 Navigate to the NetBackup configuration and verify that these parameters
(Server, Client_Name, AUTHENTICATION_DOMAIN,
AUTHORIZATION_SERVICE, USE_VXSS) in the Windows registry are correct.
NetBackup use case
17 Procedures described in this step must be executed on the media management

server: leda.universe.com. You can now log in to NetBackup via the CLI and
verify the expiry period.

Domain: SUN
Password: <administrator’s password on leda>

Name: ADMINISTRATOR
Domain: SUN
Issued by: /CN=jupiter.universe.com/ \
OU=root@mercury.sun.universe.com/O=vx
18 Invoke the NetBackup Administration Console, click Help (at the top), and
then select Current NBAC User to verify the user’s Web credential.
To enable NBAC on a UNIX or Linux media management server (with a master
server on Windows), follow the procedures and steps listed below. If the
environment has a UNIX or Linux master management server and a Windows
media management server, refer to the Enable access control on NetBackup media
servers section in Chapter 6.
On a UNIX system (janus.universe.com) with HP-UX 11.23 operating system, a
NetBackup media management server is configured. It is a prerequisite that the
HP-UX media management server is operational before attempting to enable the
NBAC functionality. At a minimum, a successful backup and restore must be
performed for a client that uses this media management server.
Authentication plug-ins such as Windows are not supported on UNIX/Linux. Users
on a UNIX or Linux system (such as HP-UX) with a media management server
cannot use a Windows authentication broker with a Windows plug-in. Therefore,
an authentication broker with an appropriate plug-in (such as UNIXPWD or
NISPLUS) can be configured on HP-UX to authenticate the users on the HP-UX
system. Users who operate on HP-UX can use a remote authentication broker.
NetBackup use case
A future release of the NetBackup product may support plug-ins like LDAP that
can be used for cross-platform (UNIX/Linux and Windows) user authentication.
To enable NBAC on a UNIX or Linux media management server
server – jupiter.universe.com. Use the following command to create an
authentication principal for the HP-UX system that has the media
management server.
C:\Program Files\VERITAS\NetBackup\bin> bpnbat -addmachine

Machine Name: janus.universe.com
Password: <pick a password for janus>

listpdprincipals --pdrtype ab \
Principal Name: janus.universe.com

-ShowMachines
janus.universe.com
NetBackup use case
2 Procedures described in this step must be executed on the system with the
HP-UX media management server: janus.universe.com. Obtain the machine’s
credential for the system janus.universe.com.
/usr/openv/netbackup/bin# ./bpnbat -loginmachine

Machine Name: janus.universe.com
/usr/openv/netbackup/bin# ./bpnbat -whoami -cf \

..\var\vxss\credentials\janus.universe.com
Name: janus.universe.com

server – jupiter.universe.com. Authorize the system with the media
management server to perform authorization check.

-allowauthorization janus.universe.com \
-server jupiter

server – jupiter.universe.com. To start the second portion of the NBAC
configuration, go to Start menu and invoke the NetBackup Administration
Console.
NetBackup use case
5 Expand the Host Properties and click the Media Servers, select
janus.universe.com as the media server by clicking the host. In the Status
column, it should show Connected. Click Actions (at the top) and select
(others are Required and Prohibit). For the usage on the VxSS tab, Required,
Prohibit and Automatic, refer to the NetBackup access control parameters
section in Appendix C for explanation.
Enter janus.universe.com as the Domain: and choose UNIXPWD as the
Authentication Mechanism. In the Broker: field, enter janus.universe.com
and a description for this Authentication Domain. The authentication broker
resides on the system janus.universe.com.
In this setup, an authentication broker is configured on the local system
janus.universe.com and it is used by the media management server to
acquire authentication credentials for UNIX/Linux users.
This media server uses the global authorization database configured on the
system jupiter.universe.com. Click the Authorization Service tab and
enter jupiter in the Host field.
to take effect, stop and start the NetBackup media management server.

8 Verify that the NetBackup media management server is set up correctly.

See “Verify NetBackup access control setup on media servers” on page 254.
Enable access control on a NetBackup client

Before the NetBackup Access Control (NBAC) is enabled on a NetBackup
management client, the management client must be managed by the master and
media management servers. To verify that the NetBackup configuration is working,
a successful backup and restore initiated from the master for a client using this
media server should be a good indicator.
NetBackup use case
This approach is helpful for fault isolation. For example, if backup and restore by
using this management client is successful without NBAC, but fails with NBAC
enabled, you can direct your troubleshooting effort at NBAC configuration.
Table 7-6 shows the specific version of the shared core service (authentication)
that is used by the NetBackup management client.
Table 7-6 NetBackup client dependency on authentication
NetBackup Authentication client
4.1 4.2 4.3
5.1MP6
6.0MP4
Management Agents that are installed on the same system as the management
client can be enabled with authentication and use the same shared core services
components.
Even though the NetBackup management client needs only the client portion of
the authentication product, other Symantec management servers or agents that
are installed on the same system as the NetBackup management client can install
an authentication broker. Users who reside on the NetBackup management client
are authenticated by using a remote authentication broker that is configured on
the system with either a master or a media management server.
To set up the NBAC functionality on a management client, the following procedures
have been tested and proven to work using the configuration described in this
use case chapter. The first portion of the procedure is done from the command
line. The NetBackup jnbSA Java GUI is used to complete the second portion of the
setup.
In this scenario, a NetBackup management client has been installed and configured
on a Windows system (callisto.universe.com) that runs on Windows Server
2003 Enterprise Edition SP1. This NetBackup client is managed by the master
management server that is configured on a Windows system
(jupiter.universe.com) that runs on Windows Server 2003 Enterprise Edition
SP1. Procedures are provided to enable the NBAC for this NetBackup management
client. These procedures can be used for adding UNIX or Linux management clients
to the master management server on Windows.
To enable NBAC for a management client, you must install the Symantec Product
Authentication client software on the system that has the management client. To
install the authentication client software, refer to the Install and configure
authentication section in Appendix B for the installation procedures.
NetBackup use case
To set up the NBAC functionality on a management client

server – jupiter.universe.com. To enable the NBAC for a management
client, an authentication principal must be created for the system where the
NetBackup management client is installed. Repeat this step for each
management client to be enabled with the NBAC. In this example, an
authentication principal is added for the system callisto.universe.com in
the NetBackup NBU_Machines private domain repository.

-addmachine
Authentication Broker: jupiter.universe.com
Machine Name: callisto.universe.com
Password: <pick a password for callisto>
C:\Program Files\VERITAS\Security\Authentication\bin>
vssat listpdprincipals \
--pdrtype ab \
Principal Name: callisto.sun.universe.com
C:\Program Files\VERITAS\NetBackup\bin>
bpnbat -ShowMachines
callisto.sun.universe.com
NetBackup use case
2 Procedures described in this step must be executed on the management client

– callisto.universe.com. Use the following command to obtain the
credential for the system callisto.universe.com:

-loginmachine
Authentication Broker: jupiter.universe.com
Machine Name: callisto.universe.com

..\var\vxss\credentials\callisto.SUN.universe.com
Name: callisto.sun.universe.com

server: jupiter.universe.com. Use the NetBackup Administration Console
to modify the Access Control properties for a NetBackup management client
– Start, NetBackup Administration Console.
4 Expand the Host Properties and click the Clients, select callisto as the
management client by clicking the host. In the Status column, it should show
Connected. Click Actions (at the top) and select Properties... On the
Properties… screen, select the Access Control (second one from the bottom
of the list). In the Veritas Security Services (VxSS) box, choose Automatic.
For the usage on the VxSS tab, Required, Prohibit and Automatic, refer to the
NetBackup access control parameters section in Appendix C for explanation.
5 Click the Authentication Domains tab, and then click Add. Enter SUN as the
Domain: and choose WINDOWS as the Authentication Mechanism. In the
Broker: field, enter jupiter and a description for this Authentication Domain.
6 Repeat the steps listed above for each NetBackup management client that
uses the NBAC capability.
NetBackup use case
to take effect, stop and start the NetBackup master management server.

8 Procedures described in this step must be executed on the NetBackup

management client – callisto.universe.com. Click Start > Run, and then
type regedit. Navigate to the NetBackup configuration and verify these
parameters (Server, Client_Name, AUTHENTICATION_DOMAIN, USE_VXSS)
in the Windows registry are correct.

Domain: SUN
Password: <administrator’s password on callisto>

Name: ADMINISTRATOR
Domain: SUN
Issued by: /CN=jupiter/OU=root@mercury.SUN.universe.com/O=vx
Invoke the NetBackup Administration Console and verify the user credential,
within Administration Console, click Help, and then select Current NBAC User.
A session is valid for 24 hours.
To enable NBAC on a UNIX/Linux management client (calypso.universe.com)
with master server on Windows, follow the steps and procedures listed in this
section. The differences are the values in the Domain, Authentication Mechanisms,
and the Broker: fields. For a UNIX/Linux management client, the Domain: should
be set to janus.universe.com (an authentication broker configured on HP-UX),
the Authentication Mechanisms: should be set to UNIXPWD, and the Broker:
should be set to janus.universe.com.
NetBackup use case
The NBAC configuration for NetBackup management client is now complete. Use
the procedures listed in the NetBackup access control setup verification on clients
section in Appendix C to verify that the NetBackup management client is setup
correctly.
If the environment has a UNIX/Linux master management server and Windows
management client, refer to the Enable access control on NetBackup clients section
in Chapter 6 for detailed instructions.
In Appendix C, the NetBackup access control troubleshooting tips section has a
list of common errors and resolutions tips.
Environment with an existing authentication hierarchy

In an enterprise where the NetBackup product is to be deployed with access control,
suppose an authentication hierarchy has already being created for another
Symantec product. When the Symantec Product Authentication Service is installed
for the NetBackup product, inadvertently, a new authentication hierarchy
configuration is also created. In Chapter 5, the Multiple root brokers section
discussed the extraneous work authentication brokers from different root
hierarchies must perform before meaningful authentication can occur. The root
broker that is configured for the NetBackup product can be replaced and the
NetBackup authentication broker can be changed to point to the existing root
broker on another system. Refer to the Replace the root broker on the NetBackup
master server section in Appendix C for detailed procedures on how to assimilate
an authentication broker from one authentication hierarchy into another.
Upgrading NetBackup and shared components

The NetBackup installation is used to install and upgrade the NetBackup software
on systems that have either management client, master, or a media management
server installed. The NetBackup installation does not upgrade the shared core
services components (AT and AZ) that are used by NetBackup Access Control. An
upgrade to a specific NetBackup version calls for the upgrade of the shared
components. The respective product’s installation script that are provided by the
shared products should be used to perform the upgrade.
After you complete a NetBackup upgrade, you should verify that NetBackup works
with the shared products that are configured on the system.
If one or more of the shared products are upgraded while the NetBackup software
remains unchanged, the proper operation of NetBackup must be verified through
the backup and restore procedures. If other Symantec agents are installed on the
same system as NetBackup, you must ensure that the new version of the shared
NetBackup Operations Manager use case
components can work with the management agents that are already present on
the system. Most of the time, it is prudent to test the configuration in a test
environment before you deploy the new version of the shared components to the

NetBackup Operations Manager (NOM) is a GUI-based administrative tool that
provides a centralized management for all the NetBackup master servers that are
deployed throughout the enterprise. In this setup, the NOM management server
is deployed on the same system as the NetBackup master management server.
Figure 7-4 depicts the deployment of NetBackup in an enterprise.
order:
■ Storage Foundation (it is optional to install this product unless the Veritas
Volume Manager is needed).
■ NetBackup (either client, media or master binaries).
The NetBackup Operations Manager uses the authentication mechanism that is
provided by the Symantec Product Authentication to authenticate users by
accessing the NOM Web administrative console. An Authentication broker is set
up with the appropriate plug-ins and made available to the NOM Web console for
authenticating users. After NOM is configured, users in the NOM_BuiltIn private
domain repository should be able to log on to the NOM Web console.
Note: In an enterprise, NOM is typically installed on a system that has only the
management server configured. In this setup, NOM needs only the NetBackup
client software installed on the system.
The following table depicts the version of the NOM product and the versions of
the AT and PBX shared components that are used by the NOM management server.
Table 7-7 NetBackup Operations Manager usage matrix
NetBackup Operations Authentication service Private Branch Exchange

Manager
4.1 4.2 4.3 1.2 1.3
6.0MP4

The version of NOM product that is used in this use case is supported on Windows
and Solaris. In this use case, NOM product is deployed on Windows with its
management server configured on the same system as the NetBackup master
management server. The NOM Management Server that is deployed on Windows
can manage NetBackup Master Servers that are deployed on other operating
systems (such Windows, Solaris, AIX, HP-UX, Red Hat and SUSE). To use NOM
for managing NetBackup 5.1 Master Server, consult the NOM product
documentation to see if the version of NOM deployed is capable of this support.
NetBackup Operations Manager management server

To deploy NetBackup Operations Manager (NOM), the system must have either
master, media, or the client software of the NetBackup product already installed.
The right version of the product Authentication should also be installed and
configured in the root plus authentication broker mode. On a system that has the
Symantec Product Authentication configured in authentication broker mode,
refer to the instructions listed in this section on how to work around this
restriction. The root broker restriction required by NOM will be lifted in a future
NOM release.
In this configuration, the NOM management server is deployed on the same system
as the NetBackup Master Server. If there are multiple Master Servers in the data
center, you should pick the one that is the least busy.
In the current edition of this Yellow Book, the version of the NetBackup master
management server that is managed by the NOM product is depicted in the
following table.
Apply the maintenance pack to the 6.0GA release to upgrade the NOM product to
a later version.
Table 7-8 NetBackup Operations Manager manages NetBackup master server
NetBackup Operations NetBackup master

Manager
5.1MP6 6.0MP4
6.0MP4
To install and configure NetBackup Operations Manager 6.0 GA on Windows

1 In an Explore window, navigate to the directory that has the NOM installation
files, and then click setup.exe.
2 On the License Agreement screen, click I accept the terms of the license
agreement.
3 On the Ready to Install the Program screen, click Install to start the NOM
installation.
4 On the System Validation Complete screen, click Finish to exit the NOM
installer.
5 Go to Start, Control Panel, Add or Remove Programs and verify the NOM
package (Veritas NetBackup Operations Manager) has been installed on the
system.
6 Verify the following NOM and supporting services are started. Go to Start >
Administrative Tools > Services.
Private Branch Exchange

Authentication
NetBackup Operations Manager Alert Manager
NetBackup Operations Manager Database Server
NetBackup Operations Manager Server
NetBackup Operations Manager Web Console Service
VERITAS Web Server
The NOM management server will be upgraded to 6.0MP4.

To upgrade NetBackup Operations Manager 6.0 GA on Windows
1 Locate the NOM maintenance pack distribution.
2 In an Explore window, navigate to the directory that has the NOM installation
files, and then double-click the setup.exe file.
3 Choose Install to this computer only, and then follow the instructions on the
screen.
4 On the Ready to Install the Program screen, click Install to start the upgrade.
5 On the System Validation Completed screen, verify that the installation
completed successfully.
6 Click Finish to exit the installer.
7 Go to Start, Control Panel, Add or Remove Programs, and then verify that
the maintenance pack has been installed on the system.
8 If the NBAC was enabled on a management client, after upgrading the
NetBackup software, the Verify NetBackup access control setup on clients
procedure listed in Appendix C should be used to ensure the management
client is working.
This version of NOM requires that the system where NOM is installed has the root
plus authentication broker configuration. In this setup (Figure 7-4), the system
(neptune.universe.com) merely has the authentication broker configured. To
work around this, execute the following procedures on the system
(neptune.universe.com) where the NOM management server is installed.
To configure root and authentication broker on NOM
1 Add the following private domains for the NOM product:

createpd --pdrtype ab \
--domain NOM_BuiltIn
Created Domain: NOM_BuiltIn

createpd \
--pdrtype ab \
--domain NOM_MACHINES
Created Domain: NOM_MACHINES

createpd \
--pdrtype ab \
--domain NOM_TRUSTED_CLIENTS
Created Domain: NOM_TRUSTED_CLIENTS
2 Add the following broker-domain mappings for the NOM product:

addbrokerdomain --broker jupiter.sun.universe.com:2821 \
--domain vx:NOM_MACHINES@jupiter.sun.universe.com
Added Domain-Broker Entry in Local Registry.

--domain vx:NOM_BuiltIn@jupiter.sun.universe.com

--domain vx:NOM_TRUSTED_CLIENTS@jupiter.sun.universe.com
3 Go to Start, Control Panel, Administrative Tools, Services, start the NetBackup

Operations Manager Server service, and then stop and start the Veritas Web
Server service.
4 Verify the NOM Web application is ONLINE.
C:\Program Files\VERITAS\VRTSweb\bin> monitorApp nom

Web Application "nom" is ONLINE
5 If the NOM is OFFLINE, start the NOM Web application.
C:\Program Files\VERITAS\VRTSweb\bin> startApp \

nom ..\VERITAS
The NetBackup Operations Manager Web Console Service service
is starting.
The NetBackup Operations Manager Web Console Service service
was started successfully.
6 Go to Start > Administrative Tools > Services, and verify that the NOM and
supporting services (listed earlier) are started.
7 To log onto the NOM administrative console, launch the Internet Explorer
browser and enter the URL http://localhost:8181/nom. You must provide a
valid user login and password in the NOM authentication domain. The
predefined user admin has a default password of Vxadmin.
8 For NOM to manage a NetBackup master management server, the host name
of the system where the NOM management server is configured should be
entered as a SERVER entry on each NetBackup master management server.
For example, NOM is configured on jupiter.universe.com and NetBackup
master management server on neptune.universe.com. On
neptune.universe.com, in the Host Properties, Master Server, highlight the
master server, Actions (at the top), Properties, Servers, and then click Add
to enter jupiter.universe.com.

It is highly recommended that you use one authentication hierarchy throughout
the enterprise. When you install a NOM in an enterprise that already has a root
broker established, you must configure an authentication broker on the system
where the NOM is to be installed as the preferred choice. Refer to the procedures
illustrated in previous section for details.
Replace the root broker that is configured for NOM with another authentication
hierarchy on a remote system.
See “Replacing the root broker on the NetBackup master server” on page 262.
Substitute the NetBackup entities with NOM backup entities.
NOM-related upgrade
The NOM installation is used to install and upgrade the NOM software only. The
NOM installation does not involve the upgrade of shared core services components,
such as AT and PBX. If an upgrade to a specific NOM version calls for the upgrade
of the shared components, the respective product’s installation script that is
provided by the shared products should be used to perform the upgrade.
After the upgrade of NOM is complete, you should verify the NOM product is able
to work with the shared products that are configured on the system. The
verification involves a successful logon to the NOM Web console by using the
existing user, an authentication domain, and a plug-in.
If one or more of the shared products are upgraded, while the NOM software
remains unchanged, the proper operation of the NOM product must be verified
through the NOM’s Web console logon. Besides the NetBackup management client,
if there are other Symantec agents installed on the same system as the NOM
management server, you must ensure that the new version of the shared
components can work with the management clients or agents that are already
present on the system. Most of the time, it is prudent to test out the configuration
in a test environment before deploying the new version of the shared components
to the production environment.

The CommandCentral (CC) product uses the authentication mechanism that is
provided by the Symantec Product Authentication to authenticate users who
access the CC Web administrative console. An Authentication broker is setup with
the appropriate authentication domain and plug-ins that are made available to
the CC Web console for authenticating users. After the CC products have been
configured, accessing the CC Web console requires a valid user login and password
that must be authenticated through the cc_users authentication domain and
plug-in.
order:
■ Storage Foundation. For CommandCentral, it is optional to install this product.
■ Management client or agents from other Symantec products (such as NetBackup
or Symantec License Inventory Manager0
Figure 7-5 depicts the deployment of the CommandCentral servers in an enterprise.
Figure 7-5 Deploying CommandCentral Storage and Service

In this use case chapter, the version of CC Storage and service management servers
and agents are primarily deployed and verified on the Windows platform. In
addition to Windows storage and service agents, Windows CC management servers
are configured to work with storage and service agents that are deployed on UNIX
and Linux platforms. In this setup, storage and service agents that are installed
on HP-UX and Red Hat platforms are configured to report to the CC management
servers on Windows.
Application server
On Windows, the CommandCentral (CC) installer decides the location to install
and store the data and temporary files. The CC Storage and service management
servers sand agents can be installed on respective systems and they do not require
that a Symantec application server, such as SFW or SFWHA, be installed first.
CommandCentral Management servers

The CommandCentral management servers (Storage and Service) are deployed
on a dedicated Windows system. CC management servers depend on Symantec
Product Authentication and a local authentication broker that is used to
authenticate users by accessing the CC Web console through a valid authentication
domain and plug-in.
In this illustration, the CC Storage and Service management servers use version
4.2 of the Authentication product. On the system where these management servers
are to be installed, you must configure an authentication broker in the
authentication hierarchy that is created on the system where the SLIM
management server is configured. To add a new authentication broker into an
existing authentication hierarchy, refer to the Add a new authentication broker
section in Appendix B for detailed procedures.
A system that is configured with CommandCentral storage and service
management servers could have Management Agents or Client of other
Management Servers deployed as well. These Agents or Clients may or may not
have the authentication enabled. As an example, the SLIM management agent
could be installed on the system that has the CC Storage management server.
Storage management server

On Windows, the version of the CommandCentral Storage (CC Storage) product
that is used for this illustration is listed in the following table. This version of the
CC Storage depends on the infrastructure that is provided by the Authentication
(AT) component. On systems that have CC Storage management server, this shared
component must be installed and configured. This shared component can be
manually installed and configured on the system first, or the CC installer can
automatically install the authentication product. CC Storage management server
uses the Web Server Service for console logon.
In the following table, cells that have the checkmark depict the specific version
of the shared core service (AT) that has been tested with the storage management
server.
Table 7-9 Storage management server dependency on shared component
4.1 4.2 4.3
4.2FP1
4.3
A valid product license key is required to install the CC Storage management

server.
If the CommandCentral authentication broker needs to be created by using an
existing root broker, you must verify that the system already has the Symantec
Product Authentication installed and configured in Authentication broker mode.
This installation session illustrates the installation for CC Storage 4.2FP1 release
on Windows Server 2003 Enterprise Edition SP1.
To install and configure a CommandCentral storage management server
1 In an Explore window, navigate to the directory that has the CC installation
2 On the License Agreement panel, click I accept the terms of the license
agreement.
3 On the Veritas CommandCentral Offerings screen, expand the
CommandCentral Storage, and then CommandCentral Storage Management
Server and CommandCentral Storage Web Engine.
4 On the Serial Numbers screen, enter a valid product key for the
ComamndCentral Storage and Service (if the CC Service product is also
included) products.
5 On the CommandCentral Storage Management Server screen, pick the Enable
Operations Modules (OM) and Enable Data Module (DM). On the system that
has the Storage management server, the storage management agent is not
required.
6 On the CommandCentral Storage Web Engine Options screen, choose the
default port (8181).
7 On the Installing Veritas CommandCentral screen, verify the Symantec
Product Authentication Service by running the following command on the
system:

showversion
vssat version: 4.3.27.1

showbrokermode
Broker Mode is : 1

listpd --pdrtype ab
8 On the Installation Complete screen, click Finish to exit the installer.

9 Go to Start > Control Panel > Add or Remove Programs, and then verify that
the Veritas CommandCentral Storage (or Suite if both Storage and Service
were installed) package is found.
10 After CommandCentral storage has been installed and configured, the
verification procedures listed in the Verify the CommandCentral server setup
section in Appendix D should be used to ensure that the CC Storage
management server is functional and working correctly.
The upgrade of the CC Storage management server software on a system is done
through these procedures and steps. The system that has the CC Storage
management server is usually the first system to be upgraded.
On a system that has the CC Service 4.2FP1 installed, upgrading CC Storage from
4.2FP1 to 4.3 is not supported. The CC Storage installation script makes this check
and would exit when such a condition is detected.
To upgrade a CommandCentral storage management server
1 Log on to the storage management server (cressida.universe.com) and
locate the CC Storage 4.3 management server software.
Service management server

The version of the CommandCentral Service (CC Service) product that is used in
Service depends on the infrastructure that is provided by the Authentication (AT)
and Private Branch Exchange (PBX) components. These shared components can
be manually installed and configured on the system first, or they can be
automatically installed and configured by the CC installer. The CC Service
management server uses the Web Server Service for console logon.
of the shared core services components (AT and PBX) that have been tested with
the Service management server.
Table 7-10 Service management server dependency on shared components
CommandCentral Authentication service Private Branch

Storage Exchange
4.1 4.2 4.3 1.2 1.3
4.2FP1
A valid product license key is required to install the CC Service management

server.
This installation session illustrates the installation for CC Service 4.2FP1 release
on Windows Server 2003 Enterprise Edition SP1 operating system.
To install and configure a CommandCentral server management server
2 In the Veritas CommandCentral Offerings screen, expand the
CommandCentral Service, and then select all the options. The
CommandCentral Storage product can also be installed in one installation
session.
3 In the ComamndCentral Service Automation Options screen, enter the FQHN
of the system (cressida.universe.com) where the CC Service is installed.
Pick the default port number (60389) for the Automation Server port.
4 On the system that has the Service management server, the service
management agent should be configured. The server Host for the service
agent should be Localhost and the default port (1556) should be used.
5 Verify that the authentication domains that are created for the CC Service
management server.

listpd --pdrtype ab
6 The rest of the procedural steps listed in the Storage management server
section are applicable to Service management server as well.
7 After the CommandCentral service product has been installed and configured,
the verification procedures listed in the Verify the CommandCentral server
setup section in Appendix D should be used to ensure that the CC Service
management server is functional and working correctly.
Version 4.2FP1 is the last release of the CommandCentral Service product. The
CommandCentral Service View Builder functionality is renamed to Veritas Backup
Reporter that is distributed with the NetBackup product. The CommandCentral
Service Metering Collector and CommandCentral Service Metering Controller are
renamed to Veritas Process Automation Server.
Installing a CommandCentral management agent

You can deploy the CommandCentral (CC) management agents on Windows Server
2003 Enterprise Edition SP1. These CC management agents are configured to
report to the CC management servers configured in the previous section.
of the shared core services component (AT) that has been tested with the Storage
and Service management agents.
Table 7-11 CommandCentral Agents Dependency on Shared AT
CommandCentral Authentication Client

Storage
4.1 4.2 4.3
4.2FP1
Use the following procedures to install CC management agents and configure

them to report to a Windows CC management server.
To install a CommandCentral Storage management agent
1 In an Explorer window, navigate to the directory that has the CC installation
2 In the Veritas CommandCentral Offerings screen, choose the CommandCentral
Storage Agent and CommandCentral Storage Web Engine options. Pick the
correct CommandCentral Storage Agent (OM and DM).
3 In the CommandCentral Storage server screen, enter the hostname
(cressida.universe.com) as the CommandCentral Storage management
server. Specify the login administrator and password.
4 In the CommandCentral Storage Web Engine Options screen, accept the
default port (8181).
5 Go to Start > Control Panel > Add or Remove Programs to see the
CommandCentral Storage agent package.
To install the CommandCentral service management agent
1 In an Explorer window, navigate to the directory that has the CC installation
2 In the Veritas CommandCentral Offerings screen, select the CommandCentral
Service Agent option.
3 In the CommandCentral Service server screen, enter the Host

(cressida.universe.com) as the CommandCentral Service management
server. Accept the default port (1556) that will be used by the Private Branch
Exchange.
4 Click Finish to exit the installer.
5 Go to Start > Control Panel > Add or Remove Programs to see the
CommandCentral Service agent package.
6 After the CommandCentral management agents are installed and configured,
use the verification procedures listed in the Verify the CommandCentral
agent setup section in Appendix D to ensure that the CC management agents
are working correctly.

When you install the CommandCentral (CC) product in an enterprise that already
has an authentication hierarchy, it is much preferred to create a new
authentication broker in the existing authentication hierarchy for the CC
management servers.
If a root broker was also configured during the CC install and there is a need to
replace the CC root broker with the existing authentication hierarchy, refer to
the Replace the root broker on the CommandCentral server section in Appendix
D for detailed procedures on how to assimilate an authentication broker from one
authentication hierarchy into another.
CommandCentral-related upgrade
The CC installation is used to install and upgrade the CC software on systems that
have either management agent, storage, or service management server. The CC
installation does not involve the upgrade of those shared core services components
(AT and PBX) that are used by CC management servers. If the upgrade to a specific
CC Storage version also calls for the upgrade of the shared components, the
respective product’s installation script that is provided by the shared products
should be used to perform the upgrade.
After the upgrade of CC software is complete, you should verify that the CC product
works with the shared products that are configured on the system.
If one or more of the shared products are upgraded, while the CC software remains
unchanged, the proper operation of the CC product must be verified through the
normal uses. If there are other Symantec agents or client installed on the same
system as the CC product, you must ensure that the new versions of the shared
components work with other management client or agents that are already present
on the system. Most of the time, it is prudent to test the configuration in a test
environment before deploying the new version of the shared components to the

The following Veritas Storage Foundation products are used throughout this
section:
■ Storage Foundation, which consists of Veritas Volume Manager, Veritas File
System, and optionally, Veritas Volume Replicator (VVR).
■ Storage Foundation for Windows, which consists of Veritas Volume Manager,
and optionally, Veritas Volume Replicator.
■ Storage Foundation Cluster File System (SFCFS) which consists Veritas File
System, Veritas Cluster Server (VCS), and the cluster functionality (shared
volumes) of Veritas Volume Manager.
■ Storage Foundation for Oracle RAC, which consists of SFCFS plus the Veritas
add-on functionality for use with Oracle databases.
The installer that is distributed with Storage Foundation for Oracle RAC 4.1MP1
on Red Hat and HP-UX is not integrated with the Symantec Product
Authentication.
See “Enabling a VCS cluster with authentication service” on page 211.
Figure 7-6 Deploying Storage Foundation

On the systems where these application servers are deployed, the management
agents or the clients of other management servers are installed. For example, on
a VCS cluster with SFWHA or SF for Oracle RAC, on each node of the VCS cluster,
the following management client and agents could be present:
■ NetBackup management client
■ CommandCentral Storage or Service management agent
■ Symantec License Inventory Manager management agent
These management client and agents are set up to report to the respective
management servers illustrated in this use case chapter. Refer to the respective
product use case section for instruction on how to setup a management agent or
client on a system.

The Storage Foundation products are deployed on Windows (SFW and SFWHA)
and UNIX or Linux (SF and SF Oracle RAC) platforms. UNIX and Linux platforms
include the HP-UX and Red Hat. The procedures and processes that are used on
Windows are platform-specific. The procedures and processes that are used on
HP-UX and Linux can be used on other UNIX and Linux platforms.
Application server
SFW is installed on a single system with a Symantec management server such as
NetBackup, SLIM, or CC. SFW is not integrated with Symantec Product
Authentication. SFW can be installed on the system with a management client
such as NetBackup and management agents such as CC and SLIM.
The installation is done on SFW 4.3MP1 on a system running Windows Server
2003 Enterprise Edition SP1.
To install Storage Foundation 4.3 for Windows
1 Navigate to the directory with the SFW distribution files, and then click
setup.exe.
2 Choose Storage Foundation 4.3 for Windows, and then select the
Complete/Customer option.
3 Click I accept the terms of the license agreement, and then enter the SFW
license key. Include the SFW client components in the installation.
4 Enter the host name of the system (for example, callisto), and then specify
the Domain for this computer (assuming the FQHN name for callisto is
callisto.universe.com).
5 Turn off Driver Signing option (located on System Properties) on the system.
6 Click Install to install the Server and Client components for SFW.
7 Click Finish to exit the Setup.exe installed and reboot the system.
8 After the system restarts, configure SFW. Go to Start > Control Panel > Add
or Remove Programs and verify that SFW is installed.
To upgrade Storage Foundation 4.3 for Windows
1 Navigate to the directory with the setup.exe file and double-click.
2 Select the Storage Foundation Maintenance Pack 1 for Windows, and then
click Install to start the upgrade.
3 Click Finish to exit the setup.exe installer and reboot the system.
4 After the system reboots, go to the Start > Control Panel > Add or Remove
Programs and verify the SFW Maintenance Pack 1 has been installed.
Storage Foundation HA for Windows (SFWHA) uses the authentication mechanism
provided by the Symantec Product Authentication to authenticate users accessing
the Veritas Cluster Server service groups and Veritas Enterprise Administrative
(VEA) Java console. An Authentication broker is set up with the appropriate
authentication domains and plug-ins and made available to the VEA Java console
for authenticating users.
This procedure installs Storage Foundation HA for Windows 4.3MP1 on a VCS
cluster running Windows Server 2003 Enterprise Edition SP1.
Table 7-12 Storage Foundation Dependency on Windows
Storage Foundation HA Authentication Client

for Windows
4.1 4.2 4.3
4.3MP1
To install Storage Foundation HA for Windows 4.3

1 Navigate to the directory that has the SFWHA distribution files, and then
click setup.exe.
2 Refer to step 1 in the Install Storage Foundation 4.3 for Windows section the
rest of the installation instructions.
3 Choose the Storage Foundation HA options and the Client components.
4 Enter the name of the systems that are part of the VCS cluster. On each
system, turn off the Driver Signing option on the System Properties screen.
5 Click Install to start the installation.

6 Click Finish to reboot the system where the installation is invoked from.
To upgrade Storage Foundation HA for Windows 4.3MP1
1 After all the systems reboot, upgrade the SFWHA to 4.3 Maintenance Pack
1.
2 The upgrade instructions that are listed in Upgrade Storage Foundation 4.3
for Windows can be used to perform the upgrade for all the nodes in the VCS
cluster. To upgrade SFWHA 4.3 to a more recent version of the maintenance
pack, the same procedure should be also be used.
3 After the upgrade, launch the VCS configuration wizard and choose Cluster
operations.
4 Pick the domain that is used in the enterprise and create a new cluster with
a unique cluster name and ID.
5 On the Configure Security Service Option screen, select use Single Sign-On
and enter mercury (FQHN is mercury.universe.com) in the VxSS Root Broker:
field.
6 On the Summary screen, verify the information is correct and click Configure
to start configuration process, and then click Next.
7 On the Cluster Service Components screen, select the Web Console and
configure the Web console.
8 Click Finish to exit. On each of the systems, there should be an authentication
broker configured and running. These authentication brokers are rooted in
the authentication hierarchy that is located on the mercury.universe.com.

When you install Storage Foundation HA for Windows (SFWHA) in an enterprise
that already has the authentication hierarchy, it is recommended that the existing
root broker be used and the new authentication brokers be created in the existing
authentication hierarchy.
Storage Foundation-related upgrade

After the upgrade of SFWHA software is complete, you should verify that the
storage foundation application server works with the shared products that are
configured on the system.
If one or more of the shared products are upgraded, while the storage foundation
software remains unchanged, the proper operation of the storage foundation
(with Authentication enabled) product must also be verified through the normal
uses. If other Symantec agents are installed on the same systems as the storage
foundation product, you must ensure that the new version of the shared
components work with the management agents that are already present on the
system. It is prudent to test out the configuration in a test environment before
you deploy the new version of the shared components to the production
environment.
Appendix A
Storage Foundation
common procedures
This appendix includes the following topics:
■ Enabling a VCS cluster with authentication service
■ Re-establishing the authentication service for a node in a VCS cluster
■ Setting up a Storage Foundation Management Server with authentication

service
■ Common Veritas Volume Manager and Veritas File System procedures
Enabling a VCS cluster with authentication service

Veritas Cluster Server (VCS) is distributed in each of these Storage Foundation
offerings:
■ Storage Foundation HA
■ Storage Foundation for Windows HA (SFWHA)
■ Storage Foundation for Oracle RAC (SF Oracle RAC)
■ Storage Foundation for Oracle HA (SF Oracle)
■ Storage Foundation Cluster File System (SFCFS)
Installing and configuring with authentication service depends on the Storage
Foundation offering, its version, and the operating system platform (UNIX, Linux,
or Windows). This section lists the common installation and configuration
procedures for Storage Foundation and the configuration instructions for enabling
VCS with authentication service in a security-enabled environment. VCS versions
212 Storage Foundation common procedures
4.1 and 5.0 are illustrated for UNIX and Linux platforms. On Windows, the
procedures are described using SF version 4.3.
Setting up a VCS cluster with authentication service on UNIX/Linux

Veritas Cluster Server can be deployed as a standalone product. Configuring a
VCS cluster with authentication service enables internode communication over
a secure channel using encrypted messages. Users of the VCS cluster must also
authenticate themselves by acquiring a valid security credential.
For these procedures, it is recommended that you input short system names. For
example, use ariel, instead of ariel.universe.com, when responding to a prompt.
The installer automatically retrieves the fully qualified host name (FQHN) and
places it wherever the FQHN is required (such as for the authentication broker
domain name.
Be prepared to provide the remote root broker information. VCS sets up each node
in a cluster with an authentication broker. You must provide the remote root
broker with a fully qualified host name, such as neptune.universe.com.
If you choose to configure the VCS cluster with authentication service, answer
yes to the following question:
Would you like to configure SFRAC to use Symantec Security Services?
Refer to the following section for details:

See “ Configuring a VCS cluster to use authentication service” on page 213.
If you choose to have the VCS cluster managed by a Storage Foundation
Management Server, answer yes to the following question:
Do you want this cluster to be managed by a management server?
Refer to the following section for details:

See “Using Storage Foundation Management Server to manage VCS clusters”
on page 213.
Configuring VCS 4.1 with authentication service

Among the Veritas Storage Foundation version 4.1 products, only SFCFS and SF
Oracle RAC are integrated with the authentication service. Their installers (on
Solaris) provide the option of installing and configuring them with authentication
service. The other SF offerings require the authentication service to be explicitly
installed and configured by a product administrator. The Symantec Product
Authentication Service can be installed from the Infrastructure Core Services
distribution media.
Storage Foundation common procedures 213
Configuring VCS 5.0 with authentication service

Veritas Storage Foundation version 5.0 includes authentication service as part of
the product installer. Using the product installation script (installer), you first
pick option I from the installer menu to Install the product, then choose option
C, Configure an Installed Product.
Configuring a VCS cluster to use authentication service

During the configuration phase of the SF Oracle RAC setup, the installer prompts
you for information related to the configuration of the authentication service.
The following example shows configuration questions related to the authentication
service for the SF Oracle RAC 5.0. You must provide the name of the system where
the root broker is configured. It is easiest to pick option 1 on the Security Menu.
The other two options are more interactive, so choosing either option 2 or 3
requires that you provide more information.
Would you like to configure SFRAC to use

Symantec Security Services? [y,n,q] (n) y
Security Menu
1) Configure security completely automatically
2) Provide AB credentials using BLOBs
3) Provide AB credentials without using BLOBs
Select the Security option you would like to perform [1-3,q,?] (1) 1
Enter the name of the VxSS Root Broker system: neptune.universe.com

Checking rsh communication with neptune.universe.com ...... SunOS 5.9
Checking vxatd process .....................................running
Checking vxatd version .....................................4.3.15.0
Using Storage Foundation Management Server to manage VCS clusters

The Storage Foundation Management Server (SFMS) and managed hosts
communicate by using a previously created authentication principal account
(vea_agent). This agent account resides in the vea_domain authentication domain
that is created during the SFMS installation. Managed hosts must obtain the
vea_agent password to authenticate themselves so that the authentication broker
can vouch for their identities.
Enabling SFMS to manage a VCS cluster has the following prerequisites:
■ SFMS is already configured and fully operational.
See “Setting up a Storage Foundation Management Server with authentication

service” on page 220.
■ The authentication broker that is used by SFMS is also configured with a
private domain vea_domain and an authentication principal vea_agent.
■ Every node in the VCS cluster must have the authentication service available
and authenticate itself to the authentication broker located on the system
where SFMS server is configured. Each node in the VCS cluster is authenticating
against the vea_agent authentication principal in the vea_domain
authentication domain.
In this setup, assume that the root broker is configured on the system
neptune.universe.com, the SFMS server is configured on system
proteus.universe.com and a VCS cluster with two nodes (larissa.universe.com
and ariel.universe.com). The SF for Oracle RAC installation is invoked from
the system ariel.universe.com.
The SF Oracle RAC 5.0 installer requires the following information to configure
the VCS cluster to be managed by an SFMS server. The installer distributed by SF
Oracle RAC 4.1 may phrase these questions differently.
■ FQHN of the Storage Foundation Management Server (SFMS)
■ Password for the vea_agent authentication principal
■ The root hash of the authentication broker that is used by SFMS. To find the
hash of the root broker that the management server authentication broker
belongs to, run the following procedure on neptune.universe.com:
# /opt/VRTSat/bin/vssat showbrokerhash
Root Hash: 9efb1d042f646656602f55be4016a8bf1a1d03b4
Do you want this cluster to be managed by a management server? Enter 'y'

if you have set up a management server. [y,n,q] (y)
Enter the network address used by

the management server [?] (ariel) proteus.universe.com
Management server address: proteus.universe.com
Enter the password for the CMC service account: <vea_agent's password>
Enter the hash of the management server's
root broker [?] 9efb1d042f646656602f55be4016a8bf1a1d03b4
Setting up a VCS cluster with authentication service on Windows

The information presented in this section applies to Storage Foundation HA 4.3
(with MP1) for Windows.
Configuring Storage Foundation HA for Windows with

authentication service
The VCS product requires an authentication broker to be configured on each node
of the VCS cluster. To enable authentication service in a VCS cluster with Storage
Foundation HA for Windows (SFWHA), follow these steps.
To configure Storage Foundation HA with authentication service
1 On one of the VCS nodes, mount the SFWHA distribution on a drive.
2 At the top level directory, double-click the installation script setup.exe and
choose the Storage Foundation HA 4.3 for Windows install option. List all
the nodes in the VCS cluster on which to install SFWHA.
3 After you install SFWHA and restart all the systems, select Start > All
Programs > VERITAS > VERITAS Cluster Server > VCS Configuration
Wizard > Cluster Operations to create a new VCS cluster. Add all the
previously specified nodes in the VCS cluster.
4 On the Configure Security Service Option screen, click the Use Single Sign-On
radio button.
5 Navigate to the VxSS Root Broker field and then type the name of the system
that has the root broker configured.
6 Click Next and continue with the VCS Configuration Wizard.
7 The Symantec Product Authentication Service is embedded in Storage
Foundation HA 4.3 for Windows, so the authentication service does not display
as one of the currently installed programs if you select Start > Control Panel
> Add or Remove Programs. To verify that the authentication service is
configured correctly, select Start > Administrative Tools > Services and
verify that the authentication service line is present and in the Started status.
To enable the authentication service on a previously configured VCS cluster
1 On one of the VCS nodes, launch the Start > All Programs > VERITAS >
VERITAS Cluster Server > VCS Configuration Wizard.
2 Select the Cluster Operations, Edit Existing Cluster and then Reconfigure.
3 After you successfully log on to the VCS cluster, select Configure/Change
VERITAS Security Service (Single Sign-On) and check the Configure Security
Services radio button. .
Re-establishing the authentication service for a node in a VCS cluster
4 In the VxSS Root Broker field, enter the name of the system where the
authentication root broker is configured.
5 Click Next and continue with the VCS configuration Wizard.
Configuring Storage Foundation with authentication service

When you are installing the Storage Foundation (not HA) for Windows on a system
that does not have the authentication service already installed, the SF installer
does not automatically install the authentication service. In this situation, the
authentication service must be explicitly installed and configured on the system.
Re-establishing the authentication service for a node

in a VCS cluster
When you upgrade a node in a cluster and that node fails to restore all of its
credentials, use the following procedure to re-establish the authentication broker
private domain repository and credential.
In a Symantec enterprise cluster (Veritas Cluster Server) environment, VCS
requires the establishment of an authentication broker on each of the cluster
nodes. VCS also creates a private domain repository called HA_SERVICES within
the authentication broker private domain repository. The private domain
repository, HA_SERVICES, contains the service authentication principals for the
following principals: _CMDSERVER_VCS_nodename, _HA_VCS_nodename, and
webserver_VCS_nodename in addition to the normal admin principal. The node
name is the name of the system that is one of the VCS nodes.
To establish the authentication service for a node within a VCS cluster, there are
three procedures you must complete before you can authenticate to the new
Assume ophelia.universe.com is the name of the system in the VCS cluster and
that the root broker is configured on neptune.universe.com.
■ Add a new authentication broker on the VCS node. The authentication broker
must belong to the existing authentication hierarchy. The principal name for
the new authentication broker should be ophelia.universe.com.
■ On the node where the new authentication broker is configured, create a private
domain repository (PDR) for VCS called HA_SERVICES.
■ In the new HA_SERVICES PDR, create three new authentication principals:
_CMDSERVER_VCS_nodename, _HA_VCS_nodename, and webserver_VCS_nodename.
Use ophelia fornodename.
To re-establish Authentication brokers in clustered environments

1 On neptune.universe.com, where the root broker is located, create an
authentication principal (ophelia.universe.com) for the new authentication
broker.
2 On ophelia.universe.com, where you are creating the new authentication
broker, copy the root broker hash file from neptune.universe.com to a local
directory on ophelia:
# rcp neptune.universe.com:/opt/VRTSat/bin/root_hash /tmp
3 If the authentication service was not installed on ophelia, use the

Infrastructure Core Services distribution to install Symantec Product
Authentication Service and configure an authentication broker using neptune
as the root broker and the /tmp/root_hash file.
4 If the authentication service is already installed on ophelia, establish an
authentication broker there. Type the following command:
# /opt/VRTSat/bin/vxatd -a \
-n ophelia.universe.com -p password \
-x vx -y root@neptune.universe.com \
-q neptune.universe.com -z 2821 \
-h /tmp/root_hash -o
Name <ophelia.universe.com>
DomainType <vx>
DomainName <root@neptune.universe.com>
BrokerName <neptune.universe.com>
BrokerPort <2821>
Hash file </tmp/root_hash>
5 On ophelia, where the new authentication broker is set up, verify that the
authentication broker is configured correctly.
6 On ophelia, create the authentication domain for VCS. Type the following
command:
# /opt/VRTSat/bin/vssat createpd \
--pdrtype ab \
--domain HA_SERVICES@ophelia.universe.com
Created Domain: HA_SERVICES@ophelia.universe.com
7 On ophelia, where the new HA_SERVICES PDR is located, create three new
authentication principals: _CMDSERVER_VCS_nodename, _HA_VCS_nodename,
and webserver_VCS_nodename. Use ophelia for the nodename. Here is the
command to create and authenticate the _HA_VCS_ophelia authentication
principal. Repeat these commands for _CMDSERVER_VCS_ophelia and
webserver_VCS_ophelia authentication principals.
# /opt/VRTSat/bin/vssat addprpl --pdrtype ab \

--domain HA_SERVICES@ophelia.universe.com \
--prplname _HA_VCS_ophelia \
--prpltype service \
--password welcome_HA
Created Principal: _HA_VCS_ophelia
# /opt/VRTSat/bin/vssat authenticate \
--domain vx:HA_SERVICES@ophelia.universe.com \
--prplname _HA_VCS_ophelia \
--broker localhost:2821
Enter password for _HA_VCS_ophelia: welcome_HA

Authenticated User _HA_VCS_ophelia
8 On ophelia, where the three new authentication principals are created in

the HA_SERVICES PDR, type the following command to list these principals:
# opt/VRTSat/bin/vssat listpdprincipals \
--pdrtype ab \
--domain HA_SERVICES@ophelia.universe.com
Principal Name: _CMDSERVER_VCS_ophelia
Principal Name: _HA_VCS_ophelia
Principal Name: webserver_VCS_ophelia
9 Verify that the VCS VxSS service agent group is known to the newly-created
authentication broker cluster host.
In the VCS configuration file, /etc/VRTSvcs/conf/config/main.cf, verify
that the SecureClus attribute in the vcs_cluster_name cluster is set to 1.
This indicates that the cluster is configured in secure mode. The VxSS VCS
service group must also be present.
cluster vcs_cluster_name (
UserNames = {"CMC@CMC_SERVICES@proteus.universe.com" = password}
ClusterAddress = "21.43.92.89"
Administrators = {"CMC@CMC_SERVICES@proteus.universe.com"}
SecureClus = 1
HacliUserLevel = COMMANDROOT
)
group VxSS (
SystemList = { bianca = 0, ophelia = 1 }
Parallel = 1
OnlineRetryLimit = 3
OnlineRetryInterval = 120
)
Phantom phantom_vxss (
)
ProcessOnOnly vxatd (
IgnoreArgs = 1
PathName = "/opt/VRTSat/bin/vxatd"
)
Setting up a Storage Foundation Management Server with authentication service
Setting up a Storage Foundation Management Server

with authentication service
The Storage Foundation Management Server (SFMS) is a management tool that
can centrally monitor, visualize, and administer hosts on which Storage Foundation
products are installed. SFMS is configured on a dedicated system to manage hosts
that have Storage Foundation 5.0 or 4.x configured on Linux or UNIX. On managed
hosts that have SF 4.x installed, the SFMS client component (Provider Access
Layer) must be installed.
For SFMS and managed hosts to communicate securely, they must authenticate
themselves to an authentication broker to establish a secure communication
channel. You should configure SFMS and an authentication broker on the same
system. The following procedure was done on a Solaris system. The procedure
assumes that you have already created an authentication principal for the new
To add a new authentication broker, you need the following information:
■ The name of the system where the Root broker is configured
■ The root broker hash file
■ The authentication service communication port number
To set up an authentication broker for SFMS
1 After mounting the SFMS product media, go to the directory with the SFMS
installer script and invoke it:
# cd mountpoint/sol
# ./installer
2 Select to install a new authentication service (option 3) with an authentication

broker (option 3).
To set up SFMS with authentication service
1 After mounting the SFMS product media, go to the directory with the SFMS
installer script and invoke it:
# cd mountpoint/sol
# ./installer
Setting up a Storage Foundation Management Server with authentication service
2 On the installation menu, select option 1 to install and configure the SFMS.
Provide the following information when prompted:
■ The name of the system where the authentication broker is configured
■ The administrative password of the authentication broker
■ A user-specified password for the vea_agent authentication principal in
the vea_domain authentication domain
To verify the configuration of SFMS

1 An authentication domain, vea_domain, is created on the system where SFMS
is configured. Type the following command to verify the setup of SFMS:

Domain Name vea_domain@proteus.universe.com
2 The vea_agent account (authentication principal) is used by the SFMS agent

running on all the hosts (server and managed) to authenticate themselves to
the authentication broker. Other authentication principals, vea_guest,
proxyuser, and webuser, should also be present in the listpdprincipals
command output. Type the following command to list the authentication
principals:
# /opt/VRTSat/bin/vssat listpdprincipals --pdrtype ab \

--domain vea_domain@proteus.universe.com
Principal Name: vea_guest
Principal Type: Service
Principal Name: vea_agent
Principal Type: Unknown
Principal Name: webuser
Principal Name: proxyuser
Using SFMS Web-based interface to administer managed hosts

The following procedure will access managed hosts from the system that has
SFMS installed and configured. To access SFMS, the administrator must log on
via the Veritas Enterprise Administrator (VEA) Web-based interface.
Common Veritas Volume Manager and Veritas File System procedures
To access a managed host using VEA

1 Open a browser window and enter the server URL:
https://proteus.universe.com:8443/VEAWeb/Login
This URL opens a SFMS login screen for the SFMS configured on system
proteus.universe.com.
2 On the Login screen, type the user name, password, and pick the
authentication domain and plug-in:
User Name: root

Password: ******
Domain: proteus.universe.com (unixpwd)
3 Click Login to continue.

4 After logging in, on the SFMS Summary page, click Managing > Servers >
hosts and select the host you want to manage:
5 On the page where host names (such as ophelia.universe.com) are displayed,
use the panel to switch between tabs. The available tabs include Overview,
LUNs, Disks, Disk Groups, Volumes, File Systems, Licenses, Packages, and
Agents. Each tab name refers to the type of operation you can perform on
the selected managed host.
For example, to create a VxFS file system on the managed host ophelia, use
the Disk Groups and Volumes tabs to make a raw Veritas volume device. Use
the File Systems tab to make and mount a VxFS file system on the raw volume
with mount point entry specified. Use the Packages tab to view specific
Symantec product information.
Common Veritas Volume Manager and Veritas File

System procedures
Veritas Volume Manager (VxVM) and Veritas File System (VxFS) are components
of Storage Foundation. These products are installed and configured by the installer
script that is available with the Storage Foundation installation media. It is
recommend that you use Veritas Volume Manager and Veritas File System for
Symantec products that install products binaries and data in specific directories.
For example, on UNIX/Linux platforms, NetBackup installs its product binaries
in the /usr/openv directory. Therefore, it is preferred that this directory be
mounted on a VxFS file system created on a VxVM volume. Similarly, a VxFS file
system should be created as a disk storage unit for NetBackup.
The commands that are used to create the VxVM objects are listed below. This
procedure was done on an HP-UX system. The same commands can be executed
on other UNIX/Linux systems.
To create a VxVM disk group and volumes on UNIX/Linux
1 On a system where VxVM is installed and configured, invoke the following
command to see the list of physical disks that are managed by VxVM:
# /usr/sbin/vxdisk list
DEVICE TYPE DISK GROUP STATUS
c2t0d0 auto:cdsdisk Disk_7 elroy online
c2t1d0s2 auto:hpdisk rootdisk01 rootdg online
c4t14d0 auto:cdsdisk - - online
2 Create a disk group named xyz on device c4t14d0 and again list the disks:
# /sbin/vxdg init xyz Disk1=c4t14d0

# /usr/sbin/vxdisk list
DEVICE TYPE DISK GROUP STATUS
c2t0d0 auto:cdsdisk Disk_7 elroy online
c2t1d0s2 auto:hpdisk rootdisk01 rootdg online
c4t14d0 auto:cdsdisk Disk1 xyz online
3 On the system with the xyz disk group, invoke the following VxVM commands
to create a volume named openv in the disk group and print the volume:
# /usr/sbin/vxassist -g xyz make openv 15G

# /usr/sbin/vxprint -g xyz -ht
On Windows, to create a VxVM disk group and volumes, use the New Group and
New Volume tabs in Start > VERITAS > VERITAS Enterprise Administrator.
To make and mount a VxFS file system on a VxVM volume

1 On the system with the VxVM disk group named xyz and the volume named
openv, type the following command to make a new VxFS file system on the
volume openv.
# mkfs -F vxfs /dev/vx/rdsk/xyz/openv

version 6 layout
15728640 sectors,
15728640 blocks of size 1024,
log size 16384 blocks
largefiles supported
2 Create a directory for the file system mount point:
# mkdir -p /usr/openv
3 Mount the file system and display the amount of disk space it occupies:
# mount -F vxfs /dev/vx/dsk/xyz/openv /usr/openv

# df -k -F vxfs
On Solaris and HP-UX platforms, use the -F option to specify the VxFS system
type.
On AIX, use the -V option.
On Linux, use the -t option.
On Solaris, the mount table is /etc/vfstab.
On HP-UX and Linux, it is /etc/fstab.
On AIX, it is /etc/filesystems.
Veritas File System is not available on Windows. On Windows, use the native file
system NTFS.
Appendix B
Infrastructure Core Services
common procedures
■ About Infrastructure Core Services
■ Verify authentication setup
■ Verify authorization setup
■ Add a new authentication broker
■ Backup and restore authentication data
■ Backup and restore authorization data
About Infrastructure Core Services

Infrastructure Core Services (ICS) consists of the following products: Private
Branch Exchange (PBX), Authentication (AT) and Authorization (AZ), and Service
Management Framework (SMF).
Note: Service Management Framework is installed and configured by the SLIM

installation script. Therefore, no further installation related details are provided
for SMF.
The name of the system (or host) on which the ICS Products is to be installed can
be specified in either a fully-qualified host name (pluto.dwarf.universe.com),
or a short-name (pluto). It is recommended that you use the fully-qualified host
name when you install CS products.
226 Infrastructure Core Services common procedures
Private Branch Exchange

Private Branch Exchange (PBX) is a product you use to enable all socket
communications that occur on a management server through a single port
connection. Management servers such as NetBackup and Symantec License
Inventory Manager use Private Branch Exchange extensively to reduce the number
of open port instances.
For example, NetBackup requires Private Branch Exchange on the administrative
consoles, the master server, and on the media servers. NetBackup clients do not
use Private Branch Exchange.
Table B-1 lists products that consume Private Branch Exchange. Entries that show
a check mark indicate the consuming products that use that specific version of
the Private Branch Exchange product. Entries that are blank indicate combinations
that are either not supported or not tested in the use cases in Chapter 6 and
Chapter 7.
Table B-1 Symantec Private Branch Exchange usage matrix
Private Branch NetBackup NetBackup Authentication Authorization Symantec SFCFS/SF

Exchange Operations License Oracle RAC
Manager Inventory
Manager
1.2
1.3
Installing and configuring Private Branch Exchange

To install and configure the Private Branch Exchange (PBX) on Windows or on
UNIX/Linux, follow the procedures and steps listed below. These steps illustrate
a sample installation for the Private Branch Exchange 1.2.2.43 release for Windows
and release 1.2.2.41 for UNIX/Linux.
To install PBX on Windows
1 Open a Microsoft Explorer window.
2 Navigate to the directory that contains the Private Branch Exchange
installation file, Veritas Private Branch Exchange.msi.
3 Double-click the msi file to start the Private Branch Exchange installation.
4 In the Setup Type window, select the Complete installation type.
5 In the Ready to install the Program window, click Install to start the
installation.
Infrastructure Core Services common procedures 227
6 Click Finish to exit the InstallShield wizard panel.

7 Click Start > Control Panel > Add or Remove Programs, and then verify that
the Private Branch Exchange package has been installed.
8 Go to Start > Administrative Tools > Services, and then verify that the Private
Branch Exchange service is started.
From the command line, the following information is displayed:
C:\Program Files\VERITAS\VxPBX\bin>pbxcfg --print

Auth User:0 : localsystem
Secure Mode: false
Debug Level: 10
Port Number: 1556
PBX service is not cluster configured
9 To start and stop the Private Branch Exchange service from the command
line, run the following commands, respectively:
c:\> net start VRTSpbx

c:\> net stop VRTSpbx
To install PBX on UNIX/Linux

1 Log in to the system on which you will install Private Branch Exchange.
Navigate to the directory that contains the Private Branch Exchange
installation file and run the installation script. Type:
# cd <mnt>/ NB_60_ICS_1.2.3.45_Solaris
# ./installics
2 Type I (for Install).

3 On the next screen, type 2 (for Private Branch Exchange).
4 Type the name of the system on which you will install Private Branch
Exchange. You see the following information displayed:
installics will install the following PBX packages

on SunOS target systems: neptune
VRTSicsco VERITAS Common Infrastructure

VRTSpbx VERITAS Private Branch Exchange Service
5 Verify Private Branch Exchange has been successfully installed and

configured. Type the following command:
# ps -ef | grep pbx

root 331 1 0 Dec 28 ? 0:16 /opt/VRTSpbx/bin/pbx_exchange
6 Start and then stop the Private Branch Exchange process daemon. Type the
following command:
# /opt/VRTSpbx/bin/vxpbx_exchanged start
The following message is displayed:
Starting VERITAS Private Branch Exchange

# /opt/VRTSpbx/bin/vxpbx_exchanged stop
Done.
7 Verify Private Branch Exchange is configured. Type the following command:
# /opt/VRTSpbx/bin/pbxcfg -p
The following message is displayed:
Auth User:0 : root

Secure Mode: false
Debug Level: 10
Port Number: 1556
PBX service is not cluster configured
About Symantec Product Authentication Service

Symantec Product Authentication Service provides the authentication protocol
to the list of Symantec products in the Table B-2 that need the capability to prove
the identity of entities that access the products. In this context, entities are
individuals who need to manage the products by using non-privileged accounts
while logging on at the operating system level. The authentication interface is
usually a logon session that uses a command line interface, a product’s graphical
user interface, or a Web interface.
Symantec Product Authentication is typically installed by using one of the
following methods:
■ It is installed using the Symantec Product Authentication product installer.
■ It is installed by one of the consuming product's installers.
Table B-2 lists all Symantec products that use Symantec Product Authentication.
Entries that show a checkmark for authentication, indicate the consuming products
that use that specific version of Symantec Product Authentication. Entries that
are blank represent combinations that are not illustrated in the chapters. Specific
versions of the consuming products are shown in their respective sections in
Chapter 6 and Chapter 7.
Table B-2 Symantec Product Authentication usage matrix
Symantec NetBackup NetBackup CommandCentral Symantec SFCFS/SF

Product Operations License Oracle RAC
Authentication Manager Storage Service Inventory
Manager
4.1
4.2
4.3
Authentication domain name after host name

The name of an authentication domain is derived from Symantec product
concatenated with the system name.
■ On UNIX/Linux, when specifying the name of the system (or host) for the AT
domain, the host name should be specified in Fully-Qualified-Host-Name
(FQHN) format (such as neptune.universe.com). In the later versions of AT
(4.3 and later), the FQHN is not required. The FQHN is always used as the
domain name for these authentication product examples.
■ On UNIX/Linux, during the installation, the host name to install the
authentication product can be specified by using the short name (such as
neptune) because the host name directs the installer to install the AT binaries
and configuration files.
■ On Windows, the short name (jupiter) should always be used during the
installation and the AT- related configuration.
Installing and configuring authentication

This installation session illustrates the installation for Authentication 4.2.2.21
release on Windows, and for Authentication 4.2.2.21 release on a system running
HP-UX 11.23 operating system.
To install and configure authentication service on Windows

1 In a browser window, navigate to the directory that has the AT installation
file. Invoke the VxSSVRTSatSetup.exe file by double-clicking it to start the
AT installation.
2 On the Setup Type screen, select Complete as the installation type. For the
destination folder, choose the default C:\Program Files\VERITAS\Security\
folder.
3 On the Authentication Broker Service screen, in the Select Authentication

Broker Mode box, choose the intended broker mode for this installation. For
the other options on this screen, use the default values.
When adding a new authentication broker (Authentication Broker Only), on
the Authentication Broker Identity screen, the following information should
be available prior to the install. In the root broker box, the host name of the
root broker and the root’s hash file. In the Broker Identity box, the name of
the authentication principal and password, domain name and type (usually
it is vx) should be entered. As an example:
Root Broker
Hostname mercury.universe.com Port 2821
Hash File C:\TEMP\root_hash
Broker Identity
Name jupiter Password *******
Domain Name root@mercury.sun.universe.com
Type vx

4 On the Summary screen, verify that the values that appear for all the options
are correct. Click Next to continue the installation.
5 On the InstallShield Wizard Complete panel click Finish to exit the installer.
Go to Start > Control Panel > Add or Remove Programs, verify that the
authentication service package has been installed. Go to Administrative Tools,
Services and verify the Authentication service has been started.
6 Use the verification procedure to verify that the Authentication product is
configured correctly.
To install and configure the Symantec Product Authentication on UNIX/Linux

1 Log in to the system on which to install the authentication service. Navigate
to the directory that contains the Authentication installation file and run the
following installation script:
# cd <mnt>/NB_60_ICS_1.2.3.45_HP
# ./installics
2 Type I (Install/Upgrade a product), and then type 3 (for Veritas Authentication

Service).
3 Type the name of the system on which you will install authentication. You
see the following information displayed:
installics will install the following AT depots

on HPUX target systems: janus
VRTSat VERITAS Authentication Service
4 Configure an authentication broker (choose 2) on the system

janus.universe.com. The following message appears:
Do you want to install the AT Server? [y,n,q] (y)
5 To install the AT client on the system, type n. The following message appears:
Are you ready to configure AT on janus? [y, n, q] (y)

1) Root Broker Only.
2) Authentication Broker Only.
3) Authentication + Root Broker.
6 Enter the mode in which you want to install VRTSat [1-3,q] 2

7 Enter the name of the host running the root broker: mercury.universe.com
8 Enter the broker port: (2821)
9 Enter authentication broker’s identity: janus
10 Enter password for janus: <janus password>
11 Enter the domain name: root\@mercury.sun.universe.com
12 Enter the location of the file containing the root’s hash: /tmp/root_hash. The
following message is displayed:
VERITAS Authentication Service configured successfully.

VERITAS Authentication Service was started successfully.
13 Choose 1 and 3 for Root broker only and Authentication + Root broker
configuration, respectively.
# ps -ef | grep vxatd

root 387 1 0 Jan 28 ? 4:51 /opt/VRTSat/bin/vxatd
14 Use the verification procedure to verify that the authentication product is

Upgrading authentication
To upgrade authentication on UNIX/Linux or Windows
1 Upgrade a system with Symantec Product Authentication 4.2 installed in one
of the following ways:
■ Install SLIM (which requires AT 4.3 and later) software (either Server or
Agent) on the system with AT 4.2. The upgrade should retain the existing
AT’s information.
■ On a system with AT 4.2 already installed, explicitly upgrade the AT to
4.3 (or later).
2 After the upgrade is complete, verify the version string of the authentication
product.
■ On UNIX/Linux:
# cat /opt/VRTSat/build_version
Authentication-4.3.15.0
■ On Windows, go to Start > Control Panel > Add or Remove Programs and
choose the authentication service. (Products such as NetBackup and SLIM
that use the authentication service should continue to work.)
3 The installation scripts that are provided in this document should be used
for performing the upgrade.
About Symantec Product Authorization Service

Symantec Product Authorization Service provides an access control service that
prevents the improper use of privileged resources. Users are allowed access only
to those resources to which they are authorized. You need to install Symantec
Product Authorization on each system for which you want to control access.
NetBackup is the only Symantec product that uses the authorization service. To
avoid network latency, install and configure the authorization service on the same
system as the master server. On each system on which the NetBackup Media
Server is installed, also install the client portion of the authorization service.
Table B-3 lists the products that consume Symantec Product Authorization. Entries
that show a checkmark for authorization indicate the consuming products that
use a specific version of Symantec Product Authorization. Empty cells indicate
combinations that are either not supported or not tested in the use cases in Chapter
6 and Chapter 7.
Table B-3 Symantec Product Authorization usage matrix
Symantec NetBackup NetBackup CommandCentral Symantec SFCFS/SF

Product Operations License Oracle RAC
Authorization Manager Storage Service Inventory
Manager
4.1
4.2
4.3
This installation session illustrates the installation for Authorization 4.2.2.16

release on Windows, and for Authorization 4.2.2.16 release on a system running
Solaris 9 operating system.
To install and configure Symantec Product Authorization on Windows
1 To install the authorization service, in an Explore window, navigate to the
directory that has the authorization service installation file, and start the
installation by invoking the VRTSazSetup.exe file.
2 On the Setup Type screen, select Custom as the installation type.
3 On the Choose Destination Location screen, choose the new folder to install
the authorization service, or use the following default destination folder:
C:\Program Files\VERITAS\Security\Authorization
4 On the Select Features screen, choose the intended installation by checking

the Client and Server options.
5 On the Start Copying Files and Setup Status screens, the installation progress
is displayed.
6 On the InstallShield Wizard Complete screen, click Finish to exit the installer.
Go to Start > Control Panel > Add or Remove Programs and verify that the
authorization service package has been installed.
7 Go to Start > Administrative Tools > Services and verify that the
authorization service has been started.
To install and configure the Symantec Product Authorization on UNIX/Linux
1 Logon to the system on which you will install Symantec Product Authorization.
Navigate to the directory that contains the Authorization installation file,
and run the following installation script:
# cd <mnt>/NB_60_ICS_1.2.3.45_Solaris
# ./installics
2 Type I (Install/Upgrade a product) and then type 5 (for Veritas Authorization

Service).
3 Type the name of the system on which you will install Authorization. The
following information is displayed:
installics will install the following AZ packages

on SunOS target systems: neptune
VRTSaz VERITAS Authorization Service
4 Configure the authorization product on the system neptune.universe.com.

The following prompt is displayed:
Do you want to install the Authorization

Service? [y,n,q] (y)
5 To install the AZ client on the system, type n. The following prompt is

displayed:
Are you ready to configure AZ on neptune? [y, n, q] (y)

Verify authentication setup
6 To configure a stand alone authorization server, enter n to the following

prompt:
Do you want the installer to do a cluster configuration

for Authorization Service? [y,n,q] (n)
VERITAS Authorization Service configured successfully.
# ps -ef | grep vxazd

root 439 1 0 Jan 28 ? 0:02 /opt/VRTSaz/bin/vxazd
7 Use the verification procedure to verify the Authorization product was

See “Verify authorization setup” on page 237.
Upgrading authorization
To upgrade the authorization on either UNIX/Linux or Windows, use the following
procedure.
To upgrade Symantec Product Authorization
1 On a system with Symantec Product Authorization 4.2 already installed, you
can explicitly upgrade the AZ to 4.3 (or later).
2 After the upgrade is complete, verify the version string of the authentication
product.
■ On UNIX/Linux:
# cat /opt/VRTSaz/build_version
Authorization-4.2.2.16-050605_1
■ On Windows, go to Start > Control Panel > Add or Remove Programs and
choose the Authentication product. (Consuming product such as NetBackup
that uses the authorization product should continue to work.)
3 The installation scripts provided in theSymantec Product Authorization

document should be used for performing the upgrade.

Symantec Product Authentication can be installed and configured in one of the
following modes:
■ Authentication Broker (mode is 1)
■ Root Broker (mode is 2)

■ Root plus Authentication Broker (mode is 3)
■ Client
To verify the authentication process
1 To verify that the authentication process on UNIX/Linux (vxatd) is running,
use the ps command.
2 On Windows, click Start > Settings > Control Panel > Administrative Tools
> Services. Locate the authentication service and verify it has started and is
online.
3 To verify the system has the root plus authentication broker installed and
configured correctly, the vxatd process must be running and the Broker mode
should be 3.
# /opt/VRTSat/bin/vssat listpd --pdrtype root

4 To find the authentication broker, the showbrokermode (available in version

4.3 and later) can be used. Type:
5 In Authentication version 4.2 and earlier, type the following command:
# /opt/VRTSat/bin/vssregctl -l -q \
-b "Security\Authentication\Authentication Broker" \
-k Mode
Verify authorization setup
The procedure for installing and configuring a root broker only on a system is
similar to that of the root plus authentication broker.
1 Verify the Authentication process (vxatd) is running, the broker’s mode is 2,
and the following commands completed successfully:
# /opt/VRTSat/bin/vssat listpd --pdrtype root

2 Verify that the authentication broker has been installed and configured
successfully using a remote root broker. The Broker’s mode should be 1.
3 Verify the Authentication process (vxatd) is running, the broker’s mode
should be 1, and the following commands completed successfully:

The Broker mode of 0 indicates that the Symantec Product Authentication

is not configured. A system that only has the authentication client component
installed will also show the mode as 0.
Verify authorization setup

You can use the procedures described in this section to verify the setup of the
authorization service
To start and stop the Authorization service
1 On Windows, go to Start > Administrative Tools > Services and start the
authorization service. The Authorization service can also be started from the
command line by executing "net start vrtsaz". To stop the Authorization
service, execute “net stop vrtsaz”.
2 On UNIX/Linux, to start the authorization service, execute the
"/opt/VRTSaz/bin/vrtsaz" command. To stop the Authorization service,
execute this command “/opt/VRTSaz/bin/vrtsaz –stop”.
3 Verify the Authorization service using one of the following commands:
■ On UNIX/Linux:
# /opt/VRTSat/bin/vssregctl \
-g /etc/vx/vss/VRTSaz.conf -e \
-b Security\\Authorization\\ServiceIdentity
Name: ServiceName Type: 0 Value: vxazd_vxsvc
Add a new authentication broker
Name: ServiceDomainName Type: 0 Value: SERVICES@neptune.

universe.com
Name: ServiceDomainType Type: 0 Value: vx
Name: AuthenticationBrokerHost Type: 0 Value: localhost
Name: AuthenticationBrokerPortNumber Type: 0 Value: 2821
■ On Windows:
vssregctl -g HKEY_LOCAL_MACHINE\Software\VERITAS
-e -bSecurity\Authorization
Add a new authentication broker

In an existing authentication hierarchy, adding a new authentication broker can
be done using the procedures in this section.
For example, assume the existing root broker is configured on system
mercury.universe.com, and that there is a need to add a new authentication
broker to this authentication hierarchy.
Use the vssat command on both UNIX/Linux and Windows. The vssat command
options are used on both platforms. The directory where the vssat command is
located is different on UNIX/Linux and Windows.
To set up the new authentication broker
1 On the system mercury.universe.com, create an authentication principal
for the new Authentication broker.
mercury.universe.com# vssat addprpl --pdrtype root \

--domain root@mercury.universe.com \
--prplname jupiter --password jupiter123 \
--credexpiry 0 \
--prpltype service
Created Principal: jupiter
2 Copy the root root_hash file to the system where the new authentication
broker will be installed. On the AB (authentication broker to be).
mercury.universe.com# rcp /opt/VRTSat/bin/root_hash \

jupiter.universe.com:/tmp
Backup and restore authentication data
3 Locate an installer that is capable of installing the version of the Symantec

Product Authentication, install and configure this Symantec product in
authentication broker mode. The authentication principal created on the
system with the root broker, principals’s password, and the root’s hash_file
must be provided when prompted by the installer script.
4 After the Symantec Product Authentication is successfully configured, verify
the authentication broker mode is 1.
jupiter.universe.com# /opt/VRTSat/bin/vssat showbrokermode
5 To start and stop the Symantec Product Authentication process, use the
following scripts:
AIX /etc/rc.d/rc2.d/S70vxatd [start | stop]

HP-UX /sbin/rc2.d/S700vxatd [start | stop]
Solaris/Linux /etc/rc2.d/S70vxatd [start | stop]
Window C:>\ net start vrtsat
Start > All Programs > Administrative Tools > Services

Symantec Product Authentication provides a utility that can be used to back up
the data that is critical to the operation for the Symantec product. The backup
utility creates a temporary backup directory, and collects all the credential and
configuration files in this directory.
The backup procedure applies to a system that has the service and client
components installed and configured, either in root or root plus Authentication
mode. On a system that only has the client component, there is no credential
information.
On UNIX/Linux, critical authentication data is stored in the following directories:
/var/VRTsat
/etc/vx/vss
On Windows, the following directory stores the critical data:
C>:\Program Files\VERITAS\Security\Authentication\systemprofile
Use the showbackuplist option in the vssat utility to obtain a snapshot of the
crucial data. The vssat creates a temporary backup directory in
/var/VRTSatSnapShot to store the backup files.
On the UNIX/Linux system, the Symantec Product Authentication is configured

in root plus Authentication broker mode.
# /opt/VRTSat/bin/vssat showbackuplist
B|/var/VRTSat/.VRTSat/profile/VRTSatlocal.conf
B|/var/VRTSat/.VRTSat/profile/certstore
B|/var/VRTSat/RBAuthSource
B|/var/VRTSat/ABAuthSource
B|/etc/vx/vss/VRTSat.conf
Quiescing ...
Snapshot Directory :/var/VRTSatSnapShot
The /var/VRTSatSnapShot directory can then be backed up by backup application

such as NetBackup, or operating system native utilities such as tar and cpio.
On Windows, use the vssat.exe showbackuplist command to perform the backup.
On this Windows system, the Symantec Product Authentication is configured in
Authentication broker mode.
C:\Program Files\VERITAS\Security\Authentication\bin> \
.\vssat.exe showbackuplist
B|C:\Program Files\VERITAS\Security\Authentication\systemprofile\ \
VRTSatlocal.conf
B|C:\Program Files\VERITAS\Security\Authentication\systemprofile\ \
certstore
B|C:\Program Files\VERITAS\Security\Authentication\systemprofile \
ABAuthSource
K|HKEY_LOCAL_MACHINE\SOFTWARE\VERITAS\Security\Authentication
Quiesing ...
Snapshot Directory :C:\Program Files\VERITAS\Security\Authentication\ \
Snapshot
It is also important to backup the Symantec Product Authentication binaries and

libraries that are installed on the system.
On UNIX/Linux, the Symantec Product Authentication is installed in /opt/VRTSat
directory. Backing up this top level directory and the associated
/var/VRTSatSnapShot backup files would constitute a valid backup.
On Windows, the Symantec Product Authentication is installed in this directory.
C>:\Program Files\VERITAS\Security\Authentication
Backup and restore authorization data
In your enterprise, the validity of the backup procedure and the data should be
verified by performing a restore. Using the NetBackup application, it is possible
to restore the backed up files to a different directory.
After the files have been restored, copy the needed files to their original location.
The Symantec Product Authentication must use the restored binaries or libraries,
and operate on the restored files.
See the vssat(1) manual page for more information on the vssat command and
showbackuplist option.

Symantec Product Authorization provides a utility that can back up data that is
critical to the operation for the Symantec product. This backup utility creates
temporary backup directories and collects the access control list data repository
and configuration files into their respective temporary directories.
The backup procedure applies to a system that has the service and client
components installed and configured in authorization service mode. On a system
that only has the client component, there is no access control list data repository
to back up.
To perform a backup, an authenticated user can use the showbackuplist option
in the vssaz utility to obtain a snapshot of the crucial data.
To authenticate a user on UNIX/Linux prior to performing a backup, type the
following command:
# /opt/VRTSaz/bin/vssaz login \
--domain unixpwd:neptune.universe.com
Enter the AT Broker(host[:port]) to use: neptune.universe.com
Enter principal name: root
Enter password for root:
Login Successful
As an authenticated user, the backup for the Symantec Product Authorization is

performed using the vssaz command on UNIX/Linux. The vssaz command creates
temporary backup directories to store the backup files, as follows:
# /opt/VRTSaz/bin/vssaz showbackuplist
B|/var/VRTSaz/DBbackup
R|/var/VRTSaz/objdb
B|/var/VRTSaz/vxazd.log
B|/var/VRTSaz/debug
B|/etc/vx/vss/VRTSaz.conf
B|/etc/vx/vss/VRTSaz.loc
#
The /var/VRTSaz directory and /etc/vx/vss/VRTSaz.conf and

/etc/vx/vss/VRTSaz.loc configuration files can then be backed up using a backup
application such as NetBackup, or operating system native utilities such as tar
and cpio. It is also important to backup the Symantec Product Authorization
binaries and libraries that are installed on the system.
On UNIX/Linux, the Symantec Product Authorization is installed in /opt/VRTSaz
directory. Backing up this top level directory, the associated /var/VRTSaz directory,
and the /etc/vx/vss configuration files would constitute a valid backup.
On Windows, the Symantec Product Authorization is installed in this directory.
The vssaz.exe command stores the backup image into specific directories
(displayed in vssaz.exe command output) similar to UNIX/Linux.
C:\Program Files\VERITAS\Security\Authorization>
In your enterprise, the validity of the backup procedure and the data should be
verified by performing a restore. Using NetBackup application, it is possible to
restore the backed up files to a different directory. After the files are restored,
copy the needed files to their original location. The Symantec Product
Authorization must be able to use the restored binaries or libraries, and operate
on the restored repository or configuration files.
See the vssaz(1) manual page for more information on the vssad command and
showbackuplist option.
Appendix C
NetBackup common
procedures
■ NetBackup access control parameters
■ Verify NetBackup access control setup on the master server
■ Verify NetBackup access control setup on media servers
■ Verify NetBackup access control setup on clients
■ Using a remote administrative client to manage the master server
■ Replacing the root broker on the NetBackup master server
■ NetBackup storage units
■ NetBackup policies
■ Successful NetBackup backup and restore
■ NetBackup and authorization
■ NetBackup tape device drivers
■ NetBackup Java Windows administration console
■ NetBackup access control troubleshooting tips and messages
NetBackup access control parameters

NetBackup Access Control (NBAC) is governed by the following NetBackup
parameters on both UNIX/Linux and Windows platforms:
244 NetBackup common procedures
AUTHORIZATION_SERVICE = <Host with AZ service running> <AZ port>

AUTHENTICATION_DOMAIN = <Domain> <"comment"> <Mechanism> <BrokerHost>
<AT Port> 0
USE_VXSS = { Prohibited | Required | Automatic }
VXSS_NETWORK = <subject IP/Subnet/Host/Domain to either prohibited \
or required>
The NetBackup parameters are defined as follows:

■ AUTHORIZATION SERVICE - refers to the host name (usually a fully-qualified
host name on UNIX/Linux, and a host name on Windows) that is running the
authorization service. The 0 signifies that NetBackup is using the default
authorization port number 4032. This parameter is applicable only to the
master and media servers.
■ AUTHENTICATION DOMAIN - contains the domain name, user-defined
comment, mechanism (UNIXPWD, NIS, NISPLUS, WINDOWS) and the
authentication broker. The lines of code (when specified in the bp.conf file)
show that the master server uses the NISPLUS and WINDOWS mechanisms
for authentication. The NISPLUS domain is universe.com. and the
authentication broker is on neptune.universe.com. For the WINDOWS
mechanism, the domain is SUN (an Active Directory on Windows), and
jupiter.universe.com is the authentication broker. The 0 signifies that
NetBackup is using the default Authentication port number: 2821
AUTHENTICATION_DOMAIN=
universe.com. "neptune NIS+" NIS+ neptune.universe.com 0
AUTHENTICATION_DOMAIN=
SUN "SUN WINDOWS" WINDOWS jupiter.universe.com 0
The showallbrokerdomains option of the vssat command shows the domain

name of an authentication mechanism (domain type).
On UNIX/Linux, the sample output is, as follows:
***********************************
Broker Port: 2821
On Windows the sample output is, as follows:

NetBackup common procedures 245
C:\Program Files\VERITAS\Security\Authentication\bin>.\vssat \
showallbrokerdomains
****************************************
Broker Name: jupiter.sun.universe.com
Broker Port: 2821
Domain Name: SUN
Domain Type: nt
The valid values for USE_VXSS parameters are as follows:

■ Prohibited - turns off NetBackup Access Control
■ Required - mandates that the master server, all the media servers (including
the masters) and all of the clients (including the client on the master) are
configured for NetBackup Access Control
■ Automatic - permits some managed hosts (such as media and client) to be
configured for NetBackup Access Control, and also permits other hosts to be
configured with NetBackup Access Control disabled or not configured at all.
The AUTHENTICATION_DOMAIN and USE_VXSS parameters are applicable to the
master server, the media server, and the client.
The VXSS_NETWORK parameter is only used when USE_VXSS is set to Automatic.
VxSS network entries can be based on IP addresses, IP subnets, host names, or
domain names. When a client or media server is involved in a NetBackup operation,
the entries in the VxSS Network are consulted to determine if the host (client or
media) requires a specific security level, such as Prohibited or Required.
The VxSS network entries are searched and evaluated from top to bottom, and
the search stops when the first match is found. For example, if a master server
has media servers and clients with IP addresses 20.240.98.* and 20.240.90.*,
respectively, specifying 20.240.90 in a VxSS network entry with Required would
mandate all the clients in this subnet to have NetBackup Access Control enabled.
Specifying 20.240.98.23 in VxSS Networks with Prohibited would turn off
NetBackup Access Control for the media server only. Specifying
pluto.dwarf.universe.com with Required would subject this host to have NBAC
enabled.
The VXSS_NETWORK parameter is applicable to the master server, the media
server, and the client. When configuring NetBackup for access control, the
/usr/openv/netbackup/bin/jnbSA (on UNIX/Linux), or administrative console
(on Windows) GUI tools should be used to modify these parameters. On
UNIX/Linux, these parameters are stored in the /usr/openv/netbackup/bp.conf
file. Do not modify the content of the bp.conf file with a text editor; always use
the jnbSA or administrative console.
Verify NetBackup access control setup on the master server
You use the following NetBackup utilities to stop and start the NetBackup server
for the changes to take effect on UNIX/Linux:
The following NetBackup access control parameters are kept in the registry on
Windows: Click Start > Run and type regedit. Navigate to the following entry
and look for the NetBackup Access Control parameters.
To change the value of an NetBackup Access Control parameter, first highlight

the parameter, then modify its value. You stop and then start the NetBackup
Server using the bpdown and bpup utilities, respectively, for the changes to take
effect on Windows.
C:\> C:\"Program Files"\VERITAS\NetBackup\bin\bpdown

C:\> C:\"Program Files"\VERITAS\NetBackup\bin\bpup
Verify NetBackup access control setup on the master

server
You follow the information described in this section to verify the NetBackup
Access Control setup on UNIX/Linux and Windows master servers.
About shared Veritas products and processes

In NetBackup 6.0 and later, the shared component, Private Branch Exchange, is
required for the NetBackup master server. Private Branch Exchange is a
prerequisite to NetBackup and must be installed and configured on a system before
installing the NetBackup master server. Configuring the NetBackup master server
and then adding NetBackup Access Control support are two separate tasks which
you can perform sequentially.
To enable NetBackup Access Control on the master server, the prerequisite
products, Symantec Product Authentication (AT) and Symantec Product
Authorization (AZ), must be installed and configured on the same system as the
master server. You normally configure Symantec Product Authentication in
authentication broker mode using an existing root broker already configured on
a remote system. If NetBackup is the only Symantec product in your data center,
you may place the root broker and the authentication brokers on the same
computer as the NetBackup master server.
To verify the installed version of the authentication and authorization products,

the list package command on Solaris (pkginfo), AIX (lslpp), HP-UX (swlist), or
Linux (rpm) can be used to show the product version. Read the command man
pages on the correct options to use. On Windows platforms, you access Start >
Settings > Control Panel > Add or Remove Programs. Then access the product
and go to the link, Click here for support information
UNIX/Linux
Before setting up NetBackup Access Control, you verify the pbx_exhange, vxatd,
and vxazd processes are running on the system on which the NetBackup master
server is configured. On the designated host, use the ps1 or
/usr/openv/netbackup/bin/bpps -x commands on the host to verify the
processes are running.
A sample output is shown, as follows:
Shared VERITAS Processes
------------------------
root 307 1 0 Dec 07 ? 0:05 /opt/VRTSpbx/bin/pbx_exchange
root 411 1 0 Dec 07 ? 0:03 /opt/VRTSaz/bin/vxazd
root 5778 1 0 Dec 07 ? 0:01 /opt/VRTSat/bin/vxatd
For information on how to manually start processes, refer to the following section.
Windows
On the system where NetBackup Master Server is configured, you navigate from
the Windows Start menu, and click Administrative Tools > Services. You then
verify the following services are started:
■ Private Branch Exchange
■ Authentication Service
■ Authorization Service
If a service is not started, highlight that service and click Start. Also, on the
Windows Task Manager, verify that the vxatd.exe and vxazd.exe processes are
running.
Verify NetBackup valid authentication domain

On the system with the master server, verify that the NetBackup domain
(NBU_Machines), the primary authentication broker, and the host name are
correct. Use the NetBackup bpnbat command to list this information.
This section contains sample outputs of the bpnbat command for UNIX/Linux
and Windows master servers. On UNIX/Linux platforms, neptune.universe.com
is the host name on which the master server is configured. On the same system,
the root and authentication brokers are also configured. The domain is
NBU_Machines@neptune.universe.com, and the primary authentication broker
is also on neptune.universe.com.
The following is a sample output for UNIX/Linux master server:

/usr/openv/var/vxss/credentials/neptune.universe.com
On Windows, all the systems in this document are contained in a private domain
named sun. The static host name for the master server is jupiter.universe.com.
Since jupiter.universe.com belongs to the sun private domain, the host name
becomes jupiter.sun.universe.com. On this system, it has an authentication
broker, and the root broker is on a remote host (mercury.universe.com). For
information on how to add a new authentication broker with a remote root broker,
refer to the following section.
The following is a sample output for a Windows master server:
C:\Program Files\VERITAS\NetBackup\bin>bpnbat -whoami -cf \

..\var\vxss\credentials\jupiter.sun.universe.com
Issued by: /CN=jupiter/OU=root@mercury.sun.universe.com/O=vx
Expiry Date: Nov 30 18:44:36 2007 GMT
C:\Program Files\VERITAS\NetBackup\bin>
The Expiry Date is displayed in Greenwich Mean Time (GMT), and not local time
on the host system. It is important to convert the local system time to GMT to
determine the validity of a user credentials.
On Windows, if the listed NetBackup domain is not
NBU_Machines@jupiter.sun.universe.com, or if it is missing, use the bpnbat
command with the host name jupiter.
The following example illustrates sample Windows output:
C:\Program Files\VERITAS\NetBackup\bin>.\bpnbat -addmachine

Does this machine use Dynamic Host \
Configuration Protocol (DHCP)? (y/n)n
Machine Name: jupiter
Password: ******
Password: ******
Note: On UNIX/Linux, if NBU_Machines is missing, use -addmachine for the host

name neptune.universe.com.
After using -addmachine, use the following command on the machine where the
certificate is to be placed. In this case, jupiter.universe.com (master server).
C:\Program Files\VERITAS\NetBackup\bin>.\bpnbat -loginmachine

Does this machine use Dynamic Host \
Configuration Protocol (DHCP)? (y/n)n
Machine Name: jupiter
Password: ******
Next, verify that you can successfully log on. This ensures that the authentication
portion of the NetBackup Access Control configuration on the master server is
set up correctly. The login name (root on UNIX/Linux or administrator on
Windows) must be a member of the NBU_Security Admin group. To log on, type
bpnbat -login.

C:\Program Files\VERITAS\NetBackup\bin>bpnbat -login

Authentication port [0 is default]:
Authentication type (NIS, NISPLUS, WINDOWS, vx, unixpwd): WINDOWS
Domain: SUN
Password: ******
Perform authorization lookups on NetBackup machines

On the system on which the authorization service server is configured for
NetBackup, login as root (on UNIX/Linux) or administrator (on Windows), and
run the NetBackup command bpnbaz -ShowAuthorizers from the command line.
This command shows the host names of the master server and of all the media
servers that are permitted to perform authorization lookups. All servers listed
should display the vx (Veritas Private Domain) authentication domain type in the
domain NBU_Machines@neptune.universe.com.
UNIX/Linux sample output, as follows:
# /usr/openv/netbackup/bin/admincmd/bpnbaz -ShowAuthorizers
==========
Type: User
Domain Type: vx
Windows sample output, as follows:
C:\Program Files\VERITAS\NetBackup\bin\admincmd> .\bpnbaz \

-ShowAuthorizers -server jupiter
==========
Type: User
Domain Type: windows
Domain:JUPITER.SUN.UNIVERSE.COM
Name: ADMINISTRATOR
==========
Type: User
Domain Type: windows
Domain:JUPITER.SUN.UNIVERSE.COM
Name: GOKU
==========
Type: User
Domain Type: vx
Domain:NBU_Machines@jupiter.sun.universe.com
==========
Type: User
Domain Type: vx
Domain:NBU_Machines@jupiter.sun.universe.com
If a host that has either the master or media server configured, but it is missing
on the list of authorized machines, add the host name using the NetBackup
command bpnbaz -allowauthorization.
On Windows, the sample output is, as follows:
C:\Program Files\VERITAS\NetBackup\bin\admincmd>.\bpnbaz \
-allowauthorization jupiter -server jupiter
Verify NetBackup authorization database

Use the NetBackup command bpnbaz to verify the authorization database is
NBU_User
NBU_Operator
NBU_Admin
NBU_Security Admin
Vault_Operator
C:\Program Files\VERITAS\NetBackup\bin\admincmd>.\bpnbaz -listgroups

NBU_User
NBU_Operator
NBU_Admin
NBU_Security Admin
Vault_Operator
If neither bpnbaz -listgroups returns any groups, or bpnbaz -listmainobjects

returns any data, use the bpnbaz -setupsecurity command to set up the security
for the master server.
Verify host properties configured correctly

While you are logged on, either through the command jnbSA on UNIX/Linux, or
through the administrative console in Windows, expand Host Properties, double
click Master and highlight the master server. On the menu bar, click Action >
Properties. In the Access Control properties, verify that the Veritas Security
Services (VxSS) property is set correctly.
The VxSS (USE_VXSS) setting should be either Automatic or Required. Required
is for a setup in which all hosts (Master, Media, Clients) are using NBAC. If all
hosts are not using NBAC, the VxSS (USE_VXSS) should be set to Automatic.
Next, verify that all domains in the authentication domains list are spelled correctly
and point to valid authentication brokers and mechanisms. Then verify that the
host name for the authorization service is spelled correctly.
On UNIX/Linux, the sample output is as follows:
SERVER = janus.univerise.com
CLIENT_NAME = neptune.universe.com
AUTHENTICATION_DOMAIN = universe.com. "NIS+ namespace"

NIS+ neptune.universe.com 0
AUTHENTICATION_DOMAIN = neptune.universe.com "/etc/passwd"
PASSWD neptune.universe.com 0
AUTHORIZATION_SERVICE = neptune.universe.com 0
USE_VXSS = REQUIRED
On Windows, the NetBackup parameters are stored in the registry. Use the regedit
(or regedt32 to handle multibyte characters) command to view NetBackup Access
Control and other NetBackup parameters. Refer to the following section for more
information.
Cross-platform authentication domains

On a master server, you can setup NetBackup for access control with multiple
authentication brokers distributed across UNIX/Linux and Windows platforms.
A master server, either UNIX/Linux or Windows, could have authentication brokers
configured on Windows, HP-UX, Red Hat, AIX, and Solaris platforms. On each of
these platforms, an authentication broker can be setup to use one or more
authentication domains and mechanisms.
For example, a master server is configured on Windows, and it has media servers
and clients on Windows, HP-UX, Red Hat, and Solaris. Users on Windows are
authenticated through the WINDOWS (nt) mechanism.
UNIX/Linux users can be authenticated by PASSWD, NIS, or NISPLUS authentication
mechanism. The WINDOWS mechanism is specific to Windows. The PASSWD, NIS,
and NISPLUS mechanisms are applicable to UNIX/Linux platforms only.
All of the media servers and clients are authenticated by the authentication broker
configured on the master server. Windows clients can be authenticated by the
authentication broker configured on either the Windows or UNIX/Linux master
server, or media server.
To authenticate users on HP-UX that use NISPLUS, an authentication broker is
needed on a UNIX/Linux platform that has the NISPLUS mechanism configured.
Since the master server has UNIX/Linux media servers, you can configure an
authentication broker with NISPLUS on a UNIX/Linux host that has a media
server.
Authentication brokers on these media servers can then be used to authenticate
their respective users. Therefore, you can use the authentication broker configured
on Red Hat to authenticate all of the Red Hat users. Similarly, the authentication
broker on Solaris could be used to authenticate all of the Solaris users. You can
use an authentication broker configured on AIX to authenticate users on HP-UX.
Conversely, a master server configured on UNIX/Linux may have authentication
brokers dispersed over Solaris, HP-UX, AIX, Red Hat, and Windows. In an
environment that has heterogenous authentication brokers, take care to ensure
that authentication brokers are associated with the correct mechanisms
(WINDOWS, NIS, NISPLUS, PASSWD) for the chosen authentication domains.
Refer to the following section for the list of NBAC parameters, and how to locate
and view them on UNIX/Linux and Windows platforms.
On Windows, the following relevant NetBackup parameters (extracted through
the config registry) are shown:
Verify NetBackup access control setup on media servers
SERVER = jupiter
MEDIA_SERVER = janus.universe.com
MEDIA_SERVER = titan.universe.com
MEDIA_SERVER = leda
CLIENT_NAME = jupiter
AUTHENTICATION_DOMAIN = SUN "Windows domain" WINDOWS jupiter 0
AUTHENTICATION_DOMAIN = titan.universe.com "/etc/passwd"
PASSWD titan.universe.com 0
AUTHENTICATION_DOMAIN = universe.com. "NIS+ domain"
NIS+ janus.universe.com 0
AUTHORIZATION_SERVICE = jupiter 0
USE_VXSS = REQUIRED
Verify NetBackup access control setup on media

servers
You follow the information in this section to verify the NetBackup Access Control
setup on both UNIX/Linux and Windows media servers.
Shared Veritas products and processes

In NetBackup 6.0 and later, the shared component Private Branch Exchange (PBX)
is required for NetBackup Media Server. PBX is a prerequisite and must be installed
and configured on the system before installing NetBackup Media Server.
Configuring NetBackup Media Server and adding NetBackup Access Control
support are two separate tasks which can be done sequentially.
To enable NetBackup Access Control on the Media Server, you must first install
the prerequisite Authentication (AT) and Authorization (AZ) products. For
NetBackup Media Server, only the client portion of these products is needed. A
client install does not require configuration and therefore the vxatd and vxazd
processes will not be running on the designated host.
However, the AT could be configured in authentication broker mode using an
existing root broker already configured on a remote system. The authentication
broker could be used to authenticate NetBackup users of the same platform as
the media server.
For example, suppose the master server is on Windows and the media server is
on HP-UX. For HP-UX clients that want to authenticate using the NISPLUS
authentication mechanism, an authentication broker that is capable of supporting
NISPLUS must be available to authenticate these HP-UX clients. The media server
uses the authentication broker configured on the master server residing on a

Windows system.
To verify the installed version of the Symantec Product Authentication and
Authorization products, use the following commands:
use the list package command on Solaris (pkginfo), AIX (lslpp), HP-UX (swlist), or
Linux (rpm) to show the product version. Read the command man pages for the
correct options to use. On Windows, you access the Control Panel, and click Add
or Remove Programs. You then select the product name, and click Click here for
support information.
Media Server valid credential verification

In the enterprise, assume the authentication root broker is configured on a
Windows host (mercury.universe.com), and all the Windows hosts are contained
in a Windows private domain (sun). Also assume the NetBackup master server
(jupiter.universe.com) has two media servers: leda.universe.com on Windows,
and janus.universe.com on HP-UX.
On Windows, for each host that has the media server configured for NetBackup
Access Control, you verify the media server’s authentication certificate is issued
by the root broker (mercury.universe.com). You also verify that the media server
is authenticated against the expected authentication broker. You use the NetBackup
command bpnbat -whoami -cf <file> to perform these verifications.
On Windows, the following sample output is shown:
C:\Program Files\VERITAS\NetBackup\bin>.\bpnbat -whoami

-cf ..\var\vxss\credentials\leda.sun.univers.com
Name: leda.sun.univers.com
On UNIX/Linux, the following sample output is shown:
-cf /usr/openv/var/vxss/credentials/janus.universe.com
Name: janus.universe.com

Media servers accessible to the authorization database

NetBackup resources such as storage units and volume pools are checked against
access control rules listed in the authorization database when they are accessed.
Therefore, media servers (configured externally to the master server) must be
able to access the authorization database. To show that a media server has access
to the authorization database, you use the NetBackup command bpnbaz
-ListGroups -CredFile <file> to perform the authorization checks.
On a UNIX/Linux media server (janus.universe.com), the following sample output

is shown:
# /usr/openv/netbackup/bin/admincmd/bpnbaz -ListGroups \
-Server jupiter.universe.com \
-CredFile /usr/openv/var/vxss/credentials/janus.universe.com
NBU_User
NBU_Operator
NBU_Admin
NBU_Security Admin
Vault_Operator
On a Windows media server (leda.universe.com), the following sample output is

shown:
C:\Program Files\VERITAS\NetBackup\bin\admincmd>.\bpnbaz
-ListGroups \
-Server jupiter \
-CredFile ..\..\var\vxss\credentials\leda.sun.univers.com
NBU_User
NBU_Operator
NBU_Admin
NBU_Security Admin
Vault_Operator
After the bpnbaz command successfully executes, it shows that the authentication
and authorization client libraries are installed and working. If the host where the
Media Server is configured was not granted the privilege to perform authorization
checks, the host must be added to the authorization list. To grant a new media
server host the authorization checks privilege, on the master server
jupiter.universe.com, you run the NetBackup command bpnbaz

-allowauthorization.
On the host that has the master server jupiter.universe.com, add a new host
(titan.universe.com on Red Hat) that has the media server configured.
On a Windows host that has the Master Server, the sample output is shown, as
follows:
C:\Program Files\VERITAS\NetBackup\bin\admincmd>.\bpnbaz \
-allowauthorization titan.universe.com -server jupiter
Media server with multiple authentication domains

On a media server (either UNIX/Linux or Windows), you can set up an
authentication broker for access control that covers multiple authentication
domains. An authentication domain uses a specific authentication mechanism.
For example, in a data center, the master has a media server on HP-UX, and an
authentication broker configured on the media server is using NISPLUS and PASSWD
authentication mechanisms. This authentication broker can be used to authenticate
NetBackup clients on Solaris, AIX, HP-UX, and Red Hat that want to use either
one of the mechanisms.
Windows clients cannot be authenticated by this media server on HP-UX, because
the mechanisms NISPLUS and PASSWD are not applicable to Windows. To
authenticate Windows clients, a separate Windows media server is needed that
uses the WINDOWS Authentication Mechanism.
In an environment where the authentication broker is configured with
heterogenous authentication domains and mechanisms, care must be taken to
ensure that authentication domains and mechanisms (WINDOWS, NIS, NISPLUS, and
PASSWD) are compatible.
Refer to the following section for the list of NetBackup Access Control parameters,
and how to locate and view them on UNIX/Linux and Windows platforms.
On an HP-UX host that has a media server, some of the relevant NetBackup
parameters (extracted from the /usr/openv/netbackup/bp.conf configuration
file) are as follows:
SERVER = jupiter.universe.com
SERVER = janus.universe.com
CLIENT_NAME = janus.universe.com
Verify NetBackup access control setup on clients
EMMSERVER = jupiter
AUTHENTICATION_DOMAIN = janus.universe.com "/etc/passwd"
PASSWD janus.universe.com 0
AUTHENTICATION_DOMAIN = universe.com. "NISPLUS"
NIS+ janus.universe.com 0
AUTHORIZATION_SERVICE = jupiter.universe.com 0

You follow the information described in this section to verify the NetBackup
Access Control setup on Windows and UNIX/Linux clients.
Shared Veritas product

In NetBackup 6.0 and later, the client installation does not need the shared
component Private Branch Exchange (PBX). Installing NetBackup Client and then
adding NetBackup Access Control support are two separate tasks that can be done
sequentially.
To enable NetBackup Access Control on the NetBackup client, first install the
prerequisite product: Authentication (AT) client. For NetBackup clients, only the
client portion of AT is needed.
The AT client install does not require configuration, so the vxatd process does
not run on the designated host. However, on the designated host where the
NetBackup client is installed, the host could be a node in the Veritas Cluster Server
(VCS). When VCS is configured for authentication, an authentication broker is
required on each node of a VCS cluster. Even though the host has an authentication
broker, the NetBackup client uses a remote authentication broker, and not the
local authentication broker on its master management server.
use the list package command on Solaris (pkginfo), AIX (lslpp), HP-UX (swlist), or
Linux (rpm) to show the product version. Read the command man pages for the
correct options to use. On Windows, you access the Control Panel, and click Add
or Remove Programs. You then select the product name, and click Click here for
support information
Client has valid credentials

You use the NetBackup bpnbat command on a NetBackup client to list the
credential, domain, and the issuing broker information. You then verify that the
client has correct credential, domain and issuing broker.
Sample outputs of the bpnbat command for Windows and UNIX/Linux clients are
shown.
C:\Program Files\VERITAS\NetBackup\bin>bpnbat -whoami \

-cf ..\var\vxss\credentials\callisto.sun.universe.com
Name: callisto.sun.universe.com
In a setup that uses the Windows Active Directory, the credential file includes the
Windows domain name, as follows:
C:\Program Files\VERITAS\NetBackup\bin>bpnbat -whoami

-cf ..\var\vxss\credentials\galileo.SUN.universe.com
Name: galileo.sun.universe.com
Issued by: /CN=broker/OU=root@jupiter.sun.universe.com/O=vx
-cf /usr/openv/var/vxss/credentials/calypso.universe.com
Name: calypso.universe.com
If the credential file is missing in the var/vxss/credentials directory, execute the

bpnbat -loginmachine command.
Authentication client libraries

The authentication client libraries must be installed on the system on which the
NetBackup client is set up to use NetBackup Access Control. The command bpnbat
must perform a successful log on to show that the correct authentication libraries
are installed on the system.
On Windows, the following sample output is shown:
C:\Program Files\VERITAS\NetBackup\bin>.\bpnbat -login

Authentication Broker: callisto
Domain: SUN
Name: <login in SUN>
Password: <login’s password>
On UNIX/Linux, the following sample output is shown:
Authentication type (NIS, NIS+, WINDOWS, vx, unixpwd): NIS+
Domain: universe.com.
Name: <NIS+’s login>
Password: <NIS+ login’s password>
You do not currently trust the server: neptune.universe.com,
do you wish to trust it? (y/n): y
The top-level directory in which the authentication libraries are installed is found
in the /etc/vx/vss/VRTSat.loc file. On Windows, this information is kept in
the Windows registry of the product.
You use the following commands to verify all the authentication libraries are
physically present in the library /opt/VRTSat/lib directory:
# grep ProductInstallDir /etc/vx/vss/VRTSat.loc

ProductInstallDir=/opt/VRTSat
# ls /opt/VRTSat/lib/*
libauthlocalhost_t.sl libvrtsat4L_t.sl libauthnis.sl libvrtsat_t.sl
libauthnisplus.sl
libAtWrapper.sl libvrtsat.sl libauthlocalhost.sl libvrtsat4L.sl
Client authentication domains

On the system on which the NetBackup Master Server is configured, launch either
the administrative console on Windows, or run the command jnbSA on UNIX/Linux.
Using a remote administrative client to manage the master server
You access the Host Properties to verify. For jnbSA, the NetBackup Access Control
attributes are found under the Access Control property.
Note: The domains listed in the authentication domain, universe.com.,

neptune.universe.com., or SUN (Windows Active Directory) must be valid for
the user and spelled correctly.
For each authentication domain, you verify that the chosen broker,
neptune.universe.com, jupiter, specified for the user, supports the selected
authentication mechanism (NIS+, PASSWD, or WINDOWS). For example, it is not valid
for an HP-UX user to use an authentication domain with a Windows authentication
broker that uses the WINDOWS mechanism.
The NetBackup Access Control parameter, AUTHENTICATION_DOMAIN, keeps track
of authentication domain, authentication broker, and mechanism (also referred
to as authentication type). The verification of the AUTHENTICATION_DOMAIN can
also be done on the user system.
On a Windows client, the NetBackup Access Control parameters are kept in the
registry. On a UNIX/Linux client, the NetBackup Access Control parameters are
stored in the /usr/openv/netbackup/bp.conf file. To change the NBAC
parameters, either on Windows or UNIX/Linux, refer to the information in the
following section. See “NetBackup access control parameters” on page 243.
Using a remote administrative client to manage the

master server
You must first establish a trust between the administrative client and the
authentication broker configured on the master server for a NetBackup client
with the remote console (administrative client), to manage the master server with
NetBackup Access Control enabled.
On the host that has the NetBackup administrative client, the client portion of
the prerequisite products, authentication (AT) and authorization (AZ), must be
installed. The client installation does not require configuration, so the vxatd.exe
and vxazd.exe processes are not running on the designated host.
It is recommended that the following procedure be performed to establish trust
between the authentication broker configured on the master server, and the
administration client (remote console) on Windows.
Replacing the root broker on the NetBackup master server
To create trust between authorization broker and administration client

1 On the host where the Master server is configured, run the following
command:
C:\Program Files\VERITAS\NetBackup\bin\admincmd> bpgetconfig \

USE_VXSS AUTHENTICATION_DOMAIN > C:\TEMP\VXSS_SETTING.txt
C:\Program Files\VERITAS\NetBackup\bin\admincmd> type \

C:\TEMP\VXSS_SETTING.txt
AUTHENTICATION_DOMAIN = SUN "WINDOWS" WINDOWS jupiter 0
2 Copy C:\TEMP\VXSS_SETTINGS.txt to the host that has the administration

client.
3 On the host that has the administration client, run the following command:
C:\Program Files\VERITAS\NetBackup\bin\admincmd> bpsetconfig \

C:\TEMP\VXSS_SETTINGS.txt
Using the USE_VXSS and AUTHENTICATION_DOMAIN values copied from the

master server, the bpsetconfig command sets these two parameters on the
administrative client to trust the authentication broker on the master server.
The administration client is then ready to log on automatically to the
4 Launch the administration console from the administration client, and a
request to establish a trust with the master server authentication broker is
initiated. Once the trust is established, the administration console is available.
Replacing the root broker on the NetBackup master

server
In a data center, a situation (consolidation) may occur that requires the move of
the root broker from the system where the NetBackup master server is configured
to a remote system. Before replacing the local root broker that is used to
authenticate the master authentication broker, first stop the master and all media
management servers.
This example assumes the following existing NetBackup configuration:
■ Host details - Host jupiter.universe.com has the NetBackup master
management server authentication root plus authentication brokers, and
authorization server configured.
■ NetBackup master management server details - NetBackup master has media

servers configured on separate Solaris, HP-UX, AIX, Red Hat, and Windows
systems. Command options, such as bpnbat, vssat, and vxatd, are identical
on both UNIX/Linux and Windows platforms. Binary files such as bpnbat,
netbackup, bpup.exe. and bpdown.exe are located in different directories on
each of these platforms. NetBackup master has management clients on Solaris,
HP-UX, AIX, Red Hat, and Windows systems.
Assume, as an example, that your company needs to decouple the root broker
from jupiter.universe.com to a remote system mercury.universe.com. Use the
following steps to replace the root broker on jupiter.universe.com with the one
on mercury.universe.com, and move all the authentication brokers in the jupiter
authentication hierarchy into mercury.
To move the root broker to a remote system
1 On mercury.universe.com, create a principal (service) for the authentication
broker on jupiter.universe.comas follows:
# /opt/VRTSat/bin/vssat addprpl \
--pdrtype root \
--prplname jupiter.universe.com \
--password jupiter_pass --prpltype service \
--domain root@mercury.universe.com
If you have additional authentication brokers configured on media servers,

these brokers also need to be moved to the new authentication hierarchy.
Create extra authentication principals (addprpl) for systems that have
2 Shut down the NetBackup master management server, authentication, and
authorization services on jupiter.universe.com, and on systems with media
servers.
■ On UNIX/Linux, as follows:
■ On Windows, bpup is equivalent to netbackup stop. Type the following

command:
C:\Program Files\VERITAS\NetBackup\bin> .\bpdown
■ On Solaris, authentication and authorization services can be stopped with

S71vxazd and S70vxatd, respectively. On other UNIX/Linux platforms,
same scripts located in different directories should be used.
# /etc/rc2.d/S71vxazd stop
# /etc/rc2.d/S70vxatd stop
■ On Windows, the authentication and authorization services can be stopped

by clicking Administrative Tools > Services.
3 Remove all the root Private Domain Repository entities on

jupiter.universe.com. On all the systems with master and media servers,
remove all the NetBackup credentials obtained through the previous root
broker. The list of credentials can be shown using the following command:
# /opt/VRTSat/bin/vssat showcred
These credentials should be removed from the system where the master
management server is located. Type the following commands:
# /opt/VRTSat/bin/vssat deletecred \
--domain vx:root@jupiter.universe.com \
--prplname broker
--domain vx:root@jupiter.universe.com \
--prplname root
--domain vx:SERVICES@jupiter.universe.com \
--prplname vxazd_vxsvc@jupiter.universe.com
4 Start an authentication broker in another authentication hierarchy by copying

the root hash from the system that has the root broker
(mercury.universe.com), to the system where the authentication broker
(jupiter.universe.com) is located. On mercury.universe.com, remote copy the
hash file to jupiter.universe.com, as follows:
# rcp /opt/VRTSat/bin/root_hash \
jupiter.universe.com:/tmp/root_hash
5 Start authentication in authentication broker mode on jupiter.universe.com

using the principal created on mercury.universe.com, as follows:
# /opt/VRTSat/bin/vxatd -a -n <broker> -p <password> \

-x <domainType> -y <domainName> -q <rootBrokerHost> \
-z <rootBrokerPort> -h <rootHashFile>
# /opt/VRTSat/bin/vxatd -a -n jupiter.universe.com \
-p jupiter_pass \
-x vx -y root@mercury.universe.com \
-q mercury.universe.com \
-z 2821 -h /tmp/root_hash
The output of the ps command for the vxatd process shows all the options
that were used. To remove those options, stop and start the vxatd process,
as follows:
# sleep 30
# /etc/rc2.d/S70vxatd start
6 Restart the authorization service, NetBackup master management server,

and all the associated media management servers.
■ On UNIX/Linux, as follows:
# /etc/rc2.d/S71vxazd start
■ On Windows, bpup is equivalent to netbackup start. Type the following

command: C:\Program Files\VERITAS\NetBackup\bin>.\bpup
7 At this point, jupiter authentication broker (vxatd) is using the root broker
on mercury.universe.com. The entities and credentials in the
NBU_Machines@jupiter.universe.com private domain repository are obsolete.
To use the mercury.universe.com credential for the NetBackup master server
on jupiter.universe.com, run the following command:
8 On each system that has a NetBackup media management server, run the
following command to enable the media server host to reacquire the new
credential using the mercury.universe.com certificate:
9 Now that the systems where the NetBackup master and media management
servers have acquired new system credentials in the new authentication
hierarchy, stop and start the NetBackup management servers on these
systems, as follows:
10 On each system that has NetBackup management client, run the following
command to enable the client host to reacquire the new credential using the
mercury.universe.com certificate:
11 Run the following command on jupiter.universe.com to get a list of systems

that were previously added to and authenticated in the NBU_Machines private
domain repository:
# /usr/openv/netbackup/bin/bpnbat -showmachines
bianca.universe.com
triton.universe.com
portia.universe.com
12 Run the following command to acquire a new login session on management

clients, master and media management servers:
13 Verify the root broker is moved to the remote system:

■ After you have completed steps 1 through 12 on the master server, media
server, and client, systems, you must successfully log on using the bpnbat
-login command.
■ Use the jnbSA command on UNIX/Linux, or the administrative console

on Windows, to verify a successful logon by the NetBackup Access Control
user. Most importantly, you must perform a backup and a restore for any
NetBackup Access Control-enabled clients using any of the NetBackup
Access Control-enabled media servers.
■ Create a new policy or modify an existing policy; create new storage unit
or modify an existing storage unit in the jnbSA or Administrative console
on the master server.
NetBackup storage units
■ On a host that has a media server, perform an update on the tape devices
to verify those connections still work.
NetBackup storage units

A storage unit is used to store backup images. Every NetBackup policy has a storage
unit. Without the NetBackup Access Control (NBAC), users must be logged in as
either root (UNIX/Linux), or administrator (Windows) to create, modify, or delete
storage units.
Ordinary users (like goku) do not have the required privilege to manipulate storage
units. With NBAC enabled, non-privileged users, who are properly authenticated
and authorized, can manipulate storage units and other NetBackup administrative
tasks that require the privileges of superusers.
To create a disk storage unit as either root or ordinary user
◆ Execute the following command on system neptune.universe.com:
# /usr/openv/netbackup/bin/admincmd/bpstuadd \
-M neptune.universe.com -label neptune-disk -disk \
-path /neptune-disk -dt 1 \
-host neptune.universe.com \
-cj 4 -okrt 0 -hwm 98 -flags NONE \
-odo 0 -mfs 524288
# /usr/openv/netbackup/bin/admincmd/bpstulist
neptune-disk 0 neptune.universe.com 0 -1 -1 4 0
/neptune-disk 0 1 524288 …
To create a storage unit through the NetBackup administration console

1 On NetBackup administration console, NetBackup Management, click the
Storage Units, Actions (at the top), New, New Storage Units…
2 On the New storage unit screen, enter the required information (like Storage
unit name, Storage unit type, Storage device, Media server). Click OK to create
the storage unit.
3 Go to NetBackup Management, Storage Units, verify the new storage unit
shows up.
An ordinary user (like goku) that was authenticated and with the appropriate
authority is able to create a new storage unit, as illustrated in UNIX/Linux
and Windows examples.
NetBackup policies
4 On the NetBackup Administration console and jnbSA, the Configure Storage

Devices wizard can be used to configure tape libraries. This wizard
automatically creates the necessary storage units for the devices and volumes
in the tape library. On a setup that has multiple media servers, options are
given to selectively pick the media server for device configuration.
5 To configure volumes in tape libraries, on the NetBackup administration
console and jnbSA, use the Configure Volumes wizard for this operation.
The Configure Storage Devices and Configure Volumes wizards should be
performed on the system that has the master management server.
To create a new NetBackup volume pool
1 On the NetBackup administration console (Windows), or jnbSA (UNIX/Linux),
go to Media and Device Management > Media, Highlight Volume Pools >
Actions > New > New Volume Pool.
2 On the New Volume Pool screen, verify the host name in the Manager host
is correct. Type in a unique name for the Pool name and a description.
3 Check the Permit only the specified host to access volumes in the pool and
enter the Host name: which should be one of the media servers already
configured in the environment. Click OK to continue.
To verify the new volume pool was created
1 Go to Media and Device Management > Media > Volume Groups. Highlight
all the volumes to assign to the new volume pool. Click Edit > Change.
2 On the Change volumes screen, in the Volume pool box, check the New pool
and select the new volume pool that was created earlier.
3 Go to the Volume Groups; those volumes that were assigned to the new volume
pool should have the new pool name in the Volume Pool column.
4 In the policy attribute screen, you can select the new volume pool for the
policy.
NetBackup policies
A policy is used to initiate a manual or scheduled backup. Every NetBackup policy
has to have management clients deployed on systems with valuable data. Without
the NetBackup Access Control (NBAC), users must be logged in as either root
(UNIX/Linux) or administrator (Windows) to create, modify, or delete policies.
Ordinary users (like goku) do not have the required privilege to manipulate policies.
With NBAC enabled, ordinary users who are properly authenticated and authorized,
Successful NetBackup backup and restore
can manipulate policies and other NetBackup administrative tasks that normally
require the privileges of superusers.
To create a NetBackup policy on Windows or UNIX/Linux
1 On the system that has the NBU master management server, go to NetBackup
Management, Policies, Actions (at the top), New, New Policy… Enter the name
for the Policy name: and check the Use Backup Policy Configuration Wizard.
Click OK to continue.
2 On the Policy Name and Type screen, in the Select the policy type field,
typically choose MS-Windows-NT on Windows and Standard on UNIX/Linux
as the policy type.
3 On the Client List screen, enter the host name of the client, client hardware
and operating system. A policy can have multiple clients that could make up
of Windows and UNIX/Linux management clients. Typically, all the Windows
clients are grouped together in policies that are created for Windows. The
same rationale applies to clients on UNIX/Linux platforms.
4 On the Files screen (Backup Selections on UNIX/Linux), enter the directories
or files this policy is intended to cover.
5 On the Backup Type screen, select the Full Backup, Incremental Backup
(differential or cumulative), and User Backup (allow users to initiate backup
on their own). To enable a user to initiate a backup or restore from a client,
the User Backup must be selected.
6 On the Rotation and Start Windows screen, select the retention for the backup
image and the time the backup should start.
7 Click Finish to start creating the NetBackup policy. On the NetBackup
Management, Policies, verify the new policy has appeared.
8 If the Bare Metal Restore license key is installed on the system that has the
NBU master management server, the Collect disaster recovery information
for Bare Metal Restore attribute is checked by default when a NetBackup
policy is created. The BMR attribute should be turned off explicitly if this
capability is not intended.
Successful NetBackup backup and restore

Before performing a backup and restore, the procedures and instructions that are
listed in the NetBackup use cases in Chapter 6 and Chapter 7 should be completed
successfully. After configuring the master, media and client, a backup policy is
needed to perform a backup. A backup policy needs a storage unit to store the
backup image. To create a backup policy, refer to the following sections.
NetBackup and authorization
See “NetBackup policies” on page 268.

A successful backup and restore is used as a simple test to verify the integrity of
the NetBackup’s configuration in the following situations:
■ After the master, media and clients are configured in an environment, but
before the NetBackup Access Control (NBAC) is enabled, the NetBackup servers
must be able to perform a backup for one of the clients (like
europa.universe.com) and restore the backup to another client (like
calypso.universe.com). This task needs to be performed by the root
(UNIX/Linux) or administrator (Windows) user.
■ After configuring the NetBackup product with the NBAC enabled on Master,
Media and Client, to ensure that the NetBackup product is still functioning,
the backup (initiated from the Master) and restore (initiated from the client)
operation is used as one of the verification tests. A properly authenticated and
authorized user other than root or administrator must be able to perform a
task like backup and restore. An ordinary user with proper authority must be
able to perform NetBackup administration tasks such as creating disk storage
units and policies.
■ To do a manual backup for a NetBackup policy, on the Administration console
(Windows) or jnbSA (UNIX/Linux), go to NetBackup Management, Policies,
and select the specific policy name, click the Actions (at the top) and pick
Manual Backup to initiate a backup.
■ A restore is launched through the Backup, Archive and Restore (BAR). On
UNIX/Linux, the BAR is listed on the jnbSA display screen. On Windows, to
get to the BAR, on the Administration console, click File (at the top) and select
the Backup, Archive, and Restore. In jnbSA, the BAR has the options of selecting
source client, destination client and backup type. In Administration console,
the BAR is display on another screen, click File (at the top) of this screen to
display various restore options.

The benefits of implementing the Symantec Product Authentication and
Authorization is illustrated by comparing a NetBackup environment with
authentication and authorization and a NetBackup environment without.
In an environment without the Symantec Product Authentication and
Authorization, only the root (UNIX/Linux) or administrator (Windows) account
can manage the NBU servers and clients. NBU management tasks (for example,
policies, storage units, volumes, backup and restore, and reporting) can only be
done by users who are logged in as either root or administrator.
With NetBackup Access Control (NBAC) enabled in a setup, when users (beside
root or administrator) are granted the necessary authorization privileges, they
can do these NBU management tasks based on the granted privileges. For example,
user goku is granted the NBU_Admin authority and the privileges associated with
this role, he has access to all the NBU subsystems when logged in through the
NetBackup Administrative Console (Windows), jnbSA (UNIX/Linux), or through
the command line. User joe is only granted the NBU_Operator authority and
therefore he can only run backup or restore related tasks.
All users must authenticate themselves and login successfully before authorization
privileges can be granted.
The NetBackup product predefines the following authorization groups when
NetBackup Access Control is configured. Each group is authorized to perform
specific management and operational tasks within NetBackup. A login (associated
with a real user) can be assigned to any number of these groups.
NBU_User
NBU_Operator
NBU_Admin
NBU_Security Admin
Vault_Operator
A login (or account on a system) must have the NBU_Security Admin privilege in
order to execute the bpnbaz command to manage (add, delete) the NBU
authorization groups. Typically, the root or administrator login is assigned to this
group when the NBAC is first setup.
The NBU authorization groups are maintained on the system with NBU master
management (neptune.universe.com) and authorization service (also on
neptune.universe.com). On the system (neptune.universe.com) with the NBU
master management server, run the following command. In this case, user goku
is using the NISPLUS plug-in.
-adduser NBU_Admin nisplus:universe.com.:goku \
-M neptune.universe.com \
-adduser NBU_Admin nt:SUN:administrator \
-listgroupmembers NBU_Admin
Type: User
Domain Type: nt
Domain:SUN
Name: ADMINISTRATOR
Type: User
Domain:universe.com.
Name: goku
To find the authentication domain associated with the NISPLUS plug-in, run the
following command.
Broker Port: 2821
To add an ordinary login to the NBU_Security Admin authorization group, run

the following command.
-adduser "NBU_Security Admin" unixpwd:neptune.universe.com:gohan \
-listgroupmembers "NBU_Security Admin"
Type: User
Domain:neptune.universe.com
Name: gohan
Type: User
Domain:neptune.universe.com
Name: root
NetBackup tape device drivers
Type: User
Domain Type: nt
Domain:SUN
Name: ADMINISTRATOR
An ordinary user goku logs onto a system using the NISPLUS authentication
mechanism (at the operating system level) and the system has the NBU master
management server enabled with NBAC. On the system, goku performs a login
and use the NISPLUS authentication plug-in assigned to him. After goku
successfully authenticates himself, he has an NBU session granted to him and is
authorized to perform the administrative tasks. At the operating system level,
goku has neither root nor administrative account privileges.
As user goku, he can logon to NBU through the jnbSA:
goku$ /usr/openv/netbackup/bin/jnbSA -d <display> \

-l /tmp/log.3 -lc &
To execute NBU administrative command from the command line, goku has to
authenticate himself and acquire a valid session first.
goku$ /usr/openv/netbackup/bin/bpnbat -login

Authentication port [0 is default]:
Authentication type (NIS, NISPLUS, WINDOWS, vx, unixpwd): NISPLUS
Domain: universe.com.
Login Name: goku
Password: <goku’s NISPLUS password>
goku$ /usr/openv/netbackup/bin/bpnbat -whoami
NetBackup tape device drivers

On the systems where NetBackup media servers are installed, to use tape libraries
for backup, the driver software for tape devices should be installed. UNIX, Linux
and Windows operating systems use different driver software. The type of driver
software may also depend on the tape library.
To configure the tape devices on UNIX/Linux platforms, refer to the Media
Manager Device Configuration Guide for UNIX for more information.
NetBackup Java Windows administration console
To configure the tape devices on Windows

1 Connect all the tape libraries to the system where the NetBackup master or
media management server is installed.
2 To install NetBackup Tape Device Drivers, invoke the installer Launch.exe
and select the Additional Products, Additional Product Installations, and
NetBackup Tape Device Drivers (32-bit).
3 On the Choosing tape drivers screen, select the Use Veritas tape drivers for
all tape devices and pick the Use Plug and Play drivers.
4 On the Scanning hardware screen, the system should find all the tape devices
that are attached to the system. Based on the types of tape devices that are
attached, appropriate drivers are then installed on the system as depicted on
the Installing Veritas drivers screen.
5 Click Finish and the screen displays with the message – You must restart
your computer before the new settings will take effect. Click Yes to Do you
want to restart your computer now?
6 After the system has been rebooted, verify the tape devices are present on
the system by going through Start, My Computer (right click), Manage, Device
Manager, and Tape drives.
If the operating system is not recognizing the tape devices, you need to
troubleshoot and ensure the right driver is loaded on the system. For the latest
device driver information and version, refer to the Symantec support website at:
http://www.symantec.com/enterprise/support/assistance_care.jsp
These Veritas device drivers do not utilize Microsoft’s digital signature capability.
NetBackup Java Windows administration console

The following procedures are specific to NetBackup administration console on
Windows only.
To install the Java Windows administration console
1 In an Explore window, navigate to the directory that has the NBU installation
files and invoke the Launch.exe file by double-clicking it.
Installation and Install Java Windows Administration Console option.
3 On the License Agreement screen, click the I accept the terms of the license
agreement.
pick the Install to this computer only option.
NetBackup access control troubleshooting tips and messages
installation of the NBU Java Windows Administration Console. The Installing
NetBackup screen displays the progress of the installation.
6 On the System Validation Complete screen, click Finish to exit the installer.
To upgrade the Java Windows administration console
1 Locate the Java maintenance patch distribution. In an Explore window,
navigate to the directory that has the Java installation files and invoke the
setup.exe file by double-clicking it.
2 On the NetBackup Installation Type screen, choose Install to this computer

only and follow the instructions on the screen.
3 On the Ready to Install the Program screen, click Install to start the
installation.
4 On the Installing NetBackup screen, it displays the version of the maintenance
patch and the installation status.
5 On the System Validation Complete screen, click Finish and verify the
installation completed successfully.
6 In the Start, Control Panel, Add or remove programs, verify the Maintenance
Patch has been installed on the system.
NetBackup access control troubleshooting tips and

messages
The following troubleshooting tips may be useful when you set up your NetBackup
product with access control.
Turn off NetBackup access control

Incorrect configurations or changes to the NetBackup Access Control (NBAC)
could cause the authentication to fail and lock out all login sessions. To repair the
NBAC configuration in the NetBackup Server (using either Administrative Console
on Windows or jnbSA JAVA GUI on UNIX/Linux), the NBAC must be disabled first.
To turn off NetBackup access control on UNIX/Linux
1 Edit the /usr/openv/netbackup/bp.conf file.
2 Set the parameter USE_VXSS to the value Prohibited.
NetBackup Access Control can also be disabled by deleting these lines entirely
or by commenting the line of these parameters using the ‘#’ character as the
prefix.
To turn-off NetBackup Access Control on Windows

1 Change the USE_VXSS parameter (using regedit), highlight it, right click and
modify its value to Prohibited.
2 NetBackup Access Control can also be disabled by deleting all of the NetBackup
Access Control parameters. Highlight the parameter, right click, and choose
the operation (Modify or Delete).
This section provides instructions on how to modify USE_VXSS and other NetBackup
Access Control parameters,along with the NetBackup Master Server restart
procedures (UNIX/Linux and Windows) required for the changes to take effect.
There are other situations where disabling NetBackup Access Control may be
needed, such as discontinuing the NetBackup Access Control capability, or if the
authentication and authorization libraries were removed.
Unable to load libraries

■ On a host with NetBackup client, verify that the shared product authentication
(client portion) is installed.
■ On a host with NetBackup Media Server, verify that the shared products
authentication and authorization (client portion) are installed.
■ On a host with NetBackup Master Server, verify that the shared products
authentication and authorization (server portion) are installed and configured.
Optional VxSS libraries not initialized

This message is likely caused by an expired session. A bpnbat –login session is
valid for 24 hours. Attempting to execute NBU commands in an expired session
would show the following message:
EXIT STATUS 116: VxSS authentication failed (status 116)
Try to acquire a new session by issuing the bpnbat –login NetBackup command
on the host that either has master, media or client.
Library Initialization failed. Access denied (188) (MM status 188)

A single jnbSA session is valid for 24 hours. On a jnbSA session that has expired,
this message is displayed. To get a valid session in jnbSA, exit and log back in.
Unable to connect to authorization server

This message indicates that the authentication session the user is logged in has
expired. Perform a bpnbat -login command to acquire a new authentication
session and then retry the bpnbaz -showauthorizers command again.
# /usr/openv/netbackup/bin/bpnbaz -showauthorizers
Unable to connect to authorization server.
Please check your -Server argument and try again.
# /usr/openv/netbackup/bin/admincmd/bpnbaz -showauthorizers
Appendix D
CommandCentral
Storage/Service common
procedures
■ Verifying the CommandCentral Storage server setup
■ Verifying the CommandCentral Service server setup
■ Verifying the CommandCentral agents setup
■ Add and modify access by user accounts
■ Replacing the root broker on the CommandCentral server
■ Troubleshooting tips
Verifying the CommandCentral Storage server setup

These procedures are used to determine the status of the CommandCentral (CC)
Storage management server and the Storage Web console on different platforms.
To verify the CommandCentral storage server setup
1 Determine the status of the CommandCentral server and Web servers.
■ On UNIX/Linux, type the following command:
# /opt/VRTS/bin/vxccstor status
***VERITAS Enterprise Administrator running***
***VERITAS Database Management Server running***
***VERITAS Trap Processor running***
280 CommandCentral Storage/Service common procedures
***VERITAS Alert Manager running***

***VERITAS SAN Access Layer running***
***VERITAS Alarm Service running***
***VERITAS CommandCentral Data Module running***
***VERITAS CommandCentral Importer running***
***VERITAS SICL running***
■ On Windows, click Start > Administrative Tools > Services and verify
that the following services are started:
■ Veritas CommandCentral Storage Alarm Service
■ Veritas CommandCentral Alert Manager
■ Veritas CommandCentral DM explorers
■ Veritas CommandCentral DM Importer
■ Veritas SAN Access Layer (SAL)
■ Veritas CommandCentral Trap Processor
■ Adaptive Server Anywhere
■ Veritas Enterprise Administrator Service
■ Veritas Simple Instrumentation Collection Layer (SICL)
2 Determine the status of the CommandCentral Storage Web servers by entering

the following commands:
# /opt/VRTSweb/bin/monitorApp cc
Web Application "cc" is ONLINE
# /opt/VRTSweb/bin/monitorApp spc
Web Application "spc" is ONLINE
# /opt/VRTSweb/bin/webgui listapps
ROOT
cc
spc
CommandCentral Storage/Service common procedures 281
3 Verify the authentication setup on the CommandCentral Storage management

server. An authentication broker with authentication domains for the
CommandCentral Storage server should be present on the system on which
the storage management server is configured.

# /opt/VRTSat/bin/vssat listpdprinicpals --pdrtype ab \
--domain ccstr_services@cressida.universe.com
Principal Name: ccstr_web
--domain cc_users@cressida.universe.com
4 Connect to the CommandCentral Storage management server through the

Web console. In a browser window, type the following URL to launch the Web
login screen:
https://cressida.universe.com:8443/cc
Enter the user name, password, and authentication domain to log on.
5 Add a new user (not admin) that can access the storage Web console:
See “Add and modify access by user accounts” on page 285.
Verifying the CommandCentral Service server setup

To determine the status of the CommandCentral Service server, use the commands
that apply to your environment.
To verify the CommandCentral Service server setup
1 Determine the status of the CommandCentral Service server, based on your
environment.
# /opt/VRTS/bin/vxccsvc status
***VERITAS Private Branch Exchange running***
***VERITAS Authentication Service running***
***VERITAS Database Management Server running***
***VERITAS Trap Processor running***
***VERITAS Alert Manager running***
***VERITAS CommandCentral Service Active Practices not running***
***VERITAS CommandCentral Service Server not running***
■ On Windows, click Start > Administrative Tools > Services and verify
that the following services are started:
■ Adaptive Server Anywhere (Sybase ASA)
■ Veritas Private Branch Exchange
■ Veritas Authentication Service
■ Veritas CommandCentral Service Automation Server
■ Veritas Web Server
■ Veritas CommandCentral Common Login Service
■ Veritas CommandCentral Storage Web Engine
■ Veritas CommandCentral Service Management Server
■ Veritas CommandCentral Service Agent
■ Veritas CommandCentral Service Metering UI
■ Veritas CommandCentral Metering Collector
■ Veritas CommandCentral Metering Controller
2 Run the following commands to check the status of the CommandCentral

Service Web server:
# /opt/VRTS/bin/vxccsvcweb status
VERITAS CommandCentral Service Server is NOT running.
VERITAS CommandCentral Service Metering UI is NOT running.
# /opt/VRTS/bin/vxccsvcweb start
Starting VERITAS CommandCentral Service Server...
Web Application "ccsvc" started successfully
Starting VERITAS CommandCentral Service Metering UI...
Web Application "ccmm_ui" started successfully
Starting VERITAS CommandCentral Service Meter Controller...
Starting VERITAS CommandCentral Service Meter Collector...
VERITAS CommandCentral Service Server is running.
VERITAS CommandCentral Service Metering UI is running.
3 Verify the authentication setup on the CommandCentral Service management

server. An authentication broker with authentication domains for the
CommandCentral Service server should be present on the system on which
the service management server is configured.

--domain ccsvc_services@cressida.universe.com
Principal Name: ccsvc_invio
Principal Name: ccsvc_agent
Principal Name: ccsvc_ccmm
Principal Name: ccsvc_server
Principal Name: ccsvc_web
--domain cc_users@cressida.universe.com
Principal Name: root
Principal Name: invio_user
Verifying the CommandCentral agents setup
4 Connect to the CommandCentral Service management server through the

Web console. In an IE browser, type the following URL:
https://cressida.universe.com:8443/cc
To launch the Web login screen. Enter the user name, password and
authentication domain to log in.
5 Add a new user (not admin) who can access the service Web console.
See “Add and modify access by user accounts” on page 285.
Verifying the CommandCentral agents setup

To determine the status of the CommandCentral agents setup, use the commands
that apply to your environment.
Add and modify access by user accounts
To verify the CommandCentral agents setup

1 For the CommandCentral Storage management agent on UNIX/Linux, type
the following command:
***VERITAS Enterprise Administrator running***
***VERITAS SAN Access Layer running***
***VERITAS CommandCentral Data Module running***
***VERITAS SICL running***
2 For the CommandCentral Service management agent on UNIX/Linux, type

the following command:
# /opt/VRTS/bin/vxccsvcagent status
***VERITAS CCService Agent is running***
3 On Windows, click Start > Administrative Tools > Services. You can then
check the Status field that corresponds to the CommandCentral agent, to see
if it has started.
Add and modify access by user accounts

Refer to the CommandCentral Storage Administrator’s Guide for information on
adding, modifying, and removing user access.
Replacing the root broker on the CommandCentral

server
In a data center, the CommandCentral server (typically containing both the storage
and the service) is configured on a system with Symantec Product Authentication
that has both root and authentication brokers. The CommandCentral management
server needs an authentication broker. You consolidate the security hierarchy by
replacing the root broker that is located on the system where the CommandCentral
server is configured, with a root broker that is configured on a remote system.
You must first stop the CommandCentral servers before the migration procedures.
The example to replace a root broker assumes the following existing
CommandCentral configuration:
■ The host cressida.universe.com (with Solaris) has CommandCentral server,
Symantec Product Authentication Service root, and authentication brokers
configured. The procedures described here are tested on Solaris and Windows
Replacing the root broker on the CommandCentral server
platforms. You can use the same procedures, by using the equivalent Windows
commands for CommandCentral server on Windows.
■ Replace the root broker on cressida.universe.com with the root broker that
is configured on mercury.universe.com.
■ The CommandCentral server has clients on both UNIX/Linux and Windows
platforms.
To move the root broker on cressida.universe.com to a root broker on remote
system mercury.universe.com, proceed as follows:
To move a root broker
1 On mercury.universe.com, create a principal of type service for the
authentication broker on cressida.universe.com. Type the following
command:
# /opt/VRTSat/bin/vssat addprpl --pdrtype root \

--domain root@mercury.universe.com \
--prplname cressida.universe.com \
--password cressida \
--prpltype service
2 On cressida.universe.com, shut down the CommandCentral Storage and

Service management servers, based on the platform you use.
■ Stop the CommandCentral Storage management server on UNIX/Linux
by typing the following command:
# /opt/VRTS/bin/vxccstorweb stop
# /opt/VRTS/bin/vxccstor stop
■ Stop the CommandCentral Service management server on UNIX/Linux

by typing the following commands:
# /opt/VRTS/bin/vxccsvcweb stop
# /opt/VRTS/bin/vxccsvc stop
■ Stop CommandCentral Storage and Service management servers on

Windows. Perform the following steps:
■ Log on to the storage server host as an administrator, or as a user in
the Administrative group.
■ Click Start > Programs > Administrative Tools > Services to open the
Windows Service Control Manager (SCM).
■ Stop the CommandCentral Storage services in the following order. You

can stop each service by right-clicking the service name, and then click
Stop.
■ Veritas CommandCentral DM Explorers
■ Stop the CommandCentral Service services in the following order. You

can stop each service by right-clicking the service name and then click
Stop.
■ Veritas CommandCentral Service Metering UI
Note: Wait at least 30 seconds after stopping the server before starting it
again. This interval gives the operating system time to free up the logical
ports and other resources that the CommandCentral Storage server may
require when it restarts.
3 On cressida.universe.com, shut down the authentication service, and then

remove all the root PDR entities: principals and credentials. Refer to the
following section for information on shutting down the authentication process
on UNIX/Linux and Windows.
4 Delete each principal in the root private domain by first listing all the
principals in the root private domain, and then deleting them one at a time,
as follows:
--pdrtype root --domain root@cressida.universe.com
# /opt/VRTSat/bin/vssat deleteprpl --pdrtype root \
--domain root@cressida.universe.com \
--prplname <prpl name> --silent
# /opt/VRTSat/bin/vssat showcred \
--domain vx:root@cressida.universe.com
--domain vx:root@cressida.universe.com \
--prplname <prpl name> \
--broker cressida.universe.com:2821
5 On mercury.universe.com, perform a remote copy for the root_hash file to

a directory on cressida.universe.com. Perform the following depending on
your platform:
cressida.universe.com:/tmp/root_hash
■ On Windows, use FTP or another remote copy program to copy the

root_hash to cressida.universe.com.
6 On cressida.universe.com, start Symantec Product Authentication in

authentication broker mode by using the principal, cressida.universe.com,
that was created on mercury.universe.com. Perform the following depending
on your platform:
■ On UNIX/Linux, type the following commands:
# /opt/VRTSat/bin/vxatd -a -n <broker> -p <password> \

-x <domain type> -y <domain name> \
-q <root broker name> -z <root broker port 2821> \
-h <has file full path>
# /opt/VRTSat/bin/vxatd -a -n cressida.universe.com \
-p cressida -x vx -y root@mercury.universe.com \
-q mercury.universe.com -z 2821 -h /tmp/root_hash
■ On Windows, the vxatd.exe command is in the following folder. The same

options that are used on UNIX/Linux can be used on Windows.
7 After the authentication process starts on Windows, the authentication service

needs to be restarted. To restart the authentication service, open the Windows
Service Control Manager (SCM), and then click Start > Programs >
■ For the CommandCentral Storage server, highlight and right-click the
following service, and then click Start:
■ Symantec Product Authentication Service
■ For the CommandCentral Service server, highlight and right-click the

service, and then click Start, in the order that is listed:
■ Private Branch Exchange
8 On cressida.universe.com, verify that the vxatd daemon is running and

the broker mode is 1. At this point, the authentication broker on
cressida.universe.com should be authenticating against the root broker
on mercury.universe.com.
9 Remove the obsolete CommandCentral entities and credentials as follows:
# /opt/VRTSccshd/bin/ccvssatsetup -delete
■ On Windows, type the following command:
ccvssatsetup.exe -delete
10 On cressida.universe.com, set up the new credentials for the

CommandCentral server, as follows:
# /opt/VRTSccshd/bin/ccvssatsetup
ccvssatsetup.exe
11 On cressida.universe.com, restart the CommandCentral processes, as

follows:
■ Start the CommandCentral Storage on UNIX/Linux, type the following
commands:
# /opt/VRTS/bin/vxccstor start
# /opt/VRTS/bin/vxccstorweb start
■ Start the CommandCentral Service on UNIX/Linux, type the following

commands:
# /opt/VRTS/bin/vxccsvc start
■ On Windows, click Start > Programs > Administrative Tools > Services
to open the Windows Service Control Manager (SCM) screen, and start
the following services in the order listed. You start each service by
right-clicking the service name, then clicking Start.
■ Veritas CommandCentral DM explorers
■ Start the CommandCentral Service services in the following order. You

can start each service by right-clicking the service name then clicking
Start.
■ Veritas CommandCentral Metering UI
On each system that has the CommandCentral agent (either Storage or Service),
reauthenticate the CommandCentral agent to replace the obsolete credential with
the new credential.
To reauthenticate hosts with management agents
1 Shut down the CommandCentral management agents on each configured
host.
■ Stop the CommandCentral Storage agent on UNIX/Linux. Type the
following commands:
# /opt/VRTS/bin/vxccstor stop
# /opt/VRTS/bin/vxccsvcagent stop
■ Stop the CommandCentral management agents on Windows by opening

the Windows Service Control Manager. Click Start > Programs >
2 Highlight and right-click the service, and then click Stop to stop the following
services:
■ Veritas CommandCentral Storage Agent

Stop the CommandCentral Service management agent, highlight the following
service, right-click and click Stop.
Note: Wait at least 30 seconds after stopping the server before starting it
again. This interval gives the operating system time to free up logical
ports and other resources that the CommandCentral Storage server may
require when it restarts.
3 On each system that has the CommandCentral management agent (either

storage or service), delete the obsolete credentials that were acquired through
the previous root broker that was replaced.
■ Delete the CommandCentral Storage credential on UNIX/Linux. Type the
following command:
--domain vx:ccstr_services@cressida.universe.com \
--prplname ccstr_web \
--broker cressida.universe.com
■ Delete the CommandCentral Service credential on UNIX/Linux. Type the

following command:
--domain vx:ccsvc_services@cressida.universe.com \
--prplname ccsvc_agent \
--broker cressida.universe.com
4 On each system that contains CommandCentral management agents,

reauthenticate each agent running on the agent host.
■ Reauthenticate the CommandCentral Service management agent on
UNIX/Linux. Type the following command:
# /opt/VRTSccsva/bin/ccsvcagentauth \
-server cressida.universe.com
■ Reauthenticate the CommandCentral Service management agent on

Windows, type the following command:
Troubleshooting tips
C:\Program Files\VERITAS\CommandCentral\Service\Agent\bin> \
ccsvcagentauth -server cressida.universe.com
Use the following procedures to check the status of the CommandCentral Storage
and CommandCentral Service servers, Web servers, or agents, that are deployed
in your environment.
To get to the storage Web console logon screen
1 Check the status of the CommandCentral Storage management server by
typing the following command:
2 Check the status of a CommandCentral Storage Web server by typing the

following commands:
# /opt/VRTSweb/bin/monitorApp cc
Web Application "cc" is ONLINE
Web Application "spc" is OFFLINE
3 Start the spc Web application by typing the following command:
# /opt/VRTSweb/bin/startApp spc /opt/VRTSweb/VERITAS

Web Application "spc" started successfully
Web Application "spc" is ONLINE
# /opt/VRTSweb/bin/webgui listapps
ROOT
cc
spc
4 Start the OFFLINE cc Web application by typing the following command:
# /opt/VRTSweb/bin/startApp cc /opt/VRTSweb/VERITAS
To get to the service Web console logon screen

1 Check the status of a CommandCentral Service server by typing the following
command:
# /opt/VRTS/bin/vxccsvc status
2 Check the status of a CommandCentral Service Web server by typing the

following command:
VERITAS CommandCentral Service Server is NOT running.
VERITAS CommandCentral Service Metering UI is NOT running.
Starting VERITAS CommandCentral Service Server...
Web Application "ccsvc" started successfully
Starting VERITAS CommandCentral Service Metering UI...
Web Application "ccmm_ui" started successfully
Starting VERITAS CommandCentral Service Meter Controller...
Starting VERITAS CommandCentral Service Meter Collector...
VERITAS CommandCentral Service Server is running.
VERITAS CommandCentral Service Metering UI is running.
Appendix E
Symantec License Inventory
Manager common
procedures
■ Verifying the SLIM server setup
■ Verifying the SLIM agent setup
■ Replacing the root broker on the SLIM server
■ SLIM troubleshooting tips
Verifying the SLIM server setup

The Symantec License Inventory Manager (SLIM) server monitors Symantec
product license information for products such as NetBackup, CommandCentral,
and Storage Foundation. The SLIM server requires SLIM agents to be installed on
client hosts. The SLIM agents detect the Symantec products that are installed on
the client hosts, and report the license information to the SLIM server.
296 Symantec License Inventory Manager common procedures
Verifying the SLIM server setup
To verify the SLIM server on Solaris and Windows

1 To verify the Symantec License Inventory Manager on Solaris, type the
following command:
# /opt/VRTSweb/bin/monitorApp slim
Web application for SLIM is ONLINE
2 To verify the SLIM server on Windows, click Start > Control Panel >
Administrative Tools > Service then verify that the following services are
running:
■ Symantec Private Branch Exchange Service
■ Symantec Service Management Framework Service
■ Veritas Web Service
■ Symantec License Inventory Manager Service
■ Adaptive Server Anywhere - VERITAS_DBMS3_<MachineName> service
3 Close the Service window after you verify that the processes are running.
4 Verify the status of the SLIM server. Type the following command:
C:\Program Files\VERITAS\VRTSweb\bin> monitorApp slim

Web application for SLIM is ONLINE
Verification procedures for Windows and UNIX

The Symantec License Inventory Manager server creates and configures its own
domain by creating two separate private domain repositories (PDR), which are
located within the authentication broker PDR. The two private domain repositories
are referred to, as follows:
■ Domain Name slim_services@belinda.universe.com - authenticates Web
services
■ Domain Name slim_users@belinda.universe.com - authenticates users
You can use the following commands to verify the SLIM server domain by
expanding the content of these two PDRs:
# /opt/VRTSat/bin/vssat listpdprincipals --pdrtype ab --domain

slim_services@belinda.universe.com
Symantec License Inventory Manager common procedures 297
Verifying the SLIM agent setup
# /opt/VRTSat/bin/vssat listpdprincipals --pdrtype ab --domain

slim_users@belinda.universe.com
To connect to the SLIM Web console

1 Connect to the Symantec License Inventory Manager Web service at the
following URL:
https://belinda.universe.com:8443/slim
2 Use admin/password to log on to the domain,

slim_users@belinda.universe.com.
3 Perform a host discovery from the SLIM Web service. From the Web console,
click Host Management > Discovery > Force Pull.
4 Type one or more comma-delimited client names in the dialog box, then click
Force Poll.
The Force Poll Queue displays.
5 Locate the host name you added, then verify that its status is Inventory
Initiated Successfully. If not, select the checkbox next to the host name, then
click Force Poll Queue.

Use the following procedures to configure and verify the Symantec License
Inventory Manager agent setup.
To configure the SLIM agent
◆ During the client installation process, enter the following information:
■ Enter the Access Point/Server hostname: belinda.universe.com
■ Do you want to enable security? [y, n] (n) y
■ Do you want configure security at this time? [y, n] (y)
■ Enter the authentication broker hostname (neptune.universe.com) \
belinda.universe.com
■ Enter the TCP/IP port number for the authentication broker,

belinda.universe.com: ( 2821)
■ Enter the certificate hash code for the authentication broker

belinda.universe.com (9efb1d042f646656602f55be4016a8bf1a1d03b4)
■ Enter the Access Point/Server user name: (slim_agent)

■ Enter the Access Point/Server user Domain name:

(slim_services@belinda.universe.com)
■ Enter the Access Point/Server user domain type: (vx)
■ Do you want to start the Symantec License Inventory Agent processes
now? [y, n] (y)
There are two verification processes you can use depending on which SLIM agent
package (SYMClma) you have installed, version 4.0 or version 4.1. In the following
procedure, select the step that corresponds to your installed version.
To verify the SLIM agent
1 For 4.0, type the following command:
# /opt/SYMClma/bin/lmautil -S
[Info] V-149-1-24528 Starting to Get Trusted User List. \
Contacting Agent.
[Info] V-149-1-24537 Name: root
[Info] V-149-1-24538 Domain Name: miranda.universe.com
[Info] V-149-1-24539 Domain Type: localhost
[Info] V-149-1-24541
[Info] V-149-1-24537 Name: slim_agent
[Info] V-149-1-24538 Domain Name: \
[Info] V-149-1-24539 Domain Type: vx
[Info] V-149-1-24541
[Info] V-149-1-24531 Completed Administrative command.
2 For 4.1, type the following command:
# /opt/SYMClma/bin/lmautil -C
[Info] V-149-1-24541
[Info] V-149-1-24549 AZLiteBootStrapComplete: 1
[Info] V-149-1-24549 SecurityEnabled: 1
[Info] V-149-1-24549 SecurityConfigComplete: 1
[Info] V-149-1-24549 SecurityConfigured: 1
[Info] V-149-1-24549 RootBrokerHostname: neptune.universe.com
[Info] V-149-1-24549 RootBrokerHash:
[Info] V-149-1-24549 CollectorNodeUsername: slim_agent
[Info] V-149-1-24549 RootBrokerHostPortNumber: 2821
[Info] V-149-1-24549 CollectorNodeUserDomainType: vx
[Info] V-149-1-24549 CosNsServerName: localhost
[Info] V-149-1-24549 CollectorNodeUserDomain: \
[Info] V-149-1-24541
3 Log on to the SLIM server Web service GUI to verify the SLIM agent for the
agent report on licences installed on the host.
See “To connect to the SLIM Web console” on page 297.
4 The SLIM agent is included with the Storage Foundation 5.0 release, so the
package is installed on the client host, but not configured. To ensure that the
SYMClma is installed, type the appropriate operating system command (for
AIX, HP-UX, Linux, Solaris, or Windows, respectively) as follows:
# lslpp -l | grep SYMClma

# swlist -l product SYMClma
# rpm -qa | grep SYMClma
# pkginfo -l | grep SYMClma
Start > Control Panel > Add or remove Programs
Replacing the root broker on the SLIM server
5 If the SLIM agent is installed but not configured, use the vssat and lmautil
commands to configure the SLIM agent to the SLIM server. These commands
include long strings, as shown below. Type the following command to obtain
the root hash key from the remote root broker host (neptune.universe.com):
9efb1d042f646656602f55be4016a8bf1a1d03b4
6 From the SLIM agent client host (miranda.universe.com), type the following
command:
# /opt/SYMClma/bin/lmautil --Config --SecurityEnabled 1 \

--RootBrokerHostname neptune.universe.com \
--CollectorNodeUsername slim_agent \
--CollectorNodeUserDomainType vx \
--CollectorNodeUserDomain slim_services@belinda.universe.com \
--RootBrokerhash 9efb1d042f646656602f55be4016a8bf1a1d03b4 \
--RootBrokerHostPortNumber 2821

When installing the Symantec License Inventory Manager, Symantec Product
Authentication is automatically installed by the SLIM installer. The installer also
configures the Symantec Product Authentication with a root and an authentication
brokers. The SLIM management server only needs an authentication broker to
authenticate users who access the SLIM Web console.
You may have to consolidate root brokers. This may occur when you want to
demote a root broker on a SLIM server to an authentication broker. Before
executing the migration procedures, stop the SLIM management server and the
SLIM entities running on systems that have access points.
For this example, assume a host uses a Solaris system (belinda.universe.com)
as the SLIM management server. Also assume that Symantec Product
Authentication is configured in root broker and authentication broker modes.
The following procedures were verified on a Solaris platform. You can use the
same procedures with a SLIM management server on Windows, by using the
equivalent Windows commands.
Demoting a root broker

The following procedure shows how to demote the root broker on
belinda.universe.com to become a new authentication broker, while a new root
broker is configured on a Solaris system, neptune.universe.com. The SLIM
management server has clients on UNIX/Linux and Windows platforms.
To demote a root broker
1 Create a (service) principal on neptune.universe.com for the existing
authentication broker on belinda.universe.com. Type the following
command:
# /opt/VRTSat/bin/vssat addprpl --pdrtype root \

--domain root \
--prplname belinda.universe.com \
--password belinda \
--prpltype service
2 On neptune.universe.com, perform a remote copy of the root_hash file to

a directory on belinda.universe.com. Type the following command:
belinda.universe.com:/tmp/root_hash
3 Shut down the processes on belinda.universe.com for the SLIM management

server and all the auxiliary products. Shut down the UNIX/Linux processes
of the auxiliary products in the following order:
# /etc/rc2.d/S75vxsmfd stop
# /etc/rc2.d/S45vxpbx_exchanged stop
# /etc/rc2.d/S38vxdbms3 stop
4 If the system has Symantec Product Authorization configured, stop the

authorization process. Type the following command:
# /etc/rc2.d/S71vxazd stop
■ On Solaris, these scripts are located in the /etc/rc2.d directory.

■ On HP-UX, these scripts are located in the /sbin/rc2.d directory.
■ On AIX, these scripts are located in the /etc/rc.d/rc2.d directory.
■ On Red Hat, these scripts are located in the etc/rc.d/rc2.d directory.
5 Shut down Windows processes by clicking either Start > Administrative

Tools > Services, or by using the command c:\> net stop vrtsat.
6 Shut down the SLIM Web server process on belinda.universe.com.
# /opt/VRTSweb/bin/stopApp slim
c:\Program Files\VERITAS\VRTSweb\bin>stopApp slim
7 Remove all the entities from belinda.universe.com related to the root broker.
■ On UNIX/Linux, type the following commands:
# /opt/VRTSat/bin/vssat deletecred --domain \

vx:broker@belinda.universe.com --prplname admin

vx:slim_users@belinda.universe.com --prplname admin

vx:slim_services@belinda.universe.com --prplname slim_agent

vx:root@belinda.universe.com --prplname root

vx:root@belinda.universe.com --prplname broker
# /opt/VRTSat/bin/vssat removetrust --broker belinda.universe.com
On Windows, change to the directory that contains the vssat.exe file. Type
the five commands that are listed for UNIX/Linux above by using the following
as an example:
■ C:\Program Files\VERITAS\Security\Authentication\bin>vssat.exe \
deletecred --domain vx:broker@belinda.universe.com \
--prplname admin
8 On belinda.universe.com, establish the Symantec Product Authentication

Service in authentication broker mode. The new root broker is on
neptune.universe.com.
■ On UNIX/Linux, use the vxatd command to start Symantec Product

Authentication in authentication broker mode. The syntax is as follows:
/opt/VRTSat/bin/vxatd \
-a -n %ABIDENTITY% \
-p %ABPASSWORD% \
-x vx -y %DOMAINNAME% \
-q %ROOTBROKER% \
-z %ATPORT%
-h %ROOTHASH%
Type the command as follows:
# /opt/VRTSat/bin/vxatd \
-a -n belinda.universe.com
-p belinda \
-x vx -y root@neptune.universe.com \
-q neptune.universe.com \
-z 2821 \
-h /tmp/root_hash
Name belinda.universe.com
DomainType vx
DomainName root@neptune.universe.com
BrokerName neptune.universe.com
BrokerPort 2821
Hash file /tmp/root_hash
■ On Windows, change to the directory containing the vssat.exe file. Type

the commands listed for UNIX/Linux above.
9 On belinda.universe.com, verify that the vxatd authentication process is

running, and that the attributes (broker mode, root broker, and domain name)
are updated.
■ On UNIX/Linux, these affected attributes are in the configuration file
/var/VRTSat/.VRTSat/profile/VRTSatlocal.conf.
# grep Mode /var/VRTSat/.VRTSat/profile/VRTSatlocal.conf

"Mode"=dword:00000001
# grep BrokerName /var/VRTSat/.VRTSat/profile/VRTSatlocal.conf

"BrokerName"="neptune.universe.com"
# grep DomainName /var/VRTSat/.VRTSat/profile/VRTSatlocal.conf

"DomainName"="root@neptune.universe.com"
■ On Windows, these attributes are in the VRTSatlocal.conf file located

in the following directory:
C:\Program Files\VERITAS\Security\Authentication\Systemprofile
10 On belinda.universe.com, reconfigure the SLIM server to point to the new

root broker.
■ On UNIX/Linux, run the following SLIM configuration script:
# /bin/sh /opt/SYMClms/bin/configure
If the following message is displayed, you can safely ignore it:

On Windows, invoke the same configuration script as shown for
UNIX/Linux. Type the following command:
C:\Program Files\Symantec\ \
License Inventory Manager\Server\bin>configure.bat
■ CORBA Exception from TAO is detected
11 On belinda.universe.com, verify that all the processes are running.

■ On UNIX/Linux, type the following commands to ensure that the processes
are running on belinda.universe.com:
# ps -ef | grep vxatd

# ps -ef | grep pbx_exchange
# ps -ef | grep vxsmf
# ps -ef | grep vxdbms
# vssat listpd -pdrtype ab
Broker mode is : 1
■ On Windows, click Administrative Tools > Services to verify that these

services are running. You can also type the following at a command prompt
window:
C:\Program Files\VERITAS\Security \
\Authentication\bin>vssat.exe showbrokermode
Broker mode is : 1
Broker mode 1 means that Symantec Product Authentication is configured

in authentication broker mode.
12 To log on to the SLIM Web service, type the following URL in a browser:
https://belinda.universe.com:8443/slim
Type the following at the prompts:
User name: admin

Password:
Domain: slim_users@belinda.universe.com (vx)
The user name admin is the default user name that was created for SLIM.
You can use other names that were created in your enterprise.
13 Perform the authentication procedure again on all the other systems that
have either a SLIM Access Point or Agent installed. This procedure allows
these SLIM entities to communicate with the SLIM Server that now belongs
to a new authentication hierarchy.
On the remote root broker, neptune.universe.com, type the following
command to obtain the root hash value:
9efb1d042f646656602f55be4016a8bf1a1d03b4
The 4.0 version of SYMClma does not have the option to reconfigure the agent
back to the SLIM server for reauthentication by using the SLIM utility.
There are two verification processes you can use depending on which SLIM
agent package (SYMClma) you have installed, version 4.0 or version 4.1.In
the following procedure, select the step that corresponds to your installed
version.
14 Select one of the following items:
■ For SYMClma 4.0, on the system miranda.universe.com, which has the
SLIM agent installed, invoke the SLIM utility to communicate with the
SLIM server that has the new authentication hierarchy. On UNIX/Linux,
type the following command:
# /opt/SYMClma/bin/lmautil \
--trust --brokerhost belinda.universe.com \
--brokerport 2821 --hash \
9efb1d042f646656602f55be4016a8bf1a1d03b4
[Info] V-149-1-24506 Setting Trust - security level HIGH.
[Info] V-149-1-24509 Trust setup with broker successful.
■ For SYMClma 4.1, on the system miranda.universe.com, which has the

SLIM agent installed, invoke the lmautil SLIM utility to communicate
SLIM troubleshooting tips
with the SLIM server that has the new authentication hierarchy. On
UNIX/Linux, type the following command:
# /opt/SYMClma/bin/lmautil --Config \
--SecurityEnabled 1 \
--RootBrokerHostname neptune.universe.com \
--CollectorNodeUserDomainType vx \
--CollectorNodeUserDomain slim_services@belinda.universe.com \
--RootBrokerhash 9efb1d042f646656602f55be4016a8bf1a1d03b4 \
--RootBrokerHostPortNumber 2821
Perform this procedure on each system that has either SLIM Access Point or
Agent installed, as the SLIM server now belongs to the new authentication
hierarchy. You can also use the Force Pull Queue option to obtain SLIM agent
reporting updates.
15 On the SLIM Web console, log on as administrator to perform a discovery of
all the SLIM agents. Click Host Management > Discovery > Force Pull. For
example, choose miranda.universe.com, which contains the SLIM agent,
and perform a Force Pull.

The information on troubleshooting is organized by specific conditions. Review
the following list of common troubleshooting issues before proceeding to more
specific tips:
■ Verify that the server package, SYMClms, is installed.
■ Verify that the Windows silent installation file, Symantec License Inventory
Manager.msi, is installed.
■ Use the VRTSweb Web GUI commands to verify that the SLIM application is
installed, and then verify the process by using the script that is located in
/etc/init.d, or by using the service control manager.
■ Use the VRTSdbms tools to ping the database (for example, dbping).
■ Examine the log files.
Log files
The Veritas Web log directory location is %VRTSweb_Home%\log. This directory
contains the following major logs:
■ slim0.0.log - for general debugging information
■ _err0.0.log - for stack traces and major errors

The other log files in this directory are used for debugging the Java virtual
machine or the Web server. Either of these log files becomes a new file when
it reaches capacity. The naming convention for these files are as follows:
■ slim0.n.log - for general debugging information
■ _err0.n.log - for stack traces and major errors
The default log level is INFO. This logs high-level functions and any errors and
warnings.
Product directory structure

There are few directories within the actual SLIM server. The important files are
located in the /VRTSweb and /VRTSdbms directories. Database and log files are
located in the following Solaris and Windows directories.
Solaris
■ /opt/SYMClms/bin/redist for data (database, transaction log file)
■ /var/VRTSweb/log for Web server log files
Windows
■ c:\program files\Symantec\License Inventory Manager\Server\bin for
data files (such as database or transaction log files)
■ c:\Program Files\VERITAS\VRTSweb\log for Web server log files
Java runtime environment debugging

The Java runtime environment, VRTSjre, is located in the following Solaris and
Windows directories:
■ /opt/VRTSjre on Solaris
■ c:\program files\Common Files\VERITAS Shared\VRTSjre on Windows
Run the command java -version from within that directory to show the current
Sun Java Virtual Machine version.
Troubleshooting steps for Sybase ASA

Table E-1 lists Sybase ASA binaries for UNIX/Linux.
Table E-1 Sybase ASA binaries for UNIX/Linux
Binaries Binaries locations
Default locations binaries are located in /opt/VRTSdbms3; database is located in

/opt/SYMClms/bin/redist/vxvlim.db.
Log files located in syslog and in $INSTALLDIR/log/*.log
Configuration location in:
/etc/vxdbms/VERITAS_DBMS3_HOSTNAME/conf /server.conf
Do not edit without engineering; use -x to set the database port and
use -s none to prevent syslog activity.
Utilities Use $INSTALLDIR/bin/dbping from source $INSTALLDIR/*env*

first. Use dblocate to identify the servers running on the local
network.
Table E-2 lists Sybase ASA binaries for Windows.
Table E-2 Sybase ASA binaries for Windows
Binaries Binaries locations
Default locations binaries are located in c:\Program Files\VERITAS\DBMS3;

database is located in c:\Program Files\Symantec\License
Inventory Manager\Server\bin
Configuration c:\Program Files\VERITAS\DBMS3\conf\server.conf and

c:\Program Files\VERITAS\DBMS3\conf\databases.conf
Utilities c:\Program Files\VERITAS\DBMS3\win32\dbping.exe and

c:\Program Files\VERITAS\DBMS3\win32\dblocate.exe
Troubleshooting steps for Tomcat (VRTSweb)

This application uses a servlet container (Tomcat).
The default Tomcat server locations are as follows:
■ On Solaris: /opt/VRTSweb.
■ Default location on Windows: c:\program files\VERITAS\VRTSweb
■ Log files on Solaris: /var/VRTSweb/log(various files)_err, slim, and
_vrtsweb.
■ Log files on Windows: c:\program files\VERITAS\VRTSweb\log(VRTSweb

logs and our logs).
■ Configuration: $INSTALLDIR/conf/vrtsweb.xml and

$INSTALLDIR/tomcat/conf/web.xml (do not modify).
■ Utilities: webgui debug [on|off] – You must restart the Web server. It sends
its output to $INSTALLDIR/tomcat/_profile.log, webgui listports, webgui
listapps, webgui smtp getserver (lists all configured SMTP servers), webgui
stop force (stops the server), and webgui restart (this should restart all of
the Web applications that were running prior to the webgui stop command).
Set the debugging level of the Tomcat server

Set the debugging level of the Tomcat server, configured under Tomcat/VRTSweb,
as follows:
1 Click Settings > System Settings > Web Console Configuration > Configure
Logging.
2 Set the default level to INFO.
3 Type the root or admin password of the user running the SLIM server.
4 Perform a Web restart to erase this setting and to reset the default level to
INFO.
Debug the access point

The agent dynamically loads the following modules:
■ Default location on Solaris: /opt/SYMClmm
■ Default location on Windows: c:\program files\Symantec\License
Inventory Manager\Access Point
■ Log files on Solaris: $AGENTDIR/logs

■ Log files on Windows: +---bin, +---conf, +---lib, and +---logs
■ Configuration file: $AGENTDIR/conf/agent.conf
■ Utilities: Set the logging level to fine, restart, and watch log files. Verify
connectivity to the server over the CORBA port, and the Last Contact time in
the agent configuration screen of the Web user interface.
Debug the push installation

A push installation works with homogeneous push-only; for example, Solaris to
Solaris, or Windows to Windows. The underlying mechanism on UNIX is
rhosts/ssh, and on Windows is VPI (msiexec service). Logs are located in the
following directories:
■ /var/tmp/install-lim1102143201/install-lim.log
■ C:\Documents and Settings\All Users\Application

Data\VERITAS\VPI\log
■ CONFIG/FINE/FINER/FINEST logs many more details and should only be used

when investigating a problem
You can set the log levels for SLIM logs in the following locations:
■ WEB.XML (requires a server restart)
■ VRTSweb configuration in the Web UI
Troubleshooting steps for Service Management Framework

Use the vxlogview utility to view the Service Management Framework (SMF) log
files as follows:
■ Symantec Product Authentication: /var/VRTSat/log/vxatd.log
■ Symantec Management Foundation:
$ vxservice --list -r RootSMF -p ICS vxservice
On Windows use:
c:\Program Files\VERITAS\VxSMF\bin\smfservice.cmd -list \

-r RootSMF -p ICS vxservice
A list of processes similar to the following will be displayed:
Process Name : ICS

Service Name : CosNotfSrvcInit
Service Name : CosNotify_Service
Service Name : Topology_Factory
Service Name : Event_Persistence
Service Name : CosNotfSrvc
Service Name : lma
Note: Service name lma would only appear if the SLIM agent was installed.
■ Private Branch Exchange: /opt/VRTSicsco/bin/vxlogview -a -t 00:10:00

displays log messages for all products generated in the last 10 minutes
■ /opt/VRTSicsco/bin/vxlogview --prodid 50936 --tail 01:10:00 displays
log messages for SMF and PBX generated in the last hour and 10 minutes
■ On Windows: c:\Program Files\Common

Files\VERITAS\VRTSicsco\vxlogview
Error: Failed to get database connection

The database is down or the Web Server started before the database. Start the
database if it is down, then restart the Web server.
Error: Authentication manager was not initialized

The authentication server is down, or the Web Server started before authorization.
Start authorization server if it is down, then login to the Application.
Error: Agent not running

Notification Service is down. Start SMF. Wait for three minutes for the Server to
reconnect to Cos Notification Service.
Error: Access point fails to start

SMF on AP not running. Start SMF, and then restart AP through the script or
Windows service control manager.
Error: Access point fails connect to server

The access point heartbeat is not updating. Make sure that the Server is up and
running. Confirm that the slim_agent credential on the Access Point machine is
authenticated against the Server Machine by executing vssat showcred to get a
list of credentials, and verifying that the slim_agent credential exists.
If slim_agent credential does not exist on the Access Point host, create it with the
following command:
# /opt/VRTSat/bin/vssat authenticate \
-domain vx:slim_services@SERVER_HOSTNAME \
-prplname slim_agent \
-password slim_agent_password \
-broker SERVER_HOSTNAME:2821
Error: Retries Exceeded. Could not connect to HOST_NAME:RootSMF

Agent-Server Communication is failing. From the server machine, use telnet to
connect the agent on port 1556.
$ telnet AGENT_HOST 1556
If telnet is not successful, there could be a firewall issue.
Error: SLIM Web Console does not display on VRTSweb console

Symantec License Inventory Manager Web App is not running. Restart the SLIM
Web app. On Windows enter the following information:
c:\Program Files\VERITAS\VRTSweb\bin\startApp.exe slim
On Solaris, type the following command:
# /opt/VRTSweb/bin/startApp slim
Embedded access point is down

The Force Poll does not work for any agent. PBX is not running. Start PBX, and
then restart the SLIM Server/AP.
Agent-server communication failure

The force poll status displays the following message:
Retries Exceeded. Could not connect to HOST_NAME:1556:lmaApp_secsvc
To debug the server

1 Type the following command to ensure that the Agent is running: :
# /opt/VRTSsmf/bin/vxservice -L
Make sure that lma is listed as a service.

2 Initiate an inventory through the CLI. Type:
# /opt/SYMClma/bin/lmautil -I
3 If steps 1 and 2 are successful, check the broker hash of the server on the
agent. Type:
4 Compare the hash with the one on the server; run the same command on the
server.
Server time-out during a force poll queue

1 Make sure Agent is running. Type:
# /opt/VRTSsmf/bi/vxservice -L
Verify that lma is listed as a service.

2 Initiate an inventory through the CLI. Type the following command:
# /opt/SYMClma/bin/lmautil -I
If the previous commands were successful, increase the timeout settings on

the server.
3 Use the following tasks to increase the timeout settings on the server:
■ Stop the Web application. Type the following command
# /opt/VRTSweb/webgui/stop
■ If slim_conf.properties does not exist under /opt/VRTSweb/conf, copy

/opt/VRTSweb/VERITAS/slim/slim_conf.properties.default to
/opt/VRTSweb/conf/slim_conf.properties.
■ Uncomment the line vxlicagent.connection.timeout and set the value

to a higher number. For example, change the default value of 60 to 600.
■ Restart the Web server. Type the following command:
# /opt/VRTSweb/bin/webgui restart
Index
A B
access control information data repository benefits
definition 39 of using Symantec Product Authentication and
acronyms Authorization 23
list of 18 broker architecture
application client in a generic enterprise security deployment
definition 32 scenario 55
application server
generic enterprise security deployment C
scenario 54
chief security officers
application service
what to read 14
definition 32
CommandCentral
approach
integration 47
multiproduct deployment 51
plug-ins 48
architecture
component details
Authorization 37
Symantec Product Authentication and
audience 14
Authorization 29
authentication
components
components 44
authentication 44
module functionality 43
authorization 38
overview 22, 43
Symantec Product Authentication and
authentication broker
Authorization 27, 48
details 30
Symantec Product Authentication Service 44
authentication client
details 32
authentication hierarchy D
definition 28 definitions
authentication module acronyms used in this book 18
components 33 authorization principal 41
description 33 terms used in this book 22
Authorization detail
architecture 37 authentication broker 30
authorization authentication client 32
module functionality 43
overview 22, 43 E
steps 42 expiry periods 36
authorization principal
definition 41
authorization service F
definition 39 functionality
authentication module 43
authorization module 43
316 Index
I plug-ins (continued)
integration supported by Veritas Storage Foundation 47
CommandCentral with common service product integration
framework products 47 enterprise 46
NetBackup Operations Manager with common product scope 15
service framework products 46
NetBackup with common core services R
products 46 resource management application
Symantec License Inventory Manager with definition 40
common core services products 48 root broker
Veritas Storage Foundation with common core definition 29
services products 47
S
L scope
local authorization service current edition 16
definition 40 future editions 17
scope of product 15
M security administrators
management agent and client what to read 14
generic enterprise security deployment Symantec License Inventory Manager
scenario 55 integration 48
management server plug-in support 48
generic enterprise security deployment Symantec Product Authentication and Authorization
scenario 54 architecture 27
master authorization service component details 29
definition 40 components 27
modules Symantec Product Authorization Service
Symantec Product Authentication and about 48
Authorization 43 Symantec products
multiproduct deployment current edition 17
approach 51 future editions 17
systems programmers
what to read 14
N
NetBackup
integration 46 T
supported plug-ins 46 terms and definitions 22
NetBackup Operations Manager topics
integration 46 overview of 13
supported plug-ins 47
U
P user benefits
plug-ins from book 14
supported by CommandCentral 48
supported by NetBackup 46 V
supported by NetBackup Operations Manager 47 validity period
supported by Symantec License Inventory certificate 36
Manager 48
Index 317
Veritas Storage Foundation

integration 47
plug-ins
UNIX/Linux 47
Windows 47

VXSS Yello Page

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VXSS Yello Page

Uploaded by

Copyright:

Available Formats

Symantec Product

The roles of Symantec Product Authentication

Documentation version 1.0

All rights reserved.

Hai Sheng Kang

Chapter 2 Overview of the Symantec Product Authentication

Chapter 3 Overview of the Symantec Product Authorization

Authorization client ............................................................... 39

Chapter 4 How authentication and authorization are used

Chapter 5 Deployment guidelines and best practices

Authentication administrator responsibilities .............................. 69

Chapter 6 Symantec solution: UNIX/Linux use cases

Storage Foundation use case ......................................................... 143

Chapter 7 Symantec solution: Windows use cases

Deployment platforms and operating systems ............................ 206

Appendix A Storage Foundation common procedures

Appendix B Infrastructure Core Services common procedures

Appendix C NetBackup common procedures

Shared Veritas products and processes ..................................... 254

Appendix D CommandCentral Storage/Service common

Appendix E Symantec License Inventory Manager common

Log files .............................................................................. 306

■ About this Yellow Book

■ Who should use this Yellow Book

■ Scope of this document

■ About acronyms and definitions

■ About authentication and authorization

About this Yellow Book

Difference between product guides and this Yellow Book

How this Yellow Book helps users

Who should use this Yellow Book

Table 1-1 Applicable sections to read

Role What to read

Chapter 2 provides an overview of authentication.

Chapter 3 provides an overview of authorization.

Chapter 5 describes approaches that give security and application administrators an

Chapter 6 provides UNIX and Linux user cases.

Chapter 7 provides Windows use cases.

Scope of this document

Symantec products covered in this Yellow Book edition

Table 1-2 Symantec products addressed in this edition

Common core services Management server Application server Management agent/client

Authentication NBU SFCFS CC Storage & CC Service

CC Storage & CC Service SF Oracle RAC SLIM

SLIM SFWHA NBU

See “About acronyms and definitions” on page 18.

About future editions of this Yellow Book

Table 1-3 Symantec products to be addressed in future editions

Common core services Management server Application server Management agent/client

Authentication NBU (6.5, 6.0MP5, SFCFS CC Storage & CC Service

Authorization NBU (6.5, 6.0MP5, CC Storage

See “About acronyms and definitions” on page 18.

Topics to be covered in future editions

About acronyms and definitions

Table 1-4 Acronym list

AT Symantec Product Authentication Service (also referred to as "authentication service")

AZ Symantec Product Authorization Service (also referred to as "authorization service")

DSU Disk Storage Unit

GSSAPI Generic Security Service Application Program Interface

LDAP Lightweight Directory Access Protocol

MP Maintenance Pack (a Veritas product patch release)

NBAC NetBackup Access Control (VxSS integration with NBU)

NBU NetBackup - NBU and NetBackup are synonymous in this document