Authentication and
Authorization
Securely deploy Symantec products using the
appropriate deployment configuration for your
enterprise environment
Legal Notice
Copyright © 2007 Symantec Corporation.
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
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
Index
12 Contents
Chapter 1
Introduction
This chapter includes the following topics:
■ Customer benefits
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.
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 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.
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.
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
NOM VCS
Authorization NBU
VAD
SFMS
VBR
CC Storage
Acronym Definition
CSF Common Service Framework (the distribution name for these products is ICS)
FQHN Fully Qualified Host Name (synonymous with FQDN—Fully Qualified Domain Name); for example,
jupiter.universe.com
ICS Infrastructure Core Services (distribution name for AT, AZ, PBX, and SMF)
Acronym Definition
PDR The root private domain repository stores information about all registered authentication brokers
(used only by the root broker)
SF UNIX/Linux Veritas Storage Foundation products, including VxVM, VxFS, and VVR
SF Oracle RAC Veritas Storage Foundation for Oracle RAC (Real Application Cluster)
SSL Secure Socket Layer protocol (each encrypted transaction generates a session key which is 128
bits)
Acronym Definition
VxSS Veritas Security Services (synonymous with authentication service plus authorization service
Table 1-5 is an alphabetical list of each special term used in this Yellow Book
followed by its definition.
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.
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.
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.
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.
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.
logon The procedure used to gain access to an operating system or Web console of an
application.
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.
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.
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
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.
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:
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
■ Authentication hierarchy
■ Authentication components
■ Authentication expiry
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.
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
Authentication components
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.
30 Overview of the Symantec Product Authentication Service
Authentication components
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.
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.
32 Overview of the Symantec Product Authentication Service
Authentication components
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.
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).
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
34 Overview of the Symantec Product Authentication Service
How the authentication process works
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.
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.
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.
■ 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.
■ Introduction
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
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.
6.0MP4
6.0MP4
4.1MP1
5.0
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.
48 How authentication and authorization are used across Symantec products
Using the authorization service for access control
4.2FP1
4.3
4.2FP1
4.0.4
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.
See “NetBackup and authorization” on page 270.
■ Authorization
Refer to the use case chapters to find out which specific version of this product
has been tested.
50 How authentication and authorization are used across Symantec products
Using the authorization service for access control
Chapter 5
Deployment guidelines and
best practices
This chapter includes the following topics:
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
Deployment guidelines and best practices 55
Broker architecture determination
server installed. For convenience, NOM may be installed and configured on the
same system as the NetBackup master management server.
See Figure 5-1 on page 53.
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.
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.
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
62 Deployment guidelines and best practices
Broker architecture determination
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.
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
Deployment guidelines and best practices 63
Broker architecture determination
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.
See Figure 5-2 on page 57.
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.
See Figure 5-5 on page 62.
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.
See Figure 5-2 on page 57.
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.
64 Deployment guidelines and best practices
Broker architecture determination
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.
In the following figure, the SLIM management server is on UNIX (Solaris), and
the CommandCentral management server is on Windows.
See Figure 5-5 on page 62.
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.
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
66 Deployment guidelines and best practices
Planning for authentication and authorization in your enterprise environment
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.
See Figure 5-1 on page 53.
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.
68 Deployment guidelines and best practices
Planning for authentication and authorization in your enterprise environment
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 “Authentication plug-ins and mechanisms” on page 30.
See “Assimilating authentication service into your enterprise” on page 46.
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.
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.
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.
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.
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).
■ 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.
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.
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
Deployment guidelines and best practices 79
Empirical use cases
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.
See Figure 5-1 on page 53.
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.
the UNIX/Linux use cases chapter, the documented procedures are applicable to
all the UNIX/Linux platforms unless otherwise noted.
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.
82 Deployment guidelines and best practices
Product troubleshooting tips
Chapter 6
Symantec solution:
UNIX/Linux use cases
This chapter includes the following topics:
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.
See Figure 6-1 on page 84.
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.
See Figure 6-2 on page 86.
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
Symantec solution: UNIX/Linux use cases 89
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.
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.
See “Application server” on page 161.
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.
1.2 1.3
6.0MP4
# cd /
# ls <mnt>/NB_60_Solaris_20050906a
install* solaris/
# <mnt>/NB_60_Solaris_20050906a/install
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
Do you wish to continue? [y,n] (y)
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
# /usr/openv/netbackup/bin/jnbSA -d <display> \
-l /tmp/jnbSA.log.1 -lc &
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
# 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
94 Symantec solution: UNIX/Linux use cases
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.
# /usr/openv/netbackup/bin/goodies/netbackup start
# cat /usr/openv/netbackup/bin/version
NetBackup-Solaris9 6.0MP4
# /usr/openv/netbackup/bin/bpps -x
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.
1.2 1.3
6.0MP4
# cd /
# ls <mnt>/NB_60_AIX_Tru64_20050906a
alpha_5/ install* rs6000/
# <mnt>/NB_60_AIX_Tru64_20050906a/install
Installing NetBackup Server Software
Do you wish to continue? [y,n] (y)
Enter license key: <NetBackup Master/Media management server keys>
veritas:2:wait:/etc/rc.veritas.aixscript
4 Verify that the NetBackup and the Private Branch Exchange processes are
running.
# /usr/openv/netbackup/bin/bpps -x
# cat /usr/openv/netbackup/bp.conf
SERVER = neptune.universe.com
SERVER = triton.universe.com
CLIENT_NAME = triton.universe.com
EMMSERVER = neptune.universe.com
# cat /usr/openv/netbackup/bp.conf
SERVER = neptune.universe.com
SERVER = oberon.universe.com
SERVER = triton.universe.com
CLIENT_NAME = bianca.universe.com
# cat /usr/openv/netbackup/bin/version
NetBackup-Solaris9 6.0MP3
# /usr/openv/netbackup/bin/admincmd/bpplclients
Hardware OS Client
---------- ------------ --------------
Solaris Solaris9 bianca.universe.com
/usr/openv/netbackup/bin# update_clients \
-Install_Client_Bins -ClientList /tmp/sc
# cat /usr/openv/netbackup/bin/version
NetBackup-Solaris9 6.0MP4
Refer to the corresponding NetBackup use case section for procedures to install
and configure a NetBackup management client on Windows.
See “NetBackup use case” on page 158.
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.
6.0MP4
# /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>
Password: <pick a password for neptune>
Operation completed successfully.
# /usr/openv/netbackup/bin/bpnbat -ShowMachines
neptune.universe.com
Symantec solution: UNIX/Linux use cases 103
NetBackup use case
# /usr/openv/netbackup/bin/bpnbat -loginmachine
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.
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.
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 Name: neptune.universe.com
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.
# /usr/openv/netbackup/bin/admincmd/bpnbaz \
-AllowAuthorization neptune.universe.com \
-server neptune.universe.com
Operation completed successfully.
# /usr/openv/netbackup/bin/admincmd/bpnbaz -ShowAuthorizers
Type: User
Domain Type: vx
Domain:NBU_Machines@neptune.universe.com
Name: neptune.universe.com
# /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.
106 Symantec solution: UNIX/Linux use cases
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.
# /usr/openv/netbackup/bin/goodies/netbackup stop
# /usr/openv/netbackup/bin/goodies/netbackup start
Symantec solution: UNIX/Linux use cases 107
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
Authentication Broker: neptune.universe.com
Authentication port[ Enter = default]:
Authentication type (NIS, NIS+, NT, vx, unixpwd): unixpwd
Domain: neptune.universe.com
Login Name: root
Password: <pick a password for neptune>
Operation completed successfully.
# /usr/openv/netbackup/bin/bpnbat -whoami
Name: root
Domain: neptune.universe.com
Issued by: /CN=broker/OU=root@neptune.universe.com/O=vx
Expiry Date: Dec 9 01:43:47 2006 GMT
Authentication method: UNIX passwd
Operation completed successfully.
# /usr/openv/netbackup/bin/admincmd/bpnbaz \
-adduser "NBU_Security Admin" \
unixpwd:neptune.universe.com:root
Operation completed successfully.
# /usr/openv/netbackup/bin/admincmd/bpnbaz \
-adduser "NBU_Admin" \
unixpwd:neptune.universe.com:root
Operation completed successfully.
# /usr/openv/netbackup/bin/admincmd/bpnbaz \
-adduser "NBU_Admin" unixpwd:neptune.universe.com:vxss
Operation completed successfully
108 Symantec solution: UNIX/Linux use cases
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.
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
110 Symantec solution: UNIX/Linux use cases
NetBackup use case
# /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: triton.universe.com
Password: <pick a password for neptune>
Password: <pick a password for neptune>
Operation completed successfully.
# /opt/VRTSat/bin/vssat listpdprincipals \
--pdrtype ab --domain NBU_Machines@neptune.universe.com
Principal Name: triton.universe.com
# /usr/openv/netbackup/bin/bpnbat -ShowMachines
neptune.universe.com
triton.universe.com
# /usr/openv/netbackup/bin/bpnbat -loginmachine
Does this machine use Dynamic Host
Configuration Protocol (DHCP)? (y/n) n
Authentication Broker: neptune.universe.com
Authentication port[ Enter = default]:
Machine Name: triton.universe.com
Password: <pick a password for triton>
Operation completed successfully.
# /usr/openv/netbackup/bin/bpnbat -whoami \
-cf /usr/openv/var/vxss/credentials/triton.universe.com
Name: triton.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
Operation completed successfully.
112 Symantec solution: UNIX/Linux use cases
NetBackup use case
# /usr/openv/netbackup/bin/admincmd/bpnbaz \
-AllowAuthorization triton.universe.com \
-server neptune.universe.com
Operation completed successfully.
# /usr/openv/netbackup/bin/admincmd/bpnbaz \
-Showauthorizers -server neptune.universe.com
Type: User
Domain Type: vx
Domain:NBU_Machines@neptune.universe.com
Name: triton.universe.com
# /usr/openv/netbackup/bin/jnbSA -d <disdplay> \
-l /tmp/log.1 -lc &
10 Save the changes, and then exit the jnbSA. For the changes to take effect,
stop and start the NetBackup media management server.
# /usr/openv/netbackup/bin/goodies/netbackup stop
# /usr/openv/netbackup/bin/goodies/netbackup start
# cat /usr/openv/netbackup/bp.conf
SERVER = neptune.universe.com
SERVER = triton.universe.com
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
114 Symantec solution: UNIX/Linux use cases
NetBackup use case
12 Log in to the NetBackup via the CLI and verify that the expiry period by
entering the following command:
# /usr/openv/netbackup/bin/bpnbat -login
Authentication Broker: neptune.universe.com
Authentication port[ Enter = default]:
Authentication type (NIS, NIS+, NT, vx, unixpwd): unixpwd
Domain: neptune.universe.com
Login Name: root
Password: <root password on triton>
Operation completed successfully.
# /usr/openv/netbackup/bin/bpnbat -whoami
Name: root
Domain: netptune.universe.com
Issued by: /CN=broker/OU=root@neptune.universe.com/O=vx
Expiry Date: Dec 26 20:42:38 2007 GMT
Authentication method: UNIX passwd
Operation completed successfully.
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.
# /usr/openv/netbackup/bin/jnbSA -d <display> \
-l /tmp/log.2 -lc &
See “NetBackup access control troubleshooting tips and messages” on page 275.
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.
See “Installing and configuring authentication” on page 229.
Symantec solution: UNIX/Linux use cases 115
NetBackup use case
# /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: oberon.universe.com
Password: <pick a password for oberon>
Password: <pick a password for oberon>
Operation completed successfully.
# /opt/VRTSat/bin/vssat listpdprincipals \
--pdrtype ab --domain NBU_Machines@neptune.universe.com
Principal Name: oberon.universe.com
# /usr/openv/netbackup/bin/bpnbat -ShowMachines
neptune.universe.com
triton.universe.com
oberon.universe.com
116 Symantec solution: UNIX/Linux use cases
NetBackup use case
C:\Program Files\VERITAS\NetBackup\bin>bpnbat \
-loginmachine
Does this machine use Dynamic Host
Configuration Protocol (DHCP)? (y/n) n
Authentication Broker: neptune.universe.com
Authentication port[ Enter = default]:
Machine Name: oberon
Password: <pick a password for oberon>
Operation completed successfully.
C:\Program Files\VERITAS\NetBackup\bin\admincmd>bpnbaz
-allowauthorization oberon -server neptune.universe.com
Operation completed successfully.
# /usr/openv/netbackup/bin/jnbSA -d <disdplay> \
-l /tmp/log.1 -lc &
Symantec solution: UNIX/Linux use cases 117
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
Properties... On the Properties… screen, select the Access Control (last one
on the list). In the Veritas Security Services (VxSS) box, choose Automatic
(others are Required and Prohibit).
See “NetBackup access control parameters” on page 243.
8 On the Authentication Domains tab, click Add and a dialog box appears. Enter
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.
# /usr/openv/netbackup/bin/goodies/netbackup stop
# /usr/openv/netbackup/bin/goodies/netbackup start
5.1MP6
6.0MP4
# /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: bianca.universe.com
Password: <pick a password for bianca>
Password: <pick a password for bianca>
Operation completed successfully.
# /usr/openv/netbackup/bin/bpnbat -ShowMachines
neptune.universe.com
triton.universe.com
bianca.universe.com
120 Symantec solution: UNIX/Linux use cases
NetBackup use case
# /usr/openv/netbackup/bin/bpnbat -loginmachine
Does this machine use Dynamic Host
Configuration Protocol (DHCP)? (y/n) n
Authentication Broker: neptune.universe.com
Authentication port[ Enter = default]:
Machine Name: bianca.universe.com
Password: <pick a password for bianca>
Operation completed successfully.
# /usr/openv/netbackup/bin/jnbSA -d <disdplay> \
-l /tmp/log.1 -lc &
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.
# /usr/openv/netbackup/bin/goodies/netbackup stop
# /usr/openv/netbackup/bin/goodies/netbackup start
122 Symantec solution: UNIX/Linux use cases
NetBackup use case
# cat /usr/openv/netbackup/bp.conf
SERVER = neptune.universe.com
SERVER = triton.universe.com
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
USE_VXSS = AUTOMATIC
# /usr/openv/netbackup/bin/bpnbat -login
Authentication Broker: neptune.universe.com
Authentication port[ Enter = default]:
Authentication type (NIS, NIS+, NT, vx, unixpwd): unixpwd
Domain: neptune.universe.com
Login Name: root
Password: <pick a password for bianca>
Operation completed successfully.
# /usr/openv/netbackup/bin/bpnbat -whoami
Name: root
Domain: neptune.universe.com
Issued by: /CN=broker/OU=root@neptune.universe.com/O=vx
Expiry Date: Dec 15 21:12:35 2006 GMT
Authentication method: UNIX passwd
Operation completed successfully.
# /usr/openv/netbackup/bin/jnbSA -d <display> \
-l /tmp/log.2 -lc &
Symantec solution: UNIX/Linux use cases 123
NetBackup 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
6.0MP4
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.
4.2FP1
4.3
# cd <mnt>/CC4.2FP1/sunos
# ls
installccs* uninsallccs*
# ./installccs
1) CommandCentral Storage Management Server
3) CommandCentral Storage Web Engine
# cd <mnt>/ CCS_4.3/4.3.0017.0/sunos
# ls installccs uninstallccs
installccs* uninstallccs
# ./installccs
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.
4.2FP1
# cd <mnt>/CC4.2FP1/sunos
# ls
installccs* uninsallccs*
# ./installccs
1) CommandCentral Service Server and Web Engine
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.
4.2FP1
Symantec solution: UNIX/Linux use cases 133
CommandCentral Storage and Service use case
4.3
# cd <mnt>/ CCS_4.3/4.3.0017.0/unix_agent
# ls *install*
installccs* uninstallccs*
# ./installccs
2) CommandCentral Storage Agent
# cd <mnt>/CC4.2FP1/sunos
Components available for installation:
3) CommandCentral Service Agent
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
136 Symantec solution: UNIX/Linux use cases
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.
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.
138 Symantec solution: UNIX/Linux use cases
Symantec License Inventory Manager use case
4.0.4
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.
cd <path>/Server/Solaris
# ls install
install
# ./install
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.
140 Symantec solution: UNIX/Linux use cases
Symantec License Inventory Manager use case
# 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
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.
142 Symantec solution: UNIX/Linux use cases
Symantec License Inventory Manager use case
# 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.
SLIM-related upgrade
SLIM upgrade typically involves one or more of the following components:
Symantec solution: UNIX/Linux use cases 143
Storage Foundation use case
respective product use case section for instruction on how to set up a management
agent or client on a system.
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.
Table 6-11 shows the specific version of the common core service (authentication)
that is used with Storage Foundation.
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.
146 Symantec solution: UNIX/Linux use cases
Storage Foundation use case
# 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.
Symantec solution: UNIX/Linux use cases 147
Storage Foundation use case
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
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
This chapter includes the following topics:
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.
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.
Symantec solution: Windows use cases 153
Symantec License Inventory Manager use case
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.
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.
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.
See “Replacing the root broker on the SLIM server” on page 300.
Symantec solution: Windows use cases 155
Symantec License Inventory Manager use case
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.
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.
See “Verifying the SLIM server setup” on page 295.
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.
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.
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.
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.
Symantec solution: Windows use cases 161
NetBackup use case
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.
See “Application server” on page 89.
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.
1.2 1.3
6.0MP4
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).
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.
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.
164 Symantec solution: Windows use cases
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.
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.
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.
166 Symantec solution: Windows use cases
NetBackup use case
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.
8 On the Ready to Install the Program screen, click Install to begin the
installation of the NetBackup media management server.
Symantec solution: Windows use cases 167
NetBackup use case
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
168 Symantec solution: Windows use cases
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.
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:
HKEY_LOCAL_MACHINE\Software\VERITAS\NetBackup\CurrentVersion\config
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.
170 Symantec solution: Windows use cases
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.
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.
Symantec solution: Windows use cases 171
NetBackup use case
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.
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.
6 To find the Domain for WINDOWS (nt) Authentication type, use the following
command:
7 Add the following master management server as the host that is authorized
to perform Authorization check:
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.
2 Click the Authentication Domains tab, click Add and a dialog box appears.
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.
Symantec solution: Windows use cases 175
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.
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.
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.
See “NetBackup access control troubleshooting tips and messages” on page 275.
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
178 Symantec solution: Windows use cases
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.
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.
HKEY_LOCAL_MACHINE\Software\VERITAS\NetBackup\CurrentVersion\config
182 Symantec solution: Windows use cases
NetBackup use case
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.
Symantec solution: Windows use cases 183
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.
See “Add a new authentication broker” on page 238.
To enable NBAC on a UNIX or Linux media management server
1 Procedures described in this step must be executed on the master management
server – jupiter.universe.com. Use the following command to create an
authentication principal for the HP-UX system that has the media
management server.
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.
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
Properties... On the Properties… screen, select the Access Control (last one
on the list). In the Veritas Security Services (VxSS) box, choose Automatic
(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.
6 Click the Authentication Domains tab, click Add and a dialog box appears.
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.
7 Save the changes, and then exit the Administration Console. For the changes
to take effect, stop and start the NetBackup media management server.
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.
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.
Symantec solution: Windows use cases 187
NetBackup use case
C:\Program Files\VERITAS\Security\Authentication\bin>
vssat listpdprincipals \
--pdrtype ab \
--domain NBU_Machines@jupiter.sun.universe.com
Principal Name: callisto.sun.universe.com
C:\Program Files\VERITAS\NetBackup\bin>
bpnbat -ShowMachines
jupiter.sun.universe.com
leda.sun.universe.com
callisto.sun.universe.com
188 Symantec solution: Windows use cases
NetBackup use case
7 Save the changes, and then exit the Administration Console. For the changes
to take effect, stop and start the NetBackup master management server.
HKEY_LOCAL_MACHINE\Software\VERITAS\NetBackup\CurrentVersion\config
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.
190 Symantec solution: Windows use cases
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.
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
production environment.
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.
6.0MP4
192 Symantec solution: Windows use cases
NetBackup Operations Manager use case
6.0MP4
Symantec solution: Windows use cases 193
NetBackup Operations Manager use case
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:
6 Go to Start > Administrative Tools > Services, and verify that the NOM and
supporting services (listed earlier) are started.
196 Symantec solution: Windows use cases
NetBackup Operations Manager use case
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.
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.
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.
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.
4.2FP1
4.3
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
files, and then click setup.exe.
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:
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.
2 In an Explore window, navigate to the directory that has the CC installation
files, and then click setup.exe.
4.2FP1
202 Symantec solution: Windows use cases
CommandCentral Storage and Service use case
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.
Symantec solution: Windows use cases 203
CommandCentral Storage and Service use case
4.2FP1
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
Symantec solution: Windows use cases 205
Storage Foundation use case
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.
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.
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).
Symantec solution: Windows use cases 207
Storage Foundation use case
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.
4.3MP1
(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.
210 Symantec solution: Windows use cases
Storage Foundation use case
Appendix A
Storage Foundation
common procedures
This appendix includes the following topics:
4.1 and 5.0 are illustrated for UNIX and Linux platforms. On Windows, the
procedures are described using SF version 4.3.
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
# /opt/VRTSat/bin/vssat showbrokerhash
Root Hash: 9efb1d042f646656602f55be4016a8bf1a1d03b4
Enter the password for the CMC service account: <vea_agent's password>
Enter the hash of the management server's
root broker [?] 9efb1d042f646656602f55be4016a8bf1a1d03b4
Storage Foundation common procedures 215
Enabling a VCS cluster with authentication service
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.
# /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.
See “Verify authentication setup” on page 235.
218 Storage Foundation common procedures
Re-establishing the authentication service for a node in a VCS cluster
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
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 authenticate \
--domain vx:HA_SERVICES@ophelia.universe.com \
--prplname _HA_VCS_ophelia \
--broker localhost:2821
# 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: admin
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"
)
220 Storage Foundation common procedures
Setting up a Storage Foundation Management Server with authentication service
# cd mountpoint/sol
# ./installer
# cd mountpoint/sol
# ./installer
Storage Foundation common procedures 221
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
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:
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:
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:
On Windows, to create a VxVM disk group and volumes, use the New Group and
New Volume tabs in Start > VERITAS > VERITAS Enterprise Administrator.
224 Storage Foundation common procedures
Common Veritas Volume Manager and Veritas File System procedures
# mkdir -p /usr/openv
3 Mount the file system and display the amount of disk space it occupies:
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
This appendix includes the following topics:
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
About Infrastructure Core Services
1.2
1.3
9 To start and stop the Private Branch Exchange service from the command
line, run the following commands, respectively:
# cd <mnt>/ NB_60_ICS_1.2.3.45_Solaris
# ./installics
6 Start and then stop the Private Branch Exchange process daemon. Type the
following command:
# /opt/VRTSpbx/bin/vxpbx_exchanged start
# /opt/VRTSpbx/bin/pbxcfg -p
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.
4.1
4.2
4.3
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
# cd <mnt>/NB_60_ICS_1.2.3.45_HP
# ./installics
5 To install the AT client on the system, type n. The following message appears:
12 Enter the location of the file containing the root’s hash: /tmp/root_hash. The
following message is displayed:
13 Choose 1 and 3 for Root broker only and Authentication + Root broker
configuration, respectively.
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.
Infrastructure Core Services common procedures 233
About Infrastructure Core Services
4.1
4.2
4.3
C:\Program Files\VERITAS\Security\Authorization
234 Infrastructure Core Services common procedures
About Infrastructure Core Services
# cd <mnt>/NB_60_ICS_1.2.3.45_Solaris
# ./installics
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.)
# /opt/VRTSat/bin/vssat showbrokermode
# /opt/VRTSat/bin/vssregctl -l -q \
-b "Security\Authentication\Authentication Broker" \
-k Mode
Infrastructure Core Services common procedures 237
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:
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:
# /opt/VRTSat/bin/vssregctl \
-g /etc/vx/vss/VRTSaz.conf -e \
-b Security\\Authorization\\ServiceIdentity
Name: ServiceName Type: 0 Value: vxazd_vxsvc
238 Infrastructure Core Services common procedures
Add a new authentication broker
■ On Windows:
C:\Program Files\VERITAS\Security\Authentication\bin>
vssregctl -g HKEY_LOCAL_MACHINE\Software\VERITAS
-e -bSecurity\Authorization
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).
5 To start and stop the Symantec Product Authentication process, use the
following scripts:
/var/VRTsat
/etc/vx/vss
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.
240 Infrastructure Core Services common procedures
Backup and restore authentication data
# /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
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
C:\Program Files\VERITAS\Security\Authentication\bin>
C>:\Program Files\VERITAS\Security\Authentication
Infrastructure Core Services common procedures 241
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.
# /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
# /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
242 Infrastructure Core Services common procedures
Backup and restore authorization data
B|/etc/vx/vss/VRTSaz.loc
#
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
This appendix includes the following topics:
■ NetBackup policies
AUTHENTICATION_DOMAIN=
universe.com. "neptune NIS+" NIS+ neptune.universe.com 0
AUTHENTICATION_DOMAIN=
SUN "SUN WINDOWS" WINDOWS jupiter.universe.com 0
# /opt/VRTSat/bin/vssat showallbrokerdomains
***********************************
Broker Name: neptune.universe.com
Broker Port: 2821
Domain Name: universe.com.
Domain Type: nisplus
C:\Program Files\VERITAS\Security\Authentication\bin>.\vssat \
showallbrokerdomains
****************************************
Broker Name: jupiter.sun.universe.com
Broker Port: 2821
Domain Name: SUN
Domain Type: nt
You use the following NetBackup utilities to stop and start the NetBackup server
for the changes to take effect on UNIX/Linux:
# /usr/openv/netbackup/bin/goodies/netbackup stop
# /usr/openv/netbackup/bin/goodies/netbackup start
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.
HKEY_LOCAL_MACHINE\Software\VERITAS\NetBackup\CurrentVersion\config
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:
# /usr/openv/netbackup/bin/bpps -x
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.
See “Verify authentication setup” on page 235.
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.
248 NetBackup common procedures
Verify NetBackup access control setup on the master server
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.
See “Add a new authentication broker” on page 238.
The following is a sample output for a Windows master server:
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:
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).
The following example illustrates sample Windows output:
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.
# /usr/openv/netbackup/bin/admincmd/bpnbaz -ShowAuthorizers
==========
Type: User
Domain Type: vx
Domain:NBU_Machines@neptune.universe.com
Name: neptune.universe.com
Type: User
Domain Type: vx
Domain:NBU_Machines@jupiter.sun.universe.com
Name: neptune.universe.com
Operation completed successfully.
==========
Type: User
Domain Type: vx
Domain:NBU_Machines@jupiter.sun.universe.com
Name: jupiter.sun.universe.com
Operation completed successfully.
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
Operation completed successfully.
# /usr/openv/netbackup/bin/admincmd/bpnbaz -listgroups
NBU_User
NBU_Operator
NBU_Admin
NBU_Security Admin
Vault_Operator
Operation completed successfully.
Vault_Operator
Operation completed successfully.
# cat /usr/openv/netbackup/bp.conf
SERVER = neptune.universe.com
SERVER = janus.univerise.com
CLIENT_NAME = neptune.universe.com
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.
See “NetBackup access control parameters” on page 243.
NetBackup common procedures 253
Verify NetBackup access control setup on the master server
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
# /usr/openv/netbackup/bin/bpnbat -whoami \
-cf /usr/openv/var/vxss/credentials/janus.universe.com
Name: janus.universe.com
Domain: NBU_Machines@jupiter.sun.universe.com
Issued by: /CN=jupiter/OU=root@mercury.sun.universe.com/O=vx
Expiry Date: Nov 30 21:42:05 2007 GMT
256 NetBackup common procedures
Verify NetBackup access control setup on media servers
# /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
Operation completed successfully.
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
Operation completed successfully.
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
NetBackup common procedures 257
Verify NetBackup access control setup on media servers
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
Operation completed successfully.
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.
See “NetBackup access control parameters” on page 243.
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
258 NetBackup common procedures
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
Sample outputs of the bpnbat command for Windows and UNIX/Linux clients are
shown.
On Windows, the sample output is, as follows:
In a setup that uses the Windows Active Directory, the credential file includes the
Windows domain name, as follows:
# /usr/openv/netbackup/bin/bpnbat -whoami \
-cf /usr/openv/var/vxss/credentials/calypso.universe.com
Name: calypso.universe.com
Domain: NBU_Machines@neptune.universe.com
Issued by: /CN=broker/OU=root@neptune.universe.com/O=vx
Expiry Date: Dec 6 14:49:00 2006 GMT
Authentication method: VERITAS Private Security
Operation completed successfully.
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:
# /usr/openv/netbackup/bin/bpnbat -login
Authentication Broker: neptune.universe.com
Authentication port[ Enter = default]:
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
Operation completed successfully.
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:
You access the Host Properties to verify. For jnbSA, the NetBackup Access Control
attributes are found under the Access Control property.
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.
# /opt/VRTSat/bin/vssat addprpl \
--pdrtype root \
--prplname jupiter.universe.com \
--password jupiter_pass --prpltype service \
--domain root@mercury.universe.com
# /usr/openv/netbackup/bin/goodies/netbackup stop
# /etc/rc2.d/S71vxazd stop
# /etc/rc2.d/S70vxatd stop
# /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
# /opt/VRTSat/bin/vssat deletecred \
--domain vx:root@jupiter.universe.com \
--prplname root
# /opt/VRTSat/bin/vssat deletecred \
--domain vx:SERVICES@jupiter.universe.com \
--prplname vxazd_vxsvc@jupiter.universe.com
# rcp /opt/VRTSat/bin/root_hash \
jupiter.universe.com:/tmp/root_hash
NetBackup common procedures 265
Replacing the root broker on the NetBackup master server
# /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 stop
# /etc/rc2.d/S70vxatd start
# /etc/rc2.d/S71vxazd start
# /usr/openv/netbackup/bin/goodies/netbackup start
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:
# /usr/openv/netbackup/bin/bpnbat -loginmachine
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:
# /usr/openv/netbackup/bin/bpnbat -loginmachine
266 NetBackup common procedures
Replacing the root broker on the NetBackup master server
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:
# /usr/openv/netbackup/bin/goodies/netbackup stop
# /usr/openv/netbackup/bin/goodies/netbackup stop
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:
# /usr/openv/netbackup/bin/bpnbat -loginmachine
# /usr/openv/netbackup/bin/bpnbat -showmachines
neptune.universe.com
bianca.universe.com
triton.universe.com
portia.universe.com
# /usr/openv/netbackup/bin/bpnbat -login
■ On a host that has a media server, perform an update on the tape devices
to verify those connections still work.
# /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 …
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,
NetBackup common procedures 269
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.
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.
# /usr/openv/netbackup/bin/admincmd/bpnbaz -listgroups
NBU_User
NBU_Operator
NBU_Admin
NBU_Security Admin
Vault_Operator
Operation completed successfully.
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.
# /usr/openv/netbackup/bin/admincmd/bpnbaz \
-adduser NBU_Admin nisplus:universe.com.:goku \
-M neptune.universe.com \
-server neptune.universe.com
Operation completed successfully.
# /usr/openv/netbackup/bin/admincmd/bpnbaz \
-adduser NBU_Admin nt:SUN:administrator \
-M neptune.universe.com \
272 NetBackup common procedures
NetBackup and authorization
-server neptune.universe.com
Operation completed successfully.
# /usr/openv/netbackup/bin/admincmd/bpnbaz \
-listgroupmembers NBU_Admin
Type: User
Domain Type: nt
Domain:SUN
Name: ADMINISTRATOR
Type: User
Domain Type: nisplus
Domain:universe.com.
Name: goku
To find the authentication domain associated with the NISPLUS plug-in, run the
following command.
# /opt/VRTSat/bin/vssat showallbrokerdomains
Broker Name: neptune.universe.com
Broker Port: 2821
Domain Name: universe.com.
Domain Type: nisplus
# /usr/openv/netbackup/bin/admincmd/bpnbaz \
-adduser "NBU_Security Admin" unixpwd:neptune.universe.com:gohan \
-M neptune.universe.com \
-server neptune.universe.com
Operation completed successfully.
# /usr/openv/netbackup/bin/admincmd/bpnbaz \
-listgroupmembers "NBU_Security Admin"
Type: User
Domain Type: unixpwd
Domain:neptune.universe.com
Name: gohan
Type: User
Domain Type: unixpwd
Domain:neptune.universe.com
Name: root
NetBackup common procedures 273
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:
To execute NBU administrative command from the command line, goku has to
authenticate himself and acquire a valid session first.
5 On the Ready to Install the Program screen, click Install to begin the
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.
Try to acquire a new session by issuing the bpnbat –login NetBackup command
on the host that either has master, media or client.
# /usr/openv/netbackup/bin/bpnbaz -showauthorizers
Unable to connect to authorization server.
Please check your -Server argument and try again.
# /usr/openv/netbackup/bin/bpnbat -login
# /usr/openv/netbackup/bin/admincmd/bpnbaz -showauthorizers
278 NetBackup common procedures
NetBackup access control troubleshooting tips and messages
Appendix D
CommandCentral
Storage/Service common
procedures
This appendix includes the following topics:
■ Troubleshooting tips
# /opt/VRTS/bin/vxccstor status
***VERITAS Enterprise Administrator running***
***VERITAS Database Management Server running***
***VERITAS Trap Processor running***
280 CommandCentral Storage/Service common procedures
Verifying the CommandCentral Storage server setup
■ 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)
# /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
Verifying the CommandCentral Storage server setup
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.
282 CommandCentral Storage/Service common procedures
Verifying the CommandCentral Service server setup
# /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 Alert Manager
■ Veritas CommandCentral Trap Processor
■ 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
CommandCentral Storage/Service common procedures 283
Verifying the CommandCentral Service server setup
# /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...
# /opt/VRTS/bin/vxccsvcweb status
VERITAS CommandCentral Service Server is running.
VERITAS CommandCentral Service Metering UI is running.
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.
# /opt/VRTS/bin/vxccstor status
***VERITAS Enterprise Administrator running***
***VERITAS SAN Access Layer running***
***VERITAS CommandCentral Data Module running***
***VERITAS SICL running***
# /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.
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/VRTS/bin/vxccstorweb stop
# /opt/VRTS/bin/vxccstor stop
# /opt/VRTS/bin/vxccsvcweb stop
# /opt/VRTS/bin/vxccsvc 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 the logical
ports and other resources that the CommandCentral Storage server may
require when it restarts.
# /opt/VRTSat/bin/vssat listpdprincipals \
--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
# /opt/VRTSat/bin/vssat deletecred \
--domain vx:root@cressida.universe.com \
--prplname <prpl name> \
--broker cressida.universe.com:2821
# rcp /opt/VRTSat/bin/root_hash \
cressida.universe.com:/tmp/root_hash
# /opt/VRTSccshd/bin/ccvssatsetup -delete
C:\Program Files\VERITAS\Security\Authentication\bin> \
ccvssatsetup.exe -delete
290 CommandCentral Storage/Service common procedures
Replacing the root broker on the CommandCentral server
# /opt/VRTSccshd/bin/ccvssatsetup
C:\Program Files\VERITAS\Security\Authentication\bin> \
ccvssatsetup.exe
# /opt/VRTS/bin/vxccstor start
# /opt/VRTS/bin/vxccstorweb start
# /opt/VRTS/bin/vxccsvc start
# /opt/VRTS/bin/vxccsvcweb 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 Enterprise Administrator Service
■ Adaptive Server Anywhere
■ Veritas CommandCentral Trap Processor
■ Veritas CommandCentral Alert Manager
■ Veritas SAN Access Layer (SAL)
■ Veritas CommandCentral Storage Alarm Service
■ Veritas CommandCentral DM explorers
■ Veritas CommandCentral DM Importer
■ Veritas Simple Instrumentation Collection Layer (SICL)
CommandCentral Storage/Service common procedures 291
Replacing the root broker on the CommandCentral server
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
2 Highlight and right-click the service, and then click Stop to stop the following
services:
■ Veritas CommandCentral Storage Agent
292 CommandCentral Storage/Service common procedures
Replacing the root broker on the CommandCentral server
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.
# /opt/VRTSat/bin/vssat deletecred \
--domain vx:ccstr_services@cressida.universe.com \
--prplname ccstr_web \
--broker cressida.universe.com
# /opt/VRTSat/bin/vssat deletecred \
--domain vx:ccsvc_services@cressida.universe.com \
--prplname ccsvc_agent \
--broker cressida.universe.com
# /opt/VRTSccsva/bin/ccsvcagentauth \
-server cressida.universe.com
C:\Program Files\VERITAS\CommandCentral\Service\Agent\bin> \
ccsvcagentauth -server cressida.universe.com
Troubleshooting tips
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:
# /opt/VRTS/bin/vxccstor status
# /opt/VRTSweb/bin/monitorApp cc
Web Application "cc" is ONLINE
# /opt/VRTSweb/bin/monitorApp spc
Web Application "spc" is OFFLINE
# /opt/VRTSweb/bin/startApp cc /opt/VRTSweb/VERITAS
294 CommandCentral Storage/Service common procedures
Troubleshooting tips
# /opt/VRTS/bin/vxccsvc status
# /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...
# /opt/VRTS/bin/vxccsvcweb status
VERITAS CommandCentral Service Server is running.
VERITAS CommandCentral Service Metering UI is running.
Appendix E
Symantec License Inventory
Manager common
procedures
This appendix includes the following topics:
# /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 Product Authentication 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:
https://belinda.universe.com:8443/slim
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.
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: \
slim_services@belinda.universe.com
[Info] V-149-1-24539 Domain Type: vx
[Info] V-149-1-24541
[Info] V-149-1-24531 Completed Administrative command.
Symantec License Inventory Manager common procedures 299
Verifying the SLIM agent setup
# /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: \
slim_services@belinda.universe.com
[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:
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):
# /opt/VRTSat/bin/vssat showbrokerhash
9efb1d042f646656602f55be4016a8bf1a1d03b4
6 From the SLIM agent client host (miranda.universe.com), type the following
command:
# rcp /opt/VRTSat/bin/root_hash \
belinda.universe.com:/tmp/root_hash
# /etc/rc2.d/S75vxsmfd stop
# /etc/rc2.d/S45vxpbx_exchanged stop
# /etc/rc2.d/S70vxatd stop
# /etc/rc2.d/S38vxdbms3 stop
# /etc/rc2.d/S71vxazd stop
# /opt/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:
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
/opt/VRTSat/bin/vxatd \
-a -n %ABIDENTITY% \
-p %ABPASSWORD% \
-x vx -y %DOMAINNAME% \
-q %ROOTBROKER% \
-z %ATPORT%
-h %ROOTHASH%
# /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
C:\Program Files\VERITAS\Security\Authentication\Systemprofile
# /bin/sh /opt/SYMClms/bin/configure
C:\Program Files\Symantec\ \
License Inventory Manager\Server\bin>configure.bat
C:\Program Files\VERITAS\Security \
\Authentication\bin>vssat.exe showbrokermode
Broker mode is : 1
12 To log on to the SLIM Web service, type the following URL in a browser:
https://belinda.universe.com:8443/slim
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:
# /opt/VRTSat/bin/vssat showbrokerhash
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.
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 \
--CollectorNodeUsername slim_agent \
--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.
■ 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:
Symantec License Inventory Manager common procedures 307
SLIM troubleshooting tips
The default log level is INFO. This logs high-level functions and any errors and
warnings.
Solaris
■ /opt/SYMClms/bin/redist for data (database, transaction log file)
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
Run the command java -version from within that directory to show the current
Sun Java Virtual Machine version.
/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: 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).
■ /var/tmp/install-lim1102143201/install-lim.log
On Windows use:
Note: Service name lma would only appear if the SLIM agent was installed.
# /opt/VRTSat/bin/vssat authenticate \
-domain vx:slim_services@SERVER_HOSTNAME \
-prplname slim_agent \
-password slim_agent_password \
-broker SERVER_HOSTNAME:2821
# /opt/VRTSweb/bin/startApp slim
# /opt/VRTSsmf/bin/vxservice -L
# /opt/SYMClma/bin/lmautil -I
3 If steps 1 and 2 are successful, check the broker hash of the server on the
agent. Type:
# /opt/VRTSat/bin/vssat showbrokerhash
4 Compare the hash with the one on the server; run the same command on the
server.
Symantec License Inventory Manager common procedures 313
SLIM troubleshooting tips
# /opt/VRTSsmf/bi/vxservice -L
# /opt/SYMClma/bin/lmautil -I
# /opt/VRTSweb/webgui/stop
# /opt/VRTSweb/bin/webgui restart
314 Symantec License Inventory Manager common procedures
SLIM troubleshooting tips
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