vxss yello page

The roles of Symantec Product Authentication and Authorization Service in your enterprise

Overview of the Symantec Product Authenticationand Authorization Service

Guidelines and best practices for deployingSymantec products with Authentication and Authorization Service

Technical information illustrating multiple productdeployment environments using tested UNIX, Linux, and Windows use cases

Symantec ProductAuthentication andAuthorization

Securely deploy Symantec products using the appropriate deployment configuration for yourenterprise environment

Verify Symantec Product Authentication and Authorization setup in your enterprise

Symantec Product Authentication and Authorization

The software described in this book is furnished under a license agreement and may be used

only in accordance with the terms of the agreement.

Documentation version 1.0

Legal Notice

Copyright © 2007 Symantec Corporation.

All rights reserved.

Symantec, the Symantec Logo, and Symantec Yellow Book are trademarks or registered

trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other

names may be trademarks of their respective owners.

Microsoft, Windows, Active Directory, Excel, JScript, Outlook, PowerPoint, SharePoint, and

Windows server are trademarks or registered trademarks of Microsoft Corporation.

The product described in this document is distributed under licenses restricting its use,

copying, distribution, and decompilation/reverse engineering. No part of this document

may be reproduced in any form by any means without prior written authorization of

Symantec Corporation and its licensors, if any.

THE DOCUMENTATION IS PROVIDED "AS IS" AND ALL EXPRESS OR IMPLIED CONDITIONS,

REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF

MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT,

ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS ARE HELD TO

BE LEGALLY INVALID. SYMANTEC CORPORATION SHALL NOT BE LIABLE FOR INCIDENTAL

OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH THE FURNISHING,

PERFORMANCE, OR USE OF THIS DOCUMENTATION. THE INFORMATION CONTAINED

IN THIS DOCUMENTATION IS SUBJECT TO CHANGE WITHOUT NOTICE.

The Licensed Software and Documentation are deemed to be commercial computer software

as defined in FAR 12.212 and subject to restricted rights as defined in FAR Section 52.227-19

"Commercial Computer Software - Restricted Rights" and DFARS 227.7202, "Rights in

Commercial Computer Software or Commercial Computer Software Documentation", as

applicable, and any successor regulations. Any use, modification, reproduction release,

performance, display or disclosure of the Licensed Software and Documentation by the U.S.

Government shall be solely in accordance with the terms of this Agreement.

Symantec Corporation

20330 Stevens Creek Blvd.

Cupertino, CA 95014

http://www.symantec.com

Acknowledgments

Symantec thanks the following people for their contribution to the Symantec Yellow Book™:

Principal Authors

Aloysius Lau

Hoang Nguyen

The principal authors and Symantec would like to thank the following contributors:

Bruce Naegel

Don Ross

John Richardson

Kurt Papke

Jose Iglesias

William Browning

Tom Stephens

Kyle Gleed

Don Brinkley

Aaron Christenson

Trung Nguyen

Chris Leffel

Rangan Doreswamy

Larry Vaught

John Belz

David Hartman

Sreekanth Vadapalli

Barry McGuckin

Eric Delaney

Tao Ni

Xiao Yin

Fan Yang

Hai Sheng Kang

Robert Robinson

Gaurav Khanna

Daniel Sronchaiprasith

Pawan Sood

Kenneth Howe

Eddie Chao

Linda Greene

Stephen England

Kathryn Cheng

Fran Heddings

Tom Dewan

Mette Wadleigh

Patrick Carri

Chapter 1 Introduction

About this Yellow Book .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Difference between product guides and this Yellow Book .... . . . . . . . . . . . 14

How this Yellow Book helps users ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Who should use this Yellow Book .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Scope of this document .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Symantec products covered in this Yellow Book edition .... . . . . . . . . . . . . . 16

About future editions of this Yellow Book .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Topics to be covered in future editions ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

About acronyms and definitions ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

About authentication and authorization .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Customer benefits ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Chapter 2 Overview of the Symantec Product AuthenticationService

Authentication service overview .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Authentication hierarchy .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Authentication principal ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Authentication components ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Root broker ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Authentication broker ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Authentication plug-ins and mechanisms .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Authentication entities ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Authentication user interface ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Authentication broker communications port ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

How the authentication process works .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Acquiring a product credential ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Authentication expiry ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Chapter 3 Overview of the Symantec Product AuthorizationService

Authorization service overview .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Authorization service components ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Authorization service ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Contents

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

Access control information data repository .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Master authorization service ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Local authorization service ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Resource management application .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Authorization group or namespace .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Authorization user interface ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Authorization service communication port ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Access control policy ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Access control lists ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

How the authorization process works .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Chapter 4 How authentication and authorization are usedacross Symantec products

Introduction .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Implementing one authentication hierarchy in your enterprise ... . . . . . . . . . . 44

Using the authentication service for secure communication .... . . . . . . . . . . . . 44

Upgrading authentication service in your enterprise ... . . . . . . . . . . . . . . . . . . 45

Assimilating authentication service into your enterprise ... . . . . . . . . . . . . . . . . . . 46

NetBackup .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

NetBackup Operations Manager ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Veritas Storage Foundation .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

CommandCentral ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Symantec License Inventory Manager ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Using the authorization service for access control ... . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

NetBackup .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Chapter 5 Deployment guidelines and best practices

Multiproduct deployment approach .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Application server ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Management server ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Management agent and client ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Broker architecture determination .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Root and authentication broker placement ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Isolated root broker ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Multiple root brokers ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Brokers in different time zones .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Broker availability ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Root broker consolidation .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Planning for authentication and authorization in your enterprise

environment .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Authentication and authorization administration .... . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Contents6

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

Authorization administrator responsibilities ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Platform-specific considerations .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Authentication and authorization service installation .... . . . . . . . . . . . . . . . 72

Authentication and authorization service upgrade .... . . . . . . . . . . . . . . . . . . . 75

Backup and recovery of authentication and authorization .... . . . . . . . . . . . . . . . . 77

Authentication data ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Authorization data ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Empirical use cases ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

UNIX/Linux use cases ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Windows use cases ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

How to use the use cases ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Product troubleshooting tips ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Chapter 6 Symantec solution: UNIX/Linux use cases

Deploy Symantec products on UNIX/Linux .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Determine broker infrastructure ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

NetBackup use case ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Deployment platforms and operating systems .... . . . . . . . . . . . . . . . . . . . . . . . . . 89

Application server ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

NetBackup management servers ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Add a media server to a master server ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

NetBackup management client ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Enable access control on a NetBackup master server ... . . . . . . . . . . . . . . . . . . 99

Enable access control on a NetBackup media server ... . . . . . . . . . . . . . . . . . 108

Enable access control on a NetBackup client ... . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Environment with existing authentication hierarchy .... . . . . . . . . . . . . . . . 123

Upgrade NetBackup and shared components ... . . . . . . . . . . . . . . . . . . . . . . . . . . 123

CommandCentral Storage and Service use case ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Deployment platforms and operating systems .... . . . . . . . . . . . . . . . . . . . . . . . . 125

Application server ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

CommandCentral management server ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

CommandCentral Management agents ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132


CommandCentral-related upgrade .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Symantec License Inventory Manager use case ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136



SLIM management server ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

SLIM management agents ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140


SLIM-related upgrade .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

7Contents

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




Storage Foundation-related upgrade .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Chapter 7 Symantec solution: Windows use cases

Deploy Symantec products on Windows .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Determine a broker infrastructure ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Symantec License Inventory Manager use case ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153



Deploy the Symantec License Inventory Manager management

server on Windows .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Deploy SLIM management agents on Windows .... . . . . . . . . . . . . . . . . . . . . . . . 156


Symantec License Inventory Manager-related upgrade .... . . . . . . . . . . . . 158

NetBackup use case ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158



NetBackup management servers ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Adding a media server to the master server ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Installing and upgrading the NetBackup management client on

Windows .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Enabling access control on a NetBackup master server ... . . . . . . . . . . . . . 170

Enabling access control on a NetBackup media server ... . . . . . . . . . . . . . . . 177

Enable access control on a NetBackup client ... . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Environment with an existing authentication hierarchy .... . . . . . . . . . . . 190

Upgrading NetBackup and shared components ... . . . . . . . . . . . . . . . . . . . . . . . . 190

NetBackup Operations Manager use case ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191


NetBackup Operations Manager management server ... . . . . . . . . . . . . . . . . 192


NOM-related upgrade .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

CommandCentral Storage and Service use case ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197



CommandCentral Management servers ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Installing a CommandCentral management agent ... . . . . . . . . . . . . . . . . . . . . 203


CommandCentral-related upgrade .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Storage Foundation use case ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Contents8




Storage Foundation-related upgrade .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Appendix A Storage Foundation common procedures

Enabling a VCS cluster with authentication service ... . . . . . . . . . . . . . . . . . . . . . . . . 211

Setting up a VCS cluster with authentication service on

UNIX/Linux .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

Configuring a VCS cluster to use authentication service ... . . . . . . . . . . . . 213

Using Storage Foundation Management Server to manage VCS

clusters ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Setting up a VCS cluster with authentication service on Windows

.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Re-establishing the authentication service for a node in a VCS

cluster ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

Setting up a Storage Foundation Management Server with

authentication service ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Using SFMS Web-based interface to administer managed

hosts ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Common Veritas Volume Manager and Veritas File System

procedures ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Appendix B Infrastructure Core Services common procedures

About Infrastructure Core Services ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Private Branch Exchange .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

About Symantec Product Authentication Service ... . . . . . . . . . . . . . . . . . . . . . 228

About Symantec Product Authorization Service ... . . . . . . . . . . . . . . . . . . . . . . 233

Upgrading authorization .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Verify authentication setup .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

Verify authorization setup .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Add a new authentication broker ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

Backup and restore authentication data ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

Backup and restore authorization data ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Appendix C NetBackup common procedures

NetBackup access control parameters ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Verify NetBackup access control setup on the master server ... . . . . . . . . . . . . 246

About shared Veritas products and processes ... . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Verify NetBackup authorization database .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Verify NetBackup access control setup on media servers ... . . . . . . . . . . . . . . . . . 254

9Contents

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

Media Server valid credential verification .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Media servers accessible to the authorization database .... . . . . . . . . . . . . 256

Verify NetBackup access control setup on clients ... . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Shared Veritas product ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Client has valid credentials ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Authentication client libraries ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

Client authentication domains .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

Using a remote administrative client to manage the master

server ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Replacing the root broker on the NetBackup master server ... . . . . . . . . . . . . . . 262

NetBackup storage units ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

NetBackup policies ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

Successful NetBackup backup and restore ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

NetBackup and authorization .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

NetBackup tape device drivers ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273

NetBackup Java Windows administration console ... . . . . . . . . . . . . . . . . . . . . . . . . . . 274

NetBackup access control troubleshooting tips and messages ... . . . . . . . . . . . 275

Turn off NetBackup access control ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Unable to load libraries ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

Optional VxSS libraries not initialized .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

Library Initialization failed. Access denied (188) (MM status

188) ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

Unable to connect to authorization server ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

Appendix D CommandCentral Storage/Service commonprocedures

Verifying the CommandCentral Storage server setup .... . . . . . . . . . . . . . . . . . . . . . 279

Verifying the CommandCentral Service server setup .... . . . . . . . . . . . . . . . . . . . . . 282

Verifying the CommandCentral agents setup .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Add and modify access by user accounts ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

Replacing the root broker on the CommandCentral server ... . . . . . . . . . . . . . . . 285

Troubleshooting tips ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

Appendix E Symantec License Inventory Manager commonprocedures

Verifying the SLIM server setup .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Verification procedures for Windows and UNIX .... . . . . . . . . . . . . . . . . . . . . . . 296

Verifying the SLIM agent setup .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Replacing the root broker on the SLIM server ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

Demoting a root broker ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

SLIM troubleshooting tips ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

Contents10

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

Product directory structure ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Java runtime environment debugging .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Troubleshooting steps for Sybase ASA .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

Troubleshooting steps for Tomcat (VRTSweb) ... . . . . . . . . . . . . . . . . . . . . . . . . . 308

Set the debugging level of the Tomcat server ... . . . . . . . . . . . . . . . . . . . . . . . . . . 309

Debug the access point ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

Debug the push installation .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

Troubleshooting steps for Service Management Framework .... . . . . . 310

Error: Failed to get database connection .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Error: Authentication manager was not initialized .... . . . . . . . . . . . . . . . . . . 311

Error: Agent not running .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Error: Access point fails to start ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Error: Access point fails connect to server ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Error: Retries Exceeded. Could not connect to

HOST_NAME:RootSMF .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

Error: SLIM Web Console does not display on VRTSweb

console ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

Embedded access point is down .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

Agent-server communication failure ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

Server time-out during a force poll queue .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

Index

11Contents

Contents12

Introduction

This chapter includes the following topics:

■ About this Yellow Book

■ Who should use this Yellow Book

■ Scope of this document

■ About acronyms and definitions

■ About authentication and authorization

■ Customer benefits

About this Yellow BookYou can use this book to learn about the Symantec Product Authentication Service

(authentication) and the Symantec Product Authorization Service (authorization)

and how to integrate them with multiple Symantec software products. This book

describes general security concepts, public key infrastructure (PKI) security

concepts, the Symantec approach to implementing authentication and

authorization, and how to implement these solutions in your environment.

This book contains the following topics:

■ Overview of the Symantec Product Authentication Service and Authorization

Service

■ Integration of the authentication service and authorization service across

Symantec products

■ Deployment guidelines and best practices

■ Technical information regarding multiple Symantec product environments,

illustrated by Linux, UNIX, and Windows use cases

1Chapter

Difference between product guides and this Yellow Book

Every Symantec product includes user guides that describe the procedures that

integrate the product with the authentication and authorization services. However,

the user guides do not contain information on how those products behave when

they are deployed with other Symantec products.

In a multiple product environment, authentication and authorization services are

shared among many Symantec products. Each product may have a different

requirement for use with authentication and authorization. This Yellow Book

illustrates, with tested and certified use cases, approaches for deploying multiple

Symantec products along with authentication and authorization. These approaches

enable you to implement a variety of product configurations, across multiple

operating systems, in a single, secure environment.

Note: This Yellow Book is not a replacement for product documentation. Refer to

the appropriate installation, administration, and user guides for detailed

information about your Symantec product.

How this Yellow Book helps users

This book provides deployment guidelines, best practices, and use cases that can

help you plan and implement authentication and authorization across Symantec

products. You can choose a deployment configuration suitable for your

environment.

You can begin by deploying a single Symantec product with authentication and

authorization (if used by the product) to establish the infrastructure for your

environment. You can then sequentially add other Symantec products with

authentication and authorization by following the use cases.

Who should use this Yellow BookThere are three primary groups who can benefit by reading this Yellow Book. At

an enterprise level, the first group includes chief information officers (CIOs), chief

security officers, and security architects. The second group includes security

administrators and application administrators. The third group includes system

programmers.

Refer to Table 1-1 to learn about which chapters of this book pertain to you, based

on your job function.

IntroductionWho should use this Yellow Book

14

Table 1-1 Applicable sections to read

What to readRole

Individuals who are responsible for the security infrastructure within an enterprise and

the deployment of authentication and authorization services should read the first five

chapters of this book.

In Chapter 1, the Customer benefits section describes the value that authentication and

authorization add to the security of your organization.

Chapter 2 provides an overview of authentication.

Chapter 3 provides an overview of authorization.

Chapter 4 discusses the integration approach that is used by Symantec products that

integrate with authentication and authorization.

Chapter 5 defines the deployment guidelines and best practices that are suggested by

Symantec Corporation when deploying multiple products within an enterprise with

authentication and authorization enabled.

Chief Information

Officers

Security Officers

Security Architects

Security administrators and Symantec application administrators are typically responsible

for the deployment of Symantec products in their enterprise.

Chapter 3 and Chapter 4 provide information to understand the integration of authentication

and authorization across Symantec products.

Chapter 5 describes approaches that give security and application administrators an

understanding of how to plan and deploy Symantec products in their enterprise

environments.

Chapter 6 provides UNIX and Linux user cases.

Chapter 7 provides Windows use cases.

Refer to the appendixes for common verification procedures that can help you to verify

your environment.

Security

administrators

Application

administrators

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.

System programmers

Scope of this documentAs Symantec becomes familiar with the deployment complexity and architectural

demands on Symantec Product Authentication and Authorization Services within

an enterprise, we can share the guidelines and best practices that have been proven

and certified in the Symantec product testing lab. This Yellow Book disseminates

15IntroductionScope of this document

this testing information to our customers so that they can use our best deployment

scenarios in their own enterprises by following the documented procedures.

Figure 1-1 lists the Symantec products that integrate with authentication and

authorization. As new Symantec products complete their integration with

authentication and authorization services, they will be illustrated in a future

edition of this Yellow Book.

Figure 1-1 Products that use one or more Common Core Services

Symantec products covered in this Yellow Book edition

Each edition of this Yellow Book applies to the Symantec products that are certified

to successfully integrate with Symantec Product Authentication and Authorization

Services.

In this Yellow Book edition, management servers (such as NetBackup Master/Media

and CommandCentral) and authentication and authorization are configured as

standalone applications without clustering (high availability) functionality. The

high availability (HA) capability of these applications will be illustrated in a future

edition. Veritas Cluster Server is illustrated in this edition.

Table 1-2 lists the products documented in this edition.

IntroductionScope of this document

16

Table 1-2 Symantec products addressed in this edition

Management agent/clientApplication serverManagement serverCommon core services

CC Storage & CC Service

SLIM

NBU

SFCFS

SF Oracle RAC

SFWHA

VCS

NBU


SLIM

NOM

Authentication

NBUAuthorization

See “About acronyms and definitions” on page 18.

About future editions of this Yellow Book

Future editions of this Yellow Book will contain information on additional

Symantec products. The high availability functionality in management servers

(such as NetBackup and Veritas Application Director), and its integration with

high availability authentication and authorization services, will be added. The

failover capability of these management servers are configured by using Veritas

Cluster Server.

Table 1-3 lists products and product versions that are scheduled to be certified

to successfully implement authentication and authorization services.

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

Management agent/clientApplication serverManagement serverCommon core services


VAD

NBU

SFCFS

SF Oracle RAC

SFWHA

VCS

NBU (6.5, 6.0MP5,

5.1MP6, & 5.0MP7)

CC Storage

CMC

PureDisk

VAD

SFMS

VBR

Authentication

CC StorageNBU (6.5, 6.0MP5,

5.1MP6, & 5.0MP7)

CC Storage

Authorization

See “About acronyms and definitions” on page 18.

17IntroductionScope of this document

Topics to be covered in future editions

The following topics will be covered incrementally in future Yellow Book editions:

■ Quantifying root broker and authentication broker performance

■ Configuring with a firewall (authentication, authorization, and PBX ports)

■ Disaster recovery involving authentication and authorization

■ Using authentication and authorization with Veritas Volume Replicator

■ Integrating authentication and authorization into a VMware environment

■ Configuring authentication and authorization across Solaris zones

About acronyms and definitionsTable 1-4 lists acronyms that are used in this Yellow Book and their definitions.

Table 1-4 Acronym list

DefinitionAcronym

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

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

Common Service Framework (the distribution name for these products is ICS)CSF

Disk Storage UnitDSU

Fully Qualified Host Name (synonymous with FQDN—Fully Qualified Domain Name); for example,

jupiter.universe.com

FQHN

Generic Security Service Application Program InterfaceGSSAPI

Infrastructure Core Services (distribution name for AT, AZ, PBX, and SMF)ICS

Lightweight Directory Access ProtocolLDAP

Maintenance Pack (a Veritas product patch release)MP

NetBackup Access Control (VxSS integration with NBU)NBAC

NetBackup - NBU and NetBackup are synonymous in this documentNBU

NetBackup Operations ManagerNOM

Pluggable Authentication ModulesPAM

IntroductionAbout acronyms and definitions

18

Table 1-4 Acronym list (continued)

DefinitionAcronym

Veritas Private Branch Exchange version 1.2

Symantec Private Branch Exchange version 1.3

PBX

The root private domain repository stores information about all registered authentication brokers

(used only by the root broker)

PDR

Public Key InfrastructurePKI

Relational Database Management SystemRDBMS

Storage Area NetworkSAN

UNIX/Linux Veritas Storage Foundation products, including VxVM, VxFS, and VVRSF

Veritas Storage Foundation Cluster File SystemSFCFS

Veritas Storage Foundation for DB2SFDB2

Veritas Storage Foundation Management ServerSFMS

Veritas Storage Foundation for OracleSF Oracle

Veritas Storage Foundation for Oracle RAC (Real Application Cluster)SF Oracle RAC

Windows Storage Foundation products, including VxVM and VVRSFW

Veritas Storage Foundation High Availability on WindowsSFWHA

Symantec License Inventory ManagerSLIM

Service Management Framework (SLIM is the consumer)SMF

Secure Socket Layer protocol (each encrypted transaction generates a session key which is 128

bits)

SSL

Shared Storage Option (in the NetBackup context)

Single Sign-On (in the authentication context)

SSO

Veritas Application DirectorVAD

Veritas Backup ReporterVBR

Veritas Cluster ServerVCS

Veritas Process Automation ServerVPAS

Veritas Volume ReplicatorVVR

19IntroductionAbout acronyms and definitions

Table 1-4 Acronym list (continued)

DefinitionAcronym

Veritas File SystemVxFS

Veritas Security Services (synonymous with authentication service plus authorization serviceVxSS

Veritas Volume ManagerVxVM

Table 1-5 is an alphabetical list of each special term used in this Yellow Book

followed by its definition.

Table 1-5 Terms and definitions

DefinitionTerm

A program that accesses a Symantec service or function that is provided by another

program, called a Symantec application service.

application client

A Symantec application that is deployed on a computer that serves a specific purpose

for an enterprise. Synonymous with application service.

See “Application server” on page 54.

application server

A program that is contacted by, and provides services to, a Symantec application

client. Synonymous with application server.

application service

The method by which authentication is conducted for the principals within a specific

namespace that is defined by a domain type.

See “Authentication plug-ins and mechanisms” on page 30.

authentication mechanism

A component that is used by the authentication broker to validate the identities

within a particular domain.


authentication plug-in

An entity that has the ability to authenticate to Symantec Product Authentication

Service with a unique identity.

See “Authentication principal” on page 28.

authentication principal

Refers to the process of copying and saving files, directories, raw partitions, or file

systems to secondary storage such as tapes or disks.

backup

An agent whose function is to validate identities by using the appropriate plug-in.broker

A type of electronic identification card (such as a passport or a driver's license)

that verifies the identity of its holder, and binds the principal's name to that

principal's public key.

certificate

IntroductionAbout acronyms and definitions

20

Table 1-5 Terms and definitions (continued)

DefinitionTerm

Issues a product credential to the requesting authentication principal based on a

validity check from the registration authority.

certificate authority

A set of hosts that share a set of disks with software coordination.cluster

An entitlement to be recognized as an authenticated principal. A valid credential

includes a certificate and the principal’s private key.

credential

Logons performed on UNIX and Linux platforms.login

The procedure used to gain access to an operating system or Web console of an

application.

logon

See management client.management agent

The client binaries of a management server that is deployed on a client computer

to manage that client computer. Synonymous with management agent.

See “Management agent and client” on page 55.

management client

An application server that manages distributed agent/client computers.

See “Management server” on page 54.

management server

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 node

A NetBackup server that provides administration and control for backups and

restores for all clients within a master and media server configuration.

master server

NetBackup software that manages the storage devices and removable media.media manager

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.

media server

A distributed backup and restore application.NetBackup

A computer within a cluster.node

An application that determines whether authentication principals are valid.registration authority

A media server that is not the master server.remote media server

A Symantec product whose resources are protected by Symantec Product

Authentication and Authorization Services. An example of a Symantec product

would be NetBackup.

resource management

application

21IntroductionAbout acronyms and definitions

Table 1-5 Terms and definitions (continued)

DefinitionTerm

The process of retrieving saved files, directories, raw partitions, or file systems to

a system for online access.

restore

A digital identity (certificate) that is signed by its creator, usually a root broker or

certificate authority. See certificate.

self-signed certificate

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.

storage area network

About authentication and authorizationAuthentication is the act of proving whether an entity is who or what it declares

itself to be. An entity can be an application process that runs on a computer, a

user, or an application Web console. The authentication process is conducted on

an intranet of an enterprise through the use of a logon procedure. The logon

procedure is used to gain access to a Symantec application. The logon procedure

requires a valid user ID and password. To ensure that a user is authentic, a valid

combination of the user’s previously declared password and ID must be provided

for the user to be granted access.

For example, an enterprise can use the NISPLUS mechanism to authenticate users

to access a CommandCentral Web console. On the logon screen, a user must enter

a valid ID and password in the NISPLUS authentication domain. Assuming a valid

user named Bob wants to access the application through the Web console, the

validation of the Bob’s identity is as follows:

Authentication: Who are you?

Bob: I am Bob.

Authentication: Prove yourself.

Bob: OK. Here are materials to prove that I am Bob.

Authentication: You have proven yourself and I am convinced. Here is

a certificate to indicate that I believe you are Bob. Combine it with

your private key to make a valid credential to access the application.

The materials that are used in the preceding example could be a user name and

a password.

To enable intranet users to securely and privately exchange sensitive and

privileged information, users must be authenticated through the Symantec Product

Authentication Service by using the authentication mechanisms that are already

established within an enterprise. Successfully authenticated users communicate

IntroductionAbout authentication and authorization

22

through the secure channel and are coupled with the public-key infrastructure

(PKI) technology (by using public and private keys) for the secure communication

to take place. PKI is the default standard on the Internet to authenticate and

transmit data, such as credit card numbers and online bill payments between

consumers and e-commerce institutions.

In the Symantec PKI implementation, authorization is always preceded by

authentication. Authorization is the act of checking what an entity can do based

on predefined rules, then granting permissions on these critical resources to the

entity. Assuming a valid user named Bob wants to do NetBackup policy

manipulation, the granting of Access Control is as follows:

Bob: I have proven that I am Bob and I want to

manage NetBackup policies.

Authorization: I believe that you are Bob. Now, let me

consult the rules to see if you are allowed to perform NetBackup

policy manipulations.

Authorization: OK. Access Control on policy management is

now granted to you.

For example, suppose user Bob is also responsible for managing the NetBackup

application. The NetBackup administrator grants the policy manipulation privilege

only to Bob. After Bob successfully authenticates to the NetBackup application,

Bob is allowed only to create, delete, or modify NetBackup policies, and perform

backups and restores. Bob will not be able to manage other NetBackup tasks such

as device discovery, new volume pool creation, or other administrative tasks.

Customer benefitsMost 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,

23IntroductionCustomer benefits

CommandCentral, and Symantec License Inventory Manager products could be

three separate individuals.

Giving superuser privileges to all the individuals who manage Symantec products

can increase the chance of exposing the password of the superuser, and render

the systems vulnerable to malicious attacks. For example, a legitimate individual

may inadvertently write down the superuser password, and this information can

be obtained by an unauthorized employee. To reduce the risk of unauthorized

access or change to systems, the number of individuals who should be given

superuser privilege should be limited and detected by the security policy that is

established within your enterprise.

Using authentication services, a user without superuser privileges can manage a

Symantec product that typically requires a superuser to manage. To accomplish

this task, Symantec products should be enabled with the Symantec Product

Authentication and Authorization Services. Certain Symantec products, such as

Symantec License Inventory Manager (SLIM), are always installed with the

Symantec Product Authentication Service enabled.

Other Symantec products, such as NetBackup, by default, are not installed with

Symantec Product Authentication and Authorization Service enabled, and

additional configuration steps must be conducted to enable this functionality.

Throughout this Yellow Book, information on Symantec product integration with

Symantec Product Authentication and Authorization Services, deployment

guidelines and best practices, and UNIX/Linux and Windows use cases are

presented to illustrate the benefits that are provided by Symantec Product

Authentication and Authorization Services.

Symantec Product Authentication and Authorization offers the following

enterprise benefits:

■ Allow authenticated and authorized users to manage Symantec products

without superuser privileges. After granting the appropriate privileges of a

Symantec product to a user, such as Bob, that user could then perform the

tasks that only the superuser was able to perform. At the operating system

level, user Bob is only an ordinary user.

■ Limit the Operating System superuser access to a small number of individuals.

Users granted sufficient privileges can manage Symantec products. Therefore,

fewer individuals within the enterprise would need superuser access.

■ Assign a user to be an administrator for each Symantec product. In an

enterprise where separation of duties is required, users Bob, Gohan, and Bulma

could be assigned to exclusively manage NetBackup, Symantec License

Inventory Manager, and CommandCentral, respectively. At the Operating

System level, these three people are non-privileged users.

IntroductionCustomer benefits

24

■ Grant application roles (administrators, operators) to users selectively. To

restrict the privilege of a night shift NetBackup operator to only be able to

launch backup jobs, the NetBackup administrator assigns the appropriate role

to the operator’s login.

■ Use existing mechanisms (such as NIS, NISPLUS, UNIXPWD, Windows, or

LDAP) to authenticate users. In the logon session, the non-privileged user only

needs to pick the right authentication mechanism and the associated

authentication domain. NIS, NISPLUS, and UNIXPWD are applicable to

UNIX/Linux platforms. The Windows mechanism is specific to the Windows

platform. LDAP, when configured correctly, could authenticate UNIX/Linux

and Windows clients and users residing on UNIX/Linux and Windows. This

eases user management and does not require the enterprise administrator to

manage users separately across all Symantec products.

Authentication service is implemented by using PKI technology that uses public

and private key pairs to produce valid users' credentials. All messages are

encrypted with a session key and transmitted by using the secure sockets layer

(SSL) protocol. A user’s public key certificate is accessible openly over the network,

but the private key is exclusively known to the credential’s requestor. The

requestor’s private key is not transmitted over the network. In order for the

requestor to read the encrypted message, the encrypted message is first decrypted

by using the SSL session key and the requestor's private key must be used to read

the message.

Because the private key is not accessible on the network, the following types of

threats are avoided by those Symantec products that use Symantec Product

Authentication Services:

■ Casual network snooping (including secretly capturing passwords or other

confidential information, for example)

■ Communication replay attacks on your intranet

■ Session hijacking

Symantec products, such as CommandCentral, Symantec License Inventory

Manager, and NetBackup Operations Manager, have Web-based interfaces that

can access these application servers by using this secure protocol. Symantec

Product Authentication Service also offers single sign-on functionality for the

Symantec products that implement this service.

25IntroductionCustomer benefits

IntroductionCustomer benefits

26

Overview of the Symantec

Product Authentication

Service


■ Authentication service overview

■ Authentication hierarchy

■ Authentication components

■ How the authentication process works

■ Authentication expiry

Authentication service overviewThe Symantec Product Authentication Service is deployed as a hierarchy of

components consisting of a root broker at the top level, one or more authentication

brokers, and including multiple authentication entities.

The root broker implements the functionality associated with a registration

authority. The registration authority is the entity that sends requests to the root

broker to determine whether authentication entities (principals) are valid.

Authentication brokers implement the certificate authority functionality, which

follows a security model similar to the public key infrastructure (PKI). The

authentication brokers issue and sign the certificates that are used to prove the

identities of entities (such as computers, users, and services) that interact with

Symantec products. The certification authority issues the product credentials to

2Chapter

the requesting authentication entities (principals) based on the registration

authority's validity check.

All communications between brokers and entities use the secure socket layer (SSL)

protocol.

Authentication hierarchyThe authentication hierarchy is the physical arrangement, or structure, of the

Symantec Product Authentication Service components in your environment,

including the root broker, authentication broker, authentication principal, and

authentication entities. At the top level, the root broker can exist by itself or

co-exist with an authentication broker. The following figure illustrates a typical

authentication hierarchy.

Figure 2-1 lists the authentication hierarchy.

Figure 2-1 Authentication hierarchy

Authentication principal

An authentication principal is any entity that can authenticate to the Symantec

Product Authentication Service with a unique identity.

Overview of the Symantec Product Authentication ServiceAuthentication hierarchy

28

An authentication principal is a logical term that typically represents a human

user, but which can also be any of the following:

■ A computer

■ A service

■ A process (such as a command line interface)

Authentication principals are authenticated based upon their identities. Most

Symantec applications are represented by authentication principals, however,

identities that are associated with the authentication principals are distinct from

the operating system login account identities.

Authentication componentsSymantec 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.

29Overview of the Symantec Product Authentication ServiceAuthentication components

Figure 2-2 Root broker private domain repository

Authentication broker

An authentication broker differs from a root broker in that is serves as both an

intermediate registration authority and as a certification authority. As a

registration authority, it determines whether authentication principals are valid.

As a certification authority, it issues product credentials to the requesting

authentication clients (such as users or services) based on the registration

authority's validity check of client's authentication principals.

The certificate of an authentication broker is signed by the root broker. The

authentication broker authenticates only clients and it cannot authenticate other

authentication brokers. The authentication broker resides one level below the

root broker in the authentication hierarchy.

Figure 2-3 shows an authentication broker that is installed on a host machine and

contains a private domain for one of the application services provisioned by the

product.

Figure 2-3 Authentication broker private domain repository

Authentication plug-ins and mechanisms

An authentication plug-in is a component that is used by the authentication broker

to validate the identities within an authentication domain. A plug-in exists for

Overview of the Symantec Product Authentication ServiceAuthentication components

30

each supported authentication mechanism. A mechanism is a method by which

authentication is conducted for the authentication principals within a specific

namespace that is defined by a domain type (such as NIS, NISPLUS, Windows NT,

LDAP, or UNIXPWD). Plug-ins and domain types are synonymous and they have

one-to-one mapping with authentication mechanisms. An authentication

mechanism encapsulates all the details of the authentication algorithm that is

specific to each domain type. For example, the NIS plug-in can validate identities

with a NIS login and password combinations against a NIS database.

The following plug-ins are supported in various versions of the authentication

service:

■ NIS – NIS v2 (formerly called YP – Yellow Pages)

■ NISPLUS (NIS+) – NIS v3

■ UNIXPWD – Password on UNIX and Linux systems

■ LDAP – OpenLDAP and iPlanet implementations

■ GSSAPI – Generic Security Service Application Program Interface

■ NT – Windows NT domains and Active Directory (SSPI)

■ VX – Symantec Private Domain (used internally by the authentication service)

Not all plug-ins exist on all platforms. For example, NIS, NISPLUS, and UNIXPWD

are available only on UNIX and Linux systems. The NT plug-in is available only

on Windows. So an authentication broker that is configured on a UNIX system

cannot use a Windows specific plug-in to authenticate users on Windows. A

Symantec application client is typically required to authenticate against only one

or two domains.

Table 2-1 lists the plug-ins supported by the Symantec Product Authentication

Service versions on UNIX/Linux platforms.

Table 2-1 Plug-ins supported on UNIX/Linux

PAMGSSAPILDAPVXUNIXPWDNIS+NISAuthentication

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.

31Overview of the Symantec Product Authentication ServiceAuthentication components

Table 2-2 Plug-ins supported on Windows

GSSAPILDAPVXWindows NTAuthentication

4.1

4.2

4.3

Authentication entities

An authentication entity is any Symantec application that sends an authentication

request to the authentication service.

Application service

An application service is a program that is contacted by, and provides services

to, a Symantec application client. The authentication service validates its identity.

Application client

An application client is a program that accesses a Symantec service or function

that is provided by another program called a Symantec application service. An

example of a secured application client is the NetBackup Operations Manager

GUI. A Symantec application client uses the authentication service to validate

the identity of the user of that client.

Authentication user interface

The Symantec Product Authentication Service provides a management utility

(vssat) for the product administrator. To see the list of options that are available

in the vssat utility, from the command line, type vssat --help. On UNIX/Linux,

type man vssat to display the manual pages. The authentication service also

provides a graphical user interface.

On UNIX/Linux, the vssat utility is available in the /opt/VRTSat/bin directory.

On Windows, the default directory for vssat.exe is C:\Program

Files\VERITAS\Security\Authorization\bin.

Authentication broker communications port

The default port number that is used by the root broker or authentication broker

is 2821. You can use the vssat utility to change the default value.

Overview of the Symantec Product Authentication ServiceAuthentication components

32

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).

How the authentication process worksFor the application client and application service to communicate securely, the

client and service entities must first be vouched for by the authentication broker

through a secure communication channel.

The authentication broker validates the authentication principals that are

associated with these entities, then issues credentials to each of them.

After these principals are authenticated, an SSL encrypted connection is

established between the Symantec application client and the Symantec application

service. The client and service interact over the SSL connection, sending and

receiving messages as necessary until the client terminates the communication.

The root broker for the authentication broker can be installed on a remote system,

or on the same system as the authentication broker. Credentials that are delivered

to the client and service must contain the electronic signature of the root broker

through the intermediary authentication broker.

Figure 2-4 provides a high-level concept of the authentication process.

Figure 2-4 Authentication process flow

Symantec Product Authentication Service uses the secure sockets layer (SSL)

technology to provide secured communication among the Symantec application

client, the authentication broker, and the Symantec application service. During

33Overview of the Symantec Product Authentication ServiceHow 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.

Acquiring a product credential

On a system with an application client, a user on client A sends authentication

materials to the authentication broker. Materials include the public part of

credential, name, authentication domain, and possibly other material.

The authentication broker is an intermediate certification authority and it has a

credential that is signed by the root broker.

The authentication broker validates the user (identity) by selecting the appropriate

plug-in. The plug-in talks to the OS mechanisms or the VX authentication domain

type. The authentication broker determines that the user on client A is valid and

signs the public part of the credential for the user.

Figure 2-5 illustrates the credential request that the user on client A sends to the

authentication broker.

Figure 2-5 Client credential request

A credential, in a form similar to a passport or ID card, is created which vouches

for the identity of the user (holder). The credential is then sent back to the user

on client A through the SSL communication channel.

Figure 2-6 illustrates the process by which the signed public credential is sent to

the requesting authentication client.

Overview of the Symantec Product Authentication ServiceHow the authentication process works

34

Figure 2-6 Authentication broker response

A valid authentication (product) credential is then constructed by combining the

signed public credential with the user's own private key. The authentication

credential entitles the user (security principal) to be recognized as a valid identity

by Symantec products.

The authentication credential is stored and managed by the credential manager

on the system (client A) where the user resides. The authentication credential is

a single sign-on credential that is valid for all Symantec applications that

participate in a single sign-on environment.

Figure 2-7 illustrates the public key infrastructure (PKI) protocol where the user's

private key (including the user's name) is bound with the certificate created and

signed by the authentication broker.

Figure 2-7 illustrates the process by which the credential is sent to the

authentication client.

Figure 2-7 Authentication credential

35Overview of the Symantec Product Authentication ServiceHow the authentication process works

Authentication expiryEach certificate that the Symantec Product Authentication Service issues has a

validity period. After a credential expires it is no longer usable, and the credential

must be reacquired. There are different types of certificates, and each type has

its own validity period.

Table 2-3 lists authentication entities and their corresponding validity periods.

Table 2-3 Default expiry periods

Default expiry periodEntity

8 yearsRoot Broker

8 yearsAuthentication Broker

2 yearsService Principal

1 yearUser Principal

2 yearsAuthorization Service

1 yearNetBackup System

24 hoursNetBackup Login Session

8 hoursWeb Session

30 minutesCommandCentral Web Session

Overview of the Symantec Product Authentication ServiceAuthentication expiry

36

Overview of the Symantec

Product Authorization

Service


■ Authorization service overview

■ Authorization service components

■ Access control policy

■ Access control lists

■ How the authorization process works

Authorization service overviewSymantec Product Authorization Service (authorization service) is an access

control decision-making service. After authentication validates the identities of

entities (principals) working with Symantec software applications, the

authorization service is used to make access control decisions. The authorization

service determines which entities have permission to perform specific tasks on

specific resources. A resource is a uniquely-identified object. For example, a

NetBackup resource can be a tape library or a volume pool.

The authorization service works within the policies that are established by a

security product administrator. An administrator can view, set, or modify a policy

through the application user interfaces. These authorization policies are recorded

in a database. Access decisions are made by consulting this database. After making

3Chapter

an access decision, authorization allows each Symantec application to enforce

the decision.

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

Figure 3-1 Authorization overview

Authorization service componentsSymantec Product Authorization Service contains the following components.

■ Authorization service

■ Authorization client

■ Access control information data repository

■ Master authorization service

Overview of the Symantec Product Authorization ServiceAuthorization service components

38

■ Local authorization service

■ Resource management application

■ Authorization group or namespace

■ Authorization user interface

■ Authorization service communication port

Authorization service

The authorization service makes access control decisions for authentication

entities (principals) after validating their identities. The authorization service

component enables a product security administrator to create and manage the

access control entries and other aspects of the Symantec Product Authorization

Service.

Authorization client

An authorization client runs on a host that requests an access control decision

from the authorization service. For example, on a host that has a NetBackup media

server, the authorization client uses the main authorization database on the

master server to allow the media server to perform an authorization check.

Access control information data repository

The data repository is a database that maintains the master copy of the

authorization service. The database contains the information required to make

authorization decisions. This information includes data on the resources that are

advertised by Symantec resource management applications (service access control

information), and data on the resources that are used by authorization

(administration access control information).

Figure 3-2 shows the structure of this type of data repository.

39Overview of the Symantec Product Authorization ServiceAuthorization service components

Figure 3-2 Authorization data repository

Master authorization service

The Master authorization service holds and maintains the central access control

information data repository. In a distributed authorization environment, where

local authorization servers exist, certain information from the master ACL data

repository is periodically copied to, and synchronized with, the Local Authorization

Server.

Local authorization service

The local authorization service is the host that holds and maintains a read-only

copy of access control information, which has been imported from the master

access control information data repository. Periodically, the local information is

synchronized with the information in the master repository.

Resource management application

This component is a Symantec product whose resources are being protected by

Symantec Product Authorization Service. Resource management applications are

made up of application clients and application services. They perform the following

tasks, related to the Symantec Product Authorization Service:

■ Advertise the existence of the resource they want to protect. This is necessary

because authorization does not have its own discovery function.

Overview of the Symantec Product Authorization ServiceAuthorization service components

40

■ Ask the authorization service to make an access control decision for the

required service requests, and then enforce the decision by applying predefined

rules or policies.

Authorization group or namespace

A collection of entities (such as users). Entities in a namespace can use different

authentication domains. For example, user vegeta can employ the UNIXPWD

domain type, while user trunk employs the NISPLUS domain type. Any

authenticated entity is then granted the authorization privileges based on the

policy that is defined for the group.

Authorization user interface

The Symantec Product Authorization Service provides a management utility

(vssaz) for the product administrator. To see the list of options that are available

in the vssaz utility, from the command line, type vssaz --help. On UNIX/Linux,

type man vssaz to display the manual pages. The authorization service also

provides a graphical user interface.

On UNIX/Linux, the vssaz utility is available in the /opt/VRTSaz/bin directory.

On Windows, the default directory for vssaz.exe is located at C:\Program

Files\VERITAS\Security\Authorization\bin.

Authorization service communication port

The Symantec Product Authorization Service default communication port number

is 4032. You should specify this port number when you connect to the authorization

service.

Access control policyAn access control policy (ACP) is a set of rules that define how application resources

are to be protected from unauthorized use. Specifically, the policy states the

permissions that an authenticated entity (such as user) can have over secured

objects. For NetBackup, the ACP is defined as individual permission groups or

namespaces. NetBackup predefines five namespaces (such as NBU_Operator and

NBU_Admin). The security administrator assigns entities to each namespace. When

an authenticated entity tries to use a secured object, the resource management

application (such as NetBackup) invokes the decision-making service of

authorization. The authorization service determines the access rights of the entity

and returns its decision to the application to be enforced.

41Overview of the Symantec Product Authorization ServiceAccess control policy

See “NetBackup and authorization” on page 270.

Access control listsAn access control list (ACL) is a collection of zero or more entries within an access

control policy (or permission namespaces). Each entry associates an authenticated

entity with a specific permission to perform tasks as defined by the access control

policy. For example, the entities that are assigned to the NetBackup NBU_Operator

permission namespace have only the ability to mount or unmount tapes.

NBU_Admin permission namespace allows the assigned entities to have

NetBackup’s administrative privileges.

How the authorization process worksFor Symantec management applications that are integrated with Symantec Product

Authorization, the product's security administrator determines which Symantec

application resource to protect. The security administrator then configures the

access control rules for the resources that are used by the protected applications.

When an entity wants to use a protected application resource, it goes through the

following authorization steps:

1 The user logs on, is authenticated, and allowed to start accessing a resource

management application.

2 The resource management application requests permission for an entity

(principal) to access a resource.

3 The authorization service consults established access control policy, and

checks the access control list to see whether the requested access is allowed.

4 The authorization service passes its decision back to the protected application.

5 The resource management application enforces the decision made by

Authorization.

Overview of the Symantec Product Authorization ServiceAccess control lists

42

How authentication and

authorization are used

across Symantec products


■ Introduction

■ Implementing one authentication hierarchy in your enterprise

■ Using the authentication service for secure communication

■ Assimilating authentication service into your enterprise

■ Using the authorization service for access control

IntroductionDeploying 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.

4Chapter

Implementing one authentication hierarchy in yourenterprise

The authentication hierarchy to which the authentication brokers belong should

also be planned according to the needs of your enterprise. Ideally, one

authentication hierarchy is sufficient and preferred. Within an authentication

hierarchy, authentication brokers can be set up across UNIX/Linux and Windows

platforms.

The root broker in the authentication hierarchy holds the absolute power on

registration and certification and it has the ultimate authority over the validity

of a certificate that is issued by an authentication broker to an authenticating

entity. Authentication brokers are the intermediary registration and certification

authorities. Their role is to authenticate client entities that must communicate

with the products' application services.

Authentication brokers that are created in separate authentication hierarchies

maintain distinct root certificates. Certificates that are from different

authentication hierarchies are not compatible. A secure communication channel

between an application client and an application service cannot be established

when the authentication broker used by the client and service are not descended

from the same root. Therefore, it is not possible for a mutual entity on a system

with the application client to access a Symantec application service.

For this reason, only one authentication hierarchy should be used throughout

your enterprise. If a root broker is created implicitly through the installation of

a product server (either management or application), you are creating a new

authentication hierarchy that is incompatible with any existing hierarchies.

See Figure 2-4 on page 33.

Using the authentication service for securecommunication

The Symantec Product Authentication Service vouches for the identities of the

application client and application service and issues certificates to these entities.

After a valid product credential is established by these entities, a secure

communication channel is created between the requesting client and the

application service. The application client can be on the system with the application

service, or on a different system.

It is recommended that each Symantec management server that is integrated

with authentication services configures an authentication broker on the same

system as the management server. To exclusively configure an authentication

How authentication and authorization are used across Symantec productsImplementing one authentication hierarchy in your enterprise

44

broker for a management server (such as NetBackup or CommandCentral), typically

a dedicated system with the management server and an authentication broker is

set up. All the management servers that are illustrated in this Yellow Book have

an accompanying authentication broker.

Besides the authentication broker, a Symantec management server must also

create one or more private authentication domains. For example, NetBackup

creates the NBU_Machines private domain that is used to hold all the NetBackup

related authentication principals (clients, master, and media). Authentication

entities (such as users) that want to establish a login session must authenticate

to the authentication broker that created the NBU_Machines private domain, or

to another authentication broker that resides in the same authentication hierarchy.

Other Symantec products, such as CommandCentral, have created the cc_users

authentication domain for the CommandCentral users to login.


Upgrading authentication service in your enterprise

On the system that has a product's management server, you can install

management agents or clients of another management server. For example, on

the system with a NetBackup management server, you can install the

CommandCentral management agent. The management server and management

agents or clients may require a different version of the authentication service.

Upgrading authentication service for a Symantec product may involve a

compatibility issue for other Symantec products. Before you upgrade the

authentication, verify that the new version is compatible with the other Symantec

products that are installed on the system. It is a good practice to maintain a test

environment in your data center and use it for testing new software releases or

maintenance packs before you deploy the software to your production

environment.

Different versions of the authentication service may be required by a management

server and management agents or clients that are deployed on a system. In this

situation, the highest version of the authentication service should be used on the

system. An approach to deploy authentication service across Symantec products

is described in Chapter 5. Deployment guidelines and best practices that are

common and applicable to most enterprises are illustrated. For specific product

use cases, refer to Chapter 6 (UNIX/Linux) and Chapter 7 (Windows) for detailed

information.

45How authentication and authorization are used across Symantec productsUsing the authentication service for secure communication

Assimilating authentication service into yourenterprise

The tables in the following sections list the authentication plug-ins that are

supported by Symantec products. Enterprises that support one or more of these

authentication mechanisms make it possible to deploy Symantec authentication

services. This allows the application servers and clients of the Symantec products

that are integrated with authentication services to reuse the authentication

infrastructure for existing users and groups in your enterprise.


NetBackup

NetBackup is integrated with the following common core services product. Refer

to the use case chapters to find out which specific version of this product has been

tested.

■ Authentication

Table 4-1 lists plug-ins supported by NetBackup on Windows and UNIX/Linux

platforms.

Table 4-1 Plug-ins supported by NetBackup

PAMGSSAPILDAPWindowsUNIX/LinuxNBU

NTUNIXPWDNISPLUSNIS

6.0MP4

NetBackup Operations Manager

NetBackup Operations Manager is integrated with the following common core

services product.

Refer to the use case chapters to find out which specific version of this product

has been tested.

■ Authentication

Table 4-2 lists plug-ins supported by NetBackup Operations Manager on Windows

and UNIX platforms.

How authentication and authorization are used across Symantec productsAssimilating authentication service into your enterprise

46

Table 4-2 Plug-ins supported by NetBackup Operations Manager

PAMGSSAPILDAPWindowsUNIXNOM

NTUNIXPWDNISPLUSNIS

6.0MP4

Veritas Storage Foundation

Veritas Storage Foundation is integrated with the following common core services

product. Refer to the use case chapters to find out which specific version of this

product has been tested.

■ Authentication

Table 4-3 lists plug-ins supported by Veritas Storage Foundation on UNIX/Linux.

Table 4-3 Plug-ins supported by Veritas Storage Foundation on UNIX/Linux

PAMGSSAPILDAPWindowsUNIX/LinuxSFCFS

SFOracle

RAC

VCS

NTUNIXPWDNISPLUSNIS

4.1MP1

5.0

Table 4-4 lists plug-ins supported by Veritas Storage Foundation on Windows.

Table 4-4 Plug-ins supported by Veritas Storage Foundation on Windows

PAMGSSAPILDAPWindowsUNIX/LinuxSFWHA

NTUNIXPWDNISPLUSNIS

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.

47How authentication and authorization are used across Symantec productsAssimilating authentication service into your enterprise

Table 4-5 Plug-ins supported by CommandCentral Storage

PAMGSSAPILDAPWindowsUNIX/LinuxCC

StorageNTUNIXPWDNISPLUSNIS

4.2FP1

4.3

Table 4-6 lists plug-ins supported by CommandCentral Storage.

Table 4-6 Plug-ins supported by CommandCentral Service

PAMGSSAPILDAPWindowsUNIX/LinuxCC

ServiceNTUNIXPWDNISPLUSNIS

4.2FP1

Symantec License Inventory Manager

The following version of Symantec License Inventory Manager (SLIM) is integrated

with the following common core services product. Refer to the use case chapters

to find out which specific version of this product has been tested.

■ Authentication

Table 4-7 lists plug-ins supported by SLIM.

Table 4-7 Plug-ins supported by Symantec License Inventory Manager

PAMGSSAPILDAPWindowsUNIX/LinuxSLIM

NTUNIXPWDNISPLUSNIS

4.0.4

Using the authorization service for access controlThe Symantec Product Authorization Service is an access control service. After

the authentication service validates the identities of entities (principals) working

with Symantec products, the authorization service determines whether the

validated entities have the authority to perform tasks on protected resources.

The authorization service works within the authorization policies that are

established by the product's security administrator. An administrator who wants

How authentication and authorization are used across Symantec productsUsing the authorization service for access control

48

to view, set, or modify policy can do so through the product user interface. The

authorization service provides a database to record the authorization policies

against which access decisions are made. After making an access decision, the

authorization service allows each Symantec application to enforce that decision.

NetBackup

In this Yellow Book edition, the capability of the authorization service is

demonstrated through NetBackup Access Control. The NetBackup management

server creates a private authentication domain, SERVICES, that holds the

authentication principal for NetBackup's authorization related activities. An

approach to deploy authorization service with NetBackup is described in Chapter

6, UNIX/Linux use cases, and Chapter 7, Windows use cases. Guidelines and best

practices that are common and applicable to most enterprises are illustrated.


■ Authorization

Refer to the use case chapters to find out which specific version of this product

has been tested.

49How authentication and authorization are used across Symantec productsUsing the authorization service for access control

How authentication and authorization are used across Symantec productsUsing the authorization service for access control

50

Deployment guidelines and

best practices


■ Multiproduct deployment approach

■ Broker architecture determination

■ Planning for authentication and authorization in your enterprise environment

■ Authentication and authorization administration

■ Backup and recovery of authentication and authorization

■ Empirical use cases

■ Product troubleshooting tips

Multiproduct deployment approachDeploying Symantec products with Symantec Product Authentication and

Authorization requires careful analysis and planning. Your business requirements

should dictate the basis of both the security architecture and the implementation

approach. It is recommended that you take time to translate these requirements

into a master scheme with both short-term and long-term plans and deliverables.

A phased approach has proven to be effective in the deployment of Symantec

Product Authentication and Authorization.

This chapter contains framework and configuration information you can use as

guidelines when you design and create an implementation plan for your enterprise.

Refer to the following sections for an example of how an enterprise designs a

high-level plan and then translates it into a diagram.

5Chapter



The following Symantec products are targeted for deployment and are illustrated

with the authentication and authorization products:

■ NetBackup

■ NetBackup Operations Manager

■ CommandCentral

■ Storage Foundation with Veritas Cluster Server

■ Symantec License Inventory Manager

Figure 5-1 shows generic enterprise security deployment scenarios.

Deployment guidelines and best practicesMultiproduct deployment approach

52

Figure 5-1 Generic enterprise security deployment scenario

The objective is to design a phased approach to the implementation of all Symantec

products in an enterprise with authentication and authorization enabled. Issues

to consider include defining the number of authentication domains, whether one

root broker is sufficient, the number of authentication brokers, and the distribution

of application servers and management agents/clients.

53Deployment guidelines and best practicesMultiproduct deployment approach

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 practicesMultiproduct deployment approach

54

server installed. For convenience, NOM may be installed and configured on the

same system as the NetBackup master management server.


On a system that has a management server (such as SLIM, NetBackup, or

CommandCentral), an authentication broker is required and should be configured

to point to either a local root broker or an existing authentication hierarchy on a

remote system. Each of these management servers requires an authentication

broker to be present on the same system as the management server.

Management agent and client

For a management server to manage a client computer, the product’s client or

agent portion of the software must be installed on the client’s computer. A client

must be associated with a specific management server by performing the necessary

configuration either during or after the installation.

NetBackup refers to its clients as client. The other Symantec products refer to

NetBackup clients as agent. On a client computer, it is permissible to have

NetBackup client, CommandCentral and License Inventory Manager agents

installed.

On systems that have either management agents or clients installed, typically,

the client component of the Symantec Product Authentication and Authorization

should be sufficient. However, it is permissible to configure a SLIM management

agent on a system that has the NetBackup management server.

Broker architecture determinationIn an authentication hierarchy tree, there is only one root broker that resides at

the top level, and is validated with a self-signed credential. Each root broker is

uniquely identified by a 40-byte electronic signature called a root hash. You can

use the command vssat showbrokerhash to view the root hash. Root brokers

cannot have the same root hash.


A root broker can be installed and configured on a UNIX/Linux or Windows

platform. The root broker authenticates a group of authentication brokers, signs

their certificates, and maintains the root private domain repository (PDR) to track

these authentication brokers.




55Deployment guidelines and best practicesBroker architecture determination

There may be a number of authentication brokers in the authentication hierarchy

tree one level below the root broker. The authentication broker serves as an

intermediary (between the root and the authenticating entities) registration

authority and a certification authority that can authenticate management servers,

management agents, or clients, users, and application services.


An authentication broker cannot authenticate other authentication brokers. Each

authentication broker has an authentication PDR that stores the management

server domains such as NetBackup, VCS, CommandCentral, and others. Associated

with each authentication broker are various plug-ins (such as NIS, NISPLUS, or

Windows NT).

Figure 5-2 shows an authentication broker configured on UNIX and Windows,

respectively, that authenticates with a platform-specific plug-in (such as NISPLUS

and Windows NT).


Most of the management servers that are illustrated in this Yellow Book require

an authentication broker to be configured on the same system as the management

server. An authentication broker can be installed and configured on UNIX/Linux

or Windows platforms. As depicted in the following figure, you can have a root

broker on Windows or UNIX/Linux, and authentication brokers on UNIX/Linux

and Windows. Each authentication broker is configured with a platform-specific

plug-in (such as NISPLUS or Windows NT) to authenticate users.

Figure 5-2 shows root broker with heterogenous authentication brokers.

Deployment guidelines and best practicesBroker architecture determination

56

Figure 5-2 Root broker with heterogenous authentication brokers

The business requirements of an enterprise have been formulated into a high-level

layout.


In this example, a pilot project is initiated by an enterprise to decide the security

infrastructure, and to choose an approach to implement all the Symantec products

with Symantec Product Authentication and Authorization. The management

servers are implemented on systems that run Windows. Application servers,

management agents or clients are deployed on systems that run Windows, HP-UX,

and Red Hat operating systems.


Symantec License Inventory Manager is the first Symantec product to be deployed.

The SLIM installation script installs and configures a root broker plus an

authentication broker on the same system as the SLIM management server. All

the SLIM users accessing the SLIM Web console should be authenticated by using

a SLIM authentication principal. SLIM server has management agents deployed

on Windows, HP-UX and Red Hat platforms.

Next, NetBackup is installed and configured. For the NetBackup management

server, the master server is configured on Windows, and it has Media servers on

Windows, HP-UX, and Red Hat. On the client side, (management agents or clients)

application servers are configured on Windows, HP-UX, and Red Hat. An

authentication broker is configured on the system that has the master management

server and possibly on other systems that have media servers. These

Authentication brokers all point to an existing authentication hierarchy that is

created by the SLIM deployment.

Similarly, CommandCentral is deployed. The CommandCentral management

server is on Windows. On the client side, management agents/client application

servers are deployed on Windows, HP-UX, and Red Hat. On the systems that have

the NetBackup and CommandCentral management servers, respectively, an

authentication broker is configured on each system that points to an existing

authentication hierarchy that is created by the SLIM deployment.

The security architect of the enterprise has decided on the single authentication

hierarchy approach. All the authenticating entities (such as users) on UNIX/Linux

management agents and clients should be assigned to authentication brokers that

are configured on UNIX/Linux platforms. Similarly, all authenticating entities on

Windows will be assigned to authentication brokers that are configured on

Windows.

On UNIX/Linux, authenticating entities (such as users) on management agents

and clients are assigned to use one of the plug-ins (such as UNIXPWD, NIS, or

NISPLUS). Similarly, a Windows plug-in (such as Windows NT) is assigned to the

authenticating entities that reside on Windows management agents and clients.

To anticipate future growth, multiple authentication brokers are set up to evenly

distribute the management agents and clients to the available authentication

brokers.

You could set up additional authentication brokers on systems that have the

NetBackup Media servers.


In the previous figure, for example, suppose that in your enterprise, NetBackup

management server has a media server on Windows, HP-UX, and Red Hat. On

each of these systems, the Symantec Product Authentication and Authorization

Service client components are required.


58

Promoting the authentication client on these systems to an authentication broker

should be straightforward. You can then use the authentication brokers that are

configured on NetBackup media servers to authenticate the users on NetBackup

management clients, or some other management agents on the same platform.

For example, all the authenticating entities (such as users) on the HP-UX

NetBackup management clients are to be authenticated by the authentication

broker that is configured on the HP-UX media server. Similarly, all the users on

Red Hat NetBackup management clients can be assigned to the authentication

broker on Red Hat media server.

In the current edition of this Yellow Book, all the demonstrations are illustrated

by using a single root broker (either on UNIX/Linux or Windows). In the

UNIX/Linux use cases chapter, the root broker is configured on Solaris, and

authentication brokers are configured on Solaris, AIX, and Windows. In the

Windows use cases chapter, the root broker is configured on Windows, and

authentication brokers are configured on Red Hat, HP-UX, and Windows.

Root and authentication broker placement

In an enterprise that deploys Symantec products on heterogenous platforms (such

as Windows, Solaris, and Red Hat), it is recommended that the root broker be

placed on the platform that gets used the most. If 65 percent of the systems are

running Windows, then Windows is the preferred platform on which to deploy

the root broker. Other factors may also determine the physical placement of the

root broker.

See “Isolated root broker” on page 61.

After a root broker is successfully deployed, you need to configure an

authentication broker on Windows and another authentication broker on

UNIX/Linux to meet the demand of authenticating entities in a heterogeneous

environment. For example, the authenticating entities that are on Windows would

most likely be assigned to an authentication broker on Windows. Refer to the

following figure for an illustration of how you can place the root and authentication

brokers.

Figure 5-3 shows root and authentication broker placement.


Figure 5-3 Root and authentication broker placement

In an enterprise that has a large number of authenticating entities (such as users)

dispersed over many management agents and clients, it is recommended that you

configure multiple authentication brokers to spread these authenticating entities

over the authentication brokers for load balancing. If an authentication broker

on a system is authenticating too many users and a catastrophic hardware failure

occurs on the system, all the users will be without an authentication broker. In

addition, the authentication broker's latency increases as demand on the

authentication broker goes up.

When deciding the number of authentication brokers to configure, it should be

based on the number of mechanisms (plug-ins) that are used in the enterprise. If

an enterprise users NISPLUS, UNIXPWD, and Windows (NT) mechanisms, an

authentication broker should be setup on a separate system for each of these

plug-ins. Each of these systems could also have a Symantec product (such as

NetBackup media server) configured.

It is also recommended to base the allocation on the usage of the authentication

plug-in. If a majority use a NISPLUS plug-in, it is ideal to have multiple

authentication brokers on UNIX/Linux configured with the NISPLUS plug-in to


60

share the load. For example, if there are four production systems in a data center

with over three thousand NISPLUS users on each system, it is best to configure

an authentication broker on four separate systems and assign users on each of

the production systems to one of the authentication brokers.

Isolated root broker


On the system where the root broker is configured, there is no authentication

broker. This configuration allows an enterprise to isolate the root broker to a

secure system that is accessible to selected individuals with high privileges.

Figure 5-4 shows isolated root broker configuration.

Figure 5-4 Isolated root broker configuration

For the enterprises that want overall control over the creation of authentication

brokers, this configuration should provide added security to the environment. It

is not recommended to set up trust between the isolated root broker and another


root broker in the enterprise. Setting up trust between these two root brokers

may defeat the purpose of having a root broker on a secure system.

Multiple root brokers

It is recommended that every management server be configured on a system by

itself. The advantage to this configuration is that each management server incurs

a different load on the system, and a system failure would only disable the

management server on which it resides. Therefore, it is typical for an administrator

to configure the NOM management server on one system, and the NBU

management server on another. The administrator of the authentication service

would typically configure a root plus authentication broker on each system that

has a management server. The NOM management server could be configured on

UNIX, and the NBU management server could be configured on Windows.

Figure 5-5 shows management servers with private root broker.

Figure 5-5 Management servers with private root broker

Every root broker has a unique electronic signature. The authentication principals

that are established in one authentication hierarchy are not recognized in another

authentication hierarchy. For the NOM to manage the NBU Master server, a trust

(NBU trusting NOM) must be established between these two root hierarchies.

Establishing trust between root hierarchies can be problematic, and requires

advanced knowledge on the authentication product, and an understanding of the

configuration to perform all the steps correctly. After the trust has been


62

established at the root level, all the authenticating entities of the NBU

authentication hierarchy must be made aware of the NOM’s root electronic

signature by setting up trust and re-authenticating.

With initial planning, the administrator of authentication services of a hypothetical

enterprise has decided to use the layout illustrated in the following figure.


The authentication administrator installs the NOM management server on a

system with an authentication broker that points to an existing authentication

hierarchy. The NOM and NBU are now under the same authentication hierarchy,

which eliminates all the trust and re-authenticating activities. Therefore, the

possibility of forgetting to re-authenticate authenticating entities has been

eliminated.

At enterprise C, a business decision requires that NBU and CommandCentral

Storage management servers be installed and configured on separate systems

with a different authentication hierarchy. No interaction is expected or permitted

between entities in these root hierarchies. In this situation, the scenario depicted

in the following figure would be appropriate.


Brokers in different time zones

Root brokers and authentication brokers can span different time zones. The

authentication and authorization service performs all of its operations relative

to Greenwich Mean Time (GMT). The system time on your root brokers and

authentication brokers must be within five minutes of each other. You can have

the root broker located in Los Angeles and authentication brokers in Shanghai or

Singapore. It is important that the time zone and clock on the systems that have

either the root or authentication broker are configured correctly according to the

local time zone.

Broker availability

Without the root broker, you cannot create new authentication brokers and

establish trust between different authentication hierarchies. You can still use the

authentication brokers when the root broker is not available. The following figure

depicts a root broker that maintains a group of authentication brokers.


An administrator must be proactive on the status of the root broker and

authentication brokers. When a user fails to authenticate or log on to the Web

console, the first step is to verify the existence of the brokers.


Without the authentication broker, management agents or clients that are assigned

to that authentication broker can no longer obtain a new authentication certificate.

Credentials that were cached on the management agent or client would continue

to function until they expire.

Authentication brokers are used more frequently than the root broker. It would

be ideal to have multiple authentication brokers that are configured with the same

authentication plug-in as backup. When a hardware failure occurs on a system

that has an authentication broker, the authenticating entities (such as users) on

the affected authentication clients can be reassigned to other authentication

brokers that support the same plug-in.

For example, users on NetBackup management clients are authenticated by

authentication brokers that are distributed over multiple media servers. When a

failure occurs on one media server, users on the affected management clients can

be reassigned to an authentication broker that supports the same plug-in on

another media server.

To determine if the system already has a root broker configured, refer to the

following section for instructions and procedures.

See “Verify authentication setup” on page 235.

Root broker consolidation

Symantec products that have management servers should be deployed on separate

systems. The installation scripts that are distributed by SLIM and CommandCentral

typically configure a new authentication hierarchy (root plus authentication

brokers) on the system where these products are installed. This creates the

possibility of inadvertently having multiple authentication hierarchies in your

enterprise.

Having the authentication service of the SLIM and CommandCentral management

servers configured in two separate authentication hierarchies has undesirable

consequences. For example, when deploying the SLIM and CommandCentral

management agents on the same system, it is ambiguous which authentication

hierarchy the system should derive its authentication principal from. Because a

system can only hold an authentication credential from one root broker at a time,

there may be an authentication failure.

This section describes the procedures for consolidating multiple authentication

hierarchies into one.

In the following figure, SLIM and CommandCentral management servers are

configured with separate root brokers.



64

In the following figure, the SLIM management server is on UNIX (Solaris), and

the CommandCentral management server is on Windows.


The two root brokers can then be consolidated into one authentication hierarchy.

To consolidate the two root hierarchies into one, the authentication hierarchy

created by the CommandCentral management server should be kept intact, and

the SLIM authentication broker should be merged into the CommandCentral

management server authentication hierarchy. To merge the authentication broker

that is created for the SLIM management server on Solaris into the authentication

hierarchy that is created for the CommandCentral management server on

Windows, refer to the following section.

See “Replacing the root broker on the SLIM server” on page 300.

After the consolidation, the hierarchy is merged as shown in Figure 5-6.

Figure 5-6 Consolidated authentication hierarchy

After the SLIM authentication broker has been moved into the CommandCentral

management server authentication hierarchy, all the SLIM management agents

that were authenticated by this authentication broker must be re-authenticated


to use the electronic signature of the root broker in the CommandCentral

authentication hierarchy. The re-authentication must be performed on each

system that has the SLIM management agent. Therefore, when consolidating root

hierarchies, it is easier to move the authentication hierarchy that has the least

number of authentication brokers, and management agents or clients.

In the NetBackup and CommandCentral appendixes, similar procedures are

provided for these Symantec products to replace the local root broker with a root

broker on a remote host.

Planning for authentication and authorization in yourenterprise environment

In an enterprise or data center, some Symantec products may already be deployed

with Symantec Product Authentication and Authorization Service. The objective

of this section is to describe various scenarios and the approaches to deploying

multiple Symantec products with the authentication and authorization service

enabled in those scenarios.

For a list of the Symantec products that are covered in this edition and future

Yellow Book editions, refer to the following tables.



Typical enterprise scenarios

1 An enterprise is ready to deploy its first Symantec product. Information that

is presented in this and other chapters demonstrates the approach, guidelines,

and best practices to deploy the product with authentication and authorization

service enabled.

2 Several Symantec products are already deployed in the enterprise. Some of

the Symantec products (such as SLIM and CommandCentral) have been

deployed with Symantec Product Authentication. Other Symantec products

(such as NetBackup and VCS) are also deployed in the enterprise, but have

not been activated with the authentication and authorization (NetBackup

only) service. An approach is shown in this scenario to illustrate the

integration of Symantec Product Authentication and Authorization with

NetBackup and VCS.

Deployment guidelines and best practicesPlanning for authentication and authorization in your enterprise environment

66

3 Several Symantec products have been deployed in the enterprise, but none

of the deployed Symantec products are activated with authentication or

authorization. This scenario is similar to the NetBackup and VCS products

described in the previous scenario except that the authentication hierarchy

does not exist yet.

4 An enterprise has already deployed a Symantec product that is targeted in

the current edition (such as NetBackup) and the second edition (such as the

Veritas Application Director, VAD) together. If VAD is already configured

with authentication service, the approach is to place the authentication

brokers that are needed by the management servers (such as NetBackup) in

the authentication hierarchy created by the VAD. Otherwise, a new

authentication hierarchy will be created with an authentication broker for

the NetBackup.

For all scenarios, it is important that your enterprise formulates a project plan

and transforms it into a diagram similar to the one in the following figure.


In scenario number 1, assume that you already created the diagram. Next, prioritize

the Symantec products in the order of importance with respect to your business

requirements and then install them. It is highly recommended that you install

each management server on a system by itself. You can place the root broker on

the system where the first Symantec product with a management server is

installed. If your enterprise requires that the root broker be isolated to a separate

system, you should install and configure the root broker before you install the

first management server. In the cited figure, the first Symantec product listed is

SLIM and it is installed first with a root broker plus authentication broker.

The next Symantec management servers to install are NetBackup and

CommandCentral. On the systems where NetBackup and CommandCentral are

installed, the authentication brokers on these systems should belong to the

authentication hierarchy that is created by SLIM and located on the same system

as SLIM. After you have configured a management server and verified that it

works, you can begin the management client/agent installation. The application

server (such as SF Oracle RAC) that is enabled with authentication service should

have an authentication broker configured on each node of the cluster, and should

reside in the authentication hierarchy that is configured on the system with the

SLIM. Refer to the Windows use case chapter (Chapter 7) and the product

appendixes for complete illustration.

Certain Symantec products (such as SLIM) use the authentication service for

authenticating SLIM users. The SLIM installation script automatically configures

an authentication broker. The installation script automatically configures the

root broker plus authentication broker on the system where the SLIM server is

installed.

67Deployment guidelines and best practicesPlanning for authentication and authorization in your enterprise environment

Other Symantec products (such as NetBackup) require that the authentication

and authorization service be installed and configured separately after NetBackup

has been configured. A future version of NetBackup may change its installation

script to mimic the installation approach that is used by SLIM.

In scenario number 2, Symantec SLIM and CommandCentral management servers

are already installed and configured on separate systems. Presumably, these

management servers are enabled with the authentication service. NetBackup

management server is installed and configured on a standalone system but without

the authentication and authorization functionality. To enable the NetBackup with

authentication and authorization, refer to the NetBackup UNIX/Linux use cases

or Windows use cases.

See “NetBackup use case” on page 87.


In the UNIX/Linux use case, NetBackup uses a local root broker. In the Windows

chapter, NetBackup uses a remote root broker that is configured in an

authentication hierarchy that is created by another Symantec management server.

VCS application server is installed on a two-node cluster with SF for Oracle RAC

and the configuration did not enable authentication service. To enable the VCS

with authentication, refer to the Storage Foundation section in the UNIX/Linux

use cases chapter for instructions and procedures.

See “Storage Foundation use case” on page 143.

On Windows, to enable SFWHA with authentication service after the product is

installed, refer to the Storage Foundation section in the Windows use cases chapter.

See “Storage Foundation use case” on page 205.

In scenario number 3, start with the Symantec product that would benefit the

most from the functionality that is offered by the authentication and authorization

service. Deploy the root broker on the system where the Symantec product is

installed or on a separate system as required by the enterprise’s business decision.

An authentication broker is configured on the system that has the Symantec

product. Refer to Chapter 6 (UNIX/Linux), Chapter 7 (Windows), and appendixes

for instructions and procedures for enabling Symantec products with

authentication and authorization.

It is possible that an enterprise has configured a local root broker for each of the

Symantec management servers. For example, NetBackup, CommandCentral and

SLIM are configured with a local root broker. To consolidate all the root brokers

into one authentication hierarchy, refer to the root broker consolidation section

and the procedures listed in the NetBackup, CommandCentral, and SLIM

appendixes.

Deployment guidelines and best practicesPlanning for authentication and authorization in your enterprise environment

68

For scenario number 4, refer to Chapter 6 (UNIX/Linux), Chapter 7 (Windows),

and appendixes for instructions and procedures for enabling Symantec products

with authentication and authorization.

Authentication and authorization administrationThese are the typical tasks for administrators who are responsible for managing

the Symantec Product Authentication and Authorization. The following list is not

exhaustive:

■ Ensure that the authentication and authorization products are configured

according to each product’s specifications and meet the business requirements

established for your enterprise.

■ Regularly backup the operation data that is generated by these products. Verify

that the recovered data is usable and valid.

■ Define an upgrade procedure for the authentication and authorization products.

The upgrade is determined by the compatibility between the new version of

the authentication and authorization and the existing consuming Symantec

products. The consuming Symantec products that are already configured on

a system must be able to work with the upgraded version.

■ Monitor the critical services and avoid disruption to availability either directly

(the designated authentication broker has stopped) or indirectly (the

authorization could not authenticate because the authentication broker that

is needed by the authorization service is no longer available).

Authentication administrator responsibilities

Symantec Product Authentication maintenance consists of maintaining the

authenticating clients, the root broker, and all the authentication brokers that

are deployed in the enterprise.

One of the most important duties for an authentication administrator is to ensure

that the operational data of the root and authentication brokers are backed up

regularly by using a backup schedule that is designed by the enterprise.

See “Backup and recovery of authentication and authorization” on page 77.

The authentication administrator must decide the authentication domains that

the authentication entities (such as users) should use and therefore the

authentication brokers they should contact. An authentication domain is associated

with a specific authentication plug-in. For example, an authentication broker is

configured with an authentication domain that supports the NISPLUS plug-in.

For a user on NetBackup management client to use the NISPLUS plug-in, the

NetBackup administrator should use the product configuration tool (jnbSA on

69Deployment guidelines and best practicesAuthentication and authorization administration

UNIX/Linux and Administrative Console on Windows) to assign the user to contact

an authentication broker that has the NISPLUS authentication domain configured.

Setting up new authentication brokers and renewing authentication broker

credentials are the responsibility of the authentication administrator.

After a root broker is configured and working, it typically requires little

maintenance other than performing regular backups. To reinstall the root broker

that has an existing authentication broker and client hierarchy requires an

elaborate recovery process. This process requires a functional configuration of

the root broker that likely must be restored from backup.

An authentication administrator must ensure that all the authentication brokers

are available to their clients all the time. An authentication broker is contacted

by clients whenever a user or an application on a client system needs to

authenticate or renew a credential.

In an enterprise, authentication and credential renewal are normally the

responsibility of the application administrators who manage the Symantec

management servers such as (NetBackup, CommandCentral, and SLIM) that are

configured with the authentication product. If the administrators for these

Symantec products are different individuals, they must work together to define

a process to address the new installation and upgrade issues especially when the

authentication product is installed on a system that is shared by a management

server and agent/client of another Symantec product.

To verify that the Symantec products are configured with authentication, refer

to the server authentication procedures listed in the NetBackup, CommandCentral,

and SLIM appendixes.

Authorization administrator responsibilities

Symantec Product Authorization maintenance consists of maintaining the

authorization server, the access control information data repository, and

authorization clients that are deployed in the enterprise.

One of the most important duties for an authorization administrator is to ensure

that the access control information data repository of the authorization service

is backed up regularly by using a backup schedule that is designed by the

enterprise. The Backup and Recovery section in this chapter has detailed

procedures for performing the backup and recovery for the authorization product.

The authorization administrator must ensure that the authorization groups,

access control list, and permission sets are defined and maintained correctly. The

authorization administrator must work with other Symantec product

administrators to ensure that the service of an authentication broker is always

Deployment guidelines and best practicesAuthentication and authorization administration

70

available and that the service provided by the authorization product is available

to other Symantec products (such as NBU) that need it.

To verify that NetBackup is configured with authorization, refer to the NetBackup

appendix.

Platform-specific considerations

In this edition of the Yellow Book, the authentication and authorization services

are illustrated on Windows, Red Hat, Solaris, AIX, and HP-UX. Refer to the use

cases chapters for the operating system version that is used on each platform.

The installation guide distributed with the authentication and authorization

product include platform-specific information. To find out if the version of the

operating system installed on a system in your enterprise is supported by the

authentication and authorization, consult the product installation guide.

To authenticate a logon session that uses material such as user name and password,

Symantec Product Authentication Service needs an authentication plug-in that

should be available on the system or configured in the enterprise. A plug-in could

be the password security that is available on a system or the NISPLUS in the

enterprise. The authentication service supports many plug-ins that can be used

to authenticate entities (such as users). Some of these plug-ins are available on

UNIX/Linux exclusively and others are available only on Windows. Symantec

Product Authentication has a proprietary plug-in named VX and it is used

exclusively to authenticate services, daemons (processes), and clients of Symantec

products.


See “Assimilating authentication service into your enterprise” on page 46.

UNIX and Linux operating systems

Mechanisms such as NIS, NISPLUS, and UnixPWD are specific to UNIX and Linux

and will not work on Windows. In order for the Symantec Product Authentication

to use NIS or NISPLUS as the authentication plug-in, this service must be already

configured in the enterprise by the system administrator. On these platforms,

the UNIX password is the basic authentication plug-in that is available to the

Symantec Product Authentication for authenticating users. An authentication

broker uses the password mechanism that is on the same system as the broker,

and not a password file on any system.

Other plug-ins such as LDAP and GSSAPI are supported by Symantec Product

Authentication on these platforms. However, a Symantec management server

such as NetBackup must support these plug-ins before they can be used to

authenticate NetBackup users.


The setup of NISPLUS, LDAP and other mechanisms is outside the scope of this

Yellow Book. System administrators should refer to the appropriate product

documentation to configure these mechanisms and to verify that they work before

integrating these mechanisms with Symantec Product Authentication.

Windows operating system

Symantec Product Authentication supports the Windows NT (nt) plug-in. The nt

plug-in uses the Security Services Provider Interface (SSPI) on Windows. This

plug-in works with all the Symantec products that run on this platform to allow

for unified logon. On Windows, the authentication service supports LDAP and

GSSAPI.

Authentication and authorization service installation

Before you install the Symantec Product Authentication and Authorization Service

on a system, it is important that you read the appropriate Symantec product

installation guide and release notes to ensure that the system configuration meets

the operating system version and patch requirements.

The Symantec Product Authentication and Authorization Service has server and

client components. These components can be installed separately. On a system,

it is permissible to install the Client component of the Symantec Product

Authentication and Authorization. To install either the service/client or client

portion of the Symantec Product Authorization, the Authentication’s Client

component must be already installed or installed at the same time. The Symantec

Product Authorization depends on the Symantec Product Authentication. Client

installations do not require any product configuration. A system that has only

the service component is not a valid installation. The installation of the service

automatically installs the client component on most platforms. Some platforms,

such as Linux, may require the client component to be installed explicitly.

On systems that have Symantec management servers, the service and client

components of the Symantec Product Authentication are also installed. Each

management server requires an authentication broker (at the minimum) to be

configured on the local system. On systems that have either management agents

or clients, only the client component of the Symantec Product Authentication is

required.

On systems that have application servers, it is common to find either management

agents or clients (and possibly both). An application server (such as VCS) needs

an Authentication broker configured on each node of the cluster. On these systems,

application servers use the service and client components of the Symantec Product

Authentication. Management agents or clients would continue to use the client

component.


72

Certain management servers, such as NetBackup, use the Symantec Product

Authorization for Access Control. On a system that has this management server,

the service and client components of the Symantec Product Authorization are

installed. A NetBackup Media Server that is configured on a stand-alone system

also needs the client component of the Symantec Product Authentication and

Authorization.

When you install Symantec Product Authentication and Authorization, you should

first attend to the systems that are targeted for the management servers. Systems

that have application servers should be visited next and then followed by the

systems that have management agents and clients.

Refer to use cases chapters and follow the orders of installation illustrated for

various Symantec products.

Installing authentication service

Symantec Product Authentication can be installed in one of the following scenarios:

■ Install the root broker. The service and client components are installed. On

the same system where the root broker is installed, it is also permissible to

install an authentication broker.

■ Install an authentication broker on the system where a prominent Symantec

management server is planned. In this case, the root broker is remote on

another system. The Service and Client components are installed.

■ Install only the Symantec Product Authentication client (depending on the

Symantec application) on the system. Only the client component is installed.

Symantec Product Authentication Service (version 4.3 and later) can be configured

to use Symantec Product Private Branch Exchange (PBX). Before you enable PBX

for the authentication service, you must install and configure PBX.

Root broker installation

Installation of the Symantec Product Authentication with a root broker is usually

done by using one of the following methods:

■ Use the installation script that is distributed by the Symantec Product

Authentication to install and configure the root broker.

■ The installation script of a consuming Symantec product (such as SLIM) installs

the Symantec Product Authentication Service and configures the root broker

plus the authentication brokers.

In the version of NetBackup that is used in this Yellow Book edition, the Symantec

Product Authentication is not integrated with the NetBackup installation script.

Therefore, to prepare a system with the right brokers for NetBackup’s


implementation, the installation script distributed by the Symantec Product

Authentication must be used.

The installation script of other consuming Symantec products (such as SLIM)

install the Symantec Product Authentication Service and unconditionally configure

a root plus authentication broker on the local system. When in doubt, always refer

to the SLIM installation guide for up-to-date information. Other Symantec products

(such as NOM) have similar restrictions. Refer to the Windows use cases chapter

for installation procedures.


Authentication broker installation

The authentication broker mode installs an authentication broker on a machine

without the root broker. Select this option if a root broker is already installed

separately somewhere and there is a need to add a new authentication broker into

the existing authentication hierarchy.

Installation of the Symantec Product Authentication with an authentication broker

is usually done by using one of the following methods:

■ Use the installation script that is distributed by the Symantec Product

Authentication to install and configure an authentication broker

■ The installation script of a consuming Symantec product (such as

CommandCentral) installs the Symantec Product Authentication Service and

configures an authentication broker

In both installation methods, a remote root broker is assumed to be available and

the preparatory steps for the new authentication broker have been completed on

the system with the root broker. Refer to the use case chapters and follow the

illustrated installation procedures.


Client installation

The installation script that is distributed by the Symantec Product Authentication

is usually used to install the Authentication Client component. The Authentication

Client component can be installed without installing the service component.

The authentication client component is on systems that have either management

clients or agents.

Installing authorization service

Authorization depends on authentication. Therefore, before installing the

authorization service, the minimum requirement of the authentication service

(which is the client component) must be already installed and configured. The


74

authentication client component is usually present on systems that have either

management clients or agents.

The authorization service can be installed in either of the following scenarios:

■ Install the authorization service. The service and client components are

installed.

■ Install only the client (depending on the Symantec application) component on

the system.

Authorization service installation

Use the installation script that is distributed with the Symantec Product

Authorization Service to install and configure it.

The authorization service should be installed on the same machine as the

management server that needs it. Having the authorization service and

management server located on the same machine removes the overhead of network

latency that could occur if these two applications are located on two separate

systems.

The master copy of the authorization access control list repository is always found

on the system where the authorization service is configured. It is permissible for

a system with the authorization client component to keep a local copy of the access

control list repository. This setup can be established in an environment that has

a NetBackup media server that communicates securely with a master server on

two separate systems.

See “Verify authorization setup” on page 237.

Client installation

The installation script that is distributed by the authorization service should be

used to install the authorization client component. The authorization client

component can be installed without installing the service component. A system

that has the NetBackup Media server is required to install the authorization client

component.

Authentication and authorization service upgrade

All the Symantec products that are illustrated in this document use the shared

installation of the Symantec Product Authentication and Authorization Service.

A shared installation refers to a product (such as authentication or authorization)

that is installed and used by all the products.

On a system, different Symantec applications such as NetBackup management

server, SLIM management agent, and CommandCentral management agent could

be installed. Each of these Symantec applications requires a specific version of


the authentication service. Symantec products that require a later version of the

authentication service would cause the version on the system to be upgraded. In

this situation, the latest version of the authentication service should be used on

the system. On the system that already has a more recent version of the

authentication service, the installation script should skip the installation task.

Symantec Product Authentication and Authorization provide compatibility

between different versions of the product. It is permissible to have NetBackup

management server configured with Authentication version 4.2 to work with a

NetBackup management client on other systems that have Authentication version

4.3. A management agent or client with Authentication version 4.2 and a

management server that has Authentication version 4.3 is also a valid

configuration.

Authentication service upgrade

Upgrade of the authentication product is normally done through the installation

script that is distributed by using the Symantec Product Authentication Service

or one of the Symantec products.

On a system, before you upgrade the authentication service that is used by multiple

Symantec products, it is always prudent to test and verify that the new version

is compatible with all the existing consuming products before the upgrade is

performed on a production system.

The authentication service is usually installed or upgraded on a system by the

Symantec application that needs it. For example, a system has version 4.2 of

authentication service installed for the NetBackup management server. It is typical

to install other Symantec management agents or clients on a system with a

Symantec management server. The SLIM management agent uses version 4.3 of

the authentication service and installing the SLIM management agent on the

system would cause the authentication service to be upgraded from version 4.2

to 4.3.

Note: On a system that has multiple Symantec products that use authentication

service, the latest version of the authentication service should be installed. Later

versions (such as 4.3) of the authentication service are compatible with Symantec

products that were shipped with an earlier version (such as 4.2).

If the authentication service is to be upgraded on the system, the administrator

must perform the following tasks before conducting the upgrade:

■ Perform a full backup for the authentication product.

See “Backup and recovery of authentication and authorization” on page 77.


76

■ There should not be any authentication activities initiated from the system

while the authentication product is being upgraded. Shut down all the Symantec

applications that use the authentication service.

■ After the upgrade is complete, verify that the authentication components and

all the consuming Symantec products are working. Refer to the appropriate

product appendix in this book for detailed procedures on the verification steps.

It is important the authentication service administrator keep track of all the

Symantec products that use authentication on a system. Chapter 4 lists all the

Symantec products that are used with authentication. To determine if a Symantec

product installed on a system is enabled with authentication, refer to the respective

verification procedures provided for each Symantec product in the appendixes.

The combinations between versions 4.2 and 4.3 of the Symantec Product

Authentication Service is verified and tested in scenarios used in first edition

Yellow Book.

Authorization service upgrade

In the first edition Yellow Book, among all the consuming Symantec products that

are targeted, only NetBackup consumes the authorization service. Therefore,

during the process of upgrade, other than ensuring that the authorization service

functions correctly and that NetBackup also works with the upgraded version of

the authorization service, there is not much else to check.

Backup and recovery of authentication andauthorization

Symantec Product Authentication and Authorization has operational data that

is needed to ensure the proper working of these Symantec products. The

operational data is generated by each product over the course of its operation.

For the authentication product, operational data could be credential information

managed by the registration authority and credential manager. For the

authorization product, the access control list data repository contains a database

that stores all the permission sets. The operational data of these products needs

to be backed up regularly by using a backup schedule that is suitable to your

enterprise.

The operational data is present on systems that have the service and client

components installed and configured. The operational data of these products

needs to be backed up regularly. The backup schedules for the systems that have

the Symantec Product Authentication and Authorization should be part of the

overall backup infrastructure for your enterprise’s backup and recovery strategy.

77Deployment guidelines and best practicesBackup and recovery of authentication and authorization

On systems that have only the client component installed, backing up the product’s

binaries and libraries should be sufficient. It is safe to keep one backup copy of

the client component of a given product version. For example, ten systems on the

same platform have the client component of the Symantec Product Authentication

version 4.2.2.22 installed. Backing up the authentication client component from

one of these systems should be sufficient.

The backup and recovery procedures that are used in your enterprise must be

verified through a successful restore, followed by proving that the recovered data

can be used by the product. The ability to use the recovered data from a backup

is the key indicator to your backup strategy. As an example, the following steps

should be used as guide when implementing a backup and recovery strategy.

See “Successful NetBackup backup and restore” on page 269.

■ Authentication and authorization products are installed and configured on a

system.

■ A full backup for these products has been taken.

■ Shut down the original system and build another system (on the same platform

and operating system) with the same host name.

■ Recover the backup to the new system.

■ Verify that the services that were hosted in the original system are now

available through the new system.

Keeping track of all the systems in production environment that have

authentication and authorization products is a manual process. Administrators

who are responsible for these Symantec products should take charge and verify

that the critical components on all of these systems are being backed up.

Authentication data

On systems that have the root broker and authentication brokers, the operational

data, service and client components should be backed up. The authentication

product binaries and libraries should be included as part of the backup as well.

The operational data that is used by the root broker includes the registration

information, private domain repositories, and credential stores. Each

authentication broker also has operational data (which includes the private domain

repositories that are created by the Symantec application servers). Backup of this

data must be performed on a regular basis on all the systems that have the

authentication brokers.

It is important to keep track of all the production systems in your enterprise that

have the root broker and authentication brokers. To help with maintenance and

Deployment guidelines and best practicesBackup and recovery of authentication and authorization

78

administration, keep an up-to-date topology layout of all the systems in your

enterprise similar to that shown in the following figure.


There could be other applications on the same systems that need backup. Refer

to the following section for the actual steps and backup application to use.

See “Backup and restore authentication data” on page 239.

Authorization data

On the systems that have the authorization service, the access control list

repository and client components should be backed up. The authorization product

binaries and libraries should be included as part of the backup as well.

It is important to keep track of all the production systems in your enterprise that

have the authorization service. Keeping an up-to-date topology layout of all the

systems in your enterprise should help in maintenance and administration.


There could be other applications on the same systems that need backup. Refer

to the following section for the actual steps and backup application to use.

See “Backup and restore authorization data” on page 241.

Empirical use casesTo support the guidelines and best practices described in this chapter, deployment

scenarios are transformed into use cases that have been tested and verified in the

Symantec’s product testing lab. These use cases have been tried on both

UNIX/Linux and Windows platforms. Important procedures pertaining to the

integration of the Symantec Product Authentication and Authorization and the

consuming Symantec products are described in the UNIX/Linux and Windows

use cases chapters, respectively.

UNIX/Linux use cases

The UNIX/Linux use case chapter is for enterprises that have the majority of their

Symantec products deployed on UNIX/Linux platforms (Solaris, AIX, HP-UX, and

Red Hat). The Symantec application server, management server, and management

agent/client are validated on one of these UNIX/Linux platforms successfully. It

is a common occurrence to have both UNIX/Linux and Windows platforms in an

enterprise. To make the test environment more realistic and resemble a real

environment in an enterprise, the application server, management agent/client,

and NetBackup Media server on Windows are added to this test environment. In

79Deployment guidelines and best practicesEmpirical use cases

the UNIX/Linux use cases chapter, the documented procedures are applicable to

all the UNIX/Linux platforms unless otherwise noted.

Windows use cases

The Windows use cases chapter is targeted for enterprises that have chosen

Windows as their primary deployment platform. The application server,

management server, and management agent/client are validated on the Windows

platform. For enterprises that have mixed platforms, the use cases in this chapter

also include the Symantec products that are deployed on UNIX/Linux platforms.

The application server, management agent/client, and NetBackup Media server

that are deployed on UNIX/Linux are managed by the management servers on

Windows. The document procedures that are listed for the UNIX/Linux use cases

apply to other UNIX/Linux platforms (Solaris, AIX, HP-UX, Red Hat) unless

otherwise noted.

How to use the use cases

In the use cases chapters, beside the Symantec Product Authentication and

Authorization, the approach is to deploy one Symantec product at a time. All the

Symantec products that are illustrated can be deployed independently of each

other. The ultimate goal is to demonstrate an environment that has all of the

Symantec products installed and configured together with the authentication and

authorization enabled.

The information presented in the use cases chapters can best be used to guide an

application administrator to do the following:

■ Enable the authentication and authorization capabilities for an already installed

Symantec product (such as NetBackup).

■ Install and configure a new Symantec product into an existing enterprise

environment with the authentication and authorization capabilities enabled.

Some of the Symantec products in the existing enterprise environment may

have the authentication and authorization already configured.

Product troubleshooting tipsIn the last section of this document, there are appendixes devoted to an individual

or group of Symantec products. The information in the appendixes includes the

verification steps for Symantec products that are configured with authentication

and authorization, relocating the root broker, authentication operating procedures,

and troubleshooting tips.

Deployment guidelines and best practicesProduct troubleshooting tips

80

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.

81Deployment guidelines and best practicesProduct troubleshooting tips

Deployment guidelines and best practicesProduct troubleshooting tips

82

Symantec solution:

UNIX/Linux use cases


■ Deploy Symantec products on UNIX/Linux

■ NetBackup use case

■ CommandCentral Storage and Service use case

■ Symantec License Inventory Manager use case

■ Storage Foundation use case

Deploy Symantec products on UNIX/LinuxIn this use case, a predominantly UNIX/Linux-based enterprise has purchased

the following Symantec products to meet the growing demands of the company’s

computing capacity and capability:

■ NetBackup

■ CommandCentral Storage and Service


■ Storage Foundation for Oracle and Storage Foundation for Oracle RAC

Included with the purchase were Symantec core services products, such as Private

Branch Exchange, Symantec Product Authentication Service and Symantec Product

Authorization Service, and Common Core Services. One or more of these core

services products are used by the Symantec products listed above. After being

installed on a system, these core services products are shared by any Symantec

products that need them.

6Chapter

See “Multiproduct deployment approach” on page 51.

Figure 6-1 shows the deployment of Symantec products on Unix and Linux

platforms.

Figure 6-1 Deployment of Symantec Products on Unix/Linux

The approach chosen by the implementation team is to deploy these Symantec

products to their enterprise data center in three major phases. A new management

Symantec solution: UNIX/Linux use casesDeploy Symantec products on UNIX/Linux

84

server and the accompanying application server, and management agents or

clients are added in each phase.

The enterprise is also security conscious and the corporate security architect

decided to implement these Symantec products with authentication or

authorization. To help the enterprise security architect and security

implementation team achieve the objectives listed in the Customer Benefits section

in Chapter 1, this chapter provides step-by-step instructions on how to individually

configure these Symantec products with authentication and authorization

capabilities.

See Determine broker infrastructure for details on the layout for the authentication

brokers.

Determine broker infrastructure

Before starting the implementation, the enterprise security team developed the

broker schema and laid the foundation for the root and authentication brokers.

All the management servers listed in Figure 6-1 need an authentication broker

configured on the systems where the management servers are located.

Using the deployment guidelines and best practices discussed in Multiproduct

deployment approach, the enterprise security team maps the Symantec products

previously listed products into the authentication hierarchy listed in the following

figures.


Figure 6-2 shows the placement of root and authentication brokers on Unix/Linux.

85Symantec solution: UNIX/Linux use casesDeploy Symantec products on UNIX/Linux

Figure 6-2 Placement of root and authentication brokers on Unix/Linux

The information depicted in the previous figure is used to guide the

implementation team on the deployment of the Symantec products that are

enabled with authentication and authorization. In this environment, only one

authentication hierarchy is set up. The authentication root broker is installed and

configured on the same system as the NetBackup management server. All the

management servers (such as NetBackup, SLIM, and CommandCentral) are installed

and configured on separate systems with respective authentication brokers. After

Symantec solution: UNIX/Linux use casesDeploy Symantec products on UNIX/Linux

86

the root broker is configured, the authentication broker can be configured on

other management servers in any order. In this use case, the CommandCentral,

SLIM, and Storage Foundation servers are configured sequentially. The following

use cases serve as templates with which you can compare your environment and

then implement the appropriate authentication solution. The basic sequence in

which you install each of these Symantec products does not vary by use case. Only

the individual tasks that are required to configure these Symantec products for

each use case vary. Refer to the following figure for an example use case.


NetBackup use caseFigure 6-3 shows the deploying NetBackup management servers and client.

Figure 6-3 Deploying NetBackup management servers and client

NetBackup uses the authentication mechanism that is provided by the Symantec

Product Authentication Service to authenticate ordinary users who access the

NetBackup subsystems. After obtaining valid authentication credentials, ordinary

users are then permitted to perform product management through the product

administrative Web console and execute privileged NetBackup commands from

the command line. One or more Authentication brokers are set up with the

appropriate plug-ins to authenticate NetBackup users (including the administrator)

and services (NetBackup media servers and clients). The Authorization service is

also set up on the system where the NetBackup master server is configured. After

a user has acquired a valid authentication credential, the access control

functionality that is provided by the Symantec Product Authorization is used to

87Symantec solution: UNIX/Linux use casesNetBackup use case

decide the operations (examples are policies and storage-units manipulation) that

an ordinary user is permitted to do.

Typically, these Symantec products are installed on the system in the following

order:

■ Storage Foundation

■ Infrastructure Core Services (Private Branch Exchange, Symantec Product

Authentication and Symantec Product Authorization). Authentication and

authorization products are required to enable NetBackup Access Control

■ Management agents from other Symantec products (such as CommandCentral

or the Symantec License Inventory Manager)

NetBackup provides backup and recovery services for the systems that are deployed

throughout the enterprise that have valuable data on them. NetBackup has

management servers (master and media) and management client (or simply client)

components. A NetBackup policy is configured on the Master server for a client

that has data to be backed up. A backup is usually initiated from the master server.

During the backup, a client reads the data from the system and sends it to the

media server which stores it to a storage unit for safe keeping. Usually, a

NetBackup management client is deployed on the systems that have SLIM,

CommandCentral, Storage Foundation and other Symantec products installed.


It is highly recommended that you install and configure NetBackup and the

NetBackup Operations Manager (NOM) master management server on a system

reserved exclusively for this management server. After the master server is

configured, the installation of media management servers can proceed. NetBackup

management clients are usually installed last. To verify that the setup is functional,

initiate a backup from the master server for a client by using one of the media

servers and restore the backup to a different client.

On the system that has the NetBackup master management server, an

authentication broker and the authorization service are also configured. Additional

authentication brokers may be required and configured on systems with media

servers. Typically, each authentication broker is configured for an authentication

domain with specific plug-in. When adding new authentication brokers to an

existing authentication hierarchy, extra preparatory steps must be performed for

these brokers from the system with the existing root broker.


Unlike other Symantec products, configuring NetBackup and enabling NetBackup

with Access Control (authentication and authorization) require two separate

configuration procedures. Access Control is added to NetBackup after the

Symantec solution: UNIX/Linux use casesNetBackup use case

88

management servers (master and media) and management clients have been

configured and functional.

A large enterprise may need multiple NetBackup master servers configured for

different backup and recovery purposes. Procedures and configuration instructions

that are provided here for NetBackup can be repeated when you add new NetBackup

management servers (master and media) and clients with Access Control.

Deployment platforms and operating systems

In this use case chapter, procedures primarily use Solaris as the platform on which

NetBackup management servers (master and media) and clients are deployed and

verified. However, the NetBackup master management server also manages

NetBackup media management servers and management clients that are

configured on AIX and Windows operating systems.

Application server

On UNIX/Linux platforms, the binaries and data files for the NetBackup media

servers and agents are installed in the /usr/openv directory. The /usr/openv

directory is typically a mount point for a VxFS file system that is created on a

Veritas Volume Manager volume. VxFS and Volume Manager are distributed

through the Symantec application server products such as Storage Foundation,

Storage Foundation Cluster File System, or Storage Foundation for Oracle RAC.

Typically, the Symantec Storage Foundation application server is also installed

on the system.

See “Common Veritas Volume Manager and Veritas File System procedures”

on page 222.


NetBackup management servers

The versions of NetBackup and the shared infrastructure core services components

NetBackup depends on are listed in the tables depicted in the Master and Media

sections, respectively. Starting from NetBackup version 6.0 release, before you

install NetBackup on a system with either a master or a media server, you must

install and configure the Private Branch Exchange (PBX). Prior to configuring

either master or media server for access control (enable authentication and

authorization), the Symantec Product Authentication and Authorization must

also be installed on the system. On a system that has the NetBackup master

management server, it is preferable to have a local authentication broker and

authorization service configured. On a system with a NetBackup media


management server, only the client portion of the Symantec Product

Authentication and Authorization is required.

To add a master server to an enterprise or add a new media server to an existing

master server, you can repeat the procedures in this section on each new system.

Master server

It is highly recommended that the NetBackup master server gets installed on a

system that merely has this management server active and running. The following

table shows the specific version of the common core service (PBX) that is used by

the NetBackup master server.

Table 6-1 explains NetBackup master server dependency on Private Branch

Exchange.

Table 6-1 NetBackup master server dependency on Private Branch Exchange

Private Branch ExchangeNetBackup

1.31.2

6.0MP4

The following procedure illustrates the installation of a NetBackup 6.0 master

management server on Sun hardware that runs the Solaris 9 operating system.

This master management server also manages NetBackup media servers and

clients that are configured on Windows, Solaris, and AIX. A valid product license

key is required to install the NetBackup master management server and the key

must be entered during the NetBackup installation.

The NetBackup installer checks for the presence of the PBX shared component

and verifies that the PBX service is started. For PBX installation instructions, refer

to the following section.

See “Installing and configuring Private Branch Exchange” on page 226.

The NetBackup installer does not configure authentication or authorization. The

system should already have a Storage Foundation product installed and configured.


90

To install and configure a NetBackup master management server on Solaris

1 Log on to the system where you will install the NetBackup master management

server (neptune.universe.com). Using the instructions described earlier in

the Application server section, prepare a Veritas file system and mount it at

the /usr/openv directory. It may also be necessary to create another Veritas

file system and mount it at /neptune-disk as storage unit for storing the

backup images.

2 Invoke the install script to install the NetBackup master management server.

The NetBackup installation files can be accessed through a mount point, in

a local or CD/DVD file system. Refer to the NetBackup UNIX/Linux installation

guide for instructions on how to access installation files through CD/DVD

distribution media.

# cd /

# ls <mnt>/NB_60_Solaris_20050906a

install* solaris/

# <mnt>/NB_60_Solaris_20050906a/install

Installing NetBackup Server Software

Do you wish to continue? [y,n] (y)

Enter license key: <NetBackup Master management server keys>

Would you like to use "neptune.universe.com" as the

configured name of the NetBackup server? [y,n] (y) y

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

Do you have any media servers? [y,n] (n) n

Enter the Enterprise Media Manager server

(default: neptune.universe.com):

Do you want to start the NetBackup bprd process so

backups and restores can be initiated? [y,n] (y)

File /usr/openv/tmp/install_trace.22417 contains a

trace of this install. That file can be deleted after

you are sure the install was successful.


3 To prepare for the push installation, install the client binaries of the platforms

that are deployed on management clients. For example, management clients

are deployed on Solaris and AIX. So, choose RS6000 and Solaris clients and

install these binaries on the master management server.

# cd <mnt>/NB_60_CLIENTS_20050906a

# ./install

Installing NetBackup Client Software


RS6000

Solaris

Is this the list you wish to use? [y,n] (y)

# cd /usr/openv/netbackup/client

# ls

Solaris/ RS6000/

# cat /usr/openv/netbackup/bin/version

NetBackup-Solaris9 6.0GA

4 To install the Add-On options, invoke the respective NetBackup install script

to install the additional options.

5 Verify that the NetBackup and the Private Branch Exchange processes are

running.

# /usr/openv/netbackup/bin/bpps -x

6 To configure various subsystems within the NetBackup product, launch the

jnbSA GUI tool and use the Getting Started wizard as a guide to the setup.

# /usr/openv/netbackup/bin/jnbSA -d <display> \

-l /tmp/jnbSA.log.1 -lc &

7 On the Veritas NetBackup jnbSA Console, Activity Monitor, select Services

and Processes to verify that the services and NetBackup processes are online.

8 Verify that the operating system can see the tape libraries and devices on a

system.

See “NetBackup tape device drivers” on page 273.

9 Create a storage unit and policy on the master management server.

See “NetBackup storage units” on page 267.

See “NetBackup policies” on page 268.


92

The NetBackup software on the master management server is usually the first

NetBackup system to be upgraded.

To upgrade a NetBackup master management server on Solaris

1 Before upgrading the NetBackup master server software, stop the NetBackup

management server. Use the following commands to stop and start NetBackup

master management server:

# /usr/openv/netbackup/bin/goodies/netbackup stop

# /usr/openv/netbackup/bin/goodies/netbackup start

2 Log in to the master management server and change to the directory with

the NetBackup maintenance pack distribution:

# cd /usr/openv/tmp/60_4_M

3 List the contents of the directory as follows:

# ls

...

VrtsNB_CLT_60_4_M.tar.Z

VrtsNB_60_4_M.solaris.tar.Z

VrtsNB_JAV_60_4_M.tar.Z

4 The maintenance pack is typically in tar format. Extract the tar files in a

directory and specify the pack to install. Specifying NB_CLT_60_4_M

automatically upgrades the server (NB_60_4_M) before the client.

# ./Vrts_pack.install

There are 3 packs available in /usr/openv/tmp/60_4_M:

(* denotes installed pack)

NB_60_4_M

NB_CLT_60_4_M

NB_JAV_60_4_M

Enter pack name (or q) [q]: NB_CLT_60_4_M


5 After the upgrade completes, verify that the NetBackup master management

server was upgraded. Start the NetBackup master management server if it

has not being started.



NetBackup-Solaris9 6.0MP4


6 If the NBAC was enabled on the master management server, after upgrading

NetBackup, the Verify NetBackup access control setup on the master server

procedure listed in Appendix C should be used to ensure the master

management server is working.

On the system that has the NetBackup master management server configured,

management agents of other Management Servers could be deployed. These

agents may or may not have the authentication enabled. As an example, SLIM

and CommandCentral Service Agents are likely to be found on the same

system as the NetBackup master management server.

Media servers

The NetBackup media management server is dependent on the service provided

by the Private Branch Exchange (PBX), and the service provided by this shared

component must be online before you install the NetBackup media management

server. The following table depicts the version of NetBackup and the version of

the PBX shared component that is currently used by the NetBackup media server.

Table 6-2 explains NetBackup media server dependency on Private Branch

Exchange.

Table 6-2 NetBackup media server dependency on Private Branch Exchange


1.31.2

6.0MP4

Before installing NetBackup media management servers, it is assumed that the

NetBackup master management server was already configured and is functioning.

In this setup, a media management server is configured on AIX, Solaris, and

Windows, respectively, for the NetBackup master management server that is

configured on Solaris. Having multiple media servers in an enterprise allows many

backup or recovery jobs to occur concurrently. Typically, a media management

server is assigned to the management client on the same platform—an AIX client


94

interacting with a media server on AIX. It is a supported configuration to have

management clients on Windows interacting with media management server

configured on Solaris platform.

This installation session illustrates the installation for NetBackup 6.0 on an AIX

5.3 operating system. A maintenance pack is then applied on top of the 6.0 release

to upgrade NetBackup to a later version. You can use this procedure to install

media management server on other UNIX/Linux platforms.

To install and configure a NetBackup media management server on Solaris

1 Log on to the system (triton.universe.com) where the NetBackup media

management server would be installed. Using the instructions described

earlier in the Application server section, prepare a Veritas file system and

mount it at the /usr/openv directory. It may also be necessary to create

another Veritas file system and mount it at /triton-disk as storage unit for

storing the backup images.

2 Invoke the install script to install the NetBackup media management server.

The NetBackup installation files could be accessed through a mount point,

either a local or CD/DVD file system. Refer to the NetBackup UNIX/Linux

installation guide for instructions on how to access installation files through

CD/DVD distribution media.

# cd /

# ls <mnt>/NB_60_AIX_Tru64_20050906a

alpha_5/ install* rs6000/

# <mnt>/NB_60_AIX_Tru64_20050906a/install

Installing NetBackup Server Software


Enter license key: <NetBackup Master/Media management server keys>

Would you like to use "triton.universe.com" as the configured

name of the NetBackup server? [y,n] (y) y

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

What is the fully qualified name of the master server?

neptune.universe.com

Enter the Enterprise Media Manager server

(default: neptune.universe.com):

File /usr/openv/tmp/install_trace.1918 contains a

trace of this install. That file can be deleted after

you are sure the install was successful.


3 Add the following line to the AIX platform /etc/inittab file:

veritas:2:wait:/etc/rc.veritas.aixscript

4 Verify that the NetBackup and the Private Branch Exchange processes are

running.


5 On the Veritas NetBackup jnbSA Console, Activity Monitor, select Services

and Processes, and then verify that the services and NetBackup processes

are online.

6 To configure storage devices for a media server, use the Configure Storage

Devices wizard on the master management server.

7 Before performing the Storage Devices configuration for the media

management server, the physical devices must be already connected to the

system with the media server. Verify that the operating system can see the

tape libraries and devices on a system.

See “NetBackup tape device drivers” on page 273.

8 Create a storage unit for the media management server.


9 After the installation is complete, verify that the bp.conf configuration file

on the media management server is correct.

# cat /usr/openv/netbackup/bp.conf

SERVER = neptune.universe.com

SERVER = triton.universe.com

CLIENT_NAME = triton.universe.com

EMMSERVER = neptune.universe.com

10 To upgrade NetBackup on a system with media management server, the same

upgrade procedure that is used in the Master server section should be used.

The NetBackup software on a media management server is upgraded after

the master management server has been upgraded. If the NBAC was enabled

on a media management server, after upgrading the NetBackup software, the

Verify NetBackup access control setup on media servers procedure listed in

Appendix C should be used to ensure the media management server is working.

Refer to the corresponding NetBackup use case section in Chapter 7 for

procedures and steps to install and configure NetBackup media management

servers on Windows platforms.


96

Add a media server to a master server

This step is to be performed on the system where the NetBackup master

management server is configured. The host to be added as the media management

server should have the NetBackup media server software installed already.

On the NetBackup Administration Console, go to the NetBackup Management,

Host Properties, Master Server. Highlight the master server, right click and choose

properties. When the Master Server Properties: neptune.universe.com screen

appears, click the Servers Properties, and then click Add. In the Add a new server:

field, enter the host name of the new media server triton.universe.com (an AIX

system), and then click Add. This procedure is used to add either a Windows or

UNIX/Linux (such as Solaris or Red Hat) media server on a UNIX/Linux master

server.

On the NetBackup Administration Console, launch the Configure Storage Devices

wizard to configure devices and storage unit for the new media management

server (triton.universe.com).

The addition of a NetBackup 5.1MP6 (or later) media server to a NetBackup 6.0MP4

(or any 6.0 version) master server is a supported configuration.

NetBackup management client

The NetBackup Management Client does not depend on the Private Branch

Exchange shared component. On UNIX/Linux, to install the NetBackup

management client and add it to a master management server, follow these

procedures and steps.

During the installation of the NetBackup master or media management server,

management client binaries of the platforms that are deployed in the enterprise

are usually installed on the system. In this setup, NetBackup client software is

installed on the management client systems through the push install utility that

is provided by NetBackup.


To install a NetBackup client on a management client system

1 Verify that the NetBackup client software is installed on the NetBackup

management server (either master or media). In this setup, the push install

is initiated from the master management server. This installation session

illustrates the push installation for NetBackup 6.0MP4 release.

2 Log on to the system (bianca.universe.com) where the NetBackup

management client would be installed, create a Veritas file system, and then

mount it on the /usr/openv directory. You can extend the size of the file

system while the file system is mounted.

See “Common Veritas Volume Manager and Veritas File System procedures”

on page 222.

Temporarily insert a line “+ +” in the ~root/.rhosts file on the system of

the management client to facilitate the push install. After the push install is

complete, remove the “+ +” line that you added to the .rhosts file.

3 Log on to the system with the master management server, create a NetBackup

policy, and then add the host name of the management client. A management

client must be present in a NetBackup policy for the push install to work.

Navigate to the /usr/openv/netbackup/bindirectory. This directory is where

the NetBackup push installation script is located. To push the NetBackup

client binaries from the master (neptune.universe.com) to a Solaris

management client (bianca.universe.com), run the following script:

# install_client_files rsh bianca.universe.com

4 Log on to the system with the management client (bianca.universe.com)

and verify the content of the bp.conf file.



SERVER = oberon.universe.com


CLIENT_NAME = bianca.universe.com



Typically, the NetBackup software on a management client is upgraded after the

master and media management servers that are associated with this management

client have been upgraded.


98

To upgrade a NetBackup client on a management client system

1 The push install facility that is available in NetBackup is used to perform the

upgrade of the NetBackup software on a management client. Assume the new

NetBackup maintenance client software has been installed on the system

that has the master management server.

2 Log on to the system of the NetBackup management client. Temporarily insert

the line “+ +” into the ~root/.rhosts file on the system of the management

client to facilitate the push install. After the push install is complete, remove

the “+ +” line that you added to the .rhosts file.

3 Log on to the system with the NetBackup master management server. Assume

that the host name of the management client is in a NetBackup policy.

# /usr/openv/netbackup/bin/admincmd/bpplclients

Hardware OS Client

---------- ------------ --------------

Solaris Solaris9 bianca.universe.com

# echo 'Solaris Solaris9 bianca.universe.com' > /tmp/sc

4 Navigate to the /usr/openv/netbackup/bin directory where the NetBackup

push installation file is located. To upgrade the NetBackup client binaries

from the master (neptune.universe.com) to a Solaris management client

(bianca.universe.com), run the following script:

/usr/openv/netbackup/bin# update_clients \

-Install_Client_Bins -ClientList /tmp/sc

5 Log on to the system with the management client (bianca.universe.com)

and verify the new version of the NetBackup client software.



Refer to the corresponding NetBackup use case section for procedures to install

and configure a NetBackup management client on Windows.


Enable access control on a NetBackup master server

Before you enable NetBackup with Access Control (NBAC), it is a prerequisite to

have the master management server (and possibly all the media and client) set

up and operational. To verify that the NetBackup configuration is working, a


successful backup and restore initiated from the master for a client by using a

specific media server should be a good indicator.

For the backup and restore procedures, refer to the Successful NetBackup backup

and restore section in Appendix C for details. This approach is helpful in terms

of fault isolation. For example, if backup and restore work fine without the NBAC,

but fail to work with NBAC enabled, then the troubleshooting effort should be

directed at the NBAC configuration.

The following table shows the specific version of the common core services

(authentication and authorization) that are used by the NetBackup master

management server.

Table 6-3 explains NetBackup master server dependency on authentication and

authorization.

Table 6-3 NetBackup master server dependency on authentication and

authorization

Authorization serviceAuthentication serviceNetBackup

4.34.24.14.34.24.1

6.0MP4

Other Management Agents, such as CommandCentral Storage and Service, that

are installed on the same system as the master management server can be enabled

with authentication and use the same common core services components.

To set up the NBAC functionality on the master management server, the following

procedures have been tested and proven to work with the configuration that is

described in this use case chapter. The first portion of the procedures is done from

the command line. The jnbSA console is used to complete the second portion of

the setup.


100

To enable Access Control on a NetBackup master server

1 A NetBackup master management server has been installed and configured

on a UNIX system (neptune.universe.com) running the Solaris 9 operating

system. Procedures are provided to enable the NBAC on the master

management server. These procedures can be used for adding master

management servers on other UNIX/Linux platforms.

2 Install and configure the authentication and authorization products on the

system that has the master management server.

In this configuration, a root plus authentication broker is configured on the

system that has the NetBackup master management server. Authentication

brokers for other management servers should be created in this authentication

hierarchy. Refer to the Install and configure authentication section in

Appendix B for the installation procedures.

On the system where the NetBackup master management server is installed,

the authorization server is configured also. The authorization product should

be installed after the authentication product. To install the authorization

product, refer to the Install and configure authorization section in Appendix

B for the installation procedures.


3 Create the authentication domain, NBU_Machines, for the NetBackup

management server. Suppose the NetBackup master management server is

configured on system neptune.universe.com with the Solaris 9 operating

system.

# /usr/openv/netbackup/bin/bpnbat -addmachine

Does this machine use Dynamic Host

Configuration Protocol (DHCP)? (y/n) n

Authentication Broker: neptune.universe.com

Authentication port[ Enter = default]:

Machine Name: neptune.universe.com

Password: <pick a password for neptune>


Operation completed successfully.

# /opt/VRTSat/bin/vssat listpd --pdrtype ab

Domain Name [email protected]

# /opt/VRTSat/bin/vssat listpdprincipals \

--pdrtype ab \

--domain [email protected]

Principal Name: admin

Principal Name: neptune.universe.com

# /usr/openv/netbackup/bin/bpnbat -ShowMachines



102

4 Obtain a valid credential for the master management server.

# /usr/openv/netbackup/bin/bpnbat -loginmachine





Machine Name: neptune.universe.com



# /usr/openv/netbackup/bin/bpnbat -whoami -cf \

/usr/openv/var/vxss/credentials/neptune.universe.com

Name: neptune.universe.com

Domain: [email protected]

Issued by: /CN=broker/[email protected]/O=vx

Expiry Date: Dec 7 19:46:51 2007 GMT

Authentication method: VERITAS Private Security



5 Create a user at the operating system level to set up the security. To create

a group and user on Solaris and HP-UX, execute the following commands.

AIX has mkgroup and mkuser. Red Hat has lgroupadd and luseradd.

# groupadd vxss

# useradd -u 35004 -g vxss -d /usr/vxss -m \

-s /bin/ksh -c "VxSS" vxss

# passwd -r files vxss

New Password:<vxss password>

# /usr/openv/netbackup/bin/admincmd/bpnbaz \

-SetupSecurity neptune.universe.com \

-Server neptune.universe.com

Please enter the login information for the first Security

Administrator other than root/Administrator. This identity

will be added to the security administrators group

(NBU_Security Admin), and to the netbackup administrators

group (NBU_Admin). It will also be used to build the initial

security information.



Authentication type (NIS, NIS+, NT, vx, unixpwd): unixpwd

Domain: neptune.universe.com

Login Name: vxss

Password: <vxss password>

Processing - please be patient



104

6 The Domain is derived from the Authentication type. To find the Domain for

unixpwd Authentication type, use the following command.

# /opt/VRTSat/bin/vssat showallbrokerdomains

Broker Name: neptune.universe.com

Broker Port: 2821

Domain Name: neptune.universe.com

Domain Type: unixpwd

**************************************


Broker Port: 2821

Domain Name: universe.com.

Domain Type: nisplus

7 Add the master management server as the host that is authorized to perform

Authorization check.


-AllowAuthorization neptune.universe.com \

-server neptune.universe.com


# /usr/openv/netbackup/bin/admincmd/bpnbaz -ShowAuthorizers

Type: User

Domain Type: vx

Domain:[email protected]


Enable Access Control from the NetBackup Administration Console

1 To start the second portion of the NBAC configuration, invoke the jnbSA GUI

administrative tool and login as user root.

# /usr/openv/netbackup/bin/jnbSA -d <disdplay> \

-l /tmp/log.1 -lc &

2 Expand the Host Properties and click the Master Servers, and then select

neptune.universe.com as the master server by clicking the host. In the Status

column, it should show Connected. Click Actions (at the top) and select

Properties... On the Properties… screen, select the Access Control (third from

the bottom). In the Veritas Security Services (VxSS) box, choose Automatic

(others are Required and Prohibit).

See “NetBackup access control parameters” on page 243.


3 On the Authentication Domains tab, clickAdd 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.




106

6 Add the vxss and root users to the privileged NetBackup security groups –

NBU_Security Admin and NBU_Admin. Without adding these users to these

privileged groups, when logging in to the jnbSA as these users, only the client

privilege is accessible. To execute bpnbaz -adduser, a valid session must be

acquired by first running the bpnbat -login command.

# /usr/openv/netbackup/bin/bpnbat -login





Login Name: root



# /usr/openv/netbackup/bin/bpnbat -whoami

Name: root




Authentication method: UNIX passwd



-adduser "NBU_Security Admin" \

unixpwd:neptune.universe.com:root



-adduser "NBU_Admin" \

unixpwd:neptune.universe.com:root



-adduser "NBU_Admin" unixpwd:neptune.universe.com:vxss

Operation completed successfully


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 CurrentNBACUser. For

NetBackup access control troubleshooting tips, refer to the following section.

See “NetBackup access control troubleshooting tips and messages” on page 275.

Enable access control on a NetBackup media server

Before attempting to enable the NetBackup Access Control (NBAC) on a media

management server, it is a prerequisite to have the media management server,

the master that manages this media server and all the clients that use this media

server, set up and operational. To verify that the NetBackup configuration is

working, a successful backup and restore initiated from the master for a client by

using this media server should be a good indicator. For the backup and restore

procedures, refer to the Successful NetBackup backups and restores section in

Appendix C for details. This approach is helpful when comes to fault isolation.

For example, if the backup and restore by using this media server works fine

without the NBAC, but failed to work with NBAC enabled, then the troubleshooting

effort should be directed at the NBAC configuration.

The following table shows the specific version of the common core services

(authentication and authorization) that are used by the NetBackup media

management server.

Table 6-4 explains NetBackup media server dependency on authentication and

authorization.


108

Table 6-4 NetBackup media server dependency on authentication and

authorization

Authorization clientAuthentication clientNetBackup

4.34.24.14.34.24.1

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


authentication broker on neptune.universe.com and not the local authentication

broker.

To set up the NBAC functionality on the media management server, the following

procedures have been tested and proven to work with the configuration that is

described in this use case chapter. The first portion of the procedures is done from

the command line. The NetBackup jnbSA is used to complete the second portion

of the setup. Some of the steps described here will have to be done on the system

with the master management server.

To enable Access Control on a media management server

1 A NetBackup media management server has been installed and configured

on a UNIX system (triton.universe.com) running AIX 5.3 operating system.

This media server is associated with the master management server that is

configured on a UNIX system (neptune.universe.com) that runs the Solaris

9 operating system. Procedures are provided to enable the NBAC on the media

management server. These procedures can be used for adding media

management server configured on other UNIX/Linux platforms. You can

enable NBAC on a Windows media management server (with either

UNIX/Linux or Windows master server).

See “To enable access control on a NetBackup media server” on page 179.

2 To enable NBAC on a media management server configured on a dedicated

system, install the client portion of the authentication and authorization

service on the system. The client portion of the authorization service should

be installed on the system that has the media management server. The

authorization service should be installed after the authentication service.



110

3 On the master management server – neptune.universe.com, enter the

following command to create an authentication principal for the system that

has the media management server:






Machine Name: triton.universe.com





--pdrtype ab --domain [email protected]

Principal Name: triton.universe.com



triton.universe.com

4 On the system with the new media management server,triton.universe.com,

type the following command to obtain the machine credential for the system

triton.universe.com:






Machine Name: triton.universe.com

Password: <pick a password for triton>


# /usr/openv/netbackup/bin/bpnbat -whoami \

-cf /usr/openv/var/vxss/credentials/triton.universe.com

Name: triton.universe.com







5 On the master management server,neptune.universe.com, type the following

command to authorize the system with the media management server to

perform authorization check:


-AllowAuthorization triton.universe.com \




-Showauthorizers -server neptune.universe.com

Type: User

Domain Type: vx


Name: triton.universe.com

6 On the master management server – neptune.universe.com, enter the

following command to start the second portion of the NBAC configuration

and invoke the jnbSA GUI administrative tool and login as user root:


-l /tmp/log.1 -lc &

7 Expand Host Properties, and then click Media Servers. select

triton.universe.com as the media server by clicking the host. The Status

column should display Connected. Click Actions (at the top), and then select

Properties... On the Properties… screen, select the Access Control (last one

on the list). In the Veritas Security Services (VxSS) box, choose Automatic



8 Click the AuthenticationDomains tab, click Add and a dialog box appears.

Enter neptune.universe.com as the Domain: and choose UNIXPWD as the

Authentication Mechanism. In the Broker: field, enter neptune.universe.com

and a description for this Authentication Domain. The authentication broker

resides on the system neptune.universe.com. The media management server

that is configured on triton.universe.com uses the remote authentication

broker that is configured on the maser management server

(neptune.universe.com).

9 Click the Authorization Service tab and enter neptune.universe.com in the

Host: field. The media server uses the global authorization database that is

configured on the system neptune.universe.com.


112

10 Save the changes, and then exit the jnbSA. For the changes to take effect,

stop and start the NetBackup media management server.



11 On the media management server triton.universe.com, enter the following

command to verify that the NetBackup configuration file on

triton.universe.com was updated:




CLIENT_NAME = triton.universe.com

EMMSERVER = neptune.universe.com

AUTHENTICATION_DOMAIN = neptune.universe.com ""

PASSWD neptune.universe.com 0

AUTHORIZATION_SERVICE = neptune.universe.com 0

USE_VXSS = AUTOMATIC


12 Log in to the NetBackup via the CLI and verify that the expiry period by

entering the following command:






Login Name: root

Password: <root password on triton>



Name: root

Domain: netptune.universe.com





13 Invoke the jnbSA and login as user root. To verify a user’s credential, within

jnbSA, click Help (at the top), and then click CurrentNBACUser. A jnbSA

session is valid for 24 hours.


-l /tmp/log.2 -lc &


You can enable NBAC on a Windows media management server (with the master

server on UNIX/Linux) If the environment has a Windows master management

server and UNIX/Linux media management server, refer to the following section.



114

To enable NBAC on a Windows media management server with a master server on

UNIX/Linux

1 On a Windows system (oberon.universe.com) with Windows Server 2003

Enterprise Edition SP1 operating system, a NetBackup media management

server is configured. The Windows media management server must be

operational before you enable the NBAC functionality. At a minimum, a

successful backup and restore must be performed for a client by using this

media management server.

2 Authentication plug-ins such as UNIXPWD and NISPLUS are not applicable

on Windows. Users on the Windows media management server are not able

to use the authentication brokers that are configured on UNIX/Linux with

these plug-ins. Therefore, an authentication broker (either remote or local)

must be configured on Windows with the platform specific authentication

domain and plug-in (WINDOWS) to authenticate Windows users.


3 On the master management serverneptune.universe.com, use the following

command to create an authentication principal for the Windows system that

has the media management server:






Machine Name: oberon.universe.com

Password: <pick a password for oberon>




--pdrtype ab --domain [email protected]

Principal Name: oberon.universe.com



triton.universe.com

oberon.universe.com


4 On the system with the Windows media management server

oberon.universe.com, enter the following command to obtain the machine

credential for the system oberon.universe.com:

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

-loginmachine





Machine Name: oberon



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

-cf ..\var\vxss\credentials\oberon.SUN.universe.com

Name: oberon.universe.com



Expiry Date: Jan 23 07:59:01 2008 GMT



5 On the master management serverneptune.universe.com, enter the following

command to authorize the system with the media management server to

perform authorization check:

C:\Program Files\VERITAS\NetBackup\bin\admincmd>bpnbaz

-allowauthorization oberon -server neptune.universe.com



command to start the second portion of the NBAC configuration, invoke the

jnbSA GUI administrative tool, and log in as user root:


-l /tmp/log.1 -lc &


116

7 ExpandHostProperties, and then clickMediaServers, select oberon (FQHN

is oberon.universe.com) as the media server by clicking the host. In the

Status column, it should show Connected. Click Actions (at the top) and select






SUN as the Domain: and choose WINDOWS as the Authentication Mechanism.

In the Broker: field, enter oberon and a description for this Authentication

Domain. The authentication broker resides on the system

oberon.universe.com.

9 On the Authorization Service tab, in the Host field, enter

neptune.universe.com. Save the changes, and then and exit the jnbSA. For

the changes to take effect, stop and start the NetBackup media management

server.



For information on verification and troubleshooting, refer to the following

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


Enable access control on a NetBackup client

Before you enable the NetBackup Access Control (NBAC) on a NetBackup

management client, the management client must be managed by the master and

media management servers. To verify that the NetBackup configuration is working,

a successful backup and restore initiated from the master for a client using this

media server should be a good indicator.


This approach is helpful for fault isolation. For example, if backup and restore by

using this management client is successful without NBAC, but fails with NBAC

enabled, you can direct your troubleshooting effort at NBAC configuration.

Table 6-5 shows the specific version of the common core service (authentication)

that is used by the NetBackup management client.


Table 6-5 NetBackup client dependency on authentication

Authentication clientNetBackup

4.34.24.1

5.1MP6

6.0MP4

Other Management Agents, such as CommandCentral Storage and Service, that

are installed on the same system as the management client can be enabled with

authentication and use the same common core services components.

Even though the NetBackup management client only needs the client portion of

the authentication product, other Symantec management servers or agents that

are installed on the same system as the NetBackup management client can install

an authentication broker. The NetBackup management client is authenticated by

a remote authentication broker that is configured on the system with the master

management server. Other Symantec management servers or agents may require

a more recent version of the Symantec Product Authentication.

To set up the NBAC functionality on a management client, the following procedures

have been tested and proven to work with the configuration that is described in

this use case chapter. The first portion of the procedures is done from the

command line. The NetBackup jnbSA is used to complete the second portion of

the setup. Some of the steps described here will have to be done on the system

with the master management server.

A NetBackup management client has been installed and configured on a UNIX

system (bianca.universe.com) that runs the Solaris 9 operating system. This

NetBackup client is managed by the master management server that is configured

on a UNIX system (neptune.universe.com) that runs the Solaris 9 operating

system. Procedures are provided to enable the NBAC for this NetBackup

management client. These procedures can be used for adding NetBackup

management clients on other UNIX/Linux platforms.


118

To enable NBAC for a management client

1 Install the Symantec Product Authentication Service client software on the

system that has the management client.


2 On the master management serverneptune.universe.com, to enable the

NBAC for a management client, create an authentication principal for the

system where the NetBackup management client is installed. Repeat this step

for each management client that is to be enabled with the NBAC. In this

example, an authentication principal is added for the system

bianca.universe.com in the NetBackup NBU_Machines private domain

repository.






Machine Name: bianca.universe.com

Password: <pick a password for bianca>



# /opt/VRTSat/bin/vssat listpdprincipals --pdrtype ab \


Principal Name: bianca.universe.com



triton.universe.com

bianca.universe.com


3 On the management clientbianca.universe.com, use the following command

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






Machine Name: bianca.universe.com




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

Name: bianca.universe.com







command to use the jnbSA to modify the Access Control properties for a

NetBackup management client.


-l /tmp/log.1 -lc &

5 Expand Host Properties, and then clickClients., select bianca.universe.com

as the management client by clicking the host. In the Status column, it should

show Connected. Click Actions (at the top) and select Properties... On the

Properties… screen, select the Access Control (second one from the bottom

of the list). In the Veritas Security Services (VxSS) box, choose Automatic




neptune.universe.com as the Domain and choose UNIXPWD as the

Authentication Mechanism. In the Broker field, enter neptune.universe.com

and a description for this Authentication Domain. The management client is

using the authentication broker residing on the system

neptune.universe.com.


120

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.




9 On the NetBackup management client bianca.universe.com, enter the

following command to verify that the /usr/openv/netbackup/bp.conf

configuration file on the management client was updated:




SERVER = oberon.universe.com

CLIENT_NAME = bianca.universe.com

AUTHENTICATION_DOMAIN =

neptune.universe.com "" PASSWD neptune.universe.com 0

AUTHENTICATION_DOMAIN =

SUN "" WINDOWS oberon.universe.com 0







Login Name: root




Name: root






Invoke the jnbSA and login as user root.

To verify the use's web credential, within jnbSA,

click Help (at the top) and select Current NBAC User.

A single jnbSA session is valid for 24 hours.


-l /tmp/log.2 -lc &


122

10 To enable NBAC on a Windows management client (ophelia.universe.com)

with master server on UNIX/Linux, follow the steps and procedures listed in

this section. The differences are the values in the Domain, Authentication

Mechanisms, and the Broker: fields. For a Windows management client, the

Domain: should be set to SUN (Windows Active Directory), the Authentication

Mechanisms: should be set to WINDOWS, and the Broker: should be set to

oberon.universe.com.

11 The NBAC configuration for NetBackup management client is now complete.

Use the procedures listed in the NetBackup access control setup verification

on clients section in Appendix C to verify that the NetBackup management

client is setup correctly. In Appendix C, the NetBackup access control

troubleshooting tips section has a list of common errors and resolutions tips.

See “Enable access control on a NetBackup media server” on page 108.

Environment with existing authentication hierarchy

In an enterprise where NetBackup is to be deployed with access control, suppose

an authentication hierarchy has already been created for another Symantec

product. When installing the Symantec Product Authentication for NetBackup,

you can install and configure an authentication broker by using the existing

authentication hierarchy that is configured on a remote system. Refer to the Add

a new authentication broker section in Appendix B for detailed procedures. If a

new authentication hierarchy is inadvertently configured also for NetBackup, the

NetBackup authentication hierarchy can be consolidated with an existing

authentication hierarchy. To consolidate the root broker, refer to the Replace the

root broker on the NetBackup master server section in Appendix C for detailed

procedures on how to assimilate an authentication broker from one authentication

hierarchy into another.

Upgrade NetBackup and shared components

The NetBackup installation is used to install and upgrade the NetBackup software

on systems that have either management client, master, or media management

server. The NetBackup installation does not involve the upgrade of those common

core services components (AT and AZ) that are used by NetBackup Access Control.

If upgrading to a specific NetBackup version also calls for the upgrade of the

shared components, the respective product installation script that is provided by

the shared products should be used to perform the upgrade.

After the upgrade of NetBackup software is complete, verify that NetBackup is

able to work with the shared products that are configured on the system.



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

Authorization

4.2 -> 4.3

Authentication

4.2 -> 4.3

PBX

1.2 -> 1.3

NetBackup

6.0MP4

CommandCentral Storage and Service use caseCommandCentral uses the authentication mechanism that is provided by the

Symantec Product Authentication to authenticate the users who access the

CommandCentral Web administrative console. An Authentication broker is set

up with the appropriate authentication domain and plug-ins that are made

available to the CommandCentral Web console for authenticating users. After the

CommandCentral products have been configured, accessing the CommandCentral

Web console requires a valid user login and password that must be authenticated

through the cc_users authentication domain and plug-in.


order:

■ Storage Foundation.

■ Infrastructure Core Services (Private Branch Exchange and Authentication).

■ CommandCentral Storage and Service.

■ Management client or agents from other Symantec products (such as

NetBackup, Symantec License Inventory Manager).

Figure 6-4 depicts the deployment of the CommandCentral servers in an enterprise.

Symantec solution: UNIX/Linux use casesCommandCentral Storage and Service use case

124

Figure 6-4 Deploying CommandCentral management servers and agent


In this use case chapters, the CommandCentral (CC) storage and service

management servers are deployed on the Solaris platform. The CC management

servers on Solaris manage the storage and service management agents that are

deployed on Solaris and Windows platforms.

Application server

On a UNIX platform, CommandCentral binaries are installed in the /opt/VRTS*

directories. CC products create data files and also generate temporary files. It is

ideal to store all the data and temporary files in a directory relative to

/var/VERITAS (or some user defined directory). The /var/VERITAS directory is

typically a mount point of a Veritas file system (VxFS) created on a Veritas Volume

Manager (VxVM) volume. The VxFS and VxVM products are distributed through

the Symantec application servers such as SF, SFCFS, or SF Oracle RAC. Before the

CC products are installed, typically, the Symantec SF application server is installed

on the system. To create a Veritas file system and mount it at /var/VERITAS, refer

to the Common Storage Foundation procedures section in Appendix A for

instructions on how to create a VxFS file system on a VxVM volume.

CommandCentral management server

In this setup, the CommandCentral (CC) management servers (Storage and Service)

are deployed on a dedicated Solaris system. CC management servers are dependent

on Symantec Product Authentication. The authentication product is used to

125Symantec solution: UNIX/Linux use casesCommandCentral Storage and Service use case

authenticate users accessing the CC Web console through a valid authentication

domain and plug-in.

In this use case, both Storage and Service management servers use version 4.2 of

the Authentication product. On the system where these management servers are

to be installed, you should configure an authentication broker in the authentication

hierarchy created on the system where the NetBackup management server is

configured. To add a new authentication broker into an existing authentication

hierarchy, refer to the Add a new authentication broker section in Appendix B for

detailed procedures.

A system that is configured with CommandCentral storage and service

management servers can have Management Agents or Client of other Management

Servers deployed as well. These Agents or Clients may or may not have the

authentication enabled. As an example, NetBackup management client could be

installed on the system that has the CC Storage management server.

Storage management server

The version of the CommandCentral Storage (CC Storage) product that is used in

this Yellow Book edition is listed in the following table. This version of the CC

Storage is dependent on the infrastructure provided by the Authentication (AT)

component. On the systems that have CC Storage management server, this shared

component must be installed and configured. This shared component could be

manually installed and configured on the system first or let the CC installer

automatically install the authentication product. CC Storage management server

uses the Web Server Service for console logon.


that is used with the storage management server.

Table 6-7 Storage management server dependency on shared component

Authentication ClientCommandCentral Storage

4.34.24.1

4.2FP1

4.3

A valid product license key is required to install the CC Storage management

server. To install and configure storage management server on Solaris, follow

these procedures and steps.

This install session illustrates the installation for CC Storage 4.2FP1 release on

Solaris 10 operating system.


126

To install and configure a CommandCentral storage management server

1 Log on to the system (cressida.universe.com) where the CC Storage

management server is to be installed. Using the instructions described earlier

in the Application server section, prepare a Veritas file system and mount it

at the /var/VERITAS directory.


2 Invoke the installccs script to install the CC Storage management server.

The CC installation files could be accessed through a mount point, either a

local or CD/DVD file system. Refer to the CC UNIX installation guide for

instructions on how to access installation files through CD/DVD distribution

media.

# cd <mnt>/CC4.2FP1/sunos

# ls

installccs* uninsallccs*

# ./installccs

1) CommandCentral Storage Management Server

3) CommandCentral Storage Web Engine

Choose the Storage Management Server and

Storage Web Engine components for installation.

For the storage management server configuration,

pick the option with both Operations and Data modules.

Where should the Data Module create this

temporary store? (/var/VERITAS)

Install Operations Module: Yes

Install Data Module: Yes

Data Module temporary dir: /var/VERITAS/ccs_data

Where should CommandCentral packages be installed? (/opt)

Where should CommandCentral databases be installed?

A directory named 'ccs_data' will be created within to

store data. (/var/VERITAS)

Please enter a CommandCentral Storage license key,

or <Return> to enter an evaluation key: <Storage key>

Do you want to start CommandCentral processes now? [y,n,q] (y)

Starting CommandCentral processes...

Starting VERITAS Enterprise Administrator...

Starting VERITAS Trap Service...

Starting CommandCentral Database...

Starting CommandCentral Alert Manager...

Starting VERITAS SAN Access Layer...

Starting CommandCentral Alarm Service...

Starting CommandCentral Importer...


128

Starting VERITAS SICL...

Starting CommandCentral Data Module...

Done starting CommandCentral processes...

3 Verify that the following CommandCentral authentication domains are present

on the system cressida.universe.com.




4 After CommandCentral Storage is installed and configured, verify that the

CC Storage management server is functional and working correctly.

See “Verifying the CommandCentral Storage server setup” on page 279.

The system that has the CC Storage management server is usually the first system

to be upgraded.

On a system that has the CC Service 4.2FP1 installed, upgrading CC Storage from

4.2FP1 to 4.3 is not supported. The CC Storage installation script makes this check

and would exit when such a condition is detected.

To upgrade a CommandCentral storage management server

1 Log on to the storage management server (cressida.universe.com), and

then locate the CommandCentral Storage 4.3 management server software.

2 Invoke the installccs script to upgrade the CC Storage management server.

The CC Storage installation files could be accessed through a mount point,

either a local or CD/DVD file system. Refer to the CC UNIX installation guide

for instructions on how to access installation files through CD/DVD

distribution media.

# cd <mnt>/ CCS_4.3/4.3.0017.0/sunos

# ls installccs uninstallccs

installccs* uninstallccs

# ./installccs

Service management server

The version of the CommandCentral Service (CC Service) product that is used in


Service is dependent on the infrastructure provided by the Authentication (AT)

and Private Branch Exchange (PBX) components. These shared components could


be manually installed and configured on the system first or let the CC installer

automatically install and configure these shared products. CC Service management

server also uses the Web Server Service for console logon.

Table 6-8 shows the specific version of the common core services (authentication

and PBX) that are used with the Service management server.

Table 6-8 Service management server dependency on shared components

Private Branch

Exchange

Authentication serviceCommandCentral Storage

1.31.24.34.24.1

4.2FP1

A valid product license key is required to install the CC Service management

server. To install and configure CC Service management server, follow these

procedures and steps. This install session illustrates the installation for CC Service

4.2FP1 release on Solaris 10 operating system.


130

To install and configure a CommandCentral server management server

1 Log on to the system (cressida.universe.com) where the CC Service

management server is to be installed. Using the instructions described earlier

in the Application server section, prepare a Veritas file system and mount it

at the /var/VERITAS directory.

2 Invoke the installccs script to install the CC Service management server. The

CC installation files can be accessed through a mount point, either a local or

CD/DVD file system. Refer to the CC UNIX installation guide for instructions

on how to access installation files through CD/DVD distribution media.


# ls

installccs* uninsallccs*

# ./installccs

1) CommandCentral Service Server and Web Engine

Installation dir: /opt

Database dir: /var/VERITAS/ccs_data

DB temp dir: /var/VERITAS/ccs_data

The CommandCentral Service Server and Web Engine

external address has been set to: cressida.universe.com

The CommandCentral Service Automation Server port has

been set to: 60389

VERITAS Web Server port: 8181

Do you want to start CommandCentral processes now? [y,n,q] (y)


Starting VERITAS Enterprise Administrator...

Starting VERITAS Trap Service...

Starting CommandCentral Database...

Starting CommandCentral Alert Manager...


Starting CommandCentral Alarm Service...

Starting CommandCentral Web Engine...

Starting CommandCentral Importer...

Starting VERITAS SICL...


Starting CommandCentral Service Server and Web Engine...

Done starting CommandCentral processes...


3 When the configured authentication broker is saved and restored after the

CC Service is installed, enter the corresponding component number to add

or remove it from the restore queue, or '3' when you are finished making

selections.

Files/directories detected, available for restore:

1) VxSS Authentication configuration

2) Select all

3) Finished with selections

4 Verify that the following CommandCentral authentication domains are present

on the system cressida.universe.com.




5 After CommandCentral Server is installed and configured, verify that the CC

Storage management server is functional and working correctly.

See “Verifying the CommandCentral Service server setup” on page 282.

Version 4.2FP1 is the last release of the CommandCentral Service product. The

CommandCentral Service View Builder functionality is renamed to Veritas Backup

Reporter, which is distributed with the NetBackup product. The CommandCentral

Service Metering Collector and CommandCentral Service Metering Controller are

renamed to Veritas Process Automation Server.

CommandCentral Management agents

In this setup, the CommandCentral (CC) management agent is deployed on Solaris

running the Solaris 9 operating system. These CC management agents are

configured to report to the CC management servers configured in the previous

section.


that is used with the Storage and Service management agents.

Table 6-9 CommandCentral agents dependency on shared component


4.34.24.1

4.2FP1


132

Table 6-9 CommandCentral agents dependency on shared component

(continued)


4.34.24.1

4.3

On Solaris, use the following procedures and steps to install a CC management

agent and configure it to report to a CC management server configured on Solaris.

The installation procedure that is illustrated on Solaris for CC management agent

is identical on other UNIX/Linux platforms.


To install the CommandCentral storage management agents

1 Navigate to the directory that has the CC management agent installation

files. The directory can be in a file system mounted on a CD-ROM/DVD drive

or a Network File System.

2 Install the CC Storage agent.

# cd <mnt>/ CCS_4.3/4.3.0017.0/unix_agent

# ls *install*

installccs* uninstallccs*

# ./installccs

2) CommandCentral Storage Agent

Choose CommandCentral Storage Agent,

Install both Operations and Data Modules,

Install support for Array Management to install.

Where should the Data Module create this temporary store? \

(/var/VERITAS)

Install Operations Module: Yes

Enable Array Management: Yes

Install Data Module: Yes

Data Module temporary dir: /var/VERITAS/ccs_data


Would you like to configure a CommandCentral Storage Management

Server for this Agent? [y,n,q] (y)

Please specify the CommandCentral Storage Management Server

hostname to configure: cressida.universe.com

Would you like to enable switch exploration

for this Agent? [y,n,q] (n) y

Installation dir: /opt

Server to configure: cressida.universe.com





134

3 Install the CC Service agent.


Components available for installation:

3) CommandCentral Service Agent


Would you like to configure a CommandCentral Service Server

and Web Engine for this Agent to report to? If no host name

is given, the following command will need to be

run after installation: /opt/VRTSccsva/bin/ccsvcagentauth \

-server server_to_connect_to [y,n,q] (y)

Please specify the CommandCentral Service Server and

Web Engine hostname to configure: cressida.universe.com




Starting CommandCentral Service Agent...

4 After CommandCentral Server management agents are installed and

configured, verify that the CC Storage management agents are functional

and working correctly.

See “Verifying the CommandCentral agents setup” on page 284.


When installing the CommandCentral (CC) product in an enterprise that already

has the authentication hierarchy, it is much preferred to create a new

authentication broker in the existing authentication hierarchy for the CC

management servers.

If a root broker was also configured during the CC install and there is a need to

replace the CC root broker with the existing authentication hierarchy, refer to

the Replace the root broker on the CommandCentral server section in Appendix

D for detailed procedures on how to assimilate an authentication broker from one

authentication hierarchy into another.

CommandCentral-related upgrade

The CC installation is used to install and upgrade the CC software on systems that

have either management agent, storage or service management server. The CC

installation does not involve the upgrade of those common core services


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.

Symantec License Inventory Manager use caseThe SLIM product uses the authentication mechanism that is provided by the

Symantec Product Authentication to authenticate users accessing the SLIM Web

administrative console. An Authentication broker is set up with the appropriate

plug-ins and made available to the SLIM Web console for authenticating users.

After the SLIM product has been configured, users in the slim_users private

domain repository should be able to log on to the SLIM Web console.


order:

■ Storage Foundation. It is optional to install the Symantec application server.

■ Infrastructure Core Services (Private Branch Exchange, Authentication, and

Service Management Framework).


■ Management client or agents from other Symantec products (such as

NetBackup, CommandCentral)

The SLIM product is used to collect licensing information of other Symantec

products that are installed on various systems. SLIM product has a management

server and management agent. The management agent collects the licensing

information and reports it to the management server, which stores the licensing

data in a central repository. Usually, the SLIM management agent is deployed on

systems that have NetBackup, CommandCentral, Storage Foundation and other

Symantec products installed.

Symantec solution: UNIX/Linux use casesSymantec License Inventory Manager use case

136

Figure 6-5 explains deploying Symantec License Inventory management server

and agent.

Figure 6-5 Deploying Symantec License Inventory management server and

agent

It is highly recommended that the SLIM management server gets installed and

configured on a system without other management servers. After the management

server is configured and functional, the installation of management agent can

proceed.

The version of the SLIM product that is used in this Yellow Book edition is listed

in the following table. This SLIM version is dependent on the infrastructure

provided by the Authentication (AT), Private Branch Exchange (PBX) and Service

Management Framework (SMF) core services components. On systems that have

SLIM management server, access points, and management agents, these shared

components must be installed and configured. These shared components can be

manually installed and configured on the system first or let the SLIM installer

automatically install them. SLIM management server uses the Web Server Service

for console logon.

Table 6-10 shows the specific version of the common core services (authentication,

PBX, and SMF) that are used by the NetBackup media management server.

137Symantec solution: UNIX/Linux use casesSymantec License Inventory Manager use case

Table 6-10 Symantec License Inventory Manager shared component

dependencies

SMFPBXAT ServerSLIM

1.31.21.31.24.34.24.1

4.0.4

The installer of this SLIM version automatically configures a root plus

authentication brokers on the system for the SLIM management server. To replace

the root broker with an existing authentication hierarchy, refer to the Replace

the root broker on the SLIM server section in Appendix E for detailed procedures.

In this SLIM version, the SLIM management server is supported only on Solaris.


In this use cases chapter, the SLIM management server and agents are primarily

deployed and verified on the Solaris and AIX platforms. A SLIM management

server that is configured on Solaris is able to work with management agents that

are deployed on Windows and others UNIX/Linux platforms. In this setup,

management agents that are installed on AIX and Windows platforms are also

configured to report to the SLIM management server on Solaris.

Application server

The SLIM management server and agent can be installed on respective systems

and they do not depend on the existence of Symantec application server such as

SF or SFCFS to be installed first.

SLIM management server collects the licensing information on systems that have

Storage Foundation, NetBackup, and CommandCentral across UNIX/Linux and

Windows platforms.

SLIM management server

In this setup, the SLIM management server is deployed on a dedicated Solaris

system that runs the Solaris 9 operating system. Common core services products

that SLIM depends on are also installed by the SLIM installation script. The

common core services products include Authentication, Private Branch Exchange,

Service Management Framework, and Web Server Service. Users who access the

SLIM Web console must be authenticated through a valid authentication domain

and plug-in.

A valid product license key is required to install the SLIM management server.


138

To install and configure SLIM management server on Solaris

1 Navigate to the directory that has the SLIM installation files. The directory

can be in a file system that is mounted on a CD-ROM or DVD drive or a

Network File System.

cd <path>/Server/Solaris

# ls install

install

# ./install

If you agree enter "YES", otherwise enter "NO".

YES

1. Symantec License Inventory Manager Server

2. Symantec License Inventory Manager Access Point

Continuing Installation

Please indicate your choice [1|2] :1

Enter license key :<enter SLIM server license key>

Enter the system names separated by spaces on which to install

SYMClms: belinda.universe.com

2 Symantec License Inventory Manager is made up of the following packages,

shown on the following screen:

Installing VRTSdbms3 3.0.21.0

on belinda.universe.com........................ done 1 of 4 steps

Installing VRTSjre 1.4


Installing VRTSweb 4.2


Installing SYMClms 4.0.21.15


3 The SLIM installation script checks for the common core services components

(PBX, AT, and SMF) on the system before installing the SLIM product. These

shared components are installed for the SLIM product if they are not present,

or if older versions of the same components are found on the system.

4 A log file is created during the installation. Look in the log file and verify that

there are no error messages or non-zero return codes.


5 The SLIM installation script configures a root plus authentication broker on

the local system for the SLIM management server. Move the authentication

broker that is created for the SLIM management server into another

authentication hierarchy. After the authentication broker is migrated to an

existing authentication hierarchy, the SLIM root broker should cease to exist.

See “Verifying the SLIM server setup” on page 295.

6 After the SLIM product has been installed and configured, the verification

procedures listed in the Verify SLIM server setup section in Appendix E should

be used to ensure that the SLIM management server is functional and working

correctly.

SLIM management agents

A system that has the SLIM Management Server configured can have Management

Agents or Client of other Management Servers deployed as well. These Agents or

Clients may or may not have the authentication enabled. As an example, NetBackup

management client can be installed on the system that has the SLIM management

server.

In this setup, the SLIM management agent is deployed on a Solaris 9 operating

system. This SLIM management agent is configured to report to the SLIM

management server that is configured in the previous section. UNIX/Linux

management agents are assigned to an authentication broker that is configured

on the respective UNIX/Linux platforms.

To install and configure SLIM management agent

1 Navigate to the directory that has the SLIM installation files. The directory

can be in a file system that is mounted on a CD-ROM or DVD drive or a

Network File System.

# cd <path>/Agent/Solaris

# ls -l *install*

-rwxr-xr-x 1 root root 2051 Jul 12 2006 install_lma*

-rwxr-xr-x 1 root root 2055 Jul 12 2006 uninstall_lma*

# ./install_lma

Enter the system names separated by spaces on which to install

LIM:juliet.universe.com

2 Symantec License Inventory Agent is made up of the following package:

SYMClma Symantec License Inventory Agent


140

3 Choose any additional languages to install on the system.

4 The SLIM installation script checks for the common core services components

(PBX, AT, and SMF) on the system before installing the SLIM management

agent. These shared components will be installed for the SLIM product if they

are not present or older versions of the same components are found on the

system.

5 On the Symantec License Inventory Agent Configuration screen, specify the

following configuration data. The Server/Access Point is the name of the

system (assuming belinda is the name of the host) that has the SLIM

management server configured.

Find the root hash on the system where the root broker is located. The

slim_agent is the authentication principal created in the slim_services private

domain repository located on the system belinda.universe.com.

Are you ready to configure LIM on juliet.universe.com? [y, n, q] (y)

Enter the Access Point/Server hostname:belinda.universe.com

Do you want to enable security? [y, n] (n) y

Do you want to configure security at this time? [y, n] (y)

Enter the Authentication Broker hostname: (belinda.universe.com)

Enter the TCP/IP port number for Authentication Broker

belinda.universe.com: (2821)

Enter the certificate hash code for Authentication Broker

belinda.universe.com: (5a08f7de42debf522cd8afaecca02b35bb37d8c4)

Enter the Access Point/Server user name: (slim_agent)

Enter the Access Point/Server user

domain name: ([email protected])

Enter the Access Point/Server user domain type: (vx)

Do you want to start Symantec License Inventory Agent

processes now? [y, n] (y)

6 Look in the log file that is created during the installation, and verify that

there are no error messages or non-zero return codes.


7 Verify that the SLIM management agent is recognized by the Service

Management Framework.

# /opt/VRTSsmf/bin/vxservice --list --processname ICS

vxservice version 1.3.9.0

Symantec Corporation

Copyright 2005 Symantec Corporation. All rights reserved.

Getting the process and service list for process ICS

Process Name: ICS

Service Name: lma

8 To remove the SLIM management agent package (SYMClma), navigate to the

directory that has the SLIM installation files, and then invoke the uninstall

script.

# cd <path>/Server/Solaris

# ./uninstall_lma

9 After a SLIM management agent is installed successfully, verify that the SLIM

management agent is configured to report to the correct SLIM management

server.

See “Verifying the SLIM agent setup” on page 297.

It is possible to add a SLIM management agent on Windows and report to a SLIM

management server on Solaris. To add a Windows SLIM management agent, the

procedures and steps listed in the SLIM management agents section in Chapter

7 should be used.

A system that has the SLIM management agent installed could have management

agents or clients of other management servers installed as well. These other agents

or clients may or may not have the authentication enabled. As an example,

CommandCentral storage agent can be installed on the system that has the SLIM

management agent.


When installing the SLIM product in an enterprise that already has the

authentication hierarchy, the root broker that is configured by the SLIM product

can be replaced and point to the existing root broker on another system.


SLIM-related upgrade

SLIM upgrade typically involves one or more of the following components:


142

■ SLIM component itself (management server or agents)

■ One or more of the common core services components (PBX, AT, and SMF) on

which SLIM depends

Before upgrading the SLIM component on the system, stop the SLIM service. To

upgrade the SLIM management server, follow the instructions in the SLIM

installation guide or release notes that come with the SLIM product. New releases

may have additional steps that require the SLIM administrator to perform during

the upgrade. On the systems that have the SLIM management agents, the upgrade

can proceed after the SLIM management server has been successfully upgraded.

After the upgrades, verify the SLIM server and SLIM agent setup to ensure that

the SLIM management server is able to pull licensing information through the

management agents.



Usually, the upgrade of the SLIM component on a system does not affect the

common core services components SLIM depends on. However, the SLIM

administrator should always consult the SLIM documentation that comes with

the upgrade to make the final determination.

Because SLIM depends on the common core services to upgrade one or more of

these components, the SLIM management server and the affected core services

must be stopped first. You should perform the upgrade for these core services

and verify that these services are started successfully. You should also stop and

start other core services, even though those shared components were not upgraded.

You should start the SLIM management server and verify the successful logon to

the SLIM Web console.

If an upgrade is required for the Symantec Product Authentication Service, refer

to the following section for further information related to the Authentication

shared component prior to the upgrade.

See “ Authentication and authorization service upgrade” on page 75.

The startup and shutdown procedures for the SLIM and core services components

are included in the Replace the root broker on the SLIM server section of Appendix

E.

Storage Foundation use caseThe following Veritas Storage Foundation products are used throughout this

section:

143Symantec solution: UNIX/Linux use casesStorage Foundation use case

■ Storage Foundation, which consists of Veritas Volume Manager, Veritas File

System, and optionally, Veritas Volume Replicator.

■ Storage Foundation for Windows, which consists of Veritas Volume Manager,

and optionally, Veritas Volume Replicator.

■ Storage Foundation Cluster File System (SFCFS) which consists Veritas File

System, Veritas Cluster Server (VCS), and the cluster functionality (shared

volumes) of Veritas Volume Manager.

■ Storage Foundation for Oracle RAC, which consists of SFCFS plus the Veritas

add-on functionality for use with Oracle databases.

On the systems where these application servers are deployed, management agents

or client of other management servers are installed. For example, on a VCS cluster

with SF Oracle RAC, on each node of the VCS cluster, the following management

client and agents could be present.

Figure 6-6 shows deploying Storage Foundation.

Figure 6-6 Deploying Storage Foundation

■ NetBackup management client

■ CommandCentral Storage or Service management agent

■ Symantec License Inventory Manager management agent

These management client and agents are set up to report to the respective

management servers that are illustrated in this use case chapter. Refer to the

Symantec solution: UNIX/Linux use casesStorage Foundation use case

144

respective product use case section for instruction on how to set up a management

agent or client on a system.


In this use case chapter, the Storage Foundation products (SF, SFCFS and SF Oracle

RAC) are deployed on UNIX (Solaris, AIX) and Windows (SFW) platforms.

Application server

Storage Foundation uses the authentication product to authenticate users who

access the VCS configuration data and the Veritas Enterprise Administrative

console. Users must be authenticated through the Symantec Product

Authentication when they access the Veritas Enterprise Administrator console.


that is used with Storage Foundation.

Table 6-11 Storage Foundation dependency on shared component

Authentication serviceStorage Foundation

4.34.24.1

4.1MP1

5.0

Throughout this use case chapter, the Storage Foundation product is installed on

a single system with a Veritas management server, such as NetBackup, SLIM, or

CC. Storage Foundation is not integrated with Symantec Product Authentication

Service. It is possible for Storage Foundation to be installed on the system with a

management client such as NetBackup and management agents such as CC and

SLIM. This installation procedure is interactive and requires that you provide

values to the prompts. A valid product license key is required to install Storage

Foundation.


To install and upgrade Storage Foundation on a Solaris 9 system

1 Navigate to the directory that has the SF distribution files and invoke the

installer script.

2 Change directory to where the installation files are located.

# cd <mnt>/cd1

# ls

file_system/ volume_manager/ installer

# ./installer

3 To upgrade the Storage Foundation, navigate to the directory that has the

distribution files.

# cd <mnt>/4.1MP1

# ./install_vp

Most of the time, SFCFS or SF for Oracle RAC is installed on a set of systems that

share a set of hardware resources, such as storage. On each of the systems, the

management client (NetBackup) and the management agents (CC and SLIM) are

installed. These management client or agents report to their respective

management servers that are configured on separate systems, respectively.

Versions 4.1MP1 on Solaris and 5.0 (and later) on UNIX/Linux platforms are

integrated with Symantec Product Authentication.

To install and upgrade Storage Foundation Cluster File System 5.0 on a VCS cluster

running AIX 5.3

1 Navigate to the directory that has the SFCFS distribution files and invoke the

installer script. The following session illustrates the sample installation and

configuration steps pertaining to the SFCFS and Symantec Product

Authentication:

# cd <mnt>/dvd1

# ls

installer

storage_foundation_cluster_file_system/

# ./installer -rsh

2 Enter the system names, separated by spaces, on which to install the product.

Enter the Storage Foundation license key.


146

3 The authentication portion of the configuration is illustrated as follows:

Would you like to configure SFCFS to use

Symantec Security Services? [y,n,q] (n) y

Security Menu

1) Configure security completely automatically

2) Provide AB credentials using BLOBs

3) Provide AB credentials without using BLOBs

Select the Security option you would like to perform [1-3,q,?] (1)

Enter the name of the VxSS Root Broker system: neptune.universe.com

4 After the installation and configuration is complete and all the systems have

been restarted, run the following commands to verify the authentication

configuration:

# /opt/VRTS/bin/hastatus -sum

Group System Probed AutoDisabled State

B VxSS larissa Y N ONLINE

B VxSS ariel Y N ONLINE

# /opt/VRTSat/bin/vssat showbrokermode

Broker mode is : 1

5 Additional verification information is available in the Appendix A.

6 To upgrade SFCFS, in the directory that has the installation files, invoke the

install_vp script to begin the upgrade.


When you install the SFCFS or SF for Oracle RAC in an enterprise that already

has the authentication hierarchy, you should use existing root broker and create

new authentication brokers in the existing authentication hierarchy.

Storage Foundation-related upgrade

After the upgrade of SFCFS/SF Oracle RAC is complete, verify that the Storage

Foundation application server works with the shared products that are configured

on the system.

If one or more of the shared products are upgraded, while the storage foundation

software remains unchanged, the proper operation of the storage foundation

(with Authentication enabled) product must be verified through the normal uses.

If there are other Symantec agents installed on the same systems as the storage


foundation product, ensure that the new version of the shared components work

with the management agents that are already present on the system. Most of the

time, it is prudent to test the configuration in a test environment before deploying

the new version of the shared components to the production environment.


148

Symantec solution:

Windows use cases


■ Deploy Symantec products on Windows

■ Determine a broker infrastructure

■ Symantec License Inventory Manager use case

■ NetBackup use case

■ NetBackup Operations Manager use case

■ CommandCentral Storage and Service use case

■ Storage Foundation use case

Deploy Symantec products on WindowsIn this use case, a predominantly Windows-based enterprise has purchased the

following Symantec products to meet the growing demands of the company’s

computing capacity and capability:


■ NetBackup

■ NetBackup Operations Manager


■ Storage Foundation HA on Windows

7Chapter

Included with the purchase were Symantec core services products, such as Private

Branch Exchange, Authentication, or Authorization and Service Management

Framework. One or more of these core services products are used by the Symantec

products. After the core services products are installed on a system, they are

shared by any Symantec products that need them.

Figure 7-1 shows a high-level deployment layout.

Figure 7-1 Deployment of Symantec products on Windows

Symantec solution: Windows use casesDeploy Symantec products on Windows

150

The approach chosen by the implementation team is to deploy these Symantec

products into the enterprise data center in three major phases. A new management

server and the accompanying application server, management agents, clients are

added in each phase.

The enterprise is security conscious, so the corporate security architect has decided

to implement these Symantec products with Symantec Product Authentication

and Authorization. To help the enterprise security architect and security

implementation team achieve the objectives listed in the Customer Benefits section

in Chapter 1, this chapter provides step-by-step instructions on how to individually

configure these Symantec products with authentication and authorization

capabilities.

See Determine a broker infrastructure for details on the layout for the


Determine a broker infrastructureBefore starting the implementation, the enterprise security team developed the

broker schema and laid the foundation for the root and authentication brokers.

All the management servers listed in Figure 7-1 need an authentication broker

configured on the systems where the management servers are located.

Using the deployment guidelines and best practices discussed in Multiproduct

deployment approach, the enterprise security team maps the Symantec products

depicted in Figure 7-1 into an authentication hierarchy illustrated in Figure 7-2.

151Symantec solution: Windows use casesDetermine a broker infrastructure

Figure 7-2 Placement of root and authentication brokers on Windows

The information that is depicted in Figure 7-2 is used to guide the implementation

team on the deployment of the Symantec products enabled with authentication

and authorization.

In this environment, only one authentication hierarchy is set up. The Symantec

Product Authentication root broker is installed and configured on the same system

as the Symantec License Inventory Manager. All the management servers (such

as SLIM, NBU/NOM and CommandCentral) are installed and configured on separate

systems with their respective authentication brokers.

Symantec solution: Windows use casesDetermine a broker infrastructure

152

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.

Symantec License Inventory Manager use caseIn this use case, the Symantec License Inventory Manager (SLIM) uses Symantec

Product Authentication mechanism to authenticate users accessing the SLIM Web

administrative console. An Authentication broker is set up with the appropriate

plug-ins and made available to the SLIM Web console to authenticate users. After

SLIM is configured, users in the slim_users private domain repository are able to

log on to the SLIM Web console.


order:

■ Storage Foundation. Installing the Symantec application server is optional.

■ Infrastructure Core Services (Private Branch Exchange, Authentication, and

Service Management Framework).

■ Symantec License Inventory Manager.

■ Management client or agents from other Symantec products, such as NetBackup

or CommandCentral).

The Symantec License Inventory Manager collects licensing information from

the other Symantec products that are installed on various systems in the

enterprise. SLIM consists of a management server and a management agent. The

management agent collects the licensing information and reports it to the

management server. The management server stores the licensing data in a central

repository. The SLIM management agent is typically deployed on systems that

have NetBackup, CommandCentral, Storage Foundation, and other Symantec

products installed.

Figure 7-3 shows the deployment of SLIM in an enterprise.

153Symantec solution: Windows use casesSymantec License Inventory Manager use case

Figure 7-3 Deploying Symantec License Inventory management server and

agent

It is highly recommended that you install and configure the SLIM management

server on a system without other management servers installed. After the

management server is configured and functional, you can install the management

agent.

The SLIM product versions used in this Yellow Book edition are listed in Table 7-1.

This SLIM version is dependent on the infrastructure that is provided by the

Symantec Product Authentication Service (AT), Private Branch Exchange (PBX),

and the Service Management Framework (SMF) core services components. On

systems that have the SLIM management server, access points, and management

agents, these shared components must be installed and configured. You can install

and configure these shared components manually, or you can let the SLIM installer

automatically install them. SLIM management server uses the Web Server Service

for console logon.

Table 7-1 Symantec License Inventory Manager shared component

dependencies

SMFPBXAuthentication serviceSLIM

1.31.21.31.24.34.24.1

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.


Symantec solution: Windows use casesSymantec License Inventory Manager use case

154


The SLIM management server and agents are deployed and verified primarily on

the Windows platform. A SLIM management server that is configured on Windows

is able to work with management agents that are deployed on UNIX and Linux

platforms. In this setup, the management agents that are installed on HP-UX and

Red Hat platforms are configured to report to the SLIM management server on

Windows.

Application server

The SLIM management server and agent can be installed on their respective

systems. They do not require the installation of a Symantec application server

such as Storage Foundation for Windows or Storage Foundation HA for Windows.

The SLIM management server can collect the licensing information from any

systems that have Storage Foundation, NetBackup, and CommandCentral installed

across UNIX/Linux and Windows platforms.

Deploy the Symantec License Inventory Manager management serveron Windows

In this use case, the SLIM management server is deployed on a dedicated Windows

system that runs the Windows Server 2003 Enterprise Edition SP1 operating

system. The shared core services products on which SLIM depends are installed

by the SLIM installation script. The shared core services products include

Authentication, Private Branch Exchange, Service Management Framework, and

Web Server Service. Any user who accesses the SLIM Web console must be

authenticated through a valid authentication domain and plug-in. A valid product

license key is required to install the SLIM management server.

To deploy the SLIM management server on Windows

1 Navigate to the directory that contains the Symantec License Inventory

Manager installation media and locate the setup file, subtypes.

2 Double-click subtypes. The Choose Setup Language dialog displays. Use this

window to select additional languages to install.

3 Click I accept the terms in the license agreement radio button, and then click

Next.

4 On the Symantec License Inventory Manager – InstallShield Wizard panel,

highlight the Symantec License Inventory Server, type the license key in the

Enter license key field, and then click Next.


5 Check each check box that corresponds to each language that you want to

install, and then click Next.

6 In the Ready to Install Program window, click Install.

7 In the InstallShield Wizard Completed window, click Finish.

8 Go to Control Panel >Add orRemove Programs and verify that the SLIM

management server, Private Branch Exchange, Authentication, and Service

Management Framework were installed successfully.


A system that has the SLIM Management Server configured could have

Management agents or client of other Management Servers deployed as well.

These agents or clients may or may not have the authentication enabled. As an

example, a NetBackup management client could be installed on the system that

has the SLIM management server.

Deploy SLIM management agents on Windows

In this use case, the SLIM management agents are deployed on the following

systems:Windows running Windows Server 2003 Enterprise Edition SP1, HP

running HP-UX 11.23 (either PA-RISC or IA64) and Red Hat running EL 4.0 on

32-bit mode. These SLIM management agents are configured to report to the same

SLIM management server. SLIM Management agents on Windows are assigned

to an authentication broker that is configured on Windows. On HP-UX and Red

Hat platforms, the SLIM management agents are authenticated by authentication

brokers that are configured on HP-UX and Red Hat, respectively.

On Windows, you can install a SLIM management agent and configure it to report

to a SLIM management server that is configured on Windows.

1 Navigate to the directory that has the SLIM installation files and click

setup.exe.

2 Select the setup language and any additional languages to install on the

system.

3 On the Symantec License Inventory Agent Configuration screen, specify the

following configuration data. The Server/Access Point is the name of the

system (in this example, mercury) that has the SLIM management server

configured.

Server/Access Point hostname mercury

Enable Security Yes

Configure Security at this time Yes

Start agent after Install Yes

Symantec solution: Windows use casesSymantec License Inventory Manager use case

156

4 Copy the root hash file from the system with the root broker to the local

system on which you want to install the SLIM agent. The username is the

slim_agent authentication principal that is created in the slim_services private

domain repository that is located on the system mercury (on Windows, use

the short host name and not an FQHN such as mercury.universe.com). In

this example, all the Windows systems belong to the Windows private domain

named sun.

Authentication Broker Hostname mercury

Authentication Broker Port Number 2821

Authentication Broker Hash c:\TEMP\root_hash

Access Point/Server username slim_agent

Access Point/Server

domain name [email protected]

Access Point/Server domain Type vx

Follow the prompts.

5 Click Install to install the SLIM management agent, and then click Finish.

6 Go to Control Panel, and then select Add or Remove programs to verify that

the SLIM management agent, Private Branch Exchange, Authentication, and

Service Management Framework were installed successfully.

7 After a SLIM management agent is installed successfully, verify that the SLIM

management agent is configured to report to the correct SLIM management

server.


To install a SLIM management agent on HP-UX or Red Hat, and configure it to

report to the SLIM management server on Windows, refer to the following section:

See “SLIM management agents” on page 140.

A system with the SLIM management agent installed can also have management

agents or clients of other management servers installed. These other agents or

clients may not have the authentication enabled. For example, the

CommandCentral storage agent may be also installed on the system that has the

SLIM management agent.


When you install the SLIM product in an enterprise that already has the

authentication hierarchy, you should consolidate the root broker that is configured

by the SLIM product with the existing authentication hierarchy. Whether to keep

the existing root broker, or the root broker configured by SLIM, is a decision that

is specific to the enterprise. Nevertheless, it is highly recommended that one


authentication hierarchy be used throughout the enterprise. If you keep the

existing root broker, you must replace the root broker that is created by the SLIM

installation with the existing root broker on another system.


Symantec License Inventory Manager-related upgrade

A Symantec License Inventory Manager upgrade typically involves one or more

of the following components:

■ Symantec License Inventory Manager (management server or agents)

■ One or more of the shared core services components on which the Symantec

License Inventory Manager depends

Before you upgrade the SLIM component on the system, you must stop the SLIM

service. To upgrade the SLIM management server, you must follow the instructions

in the SLIM installation guide. A new release may have additional steps that are

required during the upgrade. On systems that have the SLIM management agents,

you can upgrade the agents after you upgrade the SLIM management server.



Usually, the upgrade of the SLIM component on a system does not affect the

shared core services components on which SLIM depends. However, it is a good

idea to consult the SLIM documentation that comes with the upgrade before

making the final determination.

SLIM is dependent on the shared core services. To upgrade one or more of these

components, you must first halt the SLIM management server and the affected

core services. You must upgrade these core services and verify that these services

started successfully. Also, you must stop and start the other core services even

though those shared components were not upgraded. You can start the SLIM

management server and verify successful logon to the SLIM Web console.

See “ Authentication and authorization service upgrade” on page 75.


NetBackup use caseIn this use case, NetBackup uses the authentication mechanism that is provided

by the Symantec Product Authentication Service to authenticate ordinary users

accessing the NetBackup subsystems. After obtaining valid authentication

credentials, ordinary users can perform product management through the

Symantec solution: Windows use casesNetBackup use case

158

product’s administrative Web console and execute privileged NetBackup commands

from the command line. One or more Authentication brokers are set up with the

appropriate plug-ins to authenticate NetBackup users (including the administrator)

and services (NetBackup media servers and clients). The Authorization service is

also set up on the system where the NetBackup master server is configured. After

a user has acquired a valid authentication credential, the access control

functionality that is provided by the Symantec Product Authorization is used to

decide which operations the user is permitted to do, for example, policies and

storage unit manipulation.


order:

■ Storage Foundation (this is optional unless Veritas Volume Manager is

required).

■ Infrastructure Core Services (Private Branch Exchange, authentication and

authorization). Authentication and authorization products are required for

enabling NetBackup Access Control.

■ NetBackup.

■ Management agents from other Symantec products (for example,

CommandCentral, Symantec License Inventory Manager).

NetBackup provides backup and recovery services for the systems that are deployed

throughout the enterprise. NetBackup has management servers (master and

media) and management client (or simply client) components. You can configure

a NetBackup policy on the Master server for a client that contains data to back

up. A backup is typically initiated from the master server. During the backup, a

client reads the data from the system and sends it to the media server and then

to a storage unit. Usually, the NetBackup management client is deployed on the

systems that have SLIM, CommandCentral, Storage Foundation, and other

Symantec products installed.

Figure 7-4 depicts the deployment of NetBackup in an enterprise.

159Symantec solution: Windows use casesNetBackup use case

Figure 7-4 Deploying NetBackup management server and clients

It is highly recommended that you install and configure the NetBackup and

NetBackup Operations Manager (NOM) master management server on a system

that is reserved exclusively for this management server. After you configure the

master server, you can install the media management servers. You install the

NetBackup management clients last. To verify that the setup is functional, you

can initiate a backup from the master server for a client using one of the media

servers and restore the backup to a different client.

Referring to Figure 7-2, on the system that has the NetBackup master management

server, an authentication broker and the authorization service are also configured.

Additional authentication brokers may be required and configured on systems

that have media servers. Typically, each authentication broker is configured for

an authentication domain with a specific plug-in. When you add new authentication

brokers to an existing authentication hierarchy, you must perform preparatory

steps for these brokers from the system with the existing root broker.

The configuration of NetBackup and with Access Control (authentication and

authorization) requires two separate configuration procedures. You must add the

Access Control capability to NetBackup after the management servers (master

and media) and management clients are configured and functional.

A large enterprise may need multiple NetBackup master servers configured for

different backup and recovery purposes. The following procedures and

configuration instructions for NetBackup can be repeated when adding new

NetBackup management servers (master and media) and clients with Access

Control.


160


Windows is the primary platform on which the NetBackup management servers

(master and media) and clients are deployed and verified. The NetBackup master

management server also manages, in addition to the Windows platform, the

NetBackup media management servers and management clients that are

configured on UNIX and Linux platforms with HP-UX and Red Hat operating

systems.

Application server

On Windows, by default, the binaries and data files for the NetBackup management

servers and clients are installed in the C:\Program Files directory on their

respective systems. To install the NetBackup product on a separate Microsoft file

system that uses Veritas Volume Manager, you must first install a Symantec

application server such as Storage Foundation for Windows or Storage Foundation

HA for Windows.


NetBackup management servers

The versions of the NetBackup product and the shared infrastructure core services

components on which NetBackup depends are listed in the tables contained in

the Master server and Media servers sections below. Starting with the NetBackup

6.0 release, Private Branch Exchange is required by the NetBackup master and

media servers. On Windows, the NetBackup installer automatically installs PBX

on a system (if it is not yet installed) with either a master or media server. Before

you configure a master server or a media server for access control (enable

authentication and authorization), you must first install Symantec Product

Authentication and Authorization on the system. On a system with the NetBackup

master management server, you must first configure a local authentication broker

and authorization service. On a system with a NetBackup media management

server, only the client portion of Symantec Product Authentication and

Authorization is required.

Note: To add a master server to an enterprise or to add a new media server to an

existing master server, you can repeat the procedures in this section on each new

system.


Master server

It is recommend that you install the NetBackup master server on a system on

which only this management server is active and running.

Table 7-2 shows the version of the NetBackup product and the corresponding

version of the Private Branch Exchange shared component that is used by the

NetBackup master server.

Table 7-2 NetBackup master server dependency on Private Branch Exchange


1.31.2

6.0MP4

The NetBackup master management server is installed on a Windows Server 2003

Enterprise Edition SP1 operating system. This master management server also

manages NetBackup media servers and clients that are configured on Windows,

HP-UX, and Red Hat. You must enter a valid license key during the NetBackup

installation. The NetBackup installer checks for the presence of the PBX shared

component and verifies that the PBX service is started. See the Install and

configure Private Branch Exchange section in Appendix B for installation

instructions. The NetBackup installer performs neither authentication nor

authorization related configuration.

To install and configure a NetBackup master management server on Windows

1 In Windows Explorer, navigate to the directory that has the NetBackup

installation files, and then click launch.exe.

2 On the Veritas NetBackup for Windows screen, select the NetBackup

Installation and Install Server Software options.

3 On the License Agreement screen, click accept.

4 On the NetBackup Installation Type screen, select Typical installation and

choose the Install to this computer only option.

5 On the NetBackup License Key and Server Type screen, enter the NetBackup

license key. The license key determines the options (master, media, or remote

administrative console) that are available for the installation.


162

6 On the NetBackup System Names screen, in the Master Server Name: field,

enter the host name (short form) of the system on which to install the

NetBackup master management server. Specify additional servers in the

Additional Servers field. In this use case, the host name for the NetBackup

master management server is jupiter (the FQHN is jupiter.universe.com).

Master Server Name: jupiter

Additional Servers:

7 On the NetBackup Enterprise Media Manager (EMM) screen, enter the host

name of the system on which to locate the EMM database as shown below. In

this use case, the EMM database is installed on the same system as the

NetBackup master server.

Enterprise Media Manager Server: jupiter

8 On the Ready to Install the Program screen, click Install to begin the

installation of the NetBackup master management server. The Installing

NetBackup screen displays the progress of each installation step, including

Validating install, Copying new files, Starting services, and Creating

NetBackup template policies.

9 On the System Validation Complete screen, to add additional NetBackup

license keys, click the Add keys and enter more license keys. In this setup, a

tape library is shared (SSO) among all the media management servers and a

license key is required to enable the SSO option. The configuration of

NetBackup involves the following tasks:

■ Configure Storage Devices

■ Configure Volumes

■ Configure the Catalog Backup

■ Create a Backup Policy

On the NetBackup Administrative Console screen, NetBackup provides

configuration wizards to assist a NetBackup administrator with these

configuration tasks. Before performing the Storage Devices configuration,

the physical devices must be already connected to the system. The

device-drivers software that is distributed by the NetBackup product must

be installed on the system before you invoke the Configure Storage Devices

configuration wizard.

If the system already has the tape devices attached and has met the conditions

that are listed for the Storage Devices, check the Launch NetBackup

Administrative Console now check box to start the NetBackup configuration.


Otherwise, defer the configuration tasks. Click Finish to exit the System

Validation Complete screen.

10 On the NetBackup Administrative Console, Activity Monitor, select the

Services and Processes to verify that the services and NetBackup processes

are online.

11 To verify that the operating system can see the tape libraries and devices on

a system, see the NetBackup Tape Device Drivers section in Appendix C for

verification procedures.

12 To create a storage unit on the master management server, see the NetBackup

storage units section in Appendix C for details.

13 From the Control Panel, select Add or remove programs and verify that

NetBackup was installed.

14 To install the Java Windows Administration Console on the same system as

the NetBackup master management server, see the NetBackup Java Windows

Administration Console section in Appendix C for detailed procedures.

To upgrade the NetBackup master server software

1 Before you upgrade the NetBackup master server software, stop the NetBackup

management server. Use the following commands to stop and start NetBackup

master management server.

C:\Program Files\VERITAS\NetBackup\bin> bpdown

C:\Program Files\VERITAS\NetBackup\bin> bpup

2 Locate the NetBackup maintenance pack distribution. In Windows Explorer,

navigate to the directory with the NetBackup installation files, and then click

setup.exe.

3 On the NetBackup Installation Type screen, chooseInstall to this computer

only, and then follow the instructions on the screen.

4 On the Ready to Install the Program screen, click Install to start the

installation.

5 On the Installing NetBackup screen, the version of the maintenance pack and

the installation status is displayed.

6 On the System Validation Complete screen, click Finish.

7 Go to Control Panel, Add or remove programs and verify that the maintenance

pack was installed on the system.


164

8 If NetBackup Access Control (NBAC) was enabled on the master management

server, after upgrading NetBackup, verify the NBAC setup.

See “Verify NetBackup access control setup on the master server” on page 246.

9 Start the NetBackup master management server.

On the system that has the NetBackup master management server configured,

management agents of other Management Servers can be deployed. These agents

may have the authentication enabled. As an example, on the system that has the

NetBackup Master Server, SLIM, and CC Service Agents are likely to be found on

the same system.

Media servers

The version of the NetBackup media management server that is used in this Yellow

Book edition is dependent on the service that is provided by the Private Branch

Exchange. The service that is provided by the PBX shared component must be

online before you install the NetBackup media management server.

Table 7-3 depicts the version of NetBackup and the version of the PBX shared

component that is used by the NetBackup media server.

Table 7-3 NetBackup media server dependency on Private Branch Exchange


1.31.2

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.


To install and configure a NetBackup media management server on Windows

1 In Windows Explorer, navigate to the directory that has the NetBackup

installation files and select launch.exe.


Installation and Install Server Software options.

3 On the License Agreement screen, click accept.


pick the Install to this computer only option.

5 On the NetBackup License Key and Server Type screen, enter the NetBackup

license key. The license key determines the options (master, media, or remote

administrative console) that are available for the installation.

6 On the NetBackup System Names screen, in the Media Server Name field,

enter the host name (short form) of the system where the NetBackup media

management sever is to be installed. In the Master Server Name: field, enter

the host name (short form) of the system where the NetBackup master

management server is to be installed. Specify additional servers in the

Additional Servers field. In this use case, the host name for the NetBackup

media and master management servers are leda and jupiter (the FQHNs

are leda.universe.com and jupiter.universe.com), respectively.

Media Server Name: leda


Additional Servers:

7 On the NetBackup Enterprise Media Manager (EMM) screen, enter the host

name of the system where the EMM database is located. In this use case, the

EMM database is installed on the system that has the NetBackup master

management server.

Enterprise Media Manager Server: jupiter


installation of the NetBackup media management server.


166

9 On the System Validation Complete screen, to add additional NetBackup

license keys, click the Add keys and enter more license keys. In this setup, a

tape library is shared (SSO) among all the media management servers and a

license key is needed to enable the SSO option.

Before you perform the Storage Devices configuration for the media

management server, the physical devices must be already connected to the

system with the media server. The device-drivers software that is distributed

by the NetBackup product must be installed on the system before you invoke

the Configure Storage Devices configuration wizard.

If the system already has the tape devices attached and has met the conditions

listed for the Storage Devices, check the Launch NetBackup Administrative

Console now check box to start the NetBackup configuration. Otherwise, defer

the configuration tasks.

Click Finish to exit the System Validation Complete screen

10 On the NetBackup Administrative Console, Activity Monitor, select the

Services and Processes to verify that the services and NetBackup processes

are online.

11 To verify the operating system could see the tape libraries and devices on a

system, refer to the NetBackup Tape Device Drivers section in Appendix C

for verification procedures.

12 To create a storage unit for the media management server, refer to the

NetBackup storage units section in Appendix C for details.

13 From the Control Panel, select Add or Remove Programs and verify that

NetBackup was installed.

14 After the installation is complete, verify that the media's master management

server in the registry is correct. Click Start >Run, and then type regedit.

Verify that the Server registry entry points to the correct master management

server:

HKEY_LOCAL_MACHINE\Software\VERITAS\NetBackup\CurrentVersion\config

If there is a need to install the Java Windows Administration Console on the system

with a media management server, refer to the NetBackup Java Windows

Administration Console section in Appendix C for detailed procedures.

To upgrade the NetBackup software on the a system with media management

server, the same procedure that is used in the Master server section should be

used. The NetBackup software on a media management server is upgraded after

the master management server has been upgraded. If the NBAC was enabled on

a media management server, after upgrading the NetBackup software, the Verify


NetBackup access control setup on media servers procedure listed in Appendix C

should be used to ensure the media management server is working.

See the corresponding NetBackup use case section in Chapter 6 for procedures

and steps to install and configure a NetBackup media management server on UNIX

and Linux.

Adding a media server to the master server

This step is to be performed on the system where the NetBackup master

management server is configured. The host to be added as the media management

server should have the NetBackup media server software installed already.

On the NetBackup Administration Console, go to the NetBackup Management,

Host Properties, Master Server. Highlight the master server, right click and choose

properties. The Master Server Properties: jupiter screen appears, click Servers

Properties, and then click Add. In the Add a new server: field, enter the host name

of the new media server leda, and then click Add. This same procedure is used to

add either a Windows or UNIX/Linux (like HP-UX and Red Hat) media server on

a Windows master server.

On the NetBackup Administration Console, launch the Configure Storage Devices

wizard to configure devices and storage units for the new media management

server (leda).

The addition of a NetBackup 5.1MP6 (or later) media server to a NetBackup 6.0MP4

(or any 6.0 version) master server is a supported configuration.

Installing and upgrading the NetBackup management client onWindows

The NetBackup management client does not depend on the Private Branch

Exchange shared component.

You can apply a maintenance pack to the 6.0 release to upgrade the NetBackup

product to the most recent version.

To install NetBackup management client on Windows

1 In Windows Explorer , navigate to the directory that has the NetBackup

installation files, and then click launch.exe.

2 Choose NetBackup Installation, Install Client Software, Pick Typical and

Install to this computer only.


168

3 Enter the host name (in short format, such as callisto) in the Client Name for

the NetBackup client, and the host name (such as jupiter) in the Master

Server Name: for the master management server. Additional Servers is

optional. Follow the instruction on the screen and verify that the installation

completed successfully.

Client Name: callisto


Additional Servers:

4 From the Control Panel, select Add or remove programs, and then verify that

the NetBackup Client has been installed.

5 After the installation is complete, verify that the client's master management

server in the registry is correct. Click Start >Run, and then type regedit.

Verify that the Server registry entry points to the correct master management

server:


6 You may want to Install Java Windows Administration Console on the system

that has NetBackup client software for remote management. Refer to the

NetBackup Java Windows Administration Console section in Appendix C for

installation procedures.

The upgrade of the NetBackup client software on a management client is done

through these procedures and steps. Typically, the NetBackup software on a

management client is upgraded after the master and media management servers

that are associated with this management client have been upgraded.

To upgrade the NetBackup management client on Windows

1 Locate the NetBackup maintenance pack distribution. On Window Explorer,

navigate to the directory that has the NetBackup installation files, and then

click setup.exe.

2 Click Install to this computer only, and then follow the instructions on the

screen. Verify that the installation Finish successfully.

3 In the Add or remove programs, verify that the maintenance pack has been

installed on the system.

4 If NetBackup Access Control (NBAC) was enabled on a management client,

after upgrading NetBackup, use the Verify NetBackup access control setup

on clients procedure listed in Appendix C to ensure that the master

management server is working.


See the corresponding section in the NetBackup use case section in Chapter 6 for

procedures and steps to install and configure a NetBackup management client on

UNIX/Linux.

Enabling access control on a NetBackup master server

Before you enable NetBackup Access Control (NBAC) on the master management

server, the master management server (and possibly all the media and client)

must be set up and functional.

To verify that the NetBackup configuration is working, a successful backup and

restore initiated from the master for a client using this media server should be a

good indicator.


This approach is helpful for the fault isolation. For example, if backup and restore

is successful without NBAC, but fails with NBAC enabled, you can direct your

troubleshooting effort at the NBAC configuration.

In Table 7-4, cells that have the checkmark depict the specific version of the shared

core services (authentication and authorization) that are used by NetBackup

master management server.

Table 7-4 NetBackup master server dependency on authentication and

authorization

Authorization serviceAuthentication serviceNetBackup

4.34.24.14.34.24.1

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.


170

In this configuration, only an authentication broker is configured on the system

for the NetBackup master management server. The authentication broker is set

up to use an existing authentication hierarchy that is already configured on the

system with the SLIM management server. To add a new authentication broker

into an existing authentication hierarchy, refer to the Add a new authentication

broker section in Appendix B. Refer to the Install and configure authentication

section in Appendix B for the installation procedures.

Note: On the root broker, when adding the NetBackup principal for the new

authentication broker, the host name (either FQHN like jupiter.universe.com

or short name like jupiter) should be used as the principal name. This

authentication principal that names a convention is required by the NetBackup

release that is used in this Yellow Book edition.

On the system where the NetBackup master management server is installed, the

authorization server is configured also. Due to the dependency between

authentication and authorization, authorization should be installed after the

authentication service. To install the authorization shared component, refer to

the Install and configure authorization section in Appendix B for the installation

procedures.

To enable Access Control on a NetBackup master server

1 A NetBackup master management server has been installed and configured

on a Windows system (jupiter.universe.com) running Windows Server

2003 Enterprise Edition SP1 operating system. Procedures are provided to

enable the NBAC on the master management server.

2 Verify that the NetBackup management server is online.

C:\Program Files\VERITAS\NetBackup\bin> bpps


3 Create the authentication domain, NBU_Machines, for the NetBackup

management server. Suppose NetBackup master management server is

configured on system jupiter.universe.com running Windows Server 2003

Enterprise Edition SP1 operating system. In this setup, the system named

jupiter belongs to the private domain named SUN on the Windows Active

Directory. The Windows private domain name is added to the Fully Qualified

Host Name for the authentication broker.

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

-addmachine

Does this machine use

Dynamic Host Configuration Protocol (DHCP)? (y/n) n

Authentication Broker: jupiter

Authentication port[ Enter = default]: Machine Name: jupiter

Password: <pick a password for jupiter> Password: ******


C:\Program Files\VERITAS\Security\Authentication\bin> vssat \

listpd --pdrtype ab



listpdprincipals --pdrtype ab -domain \

[email protected]


Principal Name: jupiter.sun.universe.com


172

4 Obtain a valid credential for the master management server.

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




Authentication port[ Enter = default]: Machine Name: jupiter

Password: <pick a password for jupiter>


C:\Program Files\VERITAS\NetBackup\bin> bpnbat -whoami -cf \

..\var\vxss\credentials\jupiter.sun.universe.com

Name: jupiter.sun.universe.com


Issued by: /CN=jupiter.universe.com/ \

[email protected]/O=vx




5 Create an ordinary user at the operating system level to set up the security.

An ordinary user (goku) is created in the Windows Active Directory.

C:\Program Files\VERITAS\NetBackup\bin\admincmd> bpnbaz \

-SetupSecurity jupiter -Server jupiter

Please enter the login information for the first Security

Administrator other than root/Administrator. This identity

will be added to the security administrators group

(NBU_Security Admin), and to the netbackup administrators

group (NBU_Admin). It will also be used to build the initial

security information.



Authentication type (NIS, NIS+, WINDOWS, vx, unixpwd): WINDOWS

Domain: SUN

Login Name: goku

Password: <goku password>

Processing - please be patient Operation completed successfully.


6 To find the Domain for WINDOWS (nt) Authentication type, use the following

command:


showallbrokerdomains

Broker Name: jupiter.SUN.universe.com

Broker Port: 2821

Domain Name: SUN

Domain Type: nt

7 Add the following master management server as the host that is authorized

to perform Authorization check:


-AllowAuthorization jupiter \

-server jupiter


To start the second portion of the NBAC configuration, log on to the system that

has the NetBackup master management server enabled with NBAC and invokes

the NetBackup Administration Console through Start, NetBackup Administration

Console.

To enable Access Control from the NetBackup Administration Console server

1 Expand the Host Properties and click the Master Servers, select jupiter as the

master server by clicking the host. In the Status column, it should show

Connected. Click Actions (at the top) and select Properties... On the

Properties… screen, select the Access Control (third from the bottom). In the

Veritas Security Services (VxSS) box, choose Automatic.For the usage on the

VxSS tab, Required, Prohibit and Automatic, refer to the NetBackup access

control parameters section in Appendix C for explanation.

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 systemjupiter.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.


174

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.

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




Domain: SUN

Login Name: administrator

Password: <pick a password for jupiter>


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

Name: administrator

Domain: SUN

Issued by: /CN=jupiter/[email protected]/O=vx


Authentication method: Microsoft Windows


C:\Program Files\VERITAS\NetBackup\bin\admincmd> bpnbaz -adduser \

"NBU_Security Admin" nt:SUN:administrator



"NBU_Admin" nt:SUN:administrator



"NBU_Admin" nt:SUN:goku


6 Verify that the NetBackup master management server is set up correctly.

See “Verify NetBackup access control setup on the master server” on page 246.



176

7 Without invoking bpnbat -login, operations attempting to access the

NetBackup subsystems would fail with this error message.

C:\Program Files\VERITAS\NetBackup\bin\admincmd> bpnbaz -listgroups

Supplied credential is expired or incorrect. Please reauthenticate

and try again. (25)

8 Log on to the Windows system as either vxss or root. Invoke the NetBackup

Administration Console and verify the user’s Web credential, within

Administration Console, click Help (at the top) and select Current NBAC User.


Enabling access control on a NetBackup media server

Before you enable NetBackup Access Control (NBAC) on a media management

server, the media server must already be configured and associated with a master

server. The master server uses this media server for backing up and restoring

NetBackup clients.

To verify that the NetBackup configuration is working, you can use a media server

to run a successful backup and restore that is initiated from the master for a client.


This approach is helpful for fault isolation. For example, if backup and restore is

successful without NBAC, but fails with NBAC enabled, you can direct your

troubleshooting effort at NBAC configuration.

Table 7-5 shows the specific version of the shared core services (authentication

and authorization) that are used by the NetBackup media management server.

Table 7-5 NetBackup media server dependency on authentication and

authorization

Authorization clientAuthentication clientNetBackup

4.34.24.14.34.24.1

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


authentication broker to be configured on the system that has a NetBackup media

management server. Even though an authentication broker is available locally,

the NetBackup media management server should use a remote authentication

broker that is configured on the master management server.

The NetBackup master management server is configured on Windows and it has

media servers that are configured on HP-UX and Red Hat to back up those

management clients. To authenticate users on HP-UX by using the NISPLUS

plug-in (for example), an authentication broker with the NISPLUS plug-in must

be set up. Ideally, this authentication broker should be set up on the same system

as the media management server on HP-UX to authenticate those users on HP-UX.

Similarly, an authentication broker with the UNIXPWD plug-in could be set up

on the system with the Red Hat operating system to authenticate those Red Hat

users that want to use the UNIXPWD plug-in.



The NetBackup master management server has a media management server. Both

servers are on Windows. The media management server uses the authentication

broker that is configured on the master management server. Another management

agent such as SLIM is installed on the same system as the media management

server. The SLIM agent may require a local authentication broker to be present.

In this scenario, the NetBackup media management server does not use the local


To set up the NBAC functionality on the media management server, the following

procedures have been tested and proven to work using the configuration described

in this use case chapter. The first portion of these procedures is done from the

command line. The NetBackup Administration console is used to complete the

second portion of the setup.

A NetBackup media management server has been installed and configured on a

Windows system (leda.universe.com) that runs Windows Server 2003 Enterprise.

This media server is associated with a master management server that is

configured on a Windows system (jupiter.universe.com) that runs the Windows

Server 2003 Enterprise operating system. Procedures are provided to enable the

NBAC on the media management server. These procedures can be used for adding

a media management server that is configured on other Windows platforms.

See “Enable access control on a NetBackup media server” on page 108.

To enable NBAC on a media management server that is configured on a dedicated

system, you must install the client portion of the authentication and authorization

products on the system. The client portion of the authorization product should

be installed on the system that has the media management server. Due to the


178

products dependency between authentication and authorization, authorization

should be installed after the authentication product.


To enable access control on a NetBackup media server

1 Procedures described in this setup must be executed on the master

management server – jupiter.universe.com.

2 Create an authentication principal for the system that has the media

management server.


-addmachine





Machine Name: leda

Password: <pick a password for leda>

Password: <pick a password for leda>



listpdprincipals --pdrtype ab \


Principal Name: leda.sun.universe.com

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

jupiter.sun.universe.com

leda.sun.universe.com


3 Procedures described in this step must be executed on the system with the

new media management server: leda.universe.com. Obtain the machine

credential for the system leda.universe.com.


-loginmachine





Machine Name: leda

Password: *****



..\var\vxss\credentials\leda.sun.universe.com

Name: leda.sun.universe.com






4 Procedures described in this step must be executed on the master management

server: jupiter.universe.com. Authorize the system with the media

management server to perform authorization check:


-AllowAuthorization leda -server jupiter



-Showauthorizers -server jupiter

Type: User

Domain Type: vx


Name: leda.sun.universe.com


server – jupiter.universe.com. To start the second portion of the NBAC

configuration, log on to the system as either administrator or a NBAC enabled

user, go to Start menu and launch the NetBackup Administration Console.


180

6 Expand the Host Properties, click Media Servers, and then select leda as the

media server by clicking the host. The Status column should show Connected.

7 In Click Actions (at the top) and select Properties... On the Properties… screen,

select the Access Control.

8 In the Veritas Security Services (VxSS) box, choose Automatic For the usage

on the VxSS tab, Required, Prohibit and Automatic, refer to the NetBackup

access control parameters section in Appendix C.

9 Click the Authentication Domains tab, and then click Add.

10 Enter SUN as the Domain, and then select WINDOWS as the Authentication

Mechanism.

11 In the Broker field, type jupiter, and type a description for this Authentication

Domain. The authentication broker resides on the system

jupiter.universe.com.

The media management server that is configured on leda.universe.com

uses the remote authentication broker that is configured on the maser

management server (jupiter.universe.com).

12 Click the Authorization Service tab, and then type jupiter in the Host field.

The media server uses the global authorization database that is configured

on the system jupiter.universe.com.

13 Save the changes, and then exit the Administration Console. For the changes

to take effect, stop and start the NetBackup media management server.



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

server: leda.universe.com.

15 Click Start >Run, and then type regedit.

16 Navigate to the NetBackup configuration and verify that these parameters

(Server, Client_Name, AUTHENTICATION_DOMAIN,

AUTHORIZATION_SERVICE, USE_VXSS) in the Windows registry are correct.



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

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

verify the expiry period.





Domain: SUN


Password: <administrator’s password on leda>



Name: ADMINISTRATOR

Domain: SUN

Issued by: /CN=jupiter.universe.com/ \

[email protected]/O=vx




18 Invoke the NetBackup Administration Console, click Help (at the top), and

then select Current NBAC User to verify the user’s Web credential.

To enable NBAC on a UNIX or Linux media management server (with a master

server on Windows), follow the procedures and steps listed below. If the

environment has a UNIX or Linux master management server and a Windows

media management server, refer to the Enable access control on NetBackup media

servers section in Chapter 6.

On a UNIX system (janus.universe.com) with HP-UX 11.23 operating system, a

NetBackup media management server is configured. It is a prerequisite that the

HP-UX media management server is operational before attempting to enable the

NBAC functionality. At a minimum, a successful backup and restore must be

performed for a client that uses this media management server.

Authentication plug-ins such as Windows are not supported on UNIX/Linux. Users

on a UNIX or Linux system (such as HP-UX) with a media management server

cannot use a Windows authentication broker with a Windows plug-in. Therefore,

an authentication broker with an appropriate plug-in (such as UNIXPWD or

NISPLUS) can be configured on HP-UX to authenticate the users on the HP-UX

system. Users who operate on HP-UX can use a remote authentication broker.


182

A future release of the NetBackup product may support plug-ins like LDAP that

can be used for cross-platform (UNIX/Linux and Windows) user authentication.


To enable NBAC on a UNIX or Linux media management server


server – jupiter.universe.com. Use the following command to create an

authentication principal for the HP-UX system that has the media

management server.

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





Machine Name: janus.universe.com

Password: <pick a password for janus>




listpdprincipals --pdrtype ab \


Principal Name: janus.universe.com


-ShowMachines



janus.universe.com


2 Procedures described in this step must be executed on the system with the

HP-UX media management server:janus.universe.com. Obtain the machine’s

credential for the system janus.universe.com.

/usr/openv/netbackup/bin# ./bpnbat -loginmachine





Machine Name: janus.universe.com



/usr/openv/netbackup/bin# ./bpnbat -whoami -cf \

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

Name: janus.universe.com







server – jupiter.universe.com. Authorize the system with the media

management server to perform authorization check.


-allowauthorization janus.universe.com \

-server jupiter



server – jupiter.universe.com. To start the second portion of the NBAC

configuration, go to Start menu and invoke the NetBackup Administration

Console.


184

5 Expand the Host Properties and click the Media Servers, select

janus.universe.com as the media server by clicking the host. In the Status

column, it should show Connected. Click Actions (at the top) and select



(others are Required and Prohibit). For the usage on the VxSS tab, Required,

Prohibit and Automatic, refer to the NetBackup access control parameters

section in Appendix C for explanation.

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.


to take effect, stop and start the NetBackup media management server.



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

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


Enable access control on a NetBackup client

Before the NetBackup Access Control (NBAC) is enabled on a NetBackup

management client, the management client must be managed by the master and

media management servers. To verify that the NetBackup configuration is working,

a successful backup and restore initiated from the master for a client using this

media server should be a good indicator.



This approach is helpful for fault isolation. For example, if backup and restore by

using this management client is successful without NBAC, but fails with NBAC

enabled, you can direct your troubleshooting effort at NBAC configuration.

Table 7-6 shows the specific version of the shared core service (authentication)

that is used by the NetBackup management client.

Table 7-6 NetBackup client dependency on authentication

Authentication clientNetBackup

4.34.24.1

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.


186

To set up the NBAC functionality on a management client


server – jupiter.universe.com. To enable the NBAC for a management

client, an authentication principal must be created for the system where the

NetBackup management client is installed. Repeat this step for each

management client to be enabled with the NBAC. In this example, an

authentication principal is added for the system callisto.universe.com in

the NetBackup NBU_Machines private domain repository.


-addmachine



Authentication Broker: jupiter.universe.com


Machine Name: callisto.universe.com

Password: <pick a password for callisto>



C:\Program Files\VERITAS\Security\Authentication\bin>

vssat listpdprincipals \

--pdrtype ab \


Principal Name: callisto.sun.universe.com

C:\Program Files\VERITAS\NetBackup\bin>

bpnbat -ShowMachines



callisto.sun.universe.com


2 Procedures described in this step must be executed on the management client

– callisto.universe.com. Use the following command to obtain the

credential for the system callisto.universe.com:


-loginmachine



Authentication Broker: jupiter.universe.com


Machine Name: callisto.universe.com




..\var\vxss\credentials\callisto.SUN.universe.com

Name: callisto.sun.universe.com







server: jupiter.universe.com. Use the NetBackup Administration Console

to modify the Access Control properties for a NetBackup management client

– Start, NetBackup Administration Console.

4 Expand the Host Properties and click the Clients, select callisto as the

management client by clicking the host. In the Status column, it should show

Connected. Click Actions (at the top) and select Properties... On the

Properties… screen, select the Access Control (second one from the bottom

of the list). In the Veritas Security Services (VxSS) box, choose Automatic.

For the usage on the VxSS tab, Required, Prohibit and Automatic, refer to the

NetBackup access control parameters section in Appendix C for explanation.

5 Click the Authentication Domains tab, and then click Add. Enter SUN as the

Domain: and choose WINDOWS as the Authentication Mechanism. In the

Broker: field, enter jupiter and a description for this Authentication Domain.

6 Repeat the steps listed above for each NetBackup management client that

uses the NBAC capability.


188


to take effect, stop and start the NetBackup master management server.



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

management client – callisto.universe.com. Click Start > Run, and then

type regedit. Navigate to the NetBackup configuration and verify these

parameters (Server, Client_Name, AUTHENTICATION_DOMAIN, USE_VXSS)

in the Windows registry are correct.






Domain: SUN


Password: <administrator’s password on callisto>



Name: ADMINISTRATOR

Domain: SUN





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.


The NBAC configuration for NetBackup management client is now complete. Use

the procedures listed in the NetBackup access control setup verification on clients

section in Appendix C to verify that the NetBackup management client is setup

correctly.

If the environment has a UNIX/Linux master management server and Windows

management client, refer to the Enable access control on NetBackup clients section

in Chapter 6 for detailed instructions.

In Appendix C, the NetBackup access control troubleshooting tips section has a

list of common errors and resolutions tips.

Environment with an existing authentication hierarchy

In an enterprise where the NetBackup product is to be deployed with access control,

suppose an authentication hierarchy has already being created for another

Symantec product. When the Symantec Product Authentication Service is installed

for the NetBackup product, inadvertently, a new authentication hierarchy

configuration is also created. In Chapter 5, the Multiple root brokers section

discussed the extraneous work authentication brokers from different root

hierarchies must perform before meaningful authentication can occur. The root

broker that is configured for the NetBackup product can be replaced and the

NetBackup authentication broker can be changed to point to the existing root

broker on another system. Refer to the Replace the root broker on the NetBackup

master server section in Appendix C for detailed procedures on how to assimilate

an authentication broker from one authentication hierarchy into another.

Upgrading NetBackup and shared components

The NetBackup installation is used to install and upgrade the NetBackup software

on systems that have either management client, master, or a media management

server installed. The NetBackup installation does not upgrade the shared core

services components (AT and AZ) that are used by NetBackup Access Control. An

upgrade to a specific NetBackup version calls for the upgrade of the shared

components. The respective product’s installation script that are provided by the

shared products should be used to perform the upgrade.

After you complete a NetBackup upgrade, you should verify that NetBackup works

with the shared products that are configured on the system.


If one or more of the shared products are upgraded while the NetBackup software

remains unchanged, the proper operation of NetBackup must be verified through

the backup and restore procedures. If other Symantec agents are installed on the

same system as NetBackup, you must ensure that the new version of the shared


190

components can work with the management agents that are already present on

the system. Most of the time, it is prudent to test the configuration in a test

environment before you deploy the new version of the shared components to the


NetBackup Operations Manager use caseNetBackup Operations Manager (NOM) is a GUI-based administrative tool that

provides a centralized management for all the NetBackup master servers that are

deployed throughout the enterprise. In this setup, the NOM management server

is deployed on the same system as the NetBackup master management server.

Figure 7-4 depicts the deployment of NetBackup in an enterprise.


order:

■ Storage Foundation (it is optional to install this product unless the Veritas

Volume Manager is needed).


■ NetBackup (either client, media or master binaries).

The NetBackup Operations Manager uses the authentication mechanism that is

provided by the Symantec Product Authentication to authenticate users by

accessing the NOM Web administrative console. An Authentication broker is set

up with the appropriate plug-ins and made available to the NOM Web console for

authenticating users. After NOM is configured, users in the NOM_BuiltIn private

domain repository should be able to log on to the NOM Web console.

Note: In an enterprise, NOM is typically installed on a system that has only the

management server configured. In this setup, NOM needs only the NetBackup

client software installed on the system.

The following table depicts the version of the NOM product and the versions of

the AT and PBX shared components that are used by the NOM management server.

Table 7-7 NetBackup Operations Manager usage matrix

Private Branch ExchangeAuthentication serviceNetBackup Operations

Manager1.31.24.34.24.1

6.0MP4

191Symantec solution: Windows use casesNetBackup Operations Manager use case


The version of NOM product that is used in this use case is supported on Windows

and Solaris. In this use case, NOM product is deployed on Windows with its

management server configured on the same system as the NetBackup master

management server. The NOM Management Server that is deployed on Windows

can manage NetBackup Master Servers that are deployed on other operating

systems (such Windows, Solaris, AIX, HP-UX, Red Hat and SUSE). To use NOM

for managing NetBackup 5.1 Master Server, consult the NOM product

documentation to see if the version of NOM deployed is capable of this support.

NetBackup Operations Manager management server

To deploy NetBackup Operations Manager (NOM), the system must have either

master, media, or the client software of the NetBackup product already installed.

The right version of the product Authentication should also be installed and

configured in the root plus authentication broker mode. On a system that has the

Symantec Product Authentication configured in authentication broker mode,

refer to the instructions listed in this section on how to work around this

restriction. The root broker restriction required by NOM will be lifted in a future

NOM release.

In this configuration, the NOM management server is deployed on the same system

as the NetBackup Master Server. If there are multiple Master Servers in the data

center, you should pick the one that is the least busy.

In the current edition of this Yellow Book, the version of the NetBackup master

management server that is managed by the NOM product is depicted in the

following table.

Apply the maintenance pack to the 6.0GA release to upgrade the NOM product to

a later version.

Table 7-8 NetBackupOperationsManagermanagesNetBackupmaster server

NetBackup masterNetBackup Operations

Manager6.0MP45.1MP6

6.0MP4

Symantec solution: Windows use casesNetBackup Operations Manager use case

192

To install and configure NetBackup Operations Manager 6.0 GA on Windows

1 In an Explore window, navigate to the directory that has the NOM installation

files, and then click setup.exe.

2 On the License Agreement screen, click I accept the terms of the license

agreement.

3 On the Ready to Install the Program screen, click Install to start theNOM

installation.

4 On the System Validation Complete screen, click Finish to exit theNOM

installer.

5 Go to Start, Control Panel, Add or Remove Programs and verify the NOM

package (Veritas NetBackup Operations Manager) has been installed on the

system.

6 Verify the following NOM and supporting services are started. Go to Start >

Administrative Tools > Services.

Private Branch Exchange

Authentication

NetBackup Operations Manager Alert Manager

NetBackup Operations Manager Database Server

NetBackup Operations Manager Server

NetBackup Operations Manager Web Console Service

VERITAS Web Server

The NOM management server will be upgraded to 6.0MP4.

To upgrade NetBackup Operations Manager 6.0 GA on Windows

1 Locate the NOM maintenance pack distribution.

2 In an Explore window, navigate to the directory that has the NOM installation

files, and then double-click the setup.exe file.

3 Choose Install to this computer only, and then follow the instructions on the

screen.

4 On the Ready to Install the Program screen, click Install to start the upgrade.

5 On the System Validation Completed screen, verify that the installation

completed successfully.

6 Click Finish to exit the installer.


7 Go to Start, Control Panel, Add or Remove Programs, and then verify that

the maintenance pack has been installed on the system.

8 If the NBAC was enabled on a management client, after upgrading the

NetBackup software, the Verify NetBackup access control setup on clients

procedure listed in Appendix C should be used to ensure the management

client is working.

This version of NOM requires that the system where NOM is installed has the root

plus authentication broker configuration. In this setup (Figure 7-4), the system

(neptune.universe.com) merely has the authentication broker configured. To

work around this, execute the following procedures on the system

(neptune.universe.com) where the NOM management server is installed.

To configure root and authentication broker on NOM

1 Add the following private domains for the NOM product:


createpd --pdrtype ab \

--domain NOM_BuiltIn

Created Domain: NOM_BuiltIn


createpd \

--pdrtype ab \

--domain NOM_MACHINES

Created Domain: NOM_MACHINES


createpd \

--pdrtype ab \

--domain NOM_TRUSTED_CLIENTS

Created Domain: NOM_TRUSTED_CLIENTS


194

2 Add the following broker-domain mappings for the NOM product:


addbrokerdomain --broker jupiter.sun.universe.com:2821 \

--domain vx:[email protected]

Added Domain-Broker Entry in Local Registry.









3 Go to Start, Control Panel, Administrative Tools, Services, start the NetBackup

Operations Manager Server service, and then stop and start the Veritas Web

Server service.

4 Verify the NOM Web application is ONLINE.

C:\Program Files\VERITAS\VRTSweb\bin> monitorApp nom

Web Application "nom" is ONLINE

5 If the NOM is OFFLINE, start the NOM Web application.

C:\Program Files\VERITAS\VRTSweb\bin> startApp \

nom ..\VERITAS

The NetBackup Operations Manager Web Console Service service

is starting.

The NetBackup Operations Manager Web Console Service service

was started successfully.

6 Go to Start >Administrative Tools > Services, and verify that the NOM and

supporting services (listed earlier) are started.


7 To log onto the NOM administrative console, launch the Internet Explorer

browser and enter the URL http://localhost:8181/nom. You must provide a

valid user login and password in the NOM authentication domain. The

predefined user admin has a default password of Vxadmin.

8 For NOM to manage a NetBackup master management server, the host name

of the system where the NOM management server is configured should be

entered as a SERVER entry on each NetBackup master management server.

For example, NOM is configured on jupiter.universe.com and NetBackup

master management server on neptune.universe.com. On

neptune.universe.com, in the Host Properties, Master Server, highlight the

master server, Actions (at the top), Properties, Servers, and then click Add

to enter jupiter.universe.com.


It is highly recommended that you use one authentication hierarchy throughout

the enterprise. When you install a NOM in an enterprise that already has a root

broker established, you must configure an authentication broker on the system

where the NOM is to be installed as the preferred choice. Refer to the procedures

illustrated in previous section for details.

Replace the root broker that is configured for NOM with another authentication

hierarchy on a remote system.

See “Replacing the root broker on the NetBackup master server” on page 262.

Substitute the NetBackup entities with NOM backup entities.


196

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.

CommandCentral Storage and Service use caseThe CommandCentral (CC) product uses the authentication mechanism that is

provided by the Symantec Product Authentication to authenticate users who

access the CC Web administrative console. An Authentication broker is setup with

the appropriate authentication domain and plug-ins that are made available to

the CC Web console for authenticating users. After the CC products have been

configured, accessing the CC Web console requires a valid user login and password

that must be authenticated through the cc_users authentication domain and

plug-in.


order:

■ Storage Foundation. For CommandCentral, it is optional to install this product.



■ Management client or agents from other Symantec products (such as NetBackup

or Symantec License Inventory Manager0

Figure 7-5 depicts the deployment of the CommandCentral servers in an enterprise.

197Symantec solution: Windows use casesCommandCentral Storage and Service use case

Figure 7-5 Deploying CommandCentral Storage and Service


In this use case chapter, the version of CC Storage and service management servers

and agents are primarily deployed and verified on the Windows platform. In

addition to Windows storage and service agents, Windows CC management servers

are configured to work with storage and service agents that are deployed on UNIX

and Linux platforms. In this setup, storage and service agents that are installed

on HP-UX and Red Hat platforms are configured to report to the CC management

servers on Windows.

Application server

On Windows, the CommandCentral (CC) installer decides the location to install

and store the data and temporary files. The CC Storage and service management

servers sand agents can be installed on respective systems and they do not require

that a Symantec application server, such as SFW or SFWHA, be installed first.

CommandCentral Management servers

The CommandCentral management servers (Storage and Service) are deployed

on a dedicated Windows system. CC management servers depend on Symantec

Product Authentication and a local authentication broker that is used to

authenticate users by accessing the CC Web console through a valid authentication

domain and plug-in.

Symantec solution: Windows use casesCommandCentral Storage and Service use case

198

In this illustration, the CC Storage and Service management servers use version

4.2 of the Authentication product. On the system where these management servers

are to be installed, you must configure an authentication broker in the

authentication hierarchy that is created on the system where the SLIM

management server is configured. To add a new authentication broker into an

existing authentication hierarchy, refer to the Add a new authentication broker

section in Appendix B for detailed procedures.

A system that is configured with CommandCentral storage and service

management servers could have Management Agents or Client of other

Management Servers deployed as well. These Agents or Clients may or may not

have the authentication enabled. As an example, the SLIM management agent

could be installed on the system that has the CC Storage management server.

Storage management server

On Windows, the version of the CommandCentral Storage (CC Storage) product

that is used for this illustration is listed in the following table. This version of the

CC Storage depends on the infrastructure that is provided by the Authentication

(AT) component. On systems that have CC Storage management server, this shared

component must be installed and configured. This shared component can be

manually installed and configured on the system first, or the CC installer can

automatically install the authentication product. CC Storage management server

uses the Web Server Service for console logon.

In the following table, cells that have the checkmark depict the specific version

of the shared core service (AT) that has been tested with the storage management

server.

Table 7-9 Storage management server dependency on shared component


4.34.24.1

4.2FP1

4.3

A valid product license key is required to install the CC Storage management

server.

If the CommandCentral authentication broker needs to be created by using an

existing root broker, you must verify that the system already has the Symantec

Product Authentication installed and configured in Authentication broker mode.


This installation session illustrates the installation for CC Storage 4.2FP1 release

on Windows Server 2003 Enterprise Edition SP1.

To install and configure a CommandCentral storage management server

1 In an Explore window, navigate to the directory that has the CC installation


2 On the License Agreement panel, click I accept the terms of the license

agreement.

3 On the Veritas CommandCentral Offerings screen, expand the

CommandCentral Storage, and then CommandCentral Storage Management

Server and CommandCentral Storage Web Engine.

4 On the Serial Numbers screen, enter a valid product key for the

ComamndCentral Storage and Service (if the CC Service product is also

included) products.

5 On the CommandCentral Storage Management Server screen, pick the Enable

Operations Modules (OM) and Enable Data Module (DM). On the system that

has the Storage management server, the storage management agent is not

required.

6 On the CommandCentral Storage Web Engine Options screen, choose the

default port (8181).

7 On the Installing Veritas CommandCentral screen, verify the Symantec

Product Authentication Service by running the following command on the

system:


showversion

vssat version: 4.3.27.1


showbrokermode

Broker Mode is : 1


listpd --pdrtype ab



8 On the Installation Complete screen, click Finish to exit the installer.


200

9 Go to Start>ControlPanel >AddorRemovePrograms, and then verify that

the Veritas CommandCentral Storage (or Suite if both Storage and Service

were installed) package is found.

10 After CommandCentral storage has been installed and configured, the

verification procedures listed in the Verify the CommandCentral server setup

section in Appendix D should be used to ensure that the CC Storage

management server is functional and working correctly.

The upgrade of the CC Storage management server software on a system is done

through these procedures and steps. The system that has the CC Storage

management server is usually the first system to be upgraded.

On a system that has the CC Service 4.2FP1 installed, upgrading CC Storage from

4.2FP1 to 4.3 is not supported. The CC Storage installation script makes this check

and would exit when such a condition is detected.

To upgrade a CommandCentral storage management server

1 Log on to the storage management server (cressida.universe.com) and

locate the CC Storage 4.3 management server software.



Service management server

The version of the CommandCentral Service (CC Service) product that is used in


Service depends on the infrastructure that is provided by the Authentication (AT)

and Private Branch Exchange (PBX) components. These shared components can

be manually installed and configured on the system first, or they can be

automatically installed and configured by the CC installer. The CC Service

management server uses the Web Server Service for console logon.


of the shared core services components (AT and PBX) that have been tested with

the Service management server.

Table 7-10 Service management server dependency on shared components

Private Branch

Exchange

Authentication serviceCommandCentral

Storage

1.31.24.34.24.1

4.2FP1


A valid product license key is required to install the CC Service management

server.

This installation session illustrates the installation for CC Service 4.2FP1 release

on Windows Server 2003 Enterprise Edition SP1 operating system.

To install and configure a CommandCentral server management server



2 In the Veritas CommandCentral Offerings screen, expand the

CommandCentral Service, and then select all the options. The

CommandCentral Storage product can also be installed in one installation

session.

3 In the ComamndCentral Service Automation Options screen, enter the FQHN

of the system (cressida.universe.com) where the CC Service is installed.

Pick the default port number (60389) for the Automation Server port.

4 On the system that has the Service management server, the service

management agent should be configured. The server Host for the service

agent should be Localhost and the default port (1556) should be used.

5 Verify that the authentication domains that are created for the CC Service

management server.


listpd --pdrtype ab



6 The rest of the procedural steps listed in the Storage management server

section are applicable to Service management server as well.

7 After the CommandCentral service product has been installed and configured,

the verification procedures listed in the Verify the CommandCentral server

setup section in Appendix D should be used to ensure that the CC Service

management server is functional and working correctly.

Version 4.2FP1 is the last release of the CommandCentral Service product. The

CommandCentral Service View Builder functionality is renamed to Veritas Backup

Reporter that is distributed with the NetBackup product. The CommandCentral

Service Metering Collector and CommandCentral Service Metering Controller are

renamed to Veritas Process Automation Server.


202

Installing a CommandCentral management agent

You can deploy the CommandCentral (CC) management agents on Windows Server

2003 Enterprise Edition SP1. These CC management agents are configured to

report to the CC management servers configured in the previous section.


of the shared core services component (AT) that has been tested with the Storage

and Service management agents.

Table 7-11 CommandCentral Agents Dependency on Shared AT

Authentication ClientCommandCentral

Storage4.34.24.1

4.2FP1

Use the following procedures to install CC management agents and configure

them to report to a Windows CC management server.

To install a CommandCentral Storage management agent

1 In an Explorer window, navigate to the directory that has the CC installation


2 In the Veritas CommandCentral Offerings screen, choose the CommandCentral

Storage Agent and CommandCentral Storage Web Engine options. Pick the

correct CommandCentral Storage Agent (OM and DM).

3 In the CommandCentral Storage server screen, enter the hostname

(cressida.universe.com) as the CommandCentral Storage management

server. Specify the login administrator and password.

4 In the CommandCentral Storage Web Engine Options screen, accept the

default port (8181).

5 Go to Start > Control Panel >Add orRemove Programs to see the

CommandCentral Storage agent package.

To install the CommandCentral service management agent

1 In an Explorer window, navigate to the directory that has the CC installation


2 In the Veritas CommandCentral Offerings screen, select the CommandCentral

Service Agent option.


3 In the CommandCentral Service server screen, enter the Host

(cressida.universe.com) as the CommandCentral Service management

server. Accept the default port (1556) that will be used by the Private Branch

Exchange.

4 Click Finish to exit the installer.

5 Go to Start > Control Panel >Add orRemove Programs to see the

CommandCentral Service agent package.

6 After the CommandCentral management agents are installed and configured,

use the verification procedures listed in the Verify the CommandCentral

agent setup section in Appendix D to ensure that the CC management agents

are working correctly.


When you install the CommandCentral (CC) product in an enterprise that already

has an authentication hierarchy, it is much preferred to create a new

authentication broker in the existing authentication hierarchy for the CC

management servers.

If a root broker was also configured during the CC install and there is a need to

replace the CC root broker with the existing authentication hierarchy, refer to

the Replace the root broker on the CommandCentral server section in Appendix

D for detailed procedures on how to assimilate an authentication broker from one

authentication hierarchy into another.

CommandCentral-related upgrade

The CC installation is used to install and upgrade the CC software on systems that

have either management agent, storage, or service management server. The CC

installation does not involve the upgrade of those shared core services components

(AT and PBX) that are used by CC management servers. If the upgrade to a specific

CC Storage version also calls for the upgrade of the shared components, the

respective product’s installation script that is provided by the shared products

should be used to perform the upgrade.

After the upgrade of CC software is complete, you should verify that the CC product

works with the shared products that are configured on the system.

If one or more of the shared products are upgraded, while the CC software remains

unchanged, the proper operation of the CC product must be verified through the

normal uses. If there are other Symantec agents or client installed on the same

system as the CC product, you must ensure that the new versions of the shared

components work with other management client or agents that are already present


204

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


Storage Foundation use caseThe following Veritas Storage Foundation products are used throughout this

section:

■ Storage Foundation, which consists of Veritas Volume Manager, Veritas File

System, and optionally, Veritas Volume Replicator (VVR).

■ Storage Foundation for Windows, which consists of Veritas Volume Manager,

and optionally, Veritas Volume Replicator.

■ Storage Foundation Cluster File System (SFCFS) which consists Veritas File

System, Veritas Cluster Server (VCS), and the cluster functionality (shared

volumes) of Veritas Volume Manager.

■ Storage Foundation for Oracle RAC, which consists of SFCFS plus the Veritas

add-on functionality for use with Oracle databases.

The installer that is distributed with Storage Foundation for Oracle RAC 4.1MP1

on Red Hat and HP-UX is not integrated with the Symantec Product

Authentication.

See “Enabling a VCS cluster with authentication service” on page 211.

Figure 7-6 Deploying Storage Foundation

205Symantec solution: Windows use casesStorage Foundation use case

On the systems where these application servers are deployed, the management

agents or the clients of other management servers are installed. For example, on

a VCS cluster with SFWHA or SF for Oracle RAC, on each node of the VCS cluster,

the following management client and agents could be present:

■ NetBackup management client

■ CommandCentral Storage or Service management agent

■ Symantec License Inventory Manager management agent

These management client and agents are set up to report to the respective

management servers illustrated in this use case chapter. Refer to the respective

product use case section for instruction on how to setup a management agent or

client on a system.


The Storage Foundation products are deployed on Windows (SFW and SFWHA)

and UNIX or Linux (SF and SF Oracle RAC) platforms. UNIX and Linux platforms

include the HP-UX and Red Hat. The procedures and processes that are used on

Windows are platform-specific. The procedures and processes that are used on

HP-UX and Linux can be used on other UNIX and Linux platforms.

Application server

SFW is installed on a single system with a Symantec management server such as

NetBackup, SLIM, or CC. SFW is not integrated with Symantec Product

Authentication. SFW can be installed on the system with a management client

such as NetBackup and management agents such as CC and SLIM.

The installation is done on SFW 4.3MP1 on a system running Windows Server

2003 Enterprise Edition SP1.

To install Storage Foundation 4.3 for Windows

1 Navigate to the directory with the SFW distribution files, and then click

setup.exe.

2 Choose Storage Foundation 4.3 for Windows, and then select the

Complete/Customer option.

3 Click I accept the terms of the license agreement, and then enter the SFW

license key. Include the SFW client components in the installation.

4 Enter the host name of the system (for example, callisto), and then specify

the Domain for this computer (assuming the FQHN name for callisto is

callisto.universe.com).

Symantec solution: Windows use casesStorage Foundation use case

206

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

orRemove 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 orRemove

Programs and verify the SFW Maintenance Pack 1 has been installed.

Storage Foundation HA for Windows (SFWHA) uses the authentication mechanism

provided by the Symantec Product Authentication to authenticate users accessing

the Veritas Cluster Server service groups and Veritas Enterprise Administrative

(VEA) Java console. An Authentication broker is set up with the appropriate

authentication domains and plug-ins and made available to the VEA Java console

for authenticating users.

This procedure installs Storage Foundation HA for Windows 4.3MP1 on a VCS

cluster running Windows Server 2003 Enterprise Edition SP1.

Table 7-12 Storage Foundation Dependency on Windows

Authentication ClientStorage Foundation HA

for Windows4.34.24.1

4.3MP1

To install Storage Foundation HA for Windows 4.3

1 Navigate to the directory that has the SFWHA distribution files, and then

click setup.exe.

2 Refer to step 1 in the Install Storage Foundation 4.3 for Windows section the

rest of the installation instructions.

3 Choose the Storage Foundation HA options and the Client components.

4 Enter the name of the systems that are part of the VCS cluster. On each

system, turn off the Driver Signing option on the System Properties screen.


5 Click Install to start the installation.

6 Click Finish to reboot the system where the installation is invoked from.

To upgrade Storage Foundation HA for Windows 4.3MP1

1 After all the systems reboot, upgrade the SFWHA to 4.3 Maintenance Pack

1.

2 The upgrade instructions that are listed in Upgrade Storage Foundation 4.3

for Windows can be used to perform the upgrade for all the nodes in the VCS

cluster. To upgrade SFWHA 4.3 to a more recent version of the maintenance

pack, the same procedure should be also be used.

3 After the upgrade, launch the VCS configuration wizard and choose Cluster

operations.

4 Pick the domain that is used in the enterprise and create a new cluster with

a unique cluster name and ID.

5 On the Configure Security Service Option screen, select use Single Sign-On

and enter mercury (FQHN is mercury.universe.com) in the VxSS Root Broker:

field.

6 On the Summary screen, verify the information is correct and clickConfigure

to start configuration process, and then click Next.

7 On the Cluster Service Components screen, select the Web Console and

configure the Web console.

8 ClickFinish to exit. On each of the systems, there should be an authentication

broker configured and running. These authentication brokers are rooted in

the authentication hierarchy that is located on the mercury.universe.com.


When you install Storage Foundation HA for Windows (SFWHA) in an enterprise

that already has the authentication hierarchy, it is recommended that the existing

root broker be used and the new authentication brokers be created in the existing

authentication hierarchy.

Storage Foundation-related upgrade

After the upgrade of SFWHA software is complete, you should verify that the

storage foundation application server works with the shared products that are

configured on the system.

If one or more of the shared products are upgraded, while the storage foundation

software remains unchanged, the proper operation of the storage foundation


208

(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

Storage Foundation

common procedures

This appendix includes the following topics:

■ Enabling a VCS cluster with authentication service

■ Re-establishing the authentication service for a node in a VCS cluster

■ Setting up a Storage Foundation Management Server with authentication

service

■ Common Veritas Volume Manager and Veritas File System procedures

Enabling a VCS cluster with authentication serviceVeritas Cluster Server (VCS) is distributed in each of these Storage Foundation

offerings:

■ Storage Foundation HA

■ Storage Foundation for Windows HA (SFWHA)

■ Storage Foundation for Oracle RAC (SF Oracle RAC)

■ Storage Foundation for Oracle HA (SF Oracle)

■ Storage Foundation Cluster File System (SFCFS)

Installing and configuring with authentication service depends on the Storage

Foundation offering, its version, and the operating system platform (UNIX, Linux,

or Windows). This section lists the common installation and configuration

procedures for Storage Foundation and the configuration instructions for enabling

VCS with authentication service in a security-enabled environment. VCS versions

AAppendix

4.1 and 5.0 are illustrated for UNIX and Linux platforms. On Windows, the

procedures are described using SF version 4.3.

Setting up a VCS cluster with authentication service on UNIX/Linux

Veritas Cluster Server can be deployed as a standalone product. Configuring a

VCS cluster with authentication service enables internode communication over

a secure channel using encrypted messages. Users of the VCS cluster must also

authenticate themselves by acquiring a valid security credential.

For these procedures, it is recommended that you input short system names. For

example, useariel, instead ofariel.universe.com, when responding to a prompt.

The installer automatically retrieves the fully qualified host name (FQHN) and

places it wherever the FQHN is required (such as for the authentication broker

domain name.

Be prepared to provide the remote root broker information. VCS sets up each node

in a cluster with an authentication broker. You must provide the remote root

broker with a fully qualified host name, such as neptune.universe.com.

If you choose to configure the VCS cluster with authentication service, answer

yes to the following question:

Would you like to configure SFRAC to use Symantec Security Services?

Refer to the following section for details:

See “ Configuring a VCS cluster to use authentication service” on page 213.

If you choose to have the VCS cluster managed by a Storage Foundation

Management Server, answer yes to the following question:

Do you want this cluster to be managed by a management server?

Refer to the following section for details:

See “Using Storage Foundation Management Server to manage VCS clusters”

on page 213.

Configuring VCS 4.1 with authentication service

Among the Veritas Storage Foundation version 4.1 products, only SFCFS and SF

Oracle RAC are integrated with the authentication service. Their installers (on

Solaris) provide the option of installing and configuring them with authentication

service. The other SF offerings require the authentication service to be explicitly

installed and configured by a product administrator. The Symantec Product

Authentication Service can be installed from the Infrastructure Core Services

distribution media.

Storage Foundation common proceduresEnabling a VCS cluster with authentication service

212

Configuring VCS 5.0 with authentication service

Veritas Storage Foundation version 5.0 includes authentication service as part of

the product installer. Using the product installation script (installer), you first

pick option I from the installer menu to Install the product, then choose option

C, Configure an Installed Product.

Configuring a VCS cluster to use authentication service

During the configuration phase of the SF Oracle RAC setup, the installer prompts

you for information related to the configuration of the authentication service.

The following example shows configuration questions related to the authentication

service for the SF Oracle RAC 5.0. You must provide the name of the system where

the root broker is configured. It is easiest to pick option 1 on the Security Menu.

The other two options are more interactive, so choosing either option 2 or 3

requires that you provide more information.

Would you like to configure SFRAC to use

Symantec Security Services? [y,n,q] (n) y

Security Menu

1) Configure security completely automatically

2) Provide AB credentials using BLOBs

3) Provide AB credentials without using BLOBs

Select the Security option you would like to perform [1-3,q,?] (1) 1

Enter the name of the VxSS Root Broker system: neptune.universe.com

Checking rsh communication with neptune.universe.com ...... SunOS 5.9

Checking vxatd process .....................................running

Checking vxatd version .....................................4.3.15.0

Using Storage FoundationManagement Server tomanage VCS clusters

The Storage Foundation Management Server (SFMS) and managed hosts

communicate by using a previously created authentication principal account

(vea_agent). This agent account resides in the vea_domain authentication domain

that is created during the SFMS installation. Managed hosts must obtain the

vea_agentpassword to authenticate themselves so that the authentication broker

can vouch for their identities.

Enabling SFMS to manage a VCS cluster has the following prerequisites:

■ SFMS is already configured and fully operational.

213Storage Foundation common proceduresEnabling a VCS cluster with authentication service

See “Setting up a Storage Foundation Management Server with authentication

service” on page 220.

■ The authentication broker that is used by SFMS is also configured with a

private domain vea_domain and an authentication principal vea_agent.

■ Every node in the VCS cluster must have the authentication service available

and authenticate itself to the authentication broker located on the system

where SFMS server is configured. Each node in the VCS cluster is authenticating

against the vea_agent authentication principal in the vea_domain

authentication domain.

In this setup, assume that the root broker is configured on the system

neptune.universe.com, the SFMS server is configured on system

proteus.universe.com and a VCS cluster with two nodes (larissa.universe.com

and ariel.universe.com). The SF for Oracle RAC installation is invoked from

the system ariel.universe.com.

The SF Oracle RAC 5.0 installer requires the following information to configure

the VCS cluster to be managed by an SFMS server. The installer distributed by SF

Oracle RAC 4.1 may phrase these questions differently.

■ FQHN of the Storage Foundation Management Server (SFMS)

■ Password for the vea_agent authentication principal

■ The root hash of the authentication broker that is used by SFMS. To find the

hash of the root broker that the management server authentication broker

belongs to, run the following procedure on neptune.universe.com:

# /opt/VRTSat/bin/vssat showbrokerhash

Root Hash: 9efb1d042f646656602f55be4016a8bf1a1d03b4

Do you want this cluster to be managed by a management server? Enter 'y'

if you have set up a management server. [y,n,q] (y)

Enter the network address used by

the management server [?] (ariel) proteus.universe.com

Management server address: proteus.universe.com

Enter the password for the CMC service account: <vea_agent's password>

Enter the hash of the management server's

root broker [?] 9efb1d042f646656602f55be4016a8bf1a1d03b4

Storage Foundation common proceduresEnabling a VCS cluster with authentication service

214

Setting up a VCS cluster with authentication service on Windows

The information presented in this section applies to Storage Foundation HA 4.3

(with MP1) for Windows.

Configuring Storage Foundation HA for Windows withauthentication service

The VCS product requires an authentication broker to be configured on each node

of the VCS cluster. To enable authentication service in a VCS cluster with Storage

Foundation HA for Windows (SFWHA), follow these steps.

To configure Storage Foundation HA with authentication service

1 On one of the VCS nodes, mount the SFWHA distribution on a drive.

2 At the top level directory, double-click the installation script setup.exe and

choose the Storage Foundation HA 4.3 for Windows install option. List all

the nodes in the VCS cluster on which to install SFWHA.

3 After you install SFWHA and restart all the systems, select Start >All

Programs >VERITAS >VERITASCluster Server >VCSConfiguration

Wizard > Cluster Operations to create a new VCS cluster. Add all the

previously specified nodes in the VCS cluster.

4 On the Configure Security Service Option screen, click theUseSingleSign-On

radio button.

5 Navigate to the VxSS Root Broker field and then type the name of the system

that has the root broker configured.

6 Click Next and continue with the VCS Configuration Wizard.

7 The Symantec Product Authentication Service is embedded in Storage

Foundation HA 4.3 for Windows, so the authentication service does not display

as one of the currently installed programs if you select Start >Control Panel

>Add orRemove Programs. To verify that the authentication service is

configured correctly, select Start >Administrative Tools > Services and

verify that the authentication service line is present and in the Started status.

To enable the authentication service on a previously configured VCS cluster

1 On one of the VCS nodes, launch the Start >All Programs >VERITAS >

VERITASCluster Server >VCSConfigurationWizard.

2 Select the Cluster Operations, Edit Existing Cluster and then Reconfigure.

3 After you successfully log on to the VCS cluster, select Configure/Change

VERITASSecurityService(SingleSign-On) and check theConfigureSecurity

Services radio button. .

215Storage Foundation common proceduresEnabling 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.

Configuring Storage Foundation with authentication service

When you are installing the Storage Foundation (not HA) for Windows on a system

that does not have the authentication service already installed, the SF installer

does not automatically install the authentication service. In this situation, the

authentication service must be explicitly installed and configured on the system.

Re-establishing the authentication service for a nodein a VCS cluster

When you upgrade a node in a cluster and that node fails to restore all of its

credentials, use the following procedure to re-establish the authentication broker

private domain repository and credential.

In a Symantec enterprise cluster (Veritas Cluster Server) environment, VCS

requires the establishment of an authentication broker on each of the cluster

nodes. VCS also creates a private domain repository called HA_SERVICES within

the authentication broker private domain repository. The private domain

repository, HA_SERVICES, contains the service authentication principals for the

following principals: _CMDSERVER_VCS_nodename, _HA_VCS_nodename, and

webserver_VCS_nodename in addition to the normal admin principal. The node

name is the name of the system that is one of the VCS nodes.

To establish the authentication service for a node within a VCS cluster, there are

three procedures you must complete before you can authenticate to the new


Assume ophelia.universe.com is the name of the system in the VCS cluster and

that the root broker is configured on neptune.universe.com.

■ Add a new authentication broker on the VCS node. The authentication broker

must belong to the existing authentication hierarchy. The principal name for

the new authentication broker should be ophelia.universe.com.

■ On the node where the new authentication broker is configured, create a private

domain repository (PDR) for VCS called HA_SERVICES.

■ In the new HA_SERVICES PDR, create three new authentication principals:

_CMDSERVER_VCS_nodename,_HA_VCS_nodename, andwebserver_VCS_nodename.

Use ophelia fornodename.

Storage Foundation common proceduresRe-establishing the authentication service for a node in a VCS cluster

216

To re-establish Authentication brokers in clustered environments

1 On neptune.universe.com, where the root broker is located, create an

authentication principal (ophelia.universe.com) for the new authentication

broker.


2 On ophelia.universe.com, where you are creating the new authentication

broker, copy the root broker hash file from neptune.universe.com to a local

directory on ophelia:

# rcp neptune.universe.com:/opt/VRTSat/bin/root_hash /tmp

3 If the authentication service was not installed on ophelia, use the

Infrastructure Core Services distribution to install Symantec Product

Authentication Service and configure an authentication broker using neptune

as the root broker and the /tmp/root_hash file.

4 If the authentication service is already installed on ophelia, establish an

authentication broker there. Type the following command:

# /opt/VRTSat/bin/vxatd -a \

-n ophelia.universe.com -p password \

-x vx -y [email protected] \

-q neptune.universe.com -z 2821 \

-h /tmp/root_hash -o

Name <ophelia.universe.com>

DomainType <vx>

DomainName <[email protected]>

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.


217Storage Foundation common proceduresRe-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 \


Created Domain: [email protected]

7 On ophelia, where the new HA_SERVICES PDR is located, create three new

authentication principals: _CMDSERVER_VCS_nodename, _HA_VCS_nodename,

and webserver_VCS_nodename. Use ophelia for the nodename. Here is the

command to create and authenticate the _HA_VCS_ophelia authentication

principal. Repeat these commands for _CMDSERVER_VCS_ophelia and

webserver_VCS_ophelia authentication principals.

# /opt/VRTSat/bin/vssat addprpl --pdrtype ab \

--domain [email protected] \

--prplname _HA_VCS_ophelia \

--prpltype service \

--password welcome_HA

Created Principal: _HA_VCS_ophelia

# /opt/VRTSat/bin/vssat authenticate \

--domain vx:[email protected] \

--prplname _HA_VCS_ophelia \

--broker localhost:2821

Enter password for _HA_VCS_ophelia: welcome_HA

Authenticated User _HA_VCS_ophelia

Storage Foundation common proceduresRe-establishing the authentication service for a node in a VCS cluster

218

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

the HA_SERVICES PDR, type the following command to list these principals:

# opt/VRTSat/bin/vssat listpdprincipals \

--pdrtype ab \


Principal Name: _CMDSERVER_VCS_ophelia

Principal Name: _HA_VCS_ophelia


Principal Name: webserver_VCS_ophelia

9 Verify that the VCS VxSS service agent group is known to the newly-created

authentication broker cluster host.

In the VCS configuration file, /etc/VRTSvcs/conf/config/main.cf, verify

that the SecureClus attribute in the vcs_cluster_name cluster is set to 1.

This indicates that the cluster is configured in secure mode. The VxSS VCS

service group must also be present.

cluster vcs_cluster_name (

UserNames = {"CMC@[email protected]" = password}

ClusterAddress = "21.43.92.89"

Administrators = {"CMC@[email protected]"}

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"

)

219Storage Foundation common proceduresRe-establishing the authentication service for a node in a VCS cluster

Setting up aStorage FoundationManagement Serverwith authentication service

The Storage Foundation Management Server (SFMS) is a management tool that

can centrally monitor, visualize, and administer hosts on which Storage Foundation

products are installed. SFMS is configured on a dedicated system to manage hosts

that have Storage Foundation 5.0 or 4.x configured on Linux or UNIX. On managed

hosts that have SF 4.x installed, the SFMS client component (Provider Access

Layer) must be installed.

For SFMS and managed hosts to communicate securely, they must authenticate

themselves to an authentication broker to establish a secure communication

channel. You should configure SFMS and an authentication broker on the same

system. The following procedure was done on a Solaris system. The procedure

assumes that you have already created an authentication principal for the new


To add a new authentication broker, you need the following information:

■ The name of the system where the Root broker is configured

■ The root broker hash file

■ The authentication service communication port number

To set up an authentication broker for SFMS

1 After mounting the SFMS product media, go to the directory with the SFMS

installer script and invoke it:

# cd mountpoint/sol

# ./installer

2 Select to install a new authentication service (option 3) with an authentication

broker (option 3).



To set up SFMS with authentication service

1 After mounting the SFMS product media, go to the directory with the SFMS

installer script and invoke it:

# cd mountpoint/sol

# ./installer

Storage Foundation common proceduresSetting up a Storage Foundation Management Server with authentication service

220

2 On the installation menu, select option 1 to install and configure the SFMS.

Provide the following information when prompted:

■ The name of the system where the authentication broker is configured

■ The administrative password of the authentication broker

■ A user-specified password for the vea_agent authentication principal in

the vea_domain authentication domain

To verify the configuration of SFMS

1 An authentication domain, vea_domain, is created on the system where SFMS

is configured. Type the following command to verify the setup of SFMS:



2 The vea_agent account (authentication principal) is used by the SFMS agent

running on all the hosts (server and managed) to authenticate themselves to

the authentication broker. Other authentication principals, vea_guest,

proxyuser, and webuser, should also be present in the listpdprincipals

command output. Type the following command to list the authentication

principals:

# /opt/VRTSat/bin/vssat listpdprincipals --pdrtype ab \


Principal Name: vea_guest

Principal Type: Service

Principal Name: vea_agent



Principal Type: Unknown

Principal Name: webuser


Principal Name: proxyuser


Using SFMS Web-based interface to administer managed hosts

The following procedure will access managed hosts from the system that has

SFMS installed and configured. To access SFMS, the administrator must log on

via the Veritas Enterprise Administrator (VEA) Web-based interface.

221Storage Foundation common proceduresSetting up a Storage Foundation Management Server with authentication service

To access a managed host using VEA

1 Open a browser window and enter the server URL:

https://proteus.universe.com:8443/VEAWeb/Login

This URL opens a SFMS login screen for the SFMS configured on system

proteus.universe.com.

2 On the Login screen, type the user name, password, and pick the

authentication domain and plug-in:

User Name: root

Password: ******

Domain: proteus.universe.com (unixpwd)

3 Click Login to continue.

4 After logging in, on the SFMS Summary page, click Managing > Servers >

hosts and select the host you want to manage:

5 On the page where host names (such as ophelia.universe.com) are displayed,

use the panel to switch between tabs. The available tabs include Overview,

LUNs, Disks, Disk Groups, Volumes, File Systems, Licenses, Packages, and

Agents. Each tab name refers to the type of operation you can perform on

the selected managed host.

For example, to create a VxFS file system on the managed host ophelia, use

the Disk Groups and Volumes tabs to make a raw Veritas volume device. Use

the File Systems tab to make and mount a VxFS file system on the raw volume

with mount point entry specified. Use the Packages tab to view specific

Symantec product information.

Common Veritas Volume Manager and Veritas FileSystem procedures

Veritas Volume Manager (VxVM) and Veritas File System (VxFS) are components

of Storage Foundation. These products are installed and configured by the installer

script that is available with the Storage Foundation installation media. It is

recommend that you use Veritas Volume Manager and Veritas File System for

Symantec products that install products binaries and data in specific directories.

For example, on UNIX/Linux platforms, NetBackup installs its product binaries

in the /usr/openv directory. Therefore, it is preferred that this directory be

mounted on a VxFS file system created on a VxVM volume. Similarly, a VxFS file

system should be created as a disk storage unit for NetBackup.

Storage Foundation common proceduresCommon Veritas Volume Manager and Veritas File System procedures

222

The commands that are used to create the VxVM objects are listed below. This

procedure was done on an HP-UX system. The same commands can be executed

on other UNIX/Linux systems.

To create a VxVM disk group and volumes on UNIX/Linux

1 On a system where VxVM is installed and configured, invoke the following

command to see the list of physical disks that are managed by VxVM:

# /usr/sbin/vxdisk list

DEVICE TYPE DISK GROUP STATUS

c2t0d0 auto:cdsdisk Disk_7 elroy online

c2t1d0s2 auto:hpdisk rootdisk01 rootdg online

c4t14d0 auto:cdsdisk - - online

2 Create a disk group named xyz on device c4t14d0 and again list the disks:

# /sbin/vxdg init xyz Disk1=c4t14d0

# /usr/sbin/vxdisk list

DEVICE TYPE DISK GROUP STATUS

c2t0d0 auto:cdsdisk Disk_7 elroy online

c2t1d0s2 auto:hpdisk rootdisk01 rootdg online

c4t14d0 auto:cdsdisk Disk1 xyz online

3 On the system with the xyzdisk group, invoke the following VxVM commands

to create a volume named openv in the disk group and print the volume:

# /usr/sbin/vxassist -g xyz make openv 15G

# /usr/sbin/vxprint -g xyz -ht

On Windows, to create a VxVM disk group and volumes, use the NewGroup and

NewVolume tabs in Start >VERITAS >VERITASEnterpriseAdministrator.

223Storage Foundation common proceduresCommon Veritas Volume Manager and Veritas File System procedures

To make and mount a VxFS file system on a VxVM volume

1 On the system with the VxVM disk group named xyz and the volume named

openv, type the following command to make a new VxFS file system on the

volume openv.

# mkfs -F vxfs /dev/vx/rdsk/xyz/openv

version 6 layout

15728640 sectors,

15728640 blocks of size 1024,

log size 16384 blocks

largefiles supported

2 Create a directory for the file system mount point:

# mkdir -p /usr/openv

3 Mount the file system and display the amount of disk space it occupies:

# mount -F vxfs /dev/vx/dsk/xyz/openv /usr/openv

# df -k -F vxfs

On Solaris and HP-UX platforms, use the -F option to specify the VxFS system

type.

On AIX, use the -V option.

On Linux, use the -t option.

On Solaris, the mount table is /etc/vfstab.

On HP-UX and Linux, it is /etc/fstab.

On AIX, it is /etc/filesystems.

Veritas File System is not available on Windows. On Windows, use the native file

system NTFS.

Storage Foundation common proceduresCommon Veritas Volume Manager and Veritas File System procedures

224

InfrastructureCore Services

common procedures


■ About Infrastructure Core Services

■ Verify authentication setup

■ Verify authorization setup

■ Add a new authentication broker

■ Backup and restore authentication data

■ Backup and restore authorization data

About Infrastructure Core ServicesInfrastructure Core Services (ICS) consists of the following products: Private

Branch Exchange (PBX), Authentication (AT) and Authorization (AZ), and Service

Management Framework (SMF).

Note: Service Management Framework is installed and configured by the SLIM

installation script. Therefore, no further installation related details are provided

for SMF.

The name of the system (or host) on which the ICS Products is to be installed can

be specified in either a fully-qualified host name (pluto.dwarf.universe.com),

or a short-name (pluto). It is recommended that you use the fully-qualified host

name when you install CS products.

BAppendix

Private Branch Exchange

Private Branch Exchange (PBX) is a product you use to enable all socket

communications that occur on a management server through a single port

connection. Management servers such as NetBackup and Symantec License

Inventory Manager use Private Branch Exchange extensively to reduce the number

of open port instances.

For example, NetBackup requires Private Branch Exchange on the administrative

consoles, the master server, and on the media servers. NetBackup clients do not

use Private Branch Exchange.

Table B-1 lists products that consume Private Branch Exchange. Entries that show

a check mark indicate the consuming products that use that specific version of

the Private Branch Exchange product. Entries that are blank indicate combinations

that are either not supported or not tested in the use cases in Chapter 6 and

Chapter 7.

Table B-1 Symantec Private Branch Exchange usage matrix

SFCFS/SF

Oracle RAC

Symantec

License

Inventory

Manager

AuthorizationAuthenticationNetBackup

Operations

Manager

NetBackupPrivate Branch

Exchange

1.2

1.3

Installing and configuring Private Branch Exchange

To install and configure the Private Branch Exchange (PBX) on Windows or on

UNIX/Linux, follow the procedures and steps listed below. These steps illustrate

a sample installation for the Private Branch Exchange 1.2.2.43 release for Windows

and release 1.2.2.41 for UNIX/Linux.

To install PBX on Windows

1 Open a Microsoft Explorer window.

2 Navigate to the directory that contains the Private Branch Exchange

installation file, Veritas Private Branch Exchange.msi.

3 Double-click the msi file to start the Private Branch Exchange installation.

4 In the Setup Type window, select the Complete installation type.

5 In the Ready to install the Program window, click Install to start the

installation.

Infrastructure Core Services common proceduresAbout Infrastructure Core Services

226

6 Click Finish to exit the InstallShield wizard panel.

7 Click Start >Control Panel >AddorRemovePrograms, and then verify that

the Private Branch Exchange package has been installed.

8 Go toStart>AdministrativeTools>Services, and then verify that the Private

Branch Exchange service is started.

From the command line, the following information is displayed:

C:\Program Files\VERITAS\VxPBX\bin>pbxcfg --print

Auth User:0 : localsystem

Secure Mode: false

Debug Level: 10

Port Number: 1556

PBX service is not cluster configured

9 To start and stop the Private Branch Exchange service from the command

line, run the following commands, respectively:

c:\> net start VRTSpbx

c:\> net stop VRTSpbx

To install PBX on UNIX/Linux

1 Log in to the system on which you will install Private Branch Exchange.

Navigate to the directory that contains the Private Branch Exchange

installation file and run the installation script. Type:

# cd <mnt>/ NB_60_ICS_1.2.3.45_Solaris

# ./installics

2 Type I (for Install).

3 On the next screen, type 2 (for Private Branch Exchange).

4 Type the name of the system on which you will install Private Branch

Exchange. You see the following information displayed:

installics will install the following PBX packages

on SunOS target systems: neptune

VRTSicsco VERITAS Common Infrastructure

VRTSpbx VERITAS Private Branch Exchange Service

227Infrastructure Core Services common proceduresAbout Infrastructure Core Services

5 Verify Private Branch Exchange has been successfully installed and

configured. Type the following command:

# ps -ef | grep pbx

root 331 1 0 Dec 28 ? 0:16 /opt/VRTSpbx/bin/pbx_exchange

6 Start and then stop the Private Branch Exchange process daemon. Type the

following command:

# /opt/VRTSpbx/bin/vxpbx_exchanged start

The following message is displayed:

Starting VERITAS Private Branch Exchange

# /opt/VRTSpbx/bin/vxpbx_exchanged stop

Done.

7 Verify Private Branch Exchange is configured. Type the following command:

# /opt/VRTSpbx/bin/pbxcfg -p

The following message is displayed:

Auth User:0 : root

Secure Mode: false

Debug Level: 10

Port Number: 1556

PBX service is not cluster configured

About Symantec Product Authentication Service

Symantec Product Authentication Service provides the authentication protocol

to the list of Symantec products in the Table B-2 that need the capability to prove

the identity of entities that access the products. In this context, entities are

individuals who need to manage the products by using non-privileged accounts

while logging on at the operating system level. The authentication interface is

usually a logon session that uses a command line interface, a product’s graphical

user interface, or a Web interface.

Symantec Product Authentication is typically installed by using one of the

following methods:

■ It is installed using the Symantec Product Authentication product installer.

■ It is installed by one of the consuming product's installers.


228

Table B-2 lists all Symantec products that use Symantec Product Authentication.

Entries that show a checkmark for authentication, indicate the consuming products

that use that specific version of Symantec Product Authentication. Entries that

are blank represent combinations that are not illustrated in the chapters. Specific

versions of the consuming products are shown in their respective sections in

Chapter 6 and Chapter 7.

Table B-2 Symantec Product Authentication usage matrix

SFCFS/SF

Oracle RAC

Symantec

License

Inventory

Manager

CommandCentralNetBackup

Operations

Manager

NetBackupSymantec

Product

Authentication ServiceStorage

4.1

4.2

4.3

Authentication domain name after host name

The name of an authentication domain is derived from Symantec product

concatenated with the system name.

■ On UNIX/Linux, when specifying the name of the system (or host) for the AT

domain, the host name should be specified in Fully-Qualified-Host-Name

(FQHN) format (such as neptune.universe.com). In the later versions of AT

(4.3 and later), the FQHN is not required. The FQHN is always used as the

domain name for these authentication product examples.

■ On UNIX/Linux, during the installation, the host name to install the

authentication product can be specified by using the short name (such as

neptune) because the host name directs the installer to install the AT binaries

and configuration files.

■ On Windows, the short name (jupiter) should always be used during the

installation and the AT- related configuration.

Installing and configuring authentication

This installation session illustrates the installation for Authentication 4.2.2.21

release on Windows, and for Authentication 4.2.2.21 release on a system running

HP-UX 11.23 operating system.


To install and configure authentication service on Windows

1 In a browser window, navigate to the directory that has the AT installation

file. Invoke the VxSSVRTSatSetup.exe file by double-clicking it to start the

AT installation.

2 On the Setup Type screen, select Complete as the installation type. For the

destination folder, choose the defaultC:\Program Files\VERITAS\Security\

folder.

3 On the Authentication Broker Service screen, in the Select Authentication

Broker Mode box, choose the intended broker mode for this installation. For

the other options on this screen, use the default values.

When adding a new authentication broker (Authentication Broker Only), on

the Authentication Broker Identity screen, the following information should

be available prior to the install. In the root broker box, the host name of the

root broker and the root’s hash file. In the Broker Identity box, the name of

the authentication principal and password, domain name and type (usually

it is vx) should be entered. As an example:

Root Broker

Hostname mercury.universe.com Port 2821

Hash File C:\TEMP\root_hash

Broker Identity

Name jupiter Password *******


Type vx


4 On the Summary screen, verify that the values that appear for all the options

are correct. Click Next to continue the installation.

5 On the InstallShield Wizard Complete panel click Finish to exit the installer.

Go to Start > Control Panel >Add orRemove Programs, verify that the

authentication service package has been installed. Go to Administrative Tools,

Services and verify the Authentication service has been started.

6 Use the verification procedure to verify that the Authentication product is

configured correctly.



230

To install and configure the Symantec Product Authentication on UNIX/Linux

1 Log in to the system on which to install the authentication service. Navigate

to the directory that contains the Authentication installation file and run the

following installation script:

# cd <mnt>/NB_60_ICS_1.2.3.45_HP

# ./installics

2 Type I (Install/Upgrade a product), and then type 3 (for Veritas Authentication

Service).

3 Type the name of the system on which you will install authentication. You

see the following information displayed:

installics will install the following AT depots

on HPUX target systems: janus

VRTSat VERITAS Authentication Service

4 Configure an authentication broker (choose 2) on the system

janus.universe.com. The following message appears:

Do you want to install the AT Server? [y,n,q] (y)

5 To install the AT client on the system, typen. The following message appears:

Are you ready to configure AT on janus? [y, n, q] (y)

1) Root Broker Only.

2) Authentication Broker Only.

3) Authentication + Root Broker.

6 Enter the mode in which you want to install VRTSat [1-3,q] 2

7 Enter the name of the host running the root broker: mercury.universe.com

8 Enter the broker port: (2821)

9 Enter authentication broker’s identity: janus

10 Enter password for janus: <janus password>

11 Enter the domain name: root\@mercury.sun.universe.com


12 Enter the location of the file containing the root’s hash: /tmp/root_hash. The

following message is displayed:

VERITAS Authentication Service configured successfully.

VERITAS Authentication Service was started successfully.

13 Choose 1 and 3 for Root broker only and Authentication + Root broker

configuration, respectively.

# ps -ef | grep vxatd

root 387 1 0 Jan 28 ? 4:51 /opt/VRTSat/bin/vxatd

14 Use the verification procedure to verify that the authentication product is



Upgrading authentication

To upgrade authentication on UNIX/Linux or Windows

1 Upgrade a system with Symantec Product Authentication 4.2 installed in one

of the following ways:

■ Install SLIM (which requires AT 4.3 and later) software (either Server or

Agent) on the system with AT 4.2. The upgrade should retain the existing

AT’s information.

■ On a system with AT 4.2 already installed, explicitly upgrade the AT to

4.3 (or later).

2 After the upgrade is complete, verify the version string of the authentication

product.

■ On UNIX/Linux:

# cat /opt/VRTSat/build_version

Authentication-4.3.15.0

■ On Windows, go to Start >ControlPanel >AddorRemovePrograms 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.


232

About Symantec Product Authorization Service

Symantec Product Authorization Service provides an access control service that

prevents the improper use of privileged resources. Users are allowed access only

to those resources to which they are authorized. You need to install Symantec

Product Authorization on each system for which you want to control access.

NetBackup is the only Symantec product that uses the authorization service. To

avoid network latency, install and configure the authorization service on the same

system as the master server. On each system on which the NetBackup Media

Server is installed, also install the client portion of the authorization service.

Table B-3 lists the products that consume Symantec Product Authorization. Entries

that show a checkmark for authorization indicate the consuming products that

use a specific version of Symantec Product Authorization. Empty cells indicate

combinations that are either not supported or not tested in the use cases in Chapter

6 and Chapter 7.

Table B-3 Symantec Product Authorization usage matrix

SFCFS/SF

Oracle RAC

Symantec

License

Inventory

Manager

CommandCentralNetBackup

Operations

Manager

NetBackupSymantec

Product

Authorization ServiceStorage

4.1

4.2

4.3

This installation session illustrates the installation for Authorization 4.2.2.16

release on Windows, and for Authorization 4.2.2.16 release on a system running

Solaris 9 operating system.

To install and configure Symantec Product Authorization on Windows

1 To install the authorization service, in an Explore window, navigate to the

directory that has the authorization service installation file, and start the

installation by invoking the VRTSazSetup.exe file.

2 On the Setup Type screen, select Custom as the installation type.

3 On the Choose Destination Location screen, choose the new folder to install

the authorization service, or use the following default destination folder:

C:\Program Files\VERITAS\Security\Authorization


4 On the Select Features screen, choose the intended installation by checking

the Client and Server options.

5 On the Start Copying Files and Setup Status screens, the installation progress

is displayed.

6 On the InstallShield Wizard Complete screen, clickFinish to exit the installer.

Go to Start > Control Panel >Add orRemove Programs and verify that the

authorization service package has been installed.

7 Go to Start >Administrative Tools > Services and verify that the

authorization service has been started.

To install and configure the Symantec Product Authorization on UNIX/Linux

1 Logon to the system on which you will install Symantec Product Authorization.

Navigate to the directory that contains the Authorization installation file,

and run the following installation script:

# cd <mnt>/NB_60_ICS_1.2.3.45_Solaris

# ./installics

2 Type I (Install/Upgrade a product) and then type 5 (for Veritas Authorization

Service).

3 Type the name of the system on which you will install Authorization. The

following information is displayed:

installics will install the following AZ packages

on SunOS target systems: neptune

VRTSaz VERITAS Authorization Service

4 Configure the authorization product on the system neptune.universe.com.

The following prompt is displayed:

Do you want to install the Authorization

Service? [y,n,q] (y)

5 To install the AZ client on the system, type n. The following prompt is

displayed:

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


234

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

prompt:

Do you want the installer to do a cluster configuration

for Authorization Service? [y,n,q] (n)

VERITAS Authorization Service configured successfully.

# ps -ef | grep vxazd

root 439 1 0 Jan 28 ? 0:02 /opt/VRTSaz/bin/vxazd

7 Use the verification procedure to verify the Authorization product was


See “Verify authorization setup” on page 237.

Upgrading authorization

To upgrade the authorization on either UNIX/Linux or Windows, use the following

procedure.

To upgrade Symantec Product Authorization

1 On a system with Symantec Product Authorization 4.2 already installed, you

can explicitly upgrade the AZ to 4.3 (or later).

2 After the upgrade is complete, verify the version string of the authentication

product.

■ On UNIX/Linux:

# cat /opt/VRTSaz/build_version

Authorization-4.2.2.16-050605_1

■ On Windows, go to Start >ControlPanel >AddorRemovePrograms and

choose the Authentication product. (Consuming product such as NetBackup

that uses the authorization product should continue to work.)

3 The installation scripts provided in theSymantec Product Authorization

document should be used for performing the upgrade.

Verify authentication setupSymantec Product Authentication can be installed and configured in one of the

following modes:

■ Authentication Broker (mode is 1)

235Infrastructure Core Services common proceduresVerify authentication setup

■ Root Broker (mode is 2)

■ Root plus Authentication Broker (mode is 3)

■ Client

To verify the authentication process

1 To verify that the authentication process on UNIX/Linux (vxatd) is running,

use the ps command.

2 On Windows, click Start > Settings > Control Panel >Administrative Tools

> Services. Locate the authentication service and verify it has started and is

online.

3 To verify the system has the root plus authentication broker installed and

configured correctly, the vxatdprocess must be running and the Broker mode

should be 3.

# /opt/VRTSat/bin/vssat listpd --pdrtype root



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

4.3 and later) can be used. Type:


5 In Authentication version 4.2 and earlier, type the following command:

# /opt/VRTSat/bin/vssregctl -l -q \

-b "Security\Authentication\Authentication Broker" \

-k Mode

Infrastructure Core Services common proceduresVerify authentication setup

236

The procedure for installing and configuring a root broker only on a system is

similar to that of the root plus authentication broker.

1 Verify the Authentication process (vxatd) is running, the broker’s mode is 2,

and the following commands completed successfully:

# /opt/VRTSat/bin/vssat listpd --pdrtype root



2 Verify that the authentication broker has been installed and configured

successfully using a remote root broker. The Broker’s mode should be 1.

3 Verify the Authentication process (vxatd) is running, the broker’s mode

should be 1, and the following commands completed successfully:




The Broker mode of 0 indicates that the Symantec Product Authentication

is not configured. A system that only has the authentication client component

installed will also show the mode as 0.

Verify authorization setupYou can use the procedures described in this section to verify the setup of the

authorization service

To start and stop the Authorization service

1 On Windows, go to Start >Administrative Tools > Services and start the

authorization service. The Authorization service can also be started from the

command line by executing "net start vrtsaz". To stop the Authorization

service, execute “net stop vrtsaz”.

2 On UNIX/Linux, to start the authorization service, execute the

"/opt/VRTSaz/bin/vrtsaz" command. To stop the Authorization service,

execute this command “/opt/VRTSaz/bin/vrtsaz –stop”.

3 Verify the Authorization service using one of the following commands:

■ On UNIX/Linux:

# /opt/VRTSat/bin/vssregctl \

-g /etc/vx/vss/VRTSaz.conf -e \

-b Security\\Authorization\\ServiceIdentity

Name: ServiceName Type: 0 Value: vxazd_vxsvc

237Infrastructure Core Services common proceduresVerify authorization setup

Name: ServiceDomainName Type: 0 Value: SERVICES@neptune.

universe.com

Name: ServiceDomainType Type: 0 Value: vx

Name: AuthenticationBrokerHost Type: 0 Value: localhost

Name: AuthenticationBrokerPortNumber Type: 0 Value: 2821

■ On Windows:


vssregctl -g HKEY_LOCAL_MACHINE\Software\VERITAS

-e -bSecurity\Authorization

Add a new authentication brokerIn an existing authentication hierarchy, adding a new authentication broker can

be done using the procedures in this section.

For example, assume the existing root broker is configured on system

mercury.universe.com, and that there is a need to add a new authentication

broker to this authentication hierarchy.

Use the vssat command on both UNIX/Linux and Windows. The vssat command

options are used on both platforms. The directory where the vssat command is

located is different on UNIX/Linux and Windows.

To set up the new authentication broker

1 On the system mercury.universe.com, create an authentication principal

for the new Authentication broker.

mercury.universe.com# vssat addprpl --pdrtype root \


--prplname jupiter --password jupiter123 \

--credexpiry 0 \

--prpltype service

Created Principal: jupiter

2 Copy the root root_hash file to the system where the new authentication

broker will be installed. On the AB (authentication broker to be).

mercury.universe.com# rcp /opt/VRTSat/bin/root_hash \

jupiter.universe.com:/tmp

Infrastructure Core Services common proceduresAdd a new authentication broker

238

3 Locate an installer that is capable of installing the version of the Symantec

Product Authentication, install and configure this Symantec product in

authentication broker mode. The authentication principal created on the

system with the root broker, principals’s password, and the root’s hash_file

must be provided when prompted by the installer script.

4 After the Symantec Product Authentication is successfully configured, verify

the authentication broker mode is 1.

jupiter.universe.com# /opt/VRTSat/bin/vssat showbrokermode

5 To start and stop the Symantec Product Authentication process, use the

following scripts:

AIX /etc/rc.d/rc2.d/S70vxatd [start | stop]

HP-UX /sbin/rc2.d/S700vxatd [start | stop]

Solaris/Linux /etc/rc2.d/S70vxatd [start | stop]

Window C:>\ net start vrtsat

Start > All Programs > Administrative Tools > Services

Backup and restore authentication dataSymantec Product Authentication provides a utility that can be used to back up

the data that is critical to the operation for the Symantec product. The backup

utility creates a temporary backup directory, and collects all the credential and

configuration files in this directory.

The backup procedure applies to a system that has the service and client

components installed and configured, either in root or root plus Authentication

mode. On a system that only has the client component, there is no credential

information.

On UNIX/Linux, critical authentication data is stored in the following directories:

/var/VRTsat

/etc/vx/vss

On Windows, the following directory stores the critical data:

C>:\Program Files\VERITAS\Security\Authentication\systemprofile

Use the showbackuplist option in the vssat utility to obtain a snapshot of the

crucial data. The vssat creates a temporary backup directory in

/var/VRTSatSnapShot to store the backup files.

239Infrastructure Core Services common proceduresBackup and restore authentication data

On the UNIX/Linux system, the Symantec Product Authentication is configured

in root plus Authentication broker mode.

# /opt/VRTSat/bin/vssat showbackuplist

B|/var/VRTSat/.VRTSat/profile/VRTSatlocal.conf

B|/var/VRTSat/.VRTSat/profile/certstore

B|/var/VRTSat/RBAuthSource

B|/var/VRTSat/ABAuthSource

B|/etc/vx/vss/VRTSat.conf

Quiescing ...

Snapshot Directory :/var/VRTSatSnapShot

The /var/VRTSatSnapShot directory can then be backed up by backup application

such as NetBackup, or operating system native utilities such as tar and cpio.

On Windows, use thevssat.exe showbackuplist command to perform the backup.

On this Windows system, the Symantec Product Authentication is configured in

Authentication broker mode.

C:\Program Files\VERITAS\Security\Authentication\bin> \

.\vssat.exe showbackuplist

B|C:\Program Files\VERITAS\Security\Authentication\systemprofile\ \

VRTSatlocal.conf

B|C:\Program Files\VERITAS\Security\Authentication\systemprofile\ \

certstore

B|C:\Program Files\VERITAS\Security\Authentication\systemprofile \

ABAuthSource

K|HKEY_LOCAL_MACHINE\SOFTWARE\VERITAS\Security\Authentication

Quiesing ...

Snapshot Directory :C:\Program Files\VERITAS\Security\Authentication\ \

Snapshot


It is also important to backup the Symantec Product Authentication binaries and

libraries that are installed on the system.

On UNIX/Linux, the Symantec Product Authentication is installed in /opt/VRTSat

directory. Backing up this top level directory and the associated

/var/VRTSatSnapShot backup files would constitute a valid backup.

On Windows, the Symantec Product Authentication is installed in this directory.

C>:\Program Files\VERITAS\Security\Authentication

Infrastructure Core Services common proceduresBackup and restore authentication data

240

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.

Backup and restore authorization dataSymantec Product Authorization provides a utility that can back up data that is

critical to the operation for the Symantec product. This backup utility creates

temporary backup directories and collects the access control list data repository

and configuration files into their respective temporary directories.

The backup procedure applies to a system that has the service and client

components installed and configured in authorization service mode. On a system

that only has the client component, there is no access control list data repository

to back up.

To perform a backup, an authenticated user can use the showbackuplist option

in the vssaz utility to obtain a snapshot of the crucial data.

To authenticate a user on UNIX/Linux prior to performing a backup, type the

following command:

# /opt/VRTSaz/bin/vssaz login \

--domain unixpwd:neptune.universe.com

Enter the AT Broker(host[:port]) to use: neptune.universe.com

Enter principal name: root

Enter password for root:

Login Successful

As an authenticated user, the backup for the Symantec Product Authorization is

performed using the vssaz command on UNIX/Linux. The vssaz command creates

temporary backup directories to store the backup files, as follows:

# /opt/VRTSaz/bin/vssaz showbackuplist

B|/var/VRTSaz/DBbackup

R|/var/VRTSaz/objdb

B|/var/VRTSaz/vxazd.log

B|/var/VRTSaz/debug

B|/etc/vx/vss/VRTSaz.conf

241Infrastructure Core Services common proceduresBackup and restore authorization data

B|/etc/vx/vss/VRTSaz.loc

#

The /var/VRTSaz directory and /etc/vx/vss/VRTSaz.conf and

/etc/vx/vss/VRTSaz.loc configuration files can then be backed up using a backup

application such as NetBackup, or operating system native utilities such as tar

and cpio. It is also important to backup the Symantec Product Authorization

binaries and libraries that are installed on the system.

On UNIX/Linux, the Symantec Product Authorization is installed in /opt/VRTSaz

directory. Backing up this top level directory, the associated /var/VRTSazdirectory,

and the /etc/vx/vss configuration files would constitute a valid backup.

On Windows, the Symantec Product Authorization is installed in this directory.

The vssaz.exe command stores the backup image into specific directories

(displayed in vssaz.exe command output) similar to UNIX/Linux.

C:\Program Files\VERITAS\Security\Authorization>

In your enterprise, the validity of the backup procedure and the data should be

verified by performing a restore. Using NetBackup application, it is possible to

restore the backed up files to a different directory. After the files are restored,

copy the needed files to their original location. The Symantec Product

Authorization must be able to use the restored binaries or libraries, and operate

on the restored repository or configuration files.

See the vssaz(1) manual page for more information on the vssad command and

showbackuplist option.

Infrastructure Core Services common proceduresBackup and restore authorization data

242

NetBackup common

procedures


■ NetBackup access control parameters

■ Verify NetBackup access control setup on the master server

■ Verify NetBackup access control setup on media servers

■ Verify NetBackup access control setup on clients

■ Using a remote administrative client to manage the master server

■ Replacing the root broker on the NetBackup master server

■ NetBackup storage units

■ NetBackup policies

■ Successful NetBackup backup and restore

■ NetBackup and authorization

■ NetBackup tape device drivers

■ NetBackup Java Windows administration console

■ NetBackup access control troubleshooting tips and messages

NetBackup access control parametersNetBackup Access Control (NBAC) is governed by the following NetBackup

parameters on both UNIX/Linux and Windows platforms:

CAppendix

AUTHORIZATION_SERVICE = <Host with AZ service running> <AZ port>

AUTHENTICATION_DOMAIN = <Domain> <"comment"> <Mechanism> <BrokerHost>

<AT Port> 0

USE_VXSS = { Prohibited | Required | Automatic }

VXSS_NETWORK = <subject IP/Subnet/Host/Domain to either prohibited \

or required>

The NetBackup parameters are defined as follows:

■ AUTHORIZATION SERVICE - refers to the host name (usually a fully-qualified

host name on UNIX/Linux, and a host name on Windows) that is running the

authorization service. The 0 signifies that NetBackup is using the default

authorization port number 4032. This parameter is applicable only to the

master and media servers.

■ AUTHENTICATION DOMAIN - contains the domain name, user-defined

comment, mechanism (UNIXPWD, NIS, NISPLUS, WINDOWS) and the

authentication broker. The lines of code (when specified in the bp.conf file)

show that the master server uses the NISPLUS and WINDOWS mechanisms

for authentication. The NISPLUS domain is universe.com. and the

authentication broker is on neptune.universe.com. For the WINDOWS

mechanism, the domain is SUN (an Active Directory on Windows), and

jupiter.universe.com is the authentication broker. The 0 signifies that

NetBackup is using the default Authentication port number: 2821

AUTHENTICATION_DOMAIN=

universe.com. "neptune NIS+" NIS+ neptune.universe.com 0

AUTHENTICATION_DOMAIN=

SUN "SUN WINDOWS" WINDOWS jupiter.universe.com 0

The showallbrokerdomains option of the vssat command shows the domain

name of an authentication mechanism (domain type).

On UNIX/Linux, the sample output is, as follows:


***********************************


Broker Port: 2821



On Windows the sample output is, as follows:

NetBackup common proceduresNetBackup access control parameters

244

C:\Program Files\VERITAS\Security\Authentication\bin>.\vssat \

showallbrokerdomains

****************************************

Broker Name: jupiter.sun.universe.com

Broker Port: 2821

Domain Name: SUN

Domain Type: nt

The valid values for USE_VXSS parameters are as follows:

■ Prohibited - turns off NetBackup Access Control

■ Required - mandates that the master server, all the media servers (including

the masters) and all of the clients (including the client on the master) are

configured for NetBackup Access Control

■ Automatic - permits some managed hosts (such as media and client) to be

configured for NetBackup Access Control, and also permits other hosts to be

configured with NetBackup Access Control disabled or not configured at all.

The AUTHENTICATION_DOMAIN and USE_VXSS parameters are applicable to the

master server, the media server, and the client.

The VXSS_NETWORK parameter is only used when USE_VXSS is set toAutomatic.

VxSS network entries can be based on IP addresses, IP subnets, host names, or

domain names. When a client or media server is involved in a NetBackup operation,

the entries in the VxSS Network are consulted to determine if the host (client or

media) requires a specific security level, such as Prohibited or Required.

The VxSS network entries are searched and evaluated from top to bottom, and

the search stops when the first match is found. For example, if a master server

has media servers and clients with IP addresses 20.240.98.* and 20.240.90.*,

respectively, specifying 20.240.90 in a VxSS network entry with Required would

mandate all the clients in this subnet to have NetBackup Access Control enabled.

Specifying 20.240.98.23 in VxSS Networks with Prohibited would turn off

NetBackup Access Control for the media server only. Specifying

pluto.dwarf.universe.comwith Requiredwould subject this host to have NBAC

enabled.

The VXSS_NETWORK parameter is applicable to the master server, the media

server, and the client. When configuring NetBackup for access control, the

/usr/openv/netbackup/bin/jnbSA (on UNIX/Linux), or administrative console

(on Windows) GUI tools should be used to modify these parameters. On

UNIX/Linux, these parameters are stored in the /usr/openv/netbackup/bp.conf

file. Do not modify the content of the bp.conf file with a text editor; always use

the jnbSA or administrative console.

245NetBackup common proceduresNetBackup access control parameters

You use the following NetBackup utilities to stop and start the NetBackup server

for the changes to take effect on UNIX/Linux:



The following NetBackup access control parameters are kept in the registry on

Windows: Click Start >Run and type regedit. Navigate to the following entry

and look for the NetBackup Access Control parameters.


To change the value of an NetBackup Access Control parameter, first highlight

the parameter, then modify its value. You stop and then start the NetBackup

Server using the bpdown and bpup utilities, respectively, for the changes to take

effect on Windows.

C:\> C:\"Program Files"\VERITAS\NetBackup\bin\bpdown

C:\> C:\"Program Files"\VERITAS\NetBackup\bin\bpup

Verify NetBackup access control setup on themasterserver

You follow the information described in this section to verify the NetBackup

Access Control setup on UNIX/Linux and Windows master servers.

About shared Veritas products and processes

In NetBackup 6.0 and later, the shared component, Private Branch Exchange, is

required for the NetBackup master server. Private Branch Exchange is a

prerequisite to NetBackup and must be installed and configured on a system before

installing the NetBackup master server. Configuring the NetBackup master server

and then adding NetBackup Access Control support are two separate tasks which

you can perform sequentially.

To enable NetBackup Access Control on the master server, the prerequisite

products, Symantec Product Authentication (AT) and Symantec Product

Authorization (AZ), must be installed and configured on the same system as the

master server. You normally configure Symantec Product Authentication in

authentication broker mode using an existing root broker already configured on

a remote system. If NetBackup is the only Symantec product in your data center,

you may place the root broker and the authentication brokers on the same

computer as the NetBackup master server.

NetBackup common proceduresVerify NetBackup access control setup on the master server

246

To verify the installed version of the authentication and authorization products,

the list package command on Solaris (pkginfo), AIX (lslpp), HP-UX (swlist), or

Linux (rpm) can be used to show the product version. Read the command man

pages on the correct options to use. On Windows platforms, you access Start >

Settings > Control Panel >Add orRemove Programs. Then access the product

and go to the link, Click here for support information

UNIX/Linux

Before setting up NetBackup Access Control, you verify the pbx_exhange, vxatd,

and vxazd processes are running on the system on which the NetBackup master

server is configured. On the designated host, use the ps1 or

/usr/openv/netbackup/bin/bpps -x commands on the host to verify the

processes are running.

A sample output is shown, as follows:


Shared VERITAS Processes

------------------------

root 307 1 0 Dec 07 ? 0:05 /opt/VRTSpbx/bin/pbx_exchange

root 411 1 0 Dec 07 ? 0:03 /opt/VRTSaz/bin/vxazd

root 5778 1 0 Dec 07 ? 0:01 /opt/VRTSat/bin/vxatd

For information on how to manually start processes, refer to the following section.


Windows

On the system where NetBackup Master Server is configured, you navigate from

the Windows Start menu, and click Administrative Tools > Services. You then

verify the following services are started:

■ Private Branch Exchange

■ Authentication Service

■ Authorization Service

If a service is not started, highlight that service and click Start. Also, on the

Windows Task Manager, verify that the vxatd.exe and vxazd.exe processes are

running.

247NetBackup common proceduresVerify NetBackup access control setup on the master server

Verify NetBackup valid authentication domain

On the system with the master server, verify that the NetBackup domain

(NBU_Machines), the primary authentication broker, and the host name are

correct. Use the NetBackup bpnbat command to list this information.

This section contains sample outputs of the bpnbat command for UNIX/Linux

and Windows master servers. On UNIX/Linux platforms, neptune.universe.com

is the host name on which the master server is configured. On the same system,

the root and authentication brokers are also configured. The domain is

[email protected], and the primary authentication broker

is also on neptune.universe.com.

The following is a sample output for UNIX/Linux master server:


/usr/openv/var/vxss/credentials/neptune.universe.com







On Windows, all the systems in this document are contained in a private domain

named sun. The static host name for the master server is jupiter.universe.com.

Since jupiter.universe.com belongs to the sun private domain, the host name

becomes jupiter.sun.universe.com. On this system, it has an authentication

broker, and the root broker is on a remote host (mercury.universe.com). For

information on how to add a new authentication broker with a remote root broker,

refer to the following section.


The following is a sample output for a Windows master server:

C:\Program Files\VERITAS\NetBackup\bin>bpnbat -whoami -cf \

..\var\vxss\credentials\jupiter.sun.universe.com




Expiry Date: Nov 30 18:44:36 2007 GMT



C:\Program Files\VERITAS\NetBackup\bin>


248

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

[email protected], or if it is missing, use the bpnbat

command with the host name jupiter.

The following example illustrates sample Windows output:

C:\Program Files\VERITAS\NetBackup\bin>.\bpnbat -addmachine

Does this machine use Dynamic Host \

Configuration Protocol (DHCP)? (y/n)n



Machine Name: jupiter

Password: ******

Password: ******


Note: On UNIX/Linux, if NBU_Machines is missing, use -addmachine for the host

name neptune.universe.com.

After using -addmachine, use the following command on the machine where the

certificate is to be placed. In this case, jupiter.universe.com (master server).


C:\Program Files\VERITAS\NetBackup\bin>.\bpnbat -loginmachine

Does this machine use Dynamic Host \

Configuration Protocol (DHCP)? (y/n)n



Machine Name: jupiter

Password: ******


Next, verify that you can successfully log on. This ensures that the authentication

portion of the NetBackup Access Control configuration on the master server is

set up correctly. The login name (root on UNIX/Linux or administrator on

Windows) must be a member of the NBU_Security Admin group. To log on, type

bpnbat -login.



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


Authentication port [0 is default]:

Authentication type (NIS, NISPLUS, WINDOWS, vx, unixpwd): WINDOWS

Domain: SUN


Password: ******


Perform authorization lookups on NetBackup machines

On the system on which the authorization service server is configured for

NetBackup, login as root (on UNIX/Linux) or administrator (on Windows), and

run the NetBackup command bpnbaz -ShowAuthorizers from the command line.

This command shows the host names of the master server and of all the media

servers that are permitted to perform authorization lookups. All servers listed

should display the vx (Veritas Private Domain) authentication domain type in the

domain [email protected].

UNIX/Linux sample output, as follows:

# /usr/openv/netbackup/bin/admincmd/bpnbaz -ShowAuthorizers

==========

Type: User

Domain Type: vx



Windows sample output, as follows:

C:\Program Files\VERITAS\NetBackup\bin\admincmd> .\bpnbaz \

-ShowAuthorizers -server jupiter

==========

Type: User

Domain Type: windows

Domain:JUPITER.SUN.UNIVERSE.COM

Name: ADMINISTRATOR

==========

Type: User

Domain Type: windows

Domain:JUPITER.SUN.UNIVERSE.COM

Name: GOKU

==========


250

Type: User

Domain Type: vx




==========

Type: User

Domain Type: vx




If a host that has either the master or media server configured, but it is missing

on the list of authorized machines, add the host name using the NetBackup

command bpnbaz -allowauthorization.

On Windows, the sample output is, as follows:

C:\Program Files\VERITAS\NetBackup\bin\admincmd>.\bpnbaz \

-allowauthorization jupiter -server jupiter


Verify NetBackup authorization database

Use the NetBackup command bpnbaz to verify the authorization database is




NBU_User

NBU_Operator

NBU_Admin

NBU_Security Admin

Vault_Operator



C:\Program Files\VERITAS\NetBackup\bin\admincmd>.\bpnbaz -listgroups

NBU_User

NBU_Operator

NBU_Admin

NBU_Security Admin


Vault_Operator


If neither bpnbaz -listgroups returns any groups, or bpnbaz -listmainobjects

returns any data, use the bpnbaz -setupsecurity command to set up the security

for the master server.

Verify host properties configured correctly

While you are logged on, either through the command jnbSA on UNIX/Linux, or

through the administrative console in Windows, expand Host Properties, double

click Master and highlight the master server. On the menu bar, click Action >

Properties. In the Access Control properties, verify that the Veritas Security

Services (VxSS) property is set correctly.

The VxSS (USE_VXSS) setting should be either Automatic or Required. Required

is for a setup in which all hosts (Master, Media, Clients) are using NBAC. If all

hosts are not using NBAC, the VxSS (USE_VXSS) should be set to Automatic.

Next, verify that all domains in the authentication domains list are spelled correctly

and point to valid authentication brokers and mechanisms. Then verify that the

host name for the authorization service is spelled correctly.


On UNIX/Linux, the sample output is as follows:



SERVER = janus.univerise.com

CLIENT_NAME = neptune.universe.com

AUTHENTICATION_DOMAIN = universe.com. "NIS+ namespace"

NIS+ neptune.universe.com 0

AUTHENTICATION_DOMAIN = neptune.universe.com "/etc/passwd"

PASSWD neptune.universe.com 0

AUTHORIZATION_SERVICE = neptune.universe.com 0

USE_VXSS = REQUIRED

On Windows, the NetBackup parameters are stored in the registry. Use the regedit

(or regedt32 to handle multibyte characters) command to view NetBackup Access

Control and other NetBackup parameters. Refer to the following section for more

information.



252

Cross-platform authentication domains

On a master server, you can setup NetBackup for access control with multiple

authentication brokers distributed across UNIX/Linux and Windows platforms.

A master server, either UNIX/Linux or Windows, could have authentication brokers

configured on Windows, HP-UX, Red Hat, AIX, and Solaris platforms. On each of

these platforms, an authentication broker can be setup to use one or more

authentication domains and mechanisms.

For example, a master server is configured on Windows, and it has media servers

and clients on Windows, HP-UX, Red Hat, and Solaris. Users on Windows are

authenticated through the WINDOWS (nt) mechanism.

UNIX/Linux users can be authenticated by PASSWD, NIS, or NISPLUS authentication

mechanism. The WINDOWS mechanism is specific to Windows. The PASSWD, NIS,

and NISPLUS mechanisms are applicable to UNIX/Linux platforms only.

All of the media servers and clients are authenticated by the authentication broker

configured on the master server. Windows clients can be authenticated by the

authentication broker configured on either the Windows or UNIX/Linux master

server, or media server.

To authenticate users on HP-UX that use NISPLUS, an authentication broker is

needed on a UNIX/Linux platform that has the NISPLUS mechanism configured.

Since the master server has UNIX/Linux media servers, you can configure an

authentication broker with NISPLUS on a UNIX/Linux host that has a media

server.

Authentication brokers on these media servers can then be used to authenticate

their respective users. Therefore, you can use the authentication broker configured

on Red Hat to authenticate all of the Red Hat users. Similarly, the authentication

broker on Solaris could be used to authenticate all of the Solaris users. You can

use an authentication broker configured on AIX to authenticate users on HP-UX.

Conversely, a master server configured on UNIX/Linux may have authentication

brokers dispersed over Solaris, HP-UX, AIX, Red Hat, and Windows. In an

environment that has heterogenous authentication brokers, take care to ensure

that authentication brokers are associated with the correct mechanisms

(WINDOWS, NIS, NISPLUS, PASSWD) for the chosen authentication domains.

Refer to the following section for the list of NBAC parameters, and how to locate

and view them on UNIX/Linux and Windows platforms.


On Windows, the following relevant NetBackup parameters (extracted through

the config registry) are shown:


SERVER = jupiter

MEDIA_SERVER = janus.universe.com

MEDIA_SERVER = titan.universe.com

MEDIA_SERVER = leda

CLIENT_NAME = jupiter

AUTHENTICATION_DOMAIN = SUN "Windows domain" WINDOWS jupiter 0

AUTHENTICATION_DOMAIN = titan.universe.com "/etc/passwd"

PASSWD titan.universe.com 0

AUTHENTICATION_DOMAIN = universe.com. "NIS+ domain"

NIS+ janus.universe.com 0

AUTHORIZATION_SERVICE = jupiter 0

USE_VXSS = REQUIRED

Verify NetBackup access control setup on mediaservers

You follow the information in this section to verify the NetBackup Access Control

setup on both UNIX/Linux and Windows media servers.

Shared Veritas products and processes

In NetBackup 6.0 and later, the shared component Private Branch Exchange (PBX)

is required for NetBackup Media Server. PBX is a prerequisite and must be installed

and configured on the system before installing NetBackup Media Server.

Configuring NetBackup Media Server and adding NetBackup Access Control

support are two separate tasks which can be done sequentially.

To enable NetBackup Access Control on the Media Server, you must first install

the prerequisite Authentication (AT) and Authorization (AZ) products. For

NetBackup Media Server, only the client portion of these products is needed. A

client install does not require configuration and therefore the vxatd and vxazd

processes will not be running on the designated host.

However, the AT could be configured in authentication broker mode using an

existing root broker already configured on a remote system. The authentication

broker could be used to authenticate NetBackup users of the same platform as

the media server.

For example, suppose the master server is on Windows and the media server is

on HP-UX. For HP-UX clients that want to authenticate using the NISPLUS

authentication mechanism, an authentication broker that is capable of supporting

NISPLUS must be available to authenticate these HP-UX clients. The media server

NetBackup common proceduresVerify NetBackup access control setup on media servers

254

uses the authentication broker configured on the master server residing on a

Windows system.

To verify the installed version of the Symantec Product Authentication and

Authorization products, use the following commands:


use the list package command on Solaris (pkginfo), AIX (lslpp), HP-UX (swlist), or

Linux (rpm) to show the product version. Read the command man pages for the

correct options to use. On Windows, you access the Control Panel, and click Add

orRemove Programs. You then select the product name, and click Click here for

support information.

Media Server valid credential verification

In the enterprise, assume the authentication root broker is configured on a

Windows host (mercury.universe.com), and all the Windows hosts are contained

in a Windows private domain (sun). Also assume the NetBackup master server

(jupiter.universe.com) has two media servers:leda.universe.comon Windows,

and janus.universe.com on HP-UX.

On Windows, for each host that has the media server configured for NetBackup

Access Control, you verify the media server’s authentication certificate is issued

by the root broker (mercury.universe.com). You also verify that the media server

is authenticated against the expected authentication broker. You use the NetBackup

command bpnbat -whoami -cf <file> to perform these verifications.

On Windows, the following sample output is shown:

C:\Program Files\VERITAS\NetBackup\bin>.\bpnbat -whoami

-cf ..\var\vxss\credentials\leda.sun.univers.com

Name: leda.sun.univers.com






On UNIX/Linux, the following sample output is shown:


-cf /usr/openv/var/vxss/credentials/janus.universe.com

Name: janus.universe.com




255NetBackup common proceduresVerify NetBackup access control setup on media servers



Media servers accessible to the authorization database

NetBackup resources such as storage units and volume pools are checked against

access control rules listed in the authorization database when they are accessed.

Therefore, media servers (configured externally to the master server) must be

able to access the authorization database. To show that a media server has access

to the authorization database, you use the NetBackup command bpnbaz

-ListGroups -CredFile <file> to perform the authorization checks.

On a UNIX/Linux media server (janus.universe.com), the following sample output

is shown:

# /usr/openv/netbackup/bin/admincmd/bpnbaz -ListGroups \

-Server jupiter.universe.com \

-CredFile /usr/openv/var/vxss/credentials/janus.universe.com

NBU_User

NBU_Operator

NBU_Admin

NBU_Security Admin

Vault_Operator


On a Windows media server (leda.universe.com), the following sample output is

shown:

C:\Program Files\VERITAS\NetBackup\bin\admincmd>.\bpnbaz

-ListGroups \

-Server jupiter \

-CredFile ..\..\var\vxss\credentials\leda.sun.univers.com

NBU_User

NBU_Operator

NBU_Admin

NBU_Security Admin

Vault_Operator


After the bpnbaz command successfully executes, it shows that the authentication

and authorization client libraries are installed and working. If the host where the

Media Server is configured was not granted the privilege to perform authorization

checks, the host must be added to the authorization list. To grant a new media

server host the authorization checks privilege, on the master server

NetBackup common proceduresVerify NetBackup access control setup on media servers

256

jupiter.universe.com, you run the NetBackup command bpnbaz

-allowauthorization.

On the host that has the master server jupiter.universe.com, add a new host

(titan.universe.com on Red Hat) that has the media server configured.

On a Windows host that has the Master Server, the sample output is shown, as

follows:

C:\Program Files\VERITAS\NetBackup\bin\admincmd>.\bpnbaz \

-allowauthorization titan.universe.com -server jupiter


Media server with multiple authentication domains

On a media server (either UNIX/Linux or Windows), you can set up an

authentication broker for access control that covers multiple authentication

domains. An authentication domain uses a specific authentication mechanism.

For example, in a data center, the master has a media server on HP-UX, and an

authentication broker configured on the media server is using NISPLUS and PASSWD

authentication mechanisms. This authentication broker can be used to authenticate

NetBackup clients on Solaris, AIX, HP-UX, and Red Hat that want to use either

one of the mechanisms.

Windows clients cannot be authenticated by this media server on HP-UX, because

the mechanisms NISPLUS and PASSWD are not applicable to Windows. To

authenticate Windows clients, a separate Windows media server is needed that

uses the WINDOWS Authentication Mechanism.

In an environment where the authentication broker is configured with

heterogenous authentication domains and mechanisms, care must be taken to

ensure that authentication domains and mechanisms (WINDOWS, NIS, NISPLUS, and

PASSWD) are compatible.

Refer to the following section for the list of NetBackup Access Control parameters,

and how to locate and view them on UNIX/Linux and Windows platforms.


On an HP-UX host that has a media server, some of the relevant NetBackup

parameters (extracted from the /usr/openv/netbackup/bp.conf configuration

file) are as follows:

SERVER = jupiter.universe.com

SERVER = janus.universe.com

CLIENT_NAME = janus.universe.com

257NetBackup common proceduresVerify NetBackup access control setup on media servers

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

Verify NetBackup access control setup on clientsYou follow the information described in this section to verify the NetBackup

Access Control setup on Windows and UNIX/Linux clients.

Shared Veritas product

In NetBackup 6.0 and later, the client installation does not need the shared

component Private Branch Exchange (PBX). Installing NetBackup Client and then

adding NetBackup Access Control support are two separate tasks that can be done

sequentially.

To enable NetBackup Access Control on the NetBackup client, first install the

prerequisite product: Authentication (AT) client. For NetBackup clients, only the

client portion of AT is needed.

The AT client install does not require configuration, so the vxatd process does

not run on the designated host. However, on the designated host where the

NetBackup client is installed, the host could be a node in the Veritas Cluster Server

(VCS). When VCS is configured for authentication, an authentication broker is

required on each node of a VCS cluster. Even though the host has an authentication

broker, the NetBackup client uses a remote authentication broker, and not the

local authentication broker on its master management server.


use the list package command on Solaris (pkginfo), AIX (lslpp), HP-UX (swlist), or

Linux (rpm) to show the product version. Read the command man pages for the

correct options to use. On Windows, you access the Control Panel, and click Add

orRemove Programs. You then select the product name, and click Click here for

support information

Client has valid credentials

You use the NetBackup bpnbat command on a NetBackup client to list the

credential, domain, and the issuing broker information. You then verify that the

client has correct credential, domain and issuing broker.

NetBackup common proceduresVerify NetBackup access control setup on clients

258

Sample outputs of the bpnbat command for Windows and UNIX/Linux clients are

shown.


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

-cf ..\var\vxss\credentials\callisto.sun.universe.com

Name: callisto.sun.universe.com






In a setup that uses the Windows Active Directory, the credential file includes the

Windows domain name, as follows:

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

-cf ..\var\vxss\credentials\galileo.SUN.universe.com

Name: galileo.sun.universe.com








-cf /usr/openv/var/vxss/credentials/calypso.universe.com

Name: calypso.universe.com






If the credential file is missing in the var/vxss/credentials directory, execute the

bpnbat -loginmachine command.

Authentication client libraries

The authentication client libraries must be installed on the system on which the

NetBackup client is set up to use NetBackup Access Control. The command bpnbat

259NetBackup common proceduresVerify NetBackup access control setup on clients

must perform a successful log on to show that the correct authentication libraries

are installed on the system.

On Windows, the following sample output is shown:

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

Authentication Broker: callisto



Domain: SUN

Name: <login in SUN>

Password: <login’s password>


On UNIX/Linux, the following sample output is shown:




Authentication type (NIS, NIS+, WINDOWS, vx, unixpwd): NIS+

Domain: universe.com.

Name: <NIS+’s login>

Password: <NIS+ login’s password>

You do not currently trust the server: neptune.universe.com,

do you wish to trust it? (y/n): y


The top-level directory in which the authentication libraries are installed is found

in the /etc/vx/vss/VRTSat.loc file. On Windows, this information is kept in

the Windows registry of the product.

You use the following commands to verify all the authentication libraries are

physically present in the library /opt/VRTSat/lib directory:

# grep ProductInstallDir /etc/vx/vss/VRTSat.loc

ProductInstallDir=/opt/VRTSat

# ls /opt/VRTSat/lib/*

libauthlocalhost_t.sl libvrtsat4L_t.sl libauthnis.sl libvrtsat_t.sl

libauthnisplus.sl

libAtWrapper.sl libvrtsat.sl libauthlocalhost.sl libvrtsat4L.sl

Client authentication domains

On the system on which the NetBackup Master Server is configured, launch either

the administrative console on Windows, or run the commandjnbSAon UNIX/Linux.

NetBackup common proceduresVerify NetBackup access control setup on clients

260

You access theHostProperties to verify. For jnbSA, the NetBackup Access Control

attributes are found under the Access Control property.

Note: The domains listed in the authentication domain, universe.com.,

neptune.universe.com., or SUN (Windows Active Directory) must be valid for

the user and spelled correctly.

For each authentication domain, you verify that the chosen broker,

neptune.universe.com, jupiter, specified for the user, supports the selected

authentication mechanism (NIS+, PASSWD, or WINDOWS). For example, it is not valid

for an HP-UX user to use an authentication domain with a Windows authentication

broker that uses the WINDOWS mechanism.

The NetBackup Access Control parameter, AUTHENTICATION_DOMAIN, keeps track

of authentication domain, authentication broker, and mechanism (also referred

to as authentication type). The verification of the AUTHENTICATION_DOMAIN can

also be done on the user system.

On a Windows client, the NetBackup Access Control parameters are kept in the

registry. On a UNIX/Linux client, the NetBackup Access Control parameters are

stored in the /usr/openv/netbackup/bp.conf file. To change the NBAC

parameters, either on Windows or UNIX/Linux, refer to the information in the

following section. See “NetBackup access control parameters” on page 243.

Using a remote administrative client to manage themaster server

You must first establish a trust between the administrative client and the

authentication broker configured on the master server for a NetBackup client

with the remote console (administrative client), to manage the master server with

NetBackup Access Control enabled.

On the host that has the NetBackup administrative client, the client portion of

the prerequisite products, authentication (AT) and authorization (AZ), must be

installed. The client installation does not require configuration, so the vxatd.exe

and vxazd.exe processes are not running on the designated host.

It is recommended that the following procedure be performed to establish trust

between the authentication broker configured on the master server, and the

administration client (remote console) on Windows.

261NetBackup common proceduresUsing a remote administrative client to manage the master server

To create trust between authorization broker and administration client

1 On the host where the Master server is configured, run the following

command:

C:\Program Files\VERITAS\NetBackup\bin\admincmd> bpgetconfig \

USE_VXSS AUTHENTICATION_DOMAIN > C:\TEMP\VXSS_SETTING.txt

C:\Program Files\VERITAS\NetBackup\bin\admincmd> type \

C:\TEMP\VXSS_SETTING.txt


AUTHENTICATION_DOMAIN = SUN "WINDOWS" WINDOWS jupiter 0

2 Copy C:\TEMP\VXSS_SETTINGS.txt to the host that has the administration

client.

3 On the host that has the administration client, run the following command:

C:\Program Files\VERITAS\NetBackup\bin\admincmd> bpsetconfig \

C:\TEMP\VXSS_SETTINGS.txt

Using the USE_VXSS and AUTHENTICATION_DOMAIN values copied from the

master server, the bpsetconfig command sets these two parameters on the

administrative client to trust the authentication broker on the master server.

The administration client is then ready to log on automatically to the


4 Launch the administration console from the administration client, and a

request to establish a trust with the master server authentication broker is

initiated. Once the trust is established, the administration console is available.

Replacing the root broker on the NetBackup masterserver

In a data center, a situation (consolidation) may occur that requires the move of

the root broker from the system where the NetBackup master server is configured

to a remote system. Before replacing the local root broker that is used to

authenticate the master authentication broker, first stop the master and all media

management servers.

This example assumes the following existing NetBackup configuration:

■ Host details - Host jupiter.universe.com has the NetBackup master

management server authentication root plus authentication brokers, and

authorization server configured.

NetBackup common proceduresReplacing the root broker on the NetBackup master server

262

■ NetBackup master management server details - NetBackup master has media

servers configured on separate Solaris, HP-UX, AIX, Red Hat, and Windows

systems. Command options, such as bpnbat, vssat, and vxatd, are identical

on both UNIX/Linux and Windows platforms. Binary files such as bpnbat,

netbackup, bpup.exe. and bpdown.exe are located in different directories on

each of these platforms. NetBackup master has management clients on Solaris,

HP-UX, AIX, Red Hat, and Windows systems.

Assume, as an example, that your company needs to decouple the root broker

from jupiter.universe.com to a remote system mercury.universe.com. Use the

following steps to replace the root broker on jupiter.universe.com with the one

on mercury.universe.com, and move all the authentication brokers in the jupiter

authentication hierarchy into mercury.

To move the root broker to a remote system

1 On mercury.universe.com, create a principal (service) for the authentication

broker on jupiter.universe.comas follows:

# /opt/VRTSat/bin/vssat addprpl \

--pdrtype root \

--prplname jupiter.universe.com \

--password jupiter_pass --prpltype service \


If you have additional authentication brokers configured on media servers,

these brokers also need to be moved to the new authentication hierarchy.

Create extra authentication principals (addprpl) for systems that have


2 Shut down the NetBackup master management server, authentication, and

authorization services on jupiter.universe.com, and on systems with media

servers.

■ On UNIX/Linux, as follows:


■ On Windows, bpup is equivalent to netbackup stop. Type the following

command:

C:\Program Files\VERITAS\NetBackup\bin> .\bpdown

■ On Solaris, authentication and authorization services can be stopped with

S71vxazd and S70vxatd, respectively. On other UNIX/Linux platforms,

same scripts located in different directories should be used.

263NetBackup common proceduresReplacing the root broker on the NetBackup master server

# /etc/rc2.d/S71vxazd stop

# /etc/rc2.d/S70vxatd stop

■ On Windows, the authentication and authorization services can be stopped

by clicking Administrative Tools > Services.

3 Remove all the root Private Domain Repository entities on

jupiter.universe.com. On all the systems with master and media servers,

remove all the NetBackup credentials obtained through the previous root

broker. The list of credentials can be shown using the following command:

# /opt/VRTSat/bin/vssat showcred

These credentials should be removed from the system where the master

management server is located. Type the following commands:

# /opt/VRTSat/bin/vssat deletecred \


--prplname broker



--prplname root



--prplname [email protected]

4 Start an authentication broker in another authentication hierarchy by copying

the root hash from the system that has the root broker

(mercury.universe.com), to the system where the authentication broker

(jupiter.universe.com) is located. On mercury.universe.com, remote copy the

hash file to jupiter.universe.com, as follows:

# rcp /opt/VRTSat/bin/root_hash \

jupiter.universe.com:/tmp/root_hash


264

5 Start authentication in authentication broker mode onjupiter.universe.com

using the principal created on mercury.universe.com, as follows:

# /opt/VRTSat/bin/vxatd -a -n <broker> -p <password> \

-x <domainType> -y <domainName> -q <rootBrokerHost> \

-z <rootBrokerPort> -h <rootHashFile>

# /opt/VRTSat/bin/vxatd -a -n jupiter.universe.com \

-p jupiter_pass \


-q mercury.universe.com \

-z 2821 -h /tmp/root_hash

The output of the ps command for the vxatd process shows all the options

that were used. To remove those options, stop and start the vxatd process,

as follows:

# sleep 30


# /etc/rc2.d/S70vxatd start

6 Restart the authorization service, NetBackup master management server,

and all the associated media management servers.

■ On UNIX/Linux, as follows:

# /etc/rc2.d/S71vxazd start


■ On Windows, bpup is equivalent to netbackup start. Type the following

command: C:\Program Files\VERITAS\NetBackup\bin>.\bpup

7 At this point, jupiter authentication broker (vxatd) is using the root broker

on mercury.universe.com. The entities and credentials in the

[email protected] private domain repository are obsolete.

To use the mercury.universe.com credential for the NetBackup master server

on jupiter.universe.com, run the following command:


8 On each system that has a NetBackup media management server, run the

following command to enable the media server host to reacquire the new

credential using the mercury.universe.com certificate:


265NetBackup common proceduresReplacing 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:



10 On each system that has NetBackup management client, run the following

command to enable the client host to reacquire the new credential using the

mercury.universe.com certificate:


11 Run the following command on jupiter.universe.com to get a list of systems

that were previously added to and authenticated in the NBU_Machines private

domain repository:

# /usr/openv/netbackup/bin/bpnbat -showmachines


bianca.universe.com

triton.universe.com

portia.universe.com

12 Run the following command to acquire a new login session on management

clients, master and media management servers:


13 Verify the root broker is moved to the remote system:

■ After you have completed steps 1 through 12 on the master server, media

server, and client, systems, you must successfully log on using the bpnbat

-login command.

■ Use the jnbSA command on UNIX/Linux, or the administrative console

on Windows, to verify a successful logon by the NetBackup Access Control

user. Most importantly, you must perform a backup and a restore for any

NetBackup Access Control-enabled clients using any of the NetBackup

Access Control-enabled media servers.

■ Create a new policy or modify an existing policy; create new storage unit

or modify an existing storage unit in the jnbSA or Administrative console

on the master server.


266

■ On a host that has a media server, perform an update on the tape devices

to verify those connections still work.

NetBackup storage unitsA storage unit is used to store backup images. Every NetBackup policy has a storage

unit. Without the NetBackup Access Control (NBAC), users must be logged in as

either root (UNIX/Linux), or administrator (Windows) to create, modify, or delete

storage units.

Ordinary users (like goku) do not have the required privilege to manipulate storage

units. With NBAC enabled, non-privileged users, who are properly authenticated

and authorized, can manipulate storage units and other NetBackup administrative

tasks that require the privileges of superusers.

To create a disk storage unit as either root or ordinary user

◆ Execute the following command on system neptune.universe.com:

# /usr/openv/netbackup/bin/admincmd/bpstuadd \

-M neptune.universe.com -label neptune-disk -disk \

-path /neptune-disk -dt 1 \

-host neptune.universe.com \

-cj 4 -okrt 0 -hwm 98 -flags NONE \

-odo 0 -mfs 524288

# /usr/openv/netbackup/bin/admincmd/bpstulist

neptune-disk 0 neptune.universe.com 0 -1 -1 4 0

/neptune-disk 0 1 524288 …

To create a storage unit through the NetBackup administration console

1 On NetBackup administration console, NetBackup Management, click the

Storage Units, Actions (at the top), New, New Storage Units…

2 On the New storage unit screen, enter the required information (like Storage

unit name, Storage unit type, Storage device, Media server). ClickOK to create

the storage unit.

3 Go to NetBackup Management, Storage Units, verify the new storage unit

shows up.

An ordinary user (like goku) that was authenticated and with the appropriate

authority is able to create a new storage unit, as illustrated in UNIX/Linux

and Windows examples.

267NetBackup common proceduresNetBackup storage units

4 On the NetBackup Administration console and jnbSA, the Configure Storage

Devices wizard can be used to configure tape libraries. This wizard

automatically creates the necessary storage units for the devices and volumes

in the tape library. On a setup that has multiple media servers, options are

given to selectively pick the media server for device configuration.

5 To configure volumes in tape libraries, on the NetBackup administration

console and jnbSA, use the Configure Volumes wizard for this operation.

The Configure Storage Devices and Configure Volumes wizards should be

performed on the system that has the master management server.

To create a new NetBackup volume pool

1 On the NetBackup administration console (Windows), or jnbSA (UNIX/Linux),

go to Media andDeviceManagement >Media, Highlight VolumePools >

Actions >New>NewVolumePool.

2 On the New Volume Pool screen, verify the host name in the Manager host

is correct. Type in a unique name for the Pool name and a description.

3 Check the Permit only the specified host to access volumes in the pool and

enter the Host name: which should be one of the media servers already

configured in the environment. Click OK to continue.

To verify the new volume pool was created

1 Go to Media andDeviceManagement >Media >VolumeGroups. Highlight

all the volumes to assign to the new volume pool. Click Edit > Change.

2 On the Change volumes screen, in the Volume pool box, check the New pool

and select the new volume pool that was created earlier.

3 Go to the Volume Groups; those volumes that were assigned to the new volume

pool should have the new pool name in the Volume Pool column.

4 In the policy attribute screen, you can select the new volume pool for the

policy.

NetBackup policiesA 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 proceduresNetBackup policies

268

can manipulate policies and other NetBackup administrative tasks that normally

require the privileges of superusers.

To create a NetBackup policy on Windows or UNIX/Linux

1 On the system that has the NBU master management server, go to NetBackup

Management, Policies, Actions (at the top), New, New Policy… Enter the name

for the Policy name: and check the Use Backup Policy Configuration Wizard.

Click OK to continue.

2 On the Policy Name and Type screen, in the Select the policy type field,

typically choose MS-Windows-NT on Windows and Standard on UNIX/Linux

as the policy type.

3 On the Client List screen, enter the host name of the client, client hardware

and operating system. A policy can have multiple clients that could make up

of Windows and UNIX/Linux management clients. Typically, all the Windows

clients are grouped together in policies that are created for Windows. The

same rationale applies to clients on UNIX/Linux platforms.

4 On the Files screen (Backup Selections on UNIX/Linux), enter the directories

or files this policy is intended to cover.

5 On the Backup Type screen, select the Full Backup, Incremental Backup

(differential or cumulative), and User Backup (allow users to initiate backup

on their own). To enable a user to initiate a backup or restore from a client,

the User Backup must be selected.

6 On the Rotation and Start Windows screen, select the retention for the backup

image and the time the backup should start.

7 Click Finish to start creating the NetBackup policy. On the NetBackup

Management, Policies, verify the new policy has appeared.

8 If the Bare Metal Restore license key is installed on the system that has the

NBU master management server, the Collect disaster recovery information

for Bare Metal Restore attribute is checked by default when a NetBackup

policy is created. The BMR attribute should be turned off explicitly if this

capability is not intended.

Successful NetBackup backup and restoreBefore performing a backup and restore, the procedures and instructions that are

listed in the NetBackup use cases in Chapter 6 and Chapter 7 should be completed

successfully. After configuring the master, media and client, a backup policy is

needed to perform a backup. A backup policy needs a storage unit to store the

backup image. To create a backup policy, refer to the following sections.

269NetBackup common proceduresSuccessful NetBackup backup and restore

See “NetBackup policies” on page 268.


A successful backup and restore is used as a simple test to verify the integrity of

the NetBackup’s configuration in the following situations:

■ After the master, media and clients are configured in an environment, but

before the NetBackup Access Control (NBAC) is enabled, the NetBackup servers

must be able to perform a backup for one of the clients (like

europa.universe.com) and restore the backup to another client (like

calypso.universe.com). This task needs to be performed by the root

(UNIX/Linux) or administrator (Windows) user.

■ After configuring the NetBackup product with the NBAC enabled on Master,

Media and Client, to ensure that the NetBackup product is still functioning,

the backup (initiated from the Master) and restore (initiated from the client)

operation is used as one of the verification tests. A properly authenticated and

authorized user other than root or administrator must be able to perform a

task like backup and restore. An ordinary user with proper authority must be

able to perform NetBackup administration tasks such as creating disk storage

units and policies.

■ To do a manual backup for a NetBackup policy, on the Administration console

(Windows) or jnbSA (UNIX/Linux), go to NetBackup Management, Policies,

and select the specific policy name, click the Actions (at the top) and pick

Manual Backup to initiate a backup.

■ A restore is launched through the Backup, Archive and Restore (BAR). On

UNIX/Linux, the BAR is listed on the jnbSA display screen. On Windows, to

get to the BAR, on the Administration console, click File (at the top) and select

the Backup, Archive, and Restore. In jnbSA, the BAR has the options of selecting

source client, destination client and backup type. In Administration console,

the BAR is display on another screen, click File (at the top) of this screen to

display various restore options.

NetBackup and authorizationThe benefits of implementing the Symantec Product Authentication and

Authorization is illustrated by comparing a NetBackup environment with

authentication and authorization and a NetBackup environment without.

In an environment without the Symantec Product Authentication and

Authorization, only the root (UNIX/Linux) or administrator (Windows) account

can manage the NBU servers and clients. NBU management tasks (for example,

policies, storage units, volumes, backup and restore, and reporting) can only be

done by users who are logged in as either root or administrator.

NetBackup common proceduresNetBackup and authorization

270

With NetBackup Access Control (NBAC) enabled in a setup, when users (beside

root or administrator) are granted the necessary authorization privileges, they

can do these NBU management tasks based on the granted privileges. For example,

user goku is granted the NBU_Admin authority and the privileges associated with

this role, he has access to all the NBU subsystems when logged in through the

NetBackup Administrative Console (Windows), jnbSA (UNIX/Linux), or through

the command line. User joe is only granted the NBU_Operator authority and

therefore he can only run backup or restore related tasks.

All users must authenticate themselves and login successfully before authorization

privileges can be granted.

The NetBackup product predefines the following authorization groups when

NetBackup Access Control is configured. Each group is authorized to perform

specific management and operational tasks within NetBackup. A login (associated

with a real user) can be assigned to any number of these groups.


NBU_User

NBU_Operator

NBU_Admin

NBU_Security Admin

Vault_Operator


A login (or account on a system) must have the NBU_Security Admin privilege in

order to execute the bpnbaz command to manage (add, delete) the NBU

authorization groups. Typically, the root or administrator login is assigned to this

group when the NBAC is first setup.

The NBU authorization groups are maintained on the system with NBU master

management (neptune.universe.com) and authorization service (also on

neptune.universe.com). On the system (neptune.universe.com) with the NBU

master management server, run the following command. In this case, user goku

is using the NISPLUS plug-in.


-adduser NBU_Admin nisplus:universe.com.:goku \

-M neptune.universe.com \




-adduser NBU_Admin nt:SUN:administrator \


271NetBackup common proceduresNetBackup and authorization




-listgroupmembers NBU_Admin

Type: User

Domain Type: nt

Domain:SUN

Name: ADMINISTRATOR

Type: User


Domain:universe.com.

Name: goku

To find the authentication domain associated with the NISPLUS plug-in, run the

following command.



Broker Port: 2821



To add an ordinary login to the NBU_Security Admin authorization group, run

the following command.


-adduser "NBU_Security Admin" unixpwd:neptune.universe.com:gohan \





-listgroupmembers "NBU_Security Admin"

Type: User


Domain:neptune.universe.com

Name: gohan

Type: User


Domain:neptune.universe.com

Name: root

NetBackup common proceduresNetBackup and authorization

272

Type: User

Domain Type: nt

Domain:SUN

Name: ADMINISTRATOR


An ordinary user goku logs onto a system using the NISPLUS authentication

mechanism (at the operating system level) and the system has the NBU master

management server enabled with NBAC. On the system, goku performs a login

and use the NISPLUS authentication plug-in assigned to him. After goku

successfully authenticates himself, he has an NBU session granted to him and is

authorized to perform the administrative tasks. At the operating system level,

goku has neither root nor administrative account privileges.

As user goku, he can logon to NBU through the jnbSA:

goku$ /usr/openv/netbackup/bin/jnbSA -d <display> \

-l /tmp/log.3 -lc &

To execute NBU administrative command from the command line, goku has to

authenticate himself and acquire a valid session first.

goku$ /usr/openv/netbackup/bin/bpnbat -login


Authentication port [0 is default]:

Authentication type (NIS, NISPLUS, WINDOWS, vx, unixpwd): NISPLUS

Domain: universe.com.

Login Name: goku

Password: <goku’s NISPLUS password>


goku$ /usr/openv/netbackup/bin/bpnbat -whoami

NetBackup tape device driversOn the systems where NetBackup media servers are installed, to use tape libraries

for backup, the driver software for tape devices should be installed. UNIX, Linux

and Windows operating systems use different driver software. The type of driver

software may also depend on the tape library.

To configure the tape devices on UNIX/Linux platforms, refer to the Media

Manager Device Configuration Guide for UNIX for more information.

273NetBackup common proceduresNetBackup tape device drivers

To configure the tape devices on Windows

1 Connect all the tape libraries to the system where the NetBackup master or

media management server is installed.

2 To install NetBackup Tape Device Drivers, invoke the installer Launch.exe

and select the Additional Products, Additional Product Installations, and

NetBackup Tape Device Drivers (32-bit).

3 On the Choosing tape drivers screen, select the Use Veritas tape drivers for

all tape devices and pick the Use Plug and Play drivers.

4 On the Scanning hardware screen, the system should find all the tape devices

that are attached to the system. Based on the types of tape devices that are

attached, appropriate drivers are then installed on the system as depicted on

the Installing Veritas drivers screen.

5 Click Finish and the screen displays with the message – You must restart

your computer before the new settings will take effect. Click Yes to Do you

want to restart your computer now?

6 After the system has been rebooted, verify the tape devices are present on

the system by going through Start, My Computer (right click), Manage, Device

Manager, and Tape drives.

If the operating system is not recognizing the tape devices, you need to

troubleshoot and ensure the right driver is loaded on the system. For the latest

device driver information and version, refer to the Symantec support website at:

http://www.symantec.com/enterprise/support/assistance_care.jsp

These Veritas device drivers do not utilize Microsoft’s digital signature capability.

NetBackup Java Windows administration consoleThe following procedures are specific to NetBackup administration console on

Windows only.

To install the Java Windows administration console

1 In an Explore window, navigate to the directory that has the NBU installation

files and invoke the Launch.exe file by double-clicking it.


Installation and Install Java Windows Administration Console option.

3 On the License Agreement screen, click the I accept the terms of the license

agreement.


pick the Install to this computer only option.

NetBackup common proceduresNetBackup Java Windows administration console

274


installation of the NBU Java Windows Administration Console. The Installing

NetBackup screen displays the progress of the installation.

6 On the System Validation Complete screen, click Finish to exit the installer.

To upgrade the Java Windows administration console

1 Locate the Java maintenance patch distribution. In an Explore window,

navigate to the directory that has the Java installation files and invoke the

setup.exe file by double-clicking it.

2 On the NetBackup Installation Type screen, choose Install to this computer

only and follow the instructions on the screen.

3 On the Ready to Install the Program screen, click Install to start the

installation.

4 On the Installing NetBackup screen, it displays the version of the maintenance

patch and the installation status.

5 On the System Validation Complete screen, click Finish and verify the

installation completed successfully.

6 In the Start, Control Panel, Add or remove programs, verify the Maintenance

Patch has been installed on the system.

NetBackup access control troubleshooting tips andmessages

The following troubleshooting tips may be useful when you set up your NetBackup

product with access control.

Turn off NetBackup access control

Incorrect configurations or changes to the NetBackup Access Control (NBAC)

could cause the authentication to fail and lock out all login sessions. To repair the

NBAC configuration in the NetBackup Server (using either Administrative Console

on Windows or jnbSA JAVA GUI on UNIX/Linux), the NBAC must be disabled first.

To turn off NetBackup access control on UNIX/Linux

1 Edit the /usr/openv/netbackup/bp.conf file.

2 Set the parameter USE_VXSS to the value Prohibited.

NetBackup Access Control can also be disabled by deleting these lines entirely

or by commenting the line of these parameters using the ‘#’ character as the

prefix.

275NetBackup common proceduresNetBackup access control troubleshooting tips and messages

To turn-off NetBackup Access Control on Windows

1 Change the USE_VXSS parameter (using regedit), highlight it, right click and

modify its value to Prohibited.

2 NetBackup Access Control can also be disabled by deleting all of the NetBackup

Access Control parameters. Highlight the parameter, right click, and choose

the operation (Modify or Delete).


This section provides instructions on how to modifyUSE_VXSS and other NetBackup

Access Control parameters,along with the NetBackup Master Server restart

procedures (UNIX/Linux and Windows) required for the changes to take effect.

There are other situations where disabling NetBackup Access Control may be

needed, such as discontinuing the NetBackup Access Control capability, or if the

authentication and authorization libraries were removed.

Unable to load libraries

■ On a host with NetBackup client, verify that the shared product authentication

(client portion) is installed.

■ On a host with NetBackup Media Server, verify that the shared products

authentication and authorization (client portion) are installed.

■ On a host with NetBackup Master Server, verify that the shared products

authentication and authorization (server portion) are installed and configured.

Optional VxSS libraries not initialized

This message is likely caused by an expired session. A bpnbat –login session is

valid for 24 hours. Attempting to execute NBU commands in an expired session

would show the following message:

EXIT STATUS 116: VxSS authentication failed (status 116)

Try to acquire a new session by issuing the bpnbat –login NetBackup command

on the host that either has master, media or client.

Library Initialization failed. Access denied (188) (MM status 188)

A single jnbSA session is valid for 24 hours. On a jnbSA session that has expired,

this message is displayed. To get a valid session in jnbSA, exit and log back in.

NetBackup common proceduresNetBackup access control troubleshooting tips and messages

276

Unable to connect to authorization server

This message indicates that the authentication session the user is logged in has

expired. Perform a bpnbat -login command to acquire a new authentication

session and then retry the bpnbaz -showauthorizers command again.

# /usr/openv/netbackup/bin/bpnbaz -showauthorizers

Unable to connect to authorization server.

Please check your -Server argument and try again.


# /usr/openv/netbackup/bin/admincmd/bpnbaz -showauthorizers

277NetBackup common proceduresNetBackup access control troubleshooting tips and messages

NetBackup common proceduresNetBackup access control troubleshooting tips and messages

278

CommandCentral

Storage/Service common

procedures


■ Verifying the CommandCentral Storage server setup

■ Verifying the CommandCentral Service server setup

■ Verifying the CommandCentral agents setup

■ Add and modify access by user accounts

■ Replacing the root broker on the CommandCentral server

■ Troubleshooting tips

Verifying the CommandCentral Storage server setupThese procedures are used to determine the status of the CommandCentral (CC)

Storage management server and the Storage Web console on different platforms.

To verify the CommandCentral storage server setup

1 Determine the status of the CommandCentral server and Web servers.

■ On UNIX/Linux, type the following command:

# /opt/VRTS/bin/vxccstor status

***VERITAS Enterprise Administrator running***

***VERITAS Database Management Server running***

***VERITAS Trap Processor running***

DAppendix

***VERITAS Alert Manager running***

***VERITAS SAN Access Layer running***

***VERITAS Alarm Service running***

***VERITAS CommandCentral Data Module running***

***VERITAS CommandCentral Importer running***

***VERITAS SICL running***

■ On Windows, click Start >Administrative Tools > Services and verify

that the following services are started:

■ Veritas CommandCentral Storage Alarm Service

■ Veritas CommandCentral Alert Manager

■ Veritas CommandCentral DM explorers

■ Veritas CommandCentral DM Importer

■ Veritas SAN Access Layer (SAL)

■ Veritas CommandCentral Trap Processor

■ Adaptive Server Anywhere

■ Veritas Enterprise Administrator Service

■ Veritas Simple Instrumentation Collection Layer (SICL)

2 Determine the status of the CommandCentral Storage Web servers by entering

the following commands:

# /opt/VRTSweb/bin/monitorApp cc

Web Application "cc" is ONLINE

# /opt/VRTSweb/bin/monitorApp spc

Web Application "spc" is ONLINE

# /opt/VRTSweb/bin/webgui listapps

ROOT

cc

spc

CommandCentral Storage/Service common proceduresVerifying the CommandCentral Storage server setup

280

3 Verify the authentication setup on the CommandCentral Storage management

server. An authentication broker with authentication domains for the

CommandCentral Storage server should be present on the system on which

the storage management server is configured.





# /opt/VRTSat/bin/vssat listpdprinicpals --pdrtype ab \


Principal Name: ccstr_web




4 Connect to the CommandCentral Storage management server through the

Web console. In a browser window, type the following URL to launch the Web

login screen:

https://cressida.universe.com:8443/cc

Enter the user name, password, and authentication domain to log on.

5 Add a new user (not admin) that can access the storage Web console:

See “Add and modify access by user accounts” on page 285.

281CommandCentral Storage/Service common proceduresVerifying the CommandCentral Storage server setup

Verifying the CommandCentral Service server setupTo determine the status of the CommandCentral Service server, use the commands

that apply to your environment.

To verify the CommandCentral Service server setup

1 Determine the status of the CommandCentral Service server, based on your

environment.


# /opt/VRTS/bin/vxccsvc status

***VERITAS Private Branch Exchange running***

***VERITAS Authentication Service running***

***VERITAS Database Management Server running***

***VERITAS Trap Processor running***

***VERITAS Alert Manager running***

***VERITAS CommandCentral Service Active Practices not running***

***VERITAS CommandCentral Service Server not running***

■ On Windows, click Start >Administrative Tools > Services and verify

that the following services are started:

■ Adaptive Server Anywhere (Sybase ASA)

■ Veritas Private Branch Exchange

■ Veritas Authentication Service



■ Veritas CommandCentral Service Automation Server

■ Veritas Web Server

■ Veritas CommandCentral Common Login Service

■ Veritas CommandCentral Storage Web Engine

■ Veritas CommandCentral Service Management Server

■ Veritas CommandCentral Service Agent

■ Veritas CommandCentral Service Metering UI

■ Veritas CommandCentral Metering Collector

CommandCentral Storage/Service common proceduresVerifying the CommandCentral Service server setup

282

■ Veritas CommandCentral Metering Controller

2 Run the following commands to check the status of the CommandCentral

Service Web server:

# /opt/VRTS/bin/vxccsvcweb status

VERITAS CommandCentral Service Server is NOT running.

VERITAS CommandCentral Service Metering UI is NOT running.

# /opt/VRTS/bin/vxccsvcweb start

Starting VERITAS CommandCentral Service Server...

Web Application "ccsvc" started successfully

Starting VERITAS CommandCentral Service Metering UI...

Web Application "ccmm_ui" started successfully

Starting VERITAS CommandCentral Service Meter Controller...

Starting VERITAS CommandCentral Service Meter Collector...


VERITAS CommandCentral Service Server is running.

VERITAS CommandCentral Service Metering UI is running.

3 Verify the authentication setup on the CommandCentral Service management

server. An authentication broker with authentication domains for the

CommandCentral Service server should be present on the system on which

the service management server is configured.







Principal Name: ccsvc_invio

Principal Name: ccsvc_agent

Principal Name: ccsvc_ccmm

Principal Name: ccsvc_server

Principal Name: ccsvc_web



Principal Name: root


Principal Name: invio_user

283CommandCentral Storage/Service common proceduresVerifying the CommandCentral Service server setup

4 Connect to the CommandCentral Service management server through the

Web console. In an IE browser, type the following URL:

https://cressida.universe.com:8443/cc

To launch the Web login screen. Enter the user name, password and

authentication domain to log in.

5 Add a new user (not admin) who can access the service Web console.

See “Add and modify access by user accounts” on page 285.

Verifying the CommandCentral agents setupTo determine the status of the CommandCentral agents setup, use the commands

that apply to your environment.

CommandCentral Storage/Service common proceduresVerifying the CommandCentral agents setup

284

To verify the CommandCentral agents setup

1 For the CommandCentral Storage management agent on UNIX/Linux, type

the following command:


***VERITAS Enterprise Administrator running***

***VERITAS SAN Access Layer running***

***VERITAS CommandCentral Data Module running***

***VERITAS SICL running***

2 For the CommandCentral Service management agent on UNIX/Linux, type

the following command:

# /opt/VRTS/bin/vxccsvcagent status

***VERITAS CCService Agent is running***

3 On Windows, click Start >Administrative Tools > Services. You can then

check the Status field that corresponds to the CommandCentral agent, to see

if it has started.

Add and modify access by user accountsRefer to the CommandCentral Storage Administrator’s Guide for information on

adding, modifying, and removing user access.

Replacing the root broker on the CommandCentralserver

In a data center, the CommandCentral server (typically containing both the storage

and the service) is configured on a system with Symantec Product Authentication

that has both root and authentication brokers. The CommandCentral management

server needs an authentication broker. You consolidate the security hierarchy by

replacing the root broker that is located on the system where the CommandCentral

server is configured, with a root broker that is configured on a remote system.

You must first stop the CommandCentral servers before the migration procedures.

The example to replace a root broker assumes the following existing

CommandCentral configuration:

■ The host cressida.universe.com (with Solaris) has CommandCentral server,

Symantec Product Authentication Service root, and authentication brokers

configured. The procedures described here are tested on Solaris and Windows

285CommandCentral Storage/Service common proceduresAdd and modify access by user accounts

platforms. You can use the same procedures, by using the equivalent Windows

commands for CommandCentral server on Windows.

■ Replace the root broker on cressida.universe.com with the root broker that

is configured on mercury.universe.com.

■ The CommandCentral server has clients on both UNIX/Linux and Windows

platforms.

To move the root broker on cressida.universe.com to a root broker on remote

system mercury.universe.com, proceed as follows:

To move a root broker

1 On mercury.universe.com, create a principal of type service for the

authentication broker on cressida.universe.com. Type the following

command:

# /opt/VRTSat/bin/vssat addprpl --pdrtype root \


--prplname cressida.universe.com \

--password cressida \

--prpltype service

2 On cressida.universe.com, shut down the CommandCentral Storage and

Service management servers, based on the platform you use.

■ Stop the CommandCentral Storage management server on UNIX/Linux

by typing the following command:

# /opt/VRTS/bin/vxccstorweb stop

# /opt/VRTS/bin/vxccstor stop

■ Stop the CommandCentral Service management server on UNIX/Linux

by typing the following commands:

# /opt/VRTS/bin/vxccsvcweb stop

# /opt/VRTS/bin/vxccsvc stop

■ Stop CommandCentral Storage and Service management servers on

Windows. Perform the following steps:

■ Log on to the storage server host as an administrator, or as a user in

the Administrative group.

■ Click Start >Programs>AdministrativeTools > Services to open the

Windows Service Control Manager (SCM).

CommandCentral Storage/Service common proceduresReplacing the root broker on the CommandCentral server

286

■ Stop the CommandCentral Storage services in the following order. You

can stop each service by right-clicking the service name, and then click

Stop.



■ Veritas CommandCentral DM Explorers







■ Stop the CommandCentral Service services in the following order. You

can stop each service by right-clicking the service name and then click

Stop.












■ Veritas CommandCentral Service Metering UI



287CommandCentral Storage/Service common proceduresReplacing 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 the logical

ports and other resources that the CommandCentral Storage server may

require when it restarts.

3 On cressida.universe.com, shut down the authentication service, and then

remove all the root PDR entities: principals and credentials. Refer to the

following section for information on shutting down the authentication process

on UNIX/Linux and Windows.


4 Delete each principal in the root private domain by first listing all the

principals in the root private domain, and then deleting them one at a time,

as follows:


--pdrtype root --domain [email protected]

# /opt/VRTSat/bin/vssat deleteprpl --pdrtype root \


--prplname <prpl name> --silent

# /opt/VRTSat/bin/vssat showcred \




--prplname <prpl name> \

--broker cressida.universe.com:2821

5 On mercury.universe.com, perform a remote copy for the root_hash file to

a directory on cressida.universe.com. Perform the following depending on

your platform:



cressida.universe.com:/tmp/root_hash

■ On Windows, use FTP or another remote copy program to copy the

root_hash to cressida.universe.com.

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

authentication broker mode by using the principal, cressida.universe.com,

that was created on mercury.universe.com. Perform the following depending

on your platform:


288

■ On UNIX/Linux, type the following commands:

# /opt/VRTSat/bin/vxatd -a -n <broker> -p <password> \

-x <domain type> -y <domain name> \

-q <root broker name> -z <root broker port 2821> \

-h <has file full path>

# /opt/VRTSat/bin/vxatd -a -n cressida.universe.com \

-p cressida -x vx -y [email protected] \

-q mercury.universe.com -z 2821 -h /tmp/root_hash

■ On Windows, the vxatd.exe command is in the following folder. The same

options that are used on UNIX/Linux can be used on Windows.


7 After the authentication process starts on Windows, the authentication service

needs to be restarted. To restart the authentication service, open the Windows

Service Control Manager (SCM), and then click Start > Programs >


■ For the CommandCentral Storage server, highlight and right-click the

following service, and then click Start:

■ Symantec Product Authentication Service

■ For the CommandCentral Service server, highlight and right-click the

service, and then click Start, in the order that is listed:

■ Private Branch Exchange


8 On cressida.universe.com, verify that the vxatd daemon is running and

the broker mode is 1. At this point, the authentication broker on

cressida.universe.com should be authenticating against the root broker

on mercury.universe.com.

9 Remove the obsolete CommandCentral entities and credentials as follows:


# /opt/VRTSccshd/bin/ccvssatsetup -delete

■ On Windows, type the following command:


ccvssatsetup.exe -delete


10 On cressida.universe.com, set up the new credentials for the

CommandCentral server, as follows:


# /opt/VRTSccshd/bin/ccvssatsetup



ccvssatsetup.exe

11 On cressida.universe.com, restart the CommandCentral processes, as

follows:

■ Start the CommandCentral Storage on UNIX/Linux, type the following

commands:

# /opt/VRTS/bin/vxccstor start

# /opt/VRTS/bin/vxccstorweb start

■ Start the CommandCentral Service on UNIX/Linux, type the following

commands:

# /opt/VRTS/bin/vxccsvc start


■ On Windows, click Start > Programs >Administrative Tools > Services

to open the Windows Service Control Manager (SCM) screen, and start

the following services in the order listed. You start each service by

right-clicking the service name, then clicking Start.







■ Veritas CommandCentral DM explorers




290

■ Start the CommandCentral Service services in the following order. You

can start each service by right-clicking the service name then clicking

Start.



■ Veritas CommandCentral Metering UI











On each system that has the CommandCentral agent (either Storage or Service),

reauthenticate the CommandCentral agent to replace the obsolete credential with

the new credential.

To reauthenticate hosts with management agents

1 Shut down the CommandCentral management agents on each configured

host.

■ Stop the CommandCentral Storage agent on UNIX/Linux. Type the

following commands:

# /opt/VRTS/bin/vxccstor stop

# /opt/VRTS/bin/vxccsvcagent stop

■ Stop the CommandCentral management agents on Windows by opening

the Windows Service Control Manager. Click Start > Programs >


2 Highlight and right-click the service, and then clickStop to stop the following

services:

■ Veritas CommandCentral Storage Agent




Stop the CommandCentral Service management agent, highlight the following

service, right-click and click Stop.


Note: Wait at least 30 seconds after stopping the server before starting it

again. This interval gives the operating system time to free up logical

ports and other resources that the CommandCentral Storage server may

require when it restarts.

3 On each system that has the CommandCentral management agent (either

storage or service), delete the obsolete credentials that were acquired through

the previous root broker that was replaced.

■ Delete the CommandCentral Storage credential on UNIX/Linux. Type the

following command:



--prplname ccstr_web \

--broker cressida.universe.com

■ Delete the CommandCentral Service credential on UNIX/Linux. Type the

following command:



--prplname ccsvc_agent \

--broker cressida.universe.com

4 On each system that contains CommandCentral management agents,

reauthenticate each agent running on the agent host.

■ Reauthenticate the CommandCentral Service management agent on

UNIX/Linux. Type the following command:

# /opt/VRTSccsva/bin/ccsvcagentauth \

-server cressida.universe.com

■ Reauthenticate the CommandCentral Service management agent on

Windows, type the following command:


292

C:\Program Files\VERITAS\CommandCentral\Service\Agent\bin> \

ccsvcagentauth -server cressida.universe.com

Troubleshooting tipsUse the following procedures to check the status of the CommandCentral Storage

and CommandCentral Service servers, Web servers, or agents, that are deployed

in your environment.

To get to the storage Web console logon screen

1 Check the status of the CommandCentral Storage management server by

typing the following command:


2 Check the status of a CommandCentral Storage Web server by typing the

following commands:

# /opt/VRTSweb/bin/monitorApp cc

Web Application "cc" is ONLINE


Web Application "spc" is OFFLINE

3 Start the spc Web application by typing the following command:

# /opt/VRTSweb/bin/startApp spc /opt/VRTSweb/VERITAS

Web Application "spc" started successfully


Web Application "spc" is ONLINE

# /opt/VRTSweb/bin/webgui listapps

ROOT

cc

spc

4 Start the OFFLINE cc Web application by typing the following command:

# /opt/VRTSweb/bin/startApp cc /opt/VRTSweb/VERITAS

293CommandCentral Storage/Service common proceduresTroubleshooting tips

To get to the service Web console logon screen

1 Check the status of a CommandCentral Service server by typing the following

command:

# /opt/VRTS/bin/vxccsvc status

2 Check the status of a CommandCentral Service Web server by typing the

following command:


VERITAS CommandCentral Service Server is NOT running.

VERITAS CommandCentral Service Metering UI is NOT running.


Starting VERITAS CommandCentral Service Server...

Web Application "ccsvc" started successfully

Starting VERITAS CommandCentral Service Metering UI...

Web Application "ccmm_ui" started successfully

Starting VERITAS CommandCentral Service Meter Controller...

Starting VERITAS CommandCentral Service Meter Collector...


VERITAS CommandCentral Service Server is running.

VERITAS CommandCentral Service Metering UI is running.

CommandCentral Storage/Service common proceduresTroubleshooting tips

294

Symantec License Inventory

Manager common

procedures


■ Verifying the SLIM server setup

■ Verifying the SLIM agent setup

■ Replacing the root broker on the SLIM server

■ SLIM troubleshooting tips

Verifying the SLIM server setupThe Symantec License Inventory Manager (SLIM) server monitors Symantec

product license information for products such as NetBackup, CommandCentral,

and Storage Foundation. The SLIM server requires SLIM agents to be installed on

client hosts. The SLIM agents detect the Symantec products that are installed on

the client hosts, and report the license information to the SLIM server.

EAppendix

To verify the SLIM server on Solaris and Windows

1 To verify the Symantec License Inventory Manager on Solaris, type the

following command:

# /opt/VRTSweb/bin/monitorApp slim

Web application for SLIM is ONLINE

2 To verify the SLIM server on Windows, click Start > Control Panel >

Administrative Tools > Service then verify that the following services are

running:

■ Symantec Private Branch Exchange Service


■ Symantec Service Management Framework Service

■ Veritas Web Service

■ Symantec License Inventory Manager Service

■ Adaptive Server Anywhere - VERITAS_DBMS3_<MachineName> service

3 Close the Service window after you verify that the processes are running.

4 Verify the status of the SLIM server. Type the following command:

C:\Program Files\VERITAS\VRTSweb\bin> monitorApp slim

Web application for SLIM is ONLINE

Verification procedures for Windows and UNIX

The Symantec License Inventory Manager server creates and configures its own

domain by creating two separate private domain repositories (PDR), which are

located within the authentication broker PDR. The two private domain repositories

are referred to, as follows:

■ Domain Name [email protected] - authenticates Web

services

■ Domain Name [email protected] - authenticates users

You can use the following commands to verify the SLIM server domain by

expanding the content of these two PDRs:

# /opt/VRTSat/bin/vssat listpdprincipals --pdrtype ab --domain

[email protected]

Symantec License Inventory Manager common proceduresVerifying the SLIM server setup

296

# /opt/VRTSat/bin/vssat listpdprincipals --pdrtype ab --domain

[email protected]

To connect to the SLIM Web console

1 Connect to the Symantec License Inventory Manager Web service at the

following URL:

https://belinda.universe.com:8443/slim

2 Use admin/password to log on to the domain,

[email protected].

3 Perform a host discovery from the SLIM Web service. From the Web console,

click HostManagement >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.

Verifying the SLIM agent setupUse the following procedures to configure and verify the Symantec License

Inventory Manager agent setup.

To configure the SLIM agent

◆ During the client installation process, enter the following information:

■ Enter the Access Point/Server hostname: belinda.universe.com

■ Do you want to enable security? [y, n] (n) y

■ Do you want configure security at this time? [y, n] (y)

■ Enter the authentication broker hostname (neptune.universe.com) \

belinda.universe.com

■ Enter the TCP/IP port number for the authentication broker,

belinda.universe.com: ( 2821)

■ Enter the certificate hash code for the authentication broker

belinda.universe.com (9efb1d042f646656602f55be4016a8bf1a1d03b4)

■ Enter the Access Point/Server user name: (slim_agent)

297Symantec License Inventory Manager common proceduresVerifying the SLIM agent setup

■ Enter the Access Point/Server user Domain name:

([email protected])

■ Enter the Access Point/Server user domain type: (vx)

■ Do you want to start the Symantec License Inventory Agent processes

now? [y, n] (y)

There are two verification processes you can use depending on which SLIM agent

package (SYMClma) you have installed, version 4.0 or version 4.1. In the following

procedure, select the step that corresponds to your installed version.

To verify the SLIM agent

1 For 4.0, type the following command:

# /opt/SYMClma/bin/lmautil -S

[Info] V-149-1-24528 Starting to Get Trusted User List. \

Contacting Agent.

[Info] V-149-1-24537 Name: root

[Info] V-149-1-24538 Domain Name: miranda.universe.com

[Info] V-149-1-24539 Domain Type: localhost

[Info] V-149-1-24541

[Info] V-149-1-24537 Name: slim_agent

[Info] V-149-1-24538 Domain Name: \

[email protected]

[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 proceduresVerifying the SLIM agent setup

298

2 For 4.1, type the following command:

# /opt/SYMClma/bin/lmautil -C

[Info] V-149-1-24541

[Info] V-149-1-24549 AZLiteBootStrapComplete: 1

[Info] V-149-1-24549 SecurityEnabled: 1

[Info] V-149-1-24549 SecurityConfigComplete: 1

[Info] V-149-1-24549 SecurityConfigured: 1

[Info] V-149-1-24549 RootBrokerHostname: neptune.universe.com

[Info] V-149-1-24549 RootBrokerHash:

[Info] V-149-1-24549 CollectorNodeUsername: slim_agent

[Info] V-149-1-24549 RootBrokerHostPortNumber: 2821

[Info] V-149-1-24549 CollectorNodeUserDomainType: vx

[Info] V-149-1-24549 CosNsServerName: localhost

[Info] V-149-1-24549 CollectorNodeUserDomain: \

[email protected]

[Info] V-149-1-24541

3 Log on to the SLIM server Web service GUI to verify the SLIM agent for the

agent report on licences installed on the host.

See “To connect to the SLIM Web console” on page 297.

4 The SLIM agent is included with the Storage Foundation 5.0 release, so the

package is installed on the client host, but not configured. To ensure that the

SYMClma is installed, type the appropriate operating system command (for

AIX, HP-UX, Linux, Solaris, or Windows, respectively) as follows:

# lslpp -l | grep SYMClma

# swlist -l product SYMClma

# rpm -qa | grep SYMClma

# pkginfo -l | grep SYMClma

Start > Control Panel > Add or remove Programs

299Symantec License Inventory Manager common proceduresVerifying the SLIM agent setup

5 If the SLIM agent is installed but not configured, use the vssat and lmautil

commands to configure the SLIM agent to the SLIM server. These commands

include long strings, as shown below. Type the following command to obtain

the root hash key from the remote root broker host (neptune.universe.com):


9efb1d042f646656602f55be4016a8bf1a1d03b4

6 From the SLIM agent client host (miranda.universe.com), type the following

command:

# /opt/SYMClma/bin/lmautil --Config --SecurityEnabled 1 \

--RootBrokerHostname neptune.universe.com \

--CollectorNodeUsername slim_agent \


--CollectorNodeUserDomainType vx \

--CollectorNodeUserDomain [email protected] \

--RootBrokerhash 9efb1d042f646656602f55be4016a8bf1a1d03b4 \

--RootBrokerHostPortNumber 2821

Replacing the root broker on the SLIM serverWhen installing the Symantec License Inventory Manager, Symantec Product

Authentication is automatically installed by the SLIM installer. The installer also

configures the Symantec Product Authentication with a root and an authentication

brokers. The SLIM management server only needs an authentication broker to

authenticate users who access the SLIM Web console.

You may have to consolidate root brokers. This may occur when you want to

demote a root broker on a SLIM server to an authentication broker. Before

executing the migration procedures, stop the SLIM management server and the

SLIM entities running on systems that have access points.

For this example, assume a host uses a Solaris system (belinda.universe.com)

as the SLIM management server. Also assume that Symantec Product

Authentication is configured in root broker and authentication broker modes.

The following procedures were verified on a Solaris platform. You can use the

same procedures with a SLIM management server on Windows, by using the

equivalent Windows commands.

Symantec License Inventory Manager common proceduresReplacing the root broker on the SLIM server

300

Demoting a root broker

The following procedure shows how to demote the root broker on

belinda.universe.com to become a new authentication broker, while a new root

broker is configured on a Solaris system, neptune.universe.com. The SLIM

management server has clients on UNIX/Linux and Windows platforms.

To demote a root broker

1 Create a (service) principal on neptune.universe.com for the existing

authentication broker on belinda.universe.com. Type the following

command:

# /opt/VRTSat/bin/vssat addprpl --pdrtype root \

--domain root \

--prplname belinda.universe.com \

--password belinda \

--prpltype service

2 On neptune.universe.com, perform a remote copy of the root_hash file to

a directory on belinda.universe.com. Type the following command:


belinda.universe.com:/tmp/root_hash

3 Shut down the processes onbelinda.universe.com for the SLIM management

server and all the auxiliary products. Shut down the UNIX/Linux processes

of the auxiliary products in the following order:

# /etc/rc2.d/S75vxsmfd stop

# /etc/rc2.d/S45vxpbx_exchanged stop


# /etc/rc2.d/S38vxdbms3 stop

4 If the system has Symantec Product Authorization configured, stop the

authorization process. Type the following command:

# /etc/rc2.d/S71vxazd stop

■ On Solaris, these scripts are located in the /etc/rc2.d directory.

■ On HP-UX, these scripts are located in the /sbin/rc2.d directory.

■ On AIX, these scripts are located in the /etc/rc.d/rc2.d directory.

■ On Red Hat, these scripts are located in the etc/rc.d/rc2.d directory.

301Symantec License Inventory Manager common proceduresReplacing the root broker on the SLIM server

5 Shut down Windows processes by clicking either Start >Administrative

Tools > Services, or by using the command c:\> net stop vrtsat.

6 Shut down the SLIM Web server process on belinda.universe.com.


# /opt/VRTSweb/bin/stopApp slim


c:\Program Files\VERITAS\VRTSweb\bin>stopApp slim

7 Remove all the entities from belinda.universe.com related to the root broker.

■ On UNIX/Linux, type the following commands:

# /opt/VRTSat/bin/vssat deletecred --domain \

vx:[email protected] --prplname admin


vx:[email protected] --prplname admin


vx:[email protected] --prplname slim_agent


vx:[email protected] --prplname root


vx:[email protected] --prplname broker

# /opt/VRTSat/bin/vssat removetrust --broker belinda.universe.com

On Windows, change to the directory that contains the vssat.exe file. Type

the five commands that are listed for UNIX/Linux above by using the following

as an example:

■ C:\Program Files\VERITAS\Security\Authentication\bin>vssat.exe \

deletecred --domain vx:[email protected] \

--prplname admin

8 On belinda.universe.com, establish the Symantec Product Authentication

Service in authentication broker mode. The new root broker is on

neptune.universe.com.


302

■ On UNIX/Linux, use the vxatd command to start Symantec Product

Authentication in authentication broker mode. The syntax is as follows:

/opt/VRTSat/bin/vxatd \

-a -n %ABIDENTITY% \

-p %ABPASSWORD% \

-x vx -y %DOMAINNAME% \

-q %ROOTBROKER% \

-z %ATPORT%

-h %ROOTHASH%

Type the command as follows:

# /opt/VRTSat/bin/vxatd \

-a -n belinda.universe.com

-p belinda \


-q neptune.universe.com \

-z 2821 \

-h /tmp/root_hash

Name belinda.universe.com

DomainType vx

DomainName [email protected]

BrokerName neptune.universe.com

BrokerPort 2821

Hash file /tmp/root_hash

■ On Windows, change to the directory containing the vssat.exe file. Type

the commands listed for UNIX/Linux above.

9 On belinda.universe.com, verify that the vxatd authentication process is

running, and that the attributes (broker mode, root broker, and domain name)

are updated.

■ On UNIX/Linux, these affected attributes are in the configuration file

/var/VRTSat/.VRTSat/profile/VRTSatlocal.conf.

# grep Mode /var/VRTSat/.VRTSat/profile/VRTSatlocal.conf

"Mode"=dword:00000001

# grep BrokerName /var/VRTSat/.VRTSat/profile/VRTSatlocal.conf

"BrokerName"="neptune.universe.com"

# grep DomainName /var/VRTSat/.VRTSat/profile/VRTSatlocal.conf

"DomainName"="[email protected]"


■ On Windows, these attributes are in the VRTSatlocal.conf file located

in the following directory:

C:\Program Files\VERITAS\Security\Authentication\Systemprofile

10 On belinda.universe.com, reconfigure the SLIM server to point to the new

root broker.

■ On UNIX/Linux, run the following SLIM configuration script:

# /bin/sh /opt/SYMClms/bin/configure

If the following message is displayed, you can safely ignore it:

On Windows, invoke the same configuration script as shown for

UNIX/Linux. Type the following command:

C:\Program Files\Symantec\ \

License Inventory Manager\Server\bin>configure.bat

■ CORBA Exception from TAO is detected

11 On belinda.universe.com, verify that all the processes are running.

■ On UNIX/Linux, type the following commands to ensure that the processes

are running on belinda.universe.com:

# ps -ef | grep vxatd

# ps -ef | grep pbx_exchange

# ps -ef | grep vxsmf

# ps -ef | grep vxdbms

# vssat listpd -pdrtype ab


Broker mode is : 1

■ On Windows, click Administrative Tools > Services to verify that these

services are running. You can also type the following at a command prompt

window:

C:\Program Files\VERITAS\Security \

\Authentication\bin>vssat.exe showbrokermode

Broker mode is : 1

Broker mode 1 means that Symantec Product Authentication is configured

in authentication broker mode.


304

12 To log on to the SLIM Web service, type the following URL in a browser:

https://belinda.universe.com:8443/slim

Type the following at the prompts:

User name: admin

Password:

Domain: [email protected] (vx)

The user name admin is the default user name that was created for SLIM.

You can use other names that were created in your enterprise.

13 Perform the authentication procedure again on all the other systems that

have either a SLIM Access Point or Agent installed. This procedure allows

these SLIM entities to communicate with the SLIM Server that now belongs

to a new authentication hierarchy.

On the remote root broker, neptune.universe.com, type the following

command to obtain the root hash value:


9efb1d042f646656602f55be4016a8bf1a1d03b4

The 4.0 version of SYMClma does not have the option to reconfigure the agent

back to the SLIM server for reauthentication by using the SLIM utility.

There are two verification processes you can use depending on which SLIM

agent package (SYMClma) you have installed, version 4.0 or version 4.1.In

the following procedure, select the step that corresponds to your installed

version.

14 Select one of the following items:

■ For SYMClma 4.0, on the system miranda.universe.com, which has the

SLIM agent installed, invoke the SLIM utility to communicate with the

SLIM server that has the new authentication hierarchy. On UNIX/Linux,

type the following command:

# /opt/SYMClma/bin/lmautil \

--trust --brokerhost belinda.universe.com \

--brokerport 2821 --hash \

9efb1d042f646656602f55be4016a8bf1a1d03b4

[Info] V-149-1-24506 Setting Trust - security level HIGH.

[Info] V-149-1-24509 Trust setup with broker successful.

■ For SYMClma 4.1, on the system miranda.universe.com, which has the

SLIM agent installed, invoke the lmautil SLIM utility to communicate


with the SLIM server that has the new authentication hierarchy. On

UNIX/Linux, type the following command:

# /opt/SYMClma/bin/lmautil --Config \

--SecurityEnabled 1 \

--RootBrokerHostname neptune.universe.com \


--CollectorNodeUserDomainType vx \

--CollectorNodeUserDomain [email protected] \

--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 HostManagement >Discovery > Force Pull. For

example, choose miranda.universe.com, which contains the SLIM agent,

and perform a Force Pull.

SLIM troubleshooting tipsThe information on troubleshooting is organized by specific conditions. Review

the following list of common troubleshooting issues before proceeding to more

specific tips:

■ Verify that the server package, SYMClms, is installed.

■ Verify that the Windows silent installation file, Symantec License Inventory

Manager.msi, is installed.

■ Use the VRTSweb Web GUI commands to verify that the SLIM application is

installed, and then verify the process by using the script that is located in

/etc/init.d, or by using the service control manager.

■ Use the VRTSdbms tools to ping the database (for example, dbping).

■ Examine the log files.

Log files

The Veritas Web log directory location is %VRTSweb_Home%\log. This directory

contains the following major logs:

Symantec License Inventory Manager common proceduresSLIM troubleshooting tips

306

■ slim0.0.log - for general debugging information

■ _err0.0.log - for stack traces and major errors

The other log files in this directory are used for debugging the Java virtual

machine or the Web server. Either of these log files becomes a new file when

it reaches capacity. The naming convention for these files are as follows:

■ slim0.n.log - for general debugging information

■ _err0.n.log - for stack traces and major errors

The default log level is INFO. This logs high-level functions and any errors and

warnings.

Product directory structure

There are few directories within the actual SLIM server. The important files are

located in the /VRTSweb and /VRTSdbms directories. Database and log files are

located in the following Solaris and Windows directories.

Solaris

■ /opt/SYMClms/bin/redist for data (database, transaction log file)

■ /var/VRTSweb/log for Web server log files

Windows

■ c:\program files\Symantec\License Inventory Manager\Server\bin for

data files (such as database or transaction log files)

■ c:\Program Files\VERITAS\VRTSweb\log for Web server log files

Java runtime environment debugging

The Java runtime environment, VRTSjre, is located in the following Solaris and

Windows directories:

■ /opt/VRTSjre on Solaris

■ c:\program files\Common Files\VERITAS Shared\VRTSjre on Windows

Run the command java -version from within that directory to show the current

Sun Java Virtual Machine version.

Troubleshooting steps for Sybase ASA

Table E-1 lists Sybase ASA binaries for UNIX/Linux.

307Symantec License Inventory Manager common proceduresSLIM troubleshooting tips

Table E-1 Sybase ASA binaries for UNIX/Linux

Binaries locationsBinaries

binaries are located in /opt/VRTSdbms3; database is located in

/opt/SYMClms/bin/redist/vxvlim.db.

Default locations

located in syslog and in $INSTALLDIR/log/*.logLog files

location in:

/etc/vxdbms/VERITAS_DBMS3_HOSTNAME/conf /server.conf

Do not edit without engineering; use -x to set the database port and

use -s none to prevent syslog activity.

Configuration

Use$INSTALLDIR/bin/dbping from source$INSTALLDIR/*env*first. Use dblocate to identify the servers running on the local

network.

Utilities

Table E-2 lists Sybase ASA binaries for Windows.

Table E-2 Sybase ASA binaries for Windows

Binaries locationsBinaries

binaries are located in c:\Program Files\VERITAS\DBMS3;

database is located in c:\Program Files\Symantec\LicenseInventory Manager\Server\bin

Default locations

c:\Program Files\VERITAS\DBMS3\conf\server.conf and

c:\Program Files\VERITAS\DBMS3\conf\databases.confConfiguration

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

c:\Program Files\VERITAS\DBMS3\win32\dblocate.exeUtilities

Troubleshooting steps for Tomcat (VRTSweb)

This application uses a servlet container (Tomcat).

The default Tomcat server locations are as follows:

■ On Solaris: /opt/VRTSweb.

■ Default location on Windows: c:\program files\VERITAS\VRTSweb

■ Log files on Solaris: /var/VRTSweb/log(various files)_err, slim, and

_vrtsweb.

■ Log files on Windows: c:\program files\VERITAS\VRTSweb\log(VRTSweb

logs and our logs).


308

■ Configuration: $INSTALLDIR/conf/vrtsweb.xml and

$INSTALLDIR/tomcat/conf/web.xml (do not modify).

■ Utilities: webgui debug [on|off] – You must restart the Web server. It sends

its output to $INSTALLDIR/tomcat/_profile.log, webgui listports, webgui

listapps, webgui smtp getserver (lists all configured SMTP servers), webgui

stop force (stops the server), and webgui restart (this should restart all of

the Web applications that were running prior to the webgui stop command).

Set the debugging level of the Tomcat server

Set the debugging level of the Tomcat server, configured under Tomcat/VRTSweb,

as follows:

1 Click Settings > SystemSettings >WebConsole Configuration > Configure

Logging.

2 Set the default level to INFO.

3 Type the root or admin password of the user running the SLIM server.

4 Perform a Web restart to erase this setting and to reset the default level to

INFO.

Debug the access point

The agent dynamically loads the following modules:

■ Default location on Solaris: /opt/SYMClmm

■ Default location on Windows: c:\program files\Symantec\License

Inventory Manager\Access Point

■ Log files on Solaris: $AGENTDIR/logs

■ Log files on Windows: +---bin, +---conf, +---lib, and +---logs

■ Configuration file: $AGENTDIR/conf/agent.conf

■ Utilities: Set the logging level to fine, restart, and watch log files. Verify

connectivity to the server over the CORBA port, and the Last Contact time in

the agent configuration screen of the Web user interface.

Debug the push installation

A push installation works with homogeneous push-only; for example, Solaris to

Solaris, or Windows to Windows. The underlying mechanism on UNIX is

rhosts/ssh, and on Windows is VPI (msiexec service). Logs are located in the

following directories:


■ /var/tmp/install-lim1102143201/install-lim.log

■ C:\Documents and Settings\All Users\Application

Data\VERITAS\VPI\log

■ CONFIG/FINE/FINER/FINEST logs many more details and should only be used

when investigating a problem

You can set the log levels for SLIM logs in the following locations:

■ WEB.XML (requires a server restart)

■ VRTSweb configuration in the Web UI

Troubleshooting steps for Service Management Framework

Use the vxlogview utility to view the Service Management Framework (SMF) log

files as follows:

■ Symantec Product Authentication: /var/VRTSat/log/vxatd.log

■ Symantec Management Foundation:

$ vxservice --list -r RootSMF -p ICS vxservice

On Windows use:

c:\Program Files\VERITAS\VxSMF\bin\smfservice.cmd -list \

-r RootSMF -p ICS vxservice

A list of processes similar to the following will be displayed:

Process Name : ICS

Service Name : CosNotfSrvcInit

Service Name : CosNotify_Service

Service Name : Topology_Factory

Service Name : Event_Persistence

Service Name : CosNotfSrvc

Service Name : lma

Note: Service name lma would only appear if the SLIM agent was installed.

■ Private Branch Exchange: /opt/VRTSicsco/bin/vxlogview -a -t 00:10:00

displays log messages for all products generated in the last 10 minutes

■ /opt/VRTSicsco/bin/vxlogview --prodid 50936 --tail 01:10:00displays

log messages for SMF and PBX generated in the last hour and 10 minutes


310

■ On Windows: c:\Program Files\Common

Files\VERITAS\VRTSicsco\vxlogview

Error: Failed to get database connection

The database is down or the Web Server started before the database. Start the

database if it is down, then restart the Web server.

Error: Authentication manager was not initialized

The authentication server is down, or the Web Server started before authorization.

Start authorization server if it is down, then login to the Application.

Error: Agent not running

Notification Service is down. Start SMF. Wait for three minutes for the Server to

reconnect to Cos Notification Service.

Error: Access point fails to start

SMF on AP not running. Start SMF, and then restart AP through the script or

Windows service control manager.

Error: Access point fails connect to server

The access point heartbeat is not updating. Make sure that the Server is up and

running. Confirm that the slim_agent credential on the Access Point machine is

authenticated against the Server Machine by executing vssat showcred to get a

list of credentials, and verifying that the slim_agent credential exists.

If slim_agent credential does not exist on the Access Point host, create it with the

following command:

# /opt/VRTSat/bin/vssat authenticate \

-domain vx:slim_services@SERVER_HOSTNAME \

-prplname slim_agent \

-password slim_agent_password \

-broker SERVER_HOSTNAME:2821

Error: Retries Exceeded. Could not connect to HOST_NAME:RootSMF

Agent-Server Communication is failing. From the server machine, use telnet to

connect the agent on port 1556.


$ telnet AGENT_HOST 1556

If telnet is not successful, there could be a firewall issue.

Error: SLIM Web Console does not display on VRTSweb console

Symantec License Inventory Manager Web App is not running. Restart the SLIM

Web app. On Windows enter the following information:

c:\Program Files\VERITAS\VRTSweb\bin\startApp.exe slim

On Solaris, type the following command:

# /opt/VRTSweb/bin/startApp slim

Embedded access point is down

The Force Poll does not work for any agent. PBX is not running. Start PBX, and

then restart the SLIM Server/AP.

Agent-server communication failure

The force poll status displays the following message:

Retries Exceeded. Could not connect to HOST_NAME:1556:lmaApp_secsvc

To debug the server

1 Type the following command to ensure that the Agent is running: :

# /opt/VRTSsmf/bin/vxservice -L

Make sure that lma is listed as a service.

2 Initiate an inventory through the CLI. Type:

# /opt/SYMClma/bin/lmautil -I

3 If steps 1 and 2 are successful, check the broker hash of the server on the

agent. Type:


4 Compare the hash with the one on the server; run the same command on the

server.


312

Server time-out during a force poll queue

1 Make sure Agent is running. Type:

# /opt/VRTSsmf/bi/vxservice -L

Verify that lma is listed as a service.

2 Initiate an inventory through the CLI. Type the following command:

# /opt/SYMClma/bin/lmautil -I

If the previous commands were successful, increase the timeout settings on

the server.

3 Use the following tasks to increase the timeout settings on the server:

■ Stop the Web application. Type the following command

# /opt/VRTSweb/webgui/stop

■ If slim_conf.properties does not exist under /opt/VRTSweb/conf, copy

/opt/VRTSweb/VERITAS/slim/slim_conf.properties.default to

/opt/VRTSweb/conf/slim_conf.properties.

■ Uncomment the line vxlicagent.connection.timeout and set the value

to a higher number. For example, change the default value of 60 to 600.

■ Restart the Web server. Type the following command:

# /opt/VRTSweb/bin/webgui restart



314

Aaccess control information data repository

definition 39

acronyms

list of 18

application client

definition 32

application server

generic enterprise security deployment

scenario 54

application service

definition 32

approach

multiproduct deployment 51

architecture

Authorization 37

audience 14

authentication

components 44

module functionality 43

overview 22, 43

authentication broker

details 30

authentication client

details 32

authentication hierarchy

definition 28

authentication module

components 33

description 33

Authorization

architecture 37

authorization

module functionality 43

overview 22, 43

steps 42

authorization principal

definition 41

authorization service

definition 39

Bbenefits

of using Symantec Product Authentication and

Authorization 23

broker architecture

in a generic enterprise security deployment

scenario 55

Cchief security officers

what to read 14

CommandCentral

integration 47

plug-ins 48

component details

Symantec Product Authentication and

Authorization 29

components

authentication 44

authorization 38


Authorization 27, 48

Symantec Product Authentication Service 44

Ddefinitions

acronyms used in this book 18

authorization principal 41

terms used in this book 22

detail

authentication broker 30

authentication client 32

Eexpiry periods 36

Ffunctionality

authentication module 43

authorization module 43

Index

Iintegration

CommandCentral with common service

framework products 47

NetBackup Operations Manager with common

service framework products 46

NetBackup with common core services

products 46

Symantec License Inventory Manager with

common core services products 48

Veritas Storage Foundation with common core

services products 47

Llocal authorization service

definition 40

Mmanagement agent and client


scenario 55

management server


scenario 54

master authorization service

definition 40

modules


Authorization 43

multiproduct deployment

approach 51

NNetBackup

integration 46

supported plug-ins 46

NetBackup Operations Manager

integration 46

supported plug-ins 47

Pplug-ins

supported by CommandCentral 48

supported by NetBackup 46

supported by NetBackup Operations Manager 47

supported by Symantec License Inventory

Manager 48

plug-ins (continued)

supported by Veritas Storage Foundation 47

product integration

enterprise 46

product scope 15

Rresource management application

definition 40

root broker

definition 29

Sscope

current edition 16

future editions 17

scope of product 15

security administrators

what to read 14

Symantec License Inventory Manager

integration 48

plug-in support 48

Symantec Product Authentication and Authorization

architecture 27

component details 29

components 27

Symantec Product Authorization Service

about 48

Symantec products

current edition 17

future editions 17

systems programmers

what to read 14

Tterms and definitions 22

topics

overview of 13

Uuser benefits

from book 14

Vvalidity period

certificate 36

Index316

Veritas Storage Foundation

integration 47

plug-ins

UNIX/Linux 47

Windows 47

317Index