d n
2n itio
Ed
Symantec Product
Authentication and
Authorization
Volume I
Securely deploy Symantec products using the
appropriate deployment configuration for your
enterprise environment
Provides an overview of the Symantec Product
Authentication and Authorization Service
Describes the role of Symantec Product
Authentication and Authorization Service in
your enterprise
Includes guidelines and best practices for
deploying Symantec products with Symantec
Authentication and Authorization Service
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 2.0
Legal Notice
Copyright © 2008 Symantec Corporation. All rights reserved.
Symantec and the Symantec Logo 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.
This Symantec product may contain third party software for which Symantec is required
to provide attribution to the third party (“Third Party Programs”). Some of the Third Party
Programs are available under open source or free software licenses. The License Agreement
accompanying the Software does not alter any rights or obligations you may have under
those open source or free software licenses. Please see the Third Party Legal Notice Appendix
to this Documentation or TPIP ReadMe File accompanying this Symantec product for more
information on the Third Party Programs.
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
Printed in the United States of America.
10 9 8 7 6 5 4 3 2 1
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:
Trung Nguyen
Kathryn Cheng
David Hartman
Mette Wadleigh
Dhiren Chandvania
Virginie Carle
John Belz
Frances Heddings
Don Brinkley
Vuthipong "Don" Angspatt
Bruce Naegel
Kyle Gleed
Chris Leffel
Thomas Stephens
Gaurav Khanna
Contents
Chapter 1
About the Symantec Product Authentication and
Authorization Yellow Book ............................................ 9
About the volumes in the Symantec Product Authentication and
Authorization Yellow Book ........................................................ 9
Who should use this Yellow Book .................................................... 10
Chapter 2
Symantec authentication and authorization
services ............................................................................ 13
About this document ....................................................................
Difference between this document and product guides .................
This document's scope ............................................................
Acronyms and definitions ..............................................................
About authentication and authorization ...........................................
Benefits of using authentication and authorization ............................
Chapter 3
13
14
14
16
22
23
Overview of the Symantec Product Authentication
Service ............................................................................. 27
Authentication service overview .....................................................
Authentication hierarchy ..............................................................
Authentication principal .........................................................
Authentication components ..........................................................
Root broker ...........................................................................
Authentication broker .............................................................
Authentication plug-ins and mechanisms ...................................
Authentication entities ...........................................................
Authentication user interface ...................................................
Authentication broker communication port ................................
How the authentication process works .............................................
About acquiring a product credential ........................................
Authentication brokers in a high availability environment ..................
Root plus authentication broker in a high availability
environment ...................................................................
Authentication broker in a high availability environment ..............
Authentication expiry ...................................................................
27
28
29
29
29
30
30
32
32
32
33
34
36
36
36
36
6
Contents
Chapter 4
Overview of the Symantec Product Authorization
Service ............................................................................. 39
Authorization service overview ......................................................
Authorization components ............................................................
Authorization service .............................................................
Authorization client ...............................................................
Access control information data repository .................................
Master authorization service ....................................................
Local authorization service ......................................................
Resource management application ............................................
Authorization group or namespace ............................................
Authorization user interface ....................................................
Authorization service communication port .................................
Access control policy ....................................................................
Access control lists .......................................................................
Authorization service in a high availability environment .....................
How the authorization process works ..............................................
Chapter 5
How Symantec Product Authentication and
Authorization are used across Symantec
products ......................................................................... 47
About deploying an authentication hierarchy ....................................
About the need to create one authentication hierarchy for your
enterprise .......................................................................
How AT provides secure communication ...................................
About assimilating AT into your enterprise .................................
About upgrading AT ...............................................................
About deploying an authorization service .........................................
How AZ provides access control ................................................
About assimilating AZ into your enterprise .................................
About upgrading AZ ...............................................................
Chapter 6
39
40
41
41
41
42
42
42
43
43
43
43
44
44
45
47
48
49
49
55
56
56
57
57
Deployment guidelines and best practices .................... 59
Multiple product deployment approach ............................................
About application servers ........................................................
About management servers ......................................................
About management agents and clients .......................................
How to determine the broker architecture ........................................
Root and authentication brokers placement ................................
About an isolated root broker ...................................................
About multiple root brokers .....................................................
59
62
63
63
64
67
69
70
Contents
Root brokers consolidation ......................................................
About the availability of brokers ...............................................
About brokers in different time zones ........................................
About implementing AT and AZ services in your enterprise .................
AT and AZ administration tasks ......................................................
AT administrator responsibilities ..............................................
AZ administrator responsibilities ..............................................
Platform-specific considerations ...............................................
AT and AZ installation considerations .......................................
About the AT and the AZ upgrades ............................................
AT and AZ backup and recovery strategy ..........................................
Backup and recovery of AT data ................................................
Backup and recovery of AZ data ................................................
Empirical use cases ......................................................................
UNIX/Linux use cases .............................................................
Windows use cases .................................................................
Recommended approach to the use cases ....................................
Use cases verification steps and troubleshooting tips ..........................
Index
72
75
76
76
79
79
81
81
83
88
90
91
92
92
93
93
93
94
.................................................................................................................... 95
7
8
Contents
Chapter
1
About the Symantec
Product Authentication and
Authorization Yellow Book
This chapter includes the following topics:
■
About the volumes in the Symantec Product Authentication and Authorization
Yellow Book
■
Who should use this Yellow Book
About the volumes in the Symantec Product
Authentication and Authorization Yellow Book
In the second edition of the Symantec Product Authentication and Authorization
Yellow Book, the document contains three volumes (I, II, and III). Each volume is
a book.
Table 1-1 lists the title of each volume and its content.
10
About the Symantec Product Authentication and Authorization Yellow Book
Who should use this Yellow Book
Table 1-1
The document set for the Symantec Product Authentication and
Authorization Yellow Book
Volume Title
Content description
Symantec Product Authentication and
Authorization Volume I
Contains the following information:
■
■
■
■
■
Describes the value that authentication
and authorization adds to the security
infrastructure in your organization.
Provides an overview of Symantec
Product Authentication Service (AT).
Provides an overview of Symantec
Product Authorization Service (AZ).
Discusses the integration approach the
Symantec products use to integrate with
the authentication and the authorization
services.
Defines the deployment guidelines and
best practices that are suggested by the
Symantec Corporation. You can use the
deployment guidelines and best practices
to deploy multiple products in your
enterprise with AT and AZ enabled.
For more information, see the Symantec
Product Authentication and Authorization
Volume I.
Symantec Product Authentication and
Authorization Volume II
Describes the use cases that are deployed on
the UNIX/Linux and the Windows platforms.
For more information, see the Symantec
Product Authentication and Authorization
Volume II.
Symantec Product Authentication and
Authorization Volume III
Contains the procedures that are commonly
used in the UNIX/Linux and the Windows
use cases.
For more information, see the Symantec
Product Authentication and Authorization
Volume III.
Who should use this Yellow Book
There are three primary groups who can benefit by reading this Yellow Book.
At an enterprise level, the following groups benefit:
About the Symantec Product Authentication and Authorization Yellow Book
Who should use this Yellow Book
■
Chief information officers (CIOs), chief security officers, and security architects.
These individuals are responsible for the security infrastructure within an
enterprise and the deployment of Symantec Product Authentication and
Authorization Services.
■
Security administrators and application administrators who are typically
responsible for the deployment of Symantec products in their enterprise.
■
System programmers who are responsible for process automation.
Table 1-2 lists the chapters that pertain to these job roles.
Table 1-2
Applicable sections to read
Role
What to read
Chief Information
Officers
Refer to Symantec Product Authentication and Authorization
Volume I, which provides an overview to the Symantec Product
Authentication and Authorization Services. It also describes the
deployment guidelines and the best practices for the Symantec
products to be deployed with the AT and the AZ services.
Security Officers
Security Architects
For more information, see the Symantec Product Authentication
and Authorization Volume I.
See “About the volumes in the Symantec Product Authentication
and Authorization Yellow Book” on page 9.
Security
administrators
Application
administrators
Refer to Symantec Product Authentication and Authorization
Volume I for information about the integration of AT and AZ across
Symantec products. The deployment guidelines and best practices
describe the approaches that give security and application
administrators an understanding of how to plan and deploy
Symantec products in their enterprise environments.
Refer to Symantec Product Authentication and Authorization
Volume II for information about the use cases that are provided
for the UNIX/Linux platform and the Windows platform.
Refer to Symantec Product Authentication and Authorization
Volume III for information on the common verification procedures
that can help you verify the setup in your environment.
For more information, see the Symantec Product Authentication
and Authorization Volumes I, II, and III.
See “About the volumes in the Symantec Product Authentication
and Authorization Yellow Book” on page 9.
11
12
About the Symantec Product Authentication and Authorization Yellow Book
Who should use this Yellow Book
Table 1-2
Applicable sections to read (continued)
Role
What to read
System programmers
Refer to the appropriate use cases in Symantec Product
Authentication and Authorization Volume II for specific
implementation information. The use cases show you how to
implement AT and AZ for the Symantec products that are deployed
in your environments.
Refer to the appropriate appendixes in Symantec Product
Authentication and Authorization Volume III for specific
verification information. The appendixes show you how to verify
the Symantec products that are enabled with the AT and the AZ
services. You can use the troubleshooting tips for repairing the
particular Symantec products. The appendixes also show you how
to perform the tasks that are common to the UNIX/Linux platform
and the Windows platform.
For more information, see the Symantec Product Authentication
and Authorization Volumes II and III.
See “About the volumes in the Symantec Product Authentication
and Authorization Yellow Book” on page 9.
Chapter
2
Symantec authentication
and authorization services
This chapter includes the following topics:
■
About this document
■
Acronyms and definitions
■
About authentication and authorization
■
Benefits of using authentication and authorization
About this document
The Symantec Product Authentication Service (AT) and the Symantec Product
Authorization Service (AZ) allow you to integrate these services with multiple
Symantec software products. General security concepts, public key infrastructure
(PKI) security concepts, the Symantec approach to set up AT and AZ, and how to
implement these solutions in your environment are also included.
You can refer to deployment guidelines, best practices, and use cases to help you
plan and implement AT and AZ across Symantec products. You can choose a
deployment configuration suitable for your enterprise.
See “Multiple product deployment approach” on page 59.
You can begin by establishing the infrastructure for your environment, then
deploying a single Symantec product with AT and AZ (if used by the product). You
can integrate additional Symantec products with AT and AZ by following the
UNIX, Linux, and Windows use cases.
14
Symantec authentication and authorization services
About this document
For more information on deploying Symantec products with the security feature
on UNIX/Linux and Windows, see the following sections in Symantec Product
Authentication and Authorization Volume II:
■
Deployment of Symantec products with security on UNIX/Linux
■
Deployment of Symantec products with security on Windows
Difference between this document and product guides
Every Symantec product includes user guides that describe the procedures that
install the product with Symantec Product Authentication Service (AT) and
Symantec Product Authorization Service (AZ). The user guides, however, do not
contain information on how those products behave when they are deployed with
other Symantec products.
In a multiple product environment, AT and AZ are shared among many Symantec
products. Each product may have a different requirement for use with
authentication and authorization. Tested and certified use cases, and approaches
for deploying multiple Symantec products along with authentication and
authorization 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.
This document's scope
The deployment complexity and architectural demands on Symantec Product
Authentication and Authorization Services can best be demonstrated by the
guidelines and practices in an enterprise environment that are proven and certified
in the Symantec product testing lab. This document disseminates deployment
information to Symantec customers for best use in their own enterprises. In this
way, customers can use Symantec's best deployment scenarios in their own
enterprises.
Figure 2-1 lists the Symantec products that integrate with authentication and
authorization.
Symantec authentication and authorization services
About this document
Figure 2-1
Products that use one or more Common Core Services
The edition of a Yellow Book applies to the Symantec products that are certified
to successfully integrate with Symantec Product Authentication and Authorization
Services.
Table 2-1 lists the products documented in this edition.
See “Acronyms and definitions” on page 16.
Future editions will contain information on additional Symantec products when
they complete their integration with Symantec Product Authentication (AT) and
Symantec Product Authorization Service (AZ).
15
16
Symantec authentication and authorization services
Acronyms and definitions
Table 2-1
Symantec products addressed in this edition
Common core
services
Management
server
Application server Management
agent/client
AT
NetBackup
SFCFS
NetBackup
CC Storage & CC
Service
SF Oracle RAC
CC Storage & CC
Service
SLIM
NOM
SFEHA
SFWHA
VCS
SLIM
SFM (SFMS)
SFM (SFMS)
VCS MC (CMC)
VCS MC (CMC)
VBR
VBR
AZ
NetBackup
AT HA
NetBackup
SFCFS
SF Oracle RAC
SFEHA
SFWHA
VCS
AZ HA
NetBackup
Acronyms and definitions
Table 2-2 is a list of acronyms and their definitions.
Table 2-2
Acronym list
Acronym
Definition
AT
Symantec Product Authentication Service
AZ
Symantec Product Authorization Service
AT HA
Symantec Product Authentication Service for high availability.
Configuring AT with VCS improves the availability of this service by
failing or switching it over in a group of systems with a predefined
order to eliminate a single point of failure.
Symantec authentication and authorization services
Acronyms and definitions
Table 2-2
Acronym list (continued)
Acronym
Definition
AZ HA
Symantec Product Authorization Service for high availability.
Configuring AZ with VCS improves the availability of this service by
failing or switching it over in a group of systems with a predefined
order to eliminate a single point of failure.
CCS
Common Core Services—typically refer to the Symantec Product
Authentication Service and Symantec Product Authorization Service
CMC
See VCS MC
CSF
Common Service Framework (the distribution name for these products
is Infrastructure Core Services—ICS)
DSU
Disk Storage Unit
FQHN
Fully Qualified Host Name (synonymous with FQDN—Fully Qualified
Domain Name); for example, jupiter.universe.com
GSSAPI
Generic Security Service Application Programming Interface
HA
High Availability (ensures that a service is accessible without
disruption)
ICS
Infrastructure Core Services (distribution name for AT, AZ, PBX, and
SMF)
LDAP
Lightweight Directory Access Protocol
MP
Maintenance Pack (a Symantec/Veritas product patch release)
NBAC
NetBackup Access Control (AT/AZ integration with NBU)
NBU
NetBackup
NOM
NetBackup Operations Manager
PAM
Pluggable Authentication Modules
PBX
Veritas Private Branch Exchange version 1.2
Symantec Private Branch Exchange version 1.3
PDR
The root private domain repository stores information about all
registered authentication brokers (used only by the root broker).
Another PDR is the authentication.
PKI
Public Key Infrastructure
17
18
Symantec authentication and authorization services
Acronyms and definitions
Table 2-2
Acronym list (continued)
Acronym
Definition
RDBMS
Relational Database Management System, such as Oracle or DB2
SAN
Storage Area Network
SF
UNIX/Linux Veritas Storage Foundation products, including VxVM,
VxFS, and VVR
SFCFS
Veritas Storage Foundation Cluster File System
SFDB2
Veritas Storage Foundation for DB2
SFEHA
Veritas Storage Foundation Enterprise High Availability
SFM
Veritas Storage Foundation Manager. Formerly Storage Foundation
Management Server (SFMS).
SFMS
Veritas Storage Foundation Management Server. See SFM.
SF Oracle
Veritas Storage Foundation for Oracle
SF Oracle RAC
Veritas Storage Foundation for Oracle RAC (Real Application Cluster)
SFW
Windows Storage Foundation products, including VxVM and VVR
SFWHA
Veritas Storage Foundation High Availability on Windows
SLIM
Symantec License Inventory Manager
SMF
Service Management Framework (SLIM makes use of this functionality)
SSL
Secure Sockets Layer protocol (each encrypted transaction generates
a session key, which is 128 bits)
SSO
Shared Storage Option (in the NetBackup context)
Single Sign-On (in the authentication context)
VAD
Veritas Application Director
VBR
Veritas Backup Reporter
VCS
Veritas Cluster Server
VCS MC
Veritas Cluster Server Management Console (formerly CMC)
VPAS
Veritas Process Automation Server
VVR
Veritas Volume Replicator
Symantec authentication and authorization services
Acronyms and definitions
Table 2-2
Acronym list (continued)
Acronym
Definition
VxFS
Veritas File System
VxSS
Veritas Security Services (superseded by “AT plus AZ”)
VxVM
Veritas Volume Manager
Table 2-3 is an alphabetical list of each special term followed by its definition.
Table 2-3
Terms and definitions
Term
Definition
application client
A client program that accesses a Symantec service or
function that is provided by the service program (called
an application service).
application server
A Symantec application that is deployed on a computer
that serves a specific purpose for an enterprise.
Synonymous with application service.
See “About application servers” on page 62.
application service
A program that is contacted by, and provides services to,
a Symantec application client. Synonymous with
application server.
authentication mechanism
The method by which authentication is conducted for the
principals within a specific namespace that is defined by
a domain type.
See “Authentication plug-ins and mechanisms” on page 30.
authentication plug-in
A component that is used by the authentication broker to
validate the identities within a particular domain.
See “Authentication plug-ins and mechanisms” on page 30.
authentication principal
An authentication principal is an entity that can
authenticate to Symantec Product Authentication Service
with a unique identity.
See “Authentication principal” on page 29.
19
20
Symantec authentication and authorization services
Acronyms and definitions
Table 2-3
Terms and definitions (continued)
Term
Definition
authentication service
Symantec Product Authentication Service is the act of
validating who an entity is. An entity can be a user with
a unique identity that accesses (logs on to) a Symantec
product.
Symantec Product Authentication Service is the act of
validating who an entity is. An entity can be a user with
a unique identity that accesses (logs on to) a Symantec
product.
authorization service
Symantec Product Authorization Service is the act of
checking what an entity can do. An ordinary entity can
be granted the administrative privileges and possess the
administrator responsibilities on a Symantec product.
backup
Refers to the process of copying and saving files,
directories, raw partitions, or file systems to secondary
storage such as tapes or disks.
broker
An agent whose function is to validate identities by using
the appropriate plug-in.
certificate
A type of electronic identification card (such as a passport
or a driver's license) that verifies the identity of its holder,
and binds the principal's name to that principal's public
key.
certificate authority
This authority issues a product credential to the
requesting authentication principal that is based on a
validity check from the registration authority.
cluster
A set of hosts that share a set of disks with software
coordination.
credential
An entitlement that is recognized as an authenticated
principal. A valid credential includes a certificate and the
principal’s private key.
high availability
Eliminates the single points of failure and improves the
availability of an application (such as AT, AZ, or
NetBackup). An application that is configured on a VCS
can fail or switch over the service among a group of
computers with pre-defiend order to make the application
always accessible.
login
Logons performed on UNIX and Linux platforms.
Symantec authentication and authorization services
Acronyms and definitions
Table 2-3
Terms and definitions (continued)
Term
Definition
logon
The procedure that is used to gain access to an operating
system or Web console of an application.
management agent
See management client.
management client
The client binaries of a management server that is
deployed on a client computer to manage that client
computer. Synonymous with management agent.
See “About management agents and clients” on page 63.
management server
An application server that manages distributed
agent/client computers.
See “About management servers” on page 63.
master node
A cluster node that is responsible for certain Cluster
Volume Manager activities. Only one node in a given
cluster can act as the master node.
master server
A NetBackup server that provides administration and
control for backing up and restoring for all clients within
a master and a media server configuration.
media manager
The NetBackup software that manages the storage devices
and removable media.
media server
A NetBackup server that provides storage within a master
server and media server cluster. The master server can
also be a media server. A media server that is not the
master server is called a remote media server.
NetBackup
A distributed backup and restore application.
NetBackup Operations
Manager
A GUI-based administrative tool that can manage all
NetBackup master servers that are deployed throughout
an enterprise.
node
A computer within a cluster.
registration authority
An application that determines whether authentication
principals are valid.
remote media server
A media server that is not the master server.
21
22
Symantec authentication and authorization services
About authentication and authorization
Table 2-3
Terms and definitions (continued)
Term
Definition
resource management
application
A Symantec product whose resources are protected by
Symantec Product Authentication and Authorization
Services. An example of a Symantec product would be
NetBackup.
restore
The process of retrieving saved files, directories, raw
partitions, or file systems to a system for online access.
self-signed certificate
A digital identity (certificate) that is signed by its creator.
See certificate.
storage area network
A fibre channel-based network that connects the servers
and the storage devices. The storage devices are attached
to the network, and they are visible to all of the servers
on the network.
Storage Foundation Manager
A management tool that can centrally monitor, visualize,
and administer hosts on which Storage Foundation
products are installed. Formerly Storage Foundation
Management Server (SFMS).
About authentication and authorization
Authentication is the act of proving whether an entity is who or what it declares
itself to be. An entity can be a user, an application process that runs on a computer,
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 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 Bob’s identity works, as follows:
Authentication: Who are you?
Bob: I am Bob.
Authentication: Prove yourself.
Bob: OK. Here are materials to prove that I am Bob.
Symantec authentication and authorization services
Benefits of using authentication and authorization
23
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 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 (AT). Users are authenticated by using the authentication
mechanisms that are already established within an enterprise. Successfully
authenticated users communicate through the secure channel, and are coupled
with the public-key infrastructure (PKI) technology.
PKI technology uses both public and private key pairs for 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.
In the Symantec PKI implementation, authorization (provided by the Symantec
Product Authorization Service—AZ), is always preceded by authentication (provided
by AT). Authorization is the act of checking what an entity is allowed to do with
critical resources based on predefined rules, then granting permissions to the
entity to manipulate these resources.
Assuming a valid user named Bob wants to manipulate NetBackup policy, granting
access control works, 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.... Okay. Access Control on policy management is
now granted to you.
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 is not allowed to manage other NetBackup tasks such as device
discovery, new volume pool creation, or other administrative tasks.
Benefits of using authentication and authorization
Symantec products typically require users to have either administrator (Windows)
or root (UNIX/Linux) access privileges to perform installation, configuration, and
24
Symantec authentication and authorization services
Benefits of using authentication and authorization
upgrade operations. Administrator and root are considered superusers of their
respective operating systems, and these superusers have the ability to change or
modify a system’s configuration. Users who are responsible for managing
Symantec products are also required to log on as a superusers.
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 may be involved in
managing the deployed Symantec products. For example, NetBackup product
management responsibilities can be divided among administrators, security
administrators, users, and operators.
Enterprises typically assign a specific individual or group to be responsible for a
Symantec product. It is possible that the NetBackup, CommandCentral, and Cluster
Manager application administrators can be three different individuals. Giving
superuser privileges to all of the people who manage Symantec products can
increase the chance of exposing the password of the superuser, thus making the
systems more vulnerable to malicious attacks.
To reduce the risk of unauthorized access or change to systems, an enterprise
should implement a security policy to limit the number of people with superuser
privilege. By using AT and AZ, a user without superuser privileges can manage a
Symantec product that typically requires a superuser to manage.
Symantec products integration with AT and AZ, best practices, deployment
guidelines, and actual use cases illustrate 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 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 require superuser access.
■
Assign a user to be an administrator for each Symantec product. In an
enterprise where separation of responsibilities is required, users Bob, Mary,
and Lee could be assigned to exclusively manage NetBackup, Cluster Manager,
and CommandCentral Storage, respectively. At the operating system level,
these three people are non-privileged users.
■
Selectively grant application roles (administrators, operators) to users. To
restrict the privilege of a night shift NetBackup operator to only launch backup
jobs, the NetBackup administrator can assign the appropriate role to that
operator’s login.
Symantec authentication and authorization services
Benefits of using authentication and authorization
■
Use existing mechanisms (such as NIS, NISPLUS, UNIXPWD, Windows NT
domain, or LDAP) to authenticate users. In the logon session, the non-privileged
user only needs to pick the appropriate authentication mechanism and the
associated authentication domain. NIS, NISPLUS, and UNIXPWD are applicable
to UNIX/Linux platforms. The Windows NT mechanism is specific to the
Windows platform. LDAP, when configured correctly, can 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.
AT is implemented by PKI technology that uses public and private key pairs to
produce valid user 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 requestor. The requestor’s private key
is not transmitted over the network. For the requestor to read the encrypted
message, the encrypted message is first decrypted by using the SSL session key,
and then 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 make use of AT:
■
Casual network snooping (including secretly capturing passwords or other
confidential information, for example)
■
Communication replay attacks on your intranet
■
Session hijacking
Most management client and agents of Symantec products have a command-line
or Web-based interface that can access their management and application servers
by using this secure protocol.
AT offers single sign-on functionality for the Symantec products that implement
this service. Symantec products are all installed with AT enabled, except for earlier
versions of NetBackup (requires additional configuration steps to be enabled).
25
26
Symantec authentication and authorization services
Benefits of using authentication and authorization
Chapter
3
Overview of the Symantec
Product Authentication
Service
This chapter includes the following topics:
■
Authentication service overview
■
Authentication hierarchy
■
Authentication components
■
How the authentication process works
■
Authentication brokers in a high availability environment
■
Authentication expiry
Authentication service overview
The Symantec Product Authentication Service (AT) 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 that is associated with a registration
authority. The registration authority is the entity that sends requests to the root
broker to determine whether the authentication brokers are valid. The
trustworthiness of authentication brokers is vouched with the valid authentication
entities (principals).
Authentication brokers implement the certificate authority functionality, which
follows a security model similar to the public key infrastructure (PKI). The
28
Overview of the Symantec Product Authentication Service
Authentication hierarchy
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
the requesting authentication entities (principals) based on the registration
authority's validity check.
All communications between brokers and entities use the secure socket layer (SSL)
protocol.
Authentication hierarchy
The authentication hierarchy is the physical arrangement, or structure, of the
Symantec Product Authentication Service components in your environment. This
includes 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.
For more information on setting up an authentication hierarchy with stand-alone
brokers, see the Symantec Product Authentication and Authorization Volume III.
Figure 3-1 illustrates a typical authentication hierarchy.
Figure 3-1
Authentication hierarchy
Overview of the Symantec Product Authentication Service
Authentication components
Authentication principal
An authentication principal is any entity that can authenticate to the Symantec
Product Authentication Service with a unique identity.
An authentication principal is a logical term that typically represents a human
user, 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,
the identities that are associated with the authentication principals are distinct
from the operating system login account identities.
Authentication components
The Symantec Product Authentication Service (AT) consists of the following
components:
■
Root broker
■
Authentication broker
■
Authentication plug-ins and mechanisms
■
Authentication entities
■
Authentication user interface
■
Authentication broker communication 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 the authentication principals
that represent authentication brokers.
Figure 3-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.
29
30
Overview of the Symantec Product Authentication Service
Authentication components
Figure 3-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 a client's authentication principals.
The certificate of an authentication broker is signed by the root broker. The
authentication broker authenticates only clients—it cannot authenticate other
authentication brokers. The authentication broker resides one level below the
root broker in the authentication hierarchy.
Figure 3-3 shows an authentication broker that is installed on a host machine.
The authentication broker may contain multiple private domains where each
domain is provisioned by one of the application services.
Figure 3-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 Service
Authentication components
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 AT:
■
NIS (formerly called YP – Yellow Pages)
■
NISPLUS (NIS+)
■
UNIXPWD – Password on UNIX and Linux systems
■
LDAP – OpenLDAP and iPlanet implementations
■
GSSAPI – Generic Security Service Application Programming Interface
■
NT – Windows NT domains and Active Directory (SSPI)
■
VX – Symantec Private Domain (used internally by AT)
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 3-1 lists the plug-ins supported by the Symantec Product Authentication
Service versions on UNIX/Linux platforms.
Plug-ins supported on UNIX/Linux
Table 3-1
AT
NIS
NIS+
UNIXPWD
VX
LDAP
GSSAPI
4.1
4.2
4.3
Table 3-2 lists the plug-ins that are supported by the Symantec Product
Authentication Service versions on Windows.
31
32
Overview of the Symantec Product Authentication Service
Authentication components
Table 3-2
AT
Plug-ins supported on Windows
Windows NT
VX
LDAP
GSSAPI
4.1
4.2
4.3
Authentication entities
An authentication entity is any Symantec application that sends an authentication
request to the Symantec Product Authentication Service.
Application service
An application service is a program that is contacted by, and provides services
to, a Symantec application client. AT validates the application service 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 AT to validate the identity of the user of
that client.
Authentication user interface
The Symantec Product Authentication Service provides a command-line utility,
vssat to administer the product. On UNIX/Linux, the vssat utility is available in
the /opt/VRTSat/bin directory. On Windows, the default folder for vssat.exe is
C:\Program Files\VERITAS\Security\Authentication\bin
To list the vssat options from the command line, type vssat --help. On
UNIX/Linux, type man vssat to display the manual pages.
AT also provides a graphical user interface. To start the GUI, invoke the command
runvssatgui.sh on UNIX/Linux, or runvssatgui.bat on Windows.
Authentication broker communication port
The default communication port number that is used by the root broker or
authentication broker is 2821.
Overview of the Symantec Product Authentication Service
How the authentication process works
Starting with version 4.3, AT can be configured to use the Private Branch Exchange
(PBX) communication port, 1556.
How the authentication process works
For the application client and application service to communicate securely, the
client and the 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,
and 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 3-4 provides a high-level concept of the authentication process.
Figure 3-4
Authentication process flow
AT uses the secure sockets layer (SSL) technology to provide secured
communication among the Symantec application client, the authentication broker,
and the Symantec application service. During the authentication process, the
33
34
Overview of the Symantec Product Authentication Service
How the authentication process works
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 an SSL connection is used, 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. The longer the session key, the
stronger the security.
About 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 3-5 illustrates the credential request that the user on client A sends to the
authentication broker.
Figure 3-5
Client credential request
The authentication broker creates a credential (in a form analogous to a passport
or ID card) that vouches for the identity of the user (holder). It then sends the
credential back to the user on client A through the SSL communication channel.
Figure 3-6 illustrates the process by which the signed public credential is sent to
the requesting authentication client.
Overview of the Symantec Product Authentication Service
How the authentication process works
Figure 3-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 3-7 illustrates the public key infrastructure (PKI) protocol where the user's
private key (including the user's name) is bound with the public certificate created
and signed by the authentication broker. The credential is then sent to the
authentication client.
Figure 3-7
Authentication credential
35
36
Overview of the Symantec Product Authentication Service
Authentication brokers in a high availability environment
Authentication brokers in a high availability
environment
One of the most important components in the Symantec Product Authentication
Service (AT) is the broker. A root broker is needed when you want to create
additional authentication brokers. An authentication broker provides the critical
function of authentication and must be available constantly. To make these brokers
highly available, they can be configured on a Veritas Cluster Server (VCS) as a
VCS service group.
VCS ensures that the AT service group is always online on one of the nodes. Access
to the high availability AT broker is accomplished through the virtual host name
that is assigned to the AT service group. By accessing the AT service through the
virtual host name, clients do not need to know the physical computer the AT
service is located on.
For more information on setting up an authentication hierarchy with high
availability brokers, see the Symantec Product Authentication and Authorization
Volume III.
Root plus authentication broker in a high availability environment
When you create an authentication hierarchy, you can configure the authentication
service to act as both a root broker and an authentication broker. This
configuration is referred to as the root-plus-authentication broker. The
root-plus-authentication broker can be configured as a high availability broker.
Access to the high availability broker is achieved through the virtual host name.
Unlike the stand-alone AT configuration, when you add an authentication
hierarchy with high availability brokers, additional configuration steps are needed.
Authentication broker in a high availability environment
You can configure an authentication broker in a high availability configuration.
Access to the high availability authentication broker is achieved through the
virtual host name. Unlike the stand-alone authentication broker, additional
configuration steps are needed to add a high availability authentication broker.
The root broker that is remote can be configured as either a stand-alone or a high
availability broker.
Authentication expiry
Each certificate that the Symantec Product Authentication Service issues has a
validity period. After a credential expires it is no longer usable, and the credential
Overview of the Symantec Product Authentication Service
Authentication expiry
must be reacquired. There are different types of certificates, and each type has
its own validity period.
Table 3-3 lists the authentication entities and their corresponding validity periods.
Table 3-3
Default expiry periods
Entity
Default expiry period
Root Broker
8 years
Authentication Broker
8 years
Service Principal
2 years
User Principal
1 year
Authorization Service
2 years
NetBackup System
1 year
NetBackup Login Session
24 hours
Web Session
8 hours
CommandCentral Web Session
30 minutes
37
38
Overview of the Symantec Product Authentication Service
Authentication expiry
Chapter
4
Overview of the Symantec
Product Authorization
Service
This chapter includes the following topics:
■
Authorization service overview
■
Authorization components
■
Access control policy
■
Access control lists
■
Authorization service in a high availability environment
■
How the authorization process works
Authorization service overview
The Symantec Product Authorization Service (AZ) is an access control
decision-making service. The Symantec Product Authentication Service (AT)
validates the identities of entities (principals) that work with Symantec software
applications. After the identities are validated, 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
product administrator. An administrator can view, set, or modify a policy through
40
Overview of the Symantec Product Authorization Service
Authorization components
the application user interfaces. These authorization policies are recorded in a
database. Access decisions are made by consulting this database. After making
an access decision, authorization allows each Symantec application to enforce
the decision.
Figure 4-1 shows a high-level overview of the authorization process.
Figure 4-1
Authorization overview
Authorization components
Symantec Product Authorization Service (AZ) consists of the following components:
■
Authorization service
■
Authorization client
■
Access control information data repository
Overview of the Symantec Product Authorization Service
Authorization components
■
Master authorization service
■
Local authorization service
■
Resource management application
■
Authorization group or namespace
■
Authorization user interface
■
Authorization service communication port
Authorization service
The Symantec Product Authorization Service (AZ) makes access control decisions
for the authentication entities (principals) after validating their identities. The
AZ service component enables the security administrator of a Symantec product
to create and manage the access control for the entries.
For more information on setting up a stand-alone authorization service for access
control, see the Symantec Product Authentication and Authorization Volume III.
Authorization client
An authorization client runs on a host that requests an access control decision
determined by 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 4-2 shows the structure of this type of data repository.
41
42
Overview of the Symantec Product Authorization Service
Authorization components
Figure 4-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 (AZ). Resource management applications
are made up of application clients and application services. Resource management
applications perform the following tasks, related to the Symantec Product
Authorization Service:
■
Advertise the existence of the resource they want to protect because AZ does
not have its own discovery function.
Overview of the Symantec Product Authorization Service
Access control policy
■
Ask the authorization service to make an access control decision for the
required service requests, and then enforce the decision by applying predefined
rules or policies.
Authorization group or namespace
An authorization group is a collection of entities (such as users). Entities in a
namespace can use different authentication domains. For example, a user (vegeta)
can employ the UNIXPWD domain type, while another user (trunk) employs the
NISPLUS domain type. Any authenticated entity is then granted the authorization
privileges that are based on the policy that is defined for the group.
Authorization user interface
The Symantec Product Authorization Service provides a command-line utility
(vssaz) to administer the product. On UNIX/Linux, the vssaz utility is available
in the /opt/VRTSaz/bin directory. On Windows, the default folder for vssaz.exe
is C:\Program Files\VERITAS\Security\Authorization\bin
To list the vssaz options, type vssaz --help from the command line. On
UNIX/Linux, type man vssaz to display the manual pages.
Authorization service communication port
The Symantec Product Authorization Service default communication port number
is 4032. You should specify this port number when you connect to the authorization
service.
Access control policy
An access control policy (ACP) is a set of rules that define how application resources
are 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 (for example, NBU_Operator and
NBU_Admin).
The security administrator assigns entities to each namespace. When an
authenticated entity tries to use a secured object, the NetBackup resource
management application invokes the decision-making service of Symantec Product
Authorization Service (AZ). AZ determines the access rights of the entity and
returns its decision to the application to be enforced.
43
44
Overview of the Symantec Product Authorization Service
Access control lists
For more information on NetBackup and AZ service, see the Symantec Product
Authentication and Authorization Volume III.
Access control lists
An access control list (ACL) is a collection of zero or more entries within an access
control policy (or permission namespaces). Each entry associates an authenticated
entity with a specific permission to perform tasks 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. Entities
that are assigned to the NBU_Admin permission namespace have NetBackup
administrative privileges.
Authorization service in a high availability
environment
The Symantec Product Authorization Service (AZ) provides the critical function
of access control and must be available constantly. To make the AZ service highly
available, it can be configured on a Veritas Cluster Server (VCS) as a VCS service
group.
VCS ensures that the AZ service group is always online on one of the nodes. Access
to the high availability AZ service is accomplished through the virtual host name
that is assigned to the AZ service group. By accessing the AZ service through the
virtual host name, clients do not need to know the physical computer the AZ
service is located on.
Unlike the stand-alone AZ configuration, additional configuration steps are needed
when you set up a high availability authorization service.
AZ service is dependent on the AT service (for the authentication broker) and
must be configured after the high availability AT service is setup. In a high
availability configuration, both the AT and the AZ services must be configured
with high availability.
In a non-securable VCS cluster, the AZ and the AT services must be configured in
the AT VCS service group. Access to the high availability AZ services must use
the AT's virtual host name.
In a securable VCS cluster, the high availability AZ service is configured in its own
VCS service group and has its own virtual host name. The AZ virtual host name
is dedicated to the AZ's VCS service group and must be used to access the AZ
service. AZ accesses the AT service through the AT's virtual host name.
Overview of the Symantec Product Authorization Service
How the authorization process works
For more information on setting up a high availability authorization service for
access control, see the Symantec Product Authentication and Authorization Volume
III.
How the authorization process works
For Symantec management applications that are integrated with the Symantec
Product Authorization Service (AZ), the product 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 process:
■
The user logs on, is authenticated, and is allowed to start accessing a resource
management application.
■
The resource management application requests permission for an entity
(principal) to access a resource.
■
The AZ service consults established access control policy, and then checks the
access control list to determine whether the requested access is allowed.
■
The AZ service passes its decision back to the protected application.
■
The resource management application enforces the decision made by the AZ
service.
45
46
Overview of the Symantec Product Authorization Service
How the authorization process works
Chapter
5
How Symantec Product
Authentication and
Authorization are used
across Symantec products
This chapter includes the following topics:
■
About deploying an authentication hierarchy
■
About deploying an authorization service
About deploying an authentication hierarchy
Deploying Symantec products with Symantec Product Authentication Service
(AT) involves the following topics:
■
About the need to create one authentication hierarchy for your enterprise
■
How AT provides secure communication
■
About assimilating AT into your enterprise
■
About upgrading AT
Deploying a Symantec product that makes use of the Symantec Product
Authentication Service (AT) requires the implementation of an authentication
hierarchy tree. A hierarchy tree consists of a root broker and one or more
authentication brokers.
When Symantec products are integrated with AT and are deployed together, an
authentication broker is set up for each product in the authentication hierarchy.
48
How Symantec Product Authentication and Authorization are used across Symantec products
About deploying an authentication hierarchy
The root broker and authentication brokers create their private domain
repositories (root domain and authentication domains), respectively.
For more information on AT use case, see the Symantec Product Authentication
and Authorization Volume III.
Deploying a Symantec product that makes use of the Symantec Product
Authorization Service (AZ) requires the implementation of an AZ server. You
typically configure an AZ server on the same system as the resource management
application (such as the NetBackup master server).
For more information on AZ use case, see the Symantec Product Authentication
and Authorization Volume III.
About the need to create one authentication hierarchy for your
enterprise
You plan the authentication hierarchy to which the authentication brokers belong,
according to the needs of your enterprise. Ideally, one authentication hierarchy
is sufficient and recommended. Within an authentication hierarchy, you can set
up authentication brokers across UNIX/Linux and Windows platforms.
The root broker in the authentication hierarchy holds the absolute power of
registration and certification. The root broker has the ultimate authority over the
validity of a certificate that an authentication broker issues to an authenticating
entity.
Authentication brokers are the intermediary registration and certification
authorities. Their role is to authenticate the client entities that must communicate
with the products' application services.
Authentication brokers that are created in separate authentication hierarchies
maintain distinct root certificates. Certificates from different authentication
hierarchies are not compatible. A secure communication channel between an
application client and an application service cannot be established unless the
client and the service use the authentication brokers that are descended from the
same root broker. Therefore, it is a hindrance when authentication brokers from
multiple authentication hierarchies are involved.
When you install certain Symantec products that have management servers or
application servers, the authentication service is automatically configured. Be
aware that some management servers implicitly create an authentication broker
in a new authentication hierarchy during installation, and inadvertently establish
a new root broker.
See Figure 3-4 on page 33.
How Symantec Product Authentication and Authorization are used across Symantec products
About deploying an authentication hierarchy
How AT provides secure communication
The Symantec Product Authentication Service (AT) vouches for the identities of
the application client and the application service, and issues certificates to these
entities. After these entities establish a valid product credential, a secure
communication channel is created between the requesting client and the
application service. The application client can be on the computer with the
application service, or on a different computer.
See Figure 3-4 on page 33.
The Symantec products that are integrated with the AT require a dedicated
authentication broker. These Symantec products have the Symantec management
server and agent (or client) components that use the AT service. Examples of a
Symantec management server include NetBackup and CommandCentral Storage.
All of the management servers have an accompanying authentication broker.
Symantec recommends that an authentication broker be set up on the same
computer as the management server.
In addition to the authentication broker, a Symantec management server must
also create one or more private authentication domains. For example,
CommandCentral creates the cc_users authentication domain with principals
for the CommandCentral users to log in. NetBackup creates the NBU_Machines
authentication domain. The NetBackup domain holds all the NetBackup-related
authentication principals (clients, master, and media).
Entities (such as users) who want to establish an authentication session must
authenticate by using the authentication principals that are created in the
authentication domain. The authentication broker that is exclusively configured
for a management server is then used to authenticate all the entities.
See Figure 3-3 on page 30.
About assimilating AT into your enterprise
The Symantec Product Authentication Service (AT) supports many authentication
mechanisms that are available on UNIX, Linux, and Windows.
See “Authentication plug-ins and mechanisms” on page 30.
The AT product provides a plug-in for each of the supported authentication
mechanisms. Symantec products that are integrated with AT use the plug-in to
authenticate entities (such as users) who access the products.
Enterprises that set up one or more of these authentication mechanisms (such as
NIS+ or LDAP) make it possible to deploy Symantec products with AT. These
49
50
How Symantec Product Authentication and Authorization are used across Symantec products
About deploying an authentication hierarchy
mechanisms allow the users of Symantec management servers and the clients to
reuse the existing authentication infrastructure in an enterprise.
NetBackup
NetBackup is integrated with Symantec Product Authentication Service (AT).
Table 5-1 lists the plug-ins that are supported by NetBackup on UNIX, Linux, and
Windows platforms.
Table 5-1
Plug-ins supported by NetBackup
NetBackup version UNIX/Linux
platform
Windows platform Cross platform
6.0MP4
NIS
Windows NT
6.0MP5
NISPLUS
6.5
UNIXPWD
6.5.1
The use cases show the specific version of the NetBackup product that is tested.
For more information on NetBackup use case on UNIX/Linux and Windows, see
the following sections in Symantec Product Authentication and Authorization
Volume II:
■
NetBackup use case for UNIX/Linux
■
NetBackup use case for Windows
NetBackup Operations Manager
NetBackup Operations Manager (NOM) is integrated with Symantec Product
Authentication Service (AT).
Table 5-2 lists the plug-ins that are supported by NOM on UNIX, Linux, and
Windows platforms.
How Symantec Product Authentication and Authorization are used across Symantec products
About deploying an authentication hierarchy
Table 5-2
Plug-ins supported by NOM
NOM version
UNIX/Linux
platform
Windows platform Cross platform
6.0MP4
NIS
Windows NT
6.0MP5
NISPLUS
6.5
UNIXPWD
6.5.1
The use case shows the specific version of the NOM product that is tested.
For more information on NOM use case, see the Symantec Product Authentication
and Authorization Volume II.
Veritas Backup Reporter
Veritas Backup Reporter (VBR) is integrated with Symantec Product Authentication
Service (AT).
Table 5-3 lists the plug-ins that are supported by VBR on UNIX, Linux, and
Windows platforms.
Table 5-3
Plug-ins supported by VBR
VBR version
UNIX/Linux
platform
5.0
NIS
5.0MP1
NISPLUS
Windows platform Cross platform
AL: verify the plug-in
UNIXPWD
The use case shows the specific version of the VBR product that is tested.
For more information on VBR use case, see the Symantec Product Authentication
and Authorization Volume II.
Veritas Storage Foundation
The Veritas Cluster Server (VCS) that is distributed in the following Veritas Storage
Foundation products are integrated with Symantec Product Authentication Service
(AT):
■
Storage Foundation Enterprise HA (SFEHA)
■
Storage Foundation for Oracle RAC (SF RAC)
51
52
How Symantec Product Authentication and Authorization are used across Symantec products
About deploying an authentication hierarchy
■
Storage Foundation Cluster File System (SFCFS)
■
Storage Foundation for Windows HA (SFWHA)
See Table 5-4 on page 52.
The use cases show the specific version of the VCS products that are tested.
For more information on Storage Foundation products use case on UNIX/Linux
and Windows, see the following sections in Symantec Product Authentication and
Authorization Volume II:
■
Storage Foundation products use case for UNIX/Linux
■
Storage Foundation products use case for Windows
Veritas Cluster Server
Veritas Cluster Server (VCS) is integrated with Symantec Product Authentication
Service (AT).
Table 5-4 lists the plug-ins that are supported by the VCS product on UNIX, Linux,
and Windows platforms.
Table 5-4
Plug-ins supported by VCS
VCS version
UNIX/Linux
platform
4.1
NIS
4.1MP2
NISPLUS
5.0
UNIXPWD
Windows platform Cross platform
5.0MP1
4.3MP1
Windows NT
4.3MP2
5.0
5.1
The use cases show the specific version of the VCS products that are tested.
For more information on VCS use case on UNIX/Linux and Windows, see the
following sections in Symantec Product Authentication and Authorization Volume
II:
■
Veritas Cluster Server use case for UNIX/Linux
■
Veritas Cluster Server use case for Windows
How Symantec Product Authentication and Authorization are used across Symantec products
About deploying an authentication hierarchy
Storage Foundation Manager
Storage Foundation Manager (SFM) is integrated with Symantec Product
Authentication Service (AT).
Note: Storage Foundation Manager was formerly known as Storage Foundation
Management Server (SFMS).
Table 5-5 lists the plug-ins that are supported by SFM on UNIX, Linux, and
Windows platforms.
Table 5-5
Plug-ins supported by SFM
SFM version
UNIX/Linux
platform
1.0MP1
NIS
1.1
NISPLUS
Windows platform Cross platform
UNIXPWD
The use case shows the specific version of the SFM product that is tested.
For more information on the SFM use case, see the Symantec Product
Authentication and Authorization Volume II.
Veritas Cluster Server Management Console
Veritas Cluster Server Management Console (VCS MC) is integrated with Symantec
Product Authentication Service (AT).
Note: Veritas Cluster Server Management Console was formerly known as Cluster
Management Console (CMC).
Table 5-6 lists the plug-ins that are supported by VCS MC on UNIX, Linux, and
Windows platforms.
53
54
How Symantec Product Authentication and Authorization are used across Symantec products
About deploying an authentication hierarchy
Table 5-6
Plug-ins supported by VCS MC
VCS MC version
UNIX/Linux
platform
5.0
NIS
5.0MP1
NISPLUS
Windows platform Cross platform
UNIXPWD
The use case shows the specific version of the VCS MC product that is tested.
For more information on the VCS MC use case, see the Symantec Product
Authentication and Authorization Volume II.
CommandCentral Storage and Service
CommandCentral Storage and Service are integrated with Symantec Product
Authentication Service (AT).
Table 5-7 lists the plug-ins that are supported by CommandCentral Storage on
UNIX, Linux, and Windows platforms.
Table 5-7
Plug-ins supported by CommandCentral Storage
CC Storage version UNIX/Linux
platform
Windows platform Cross platform
4.2FP1
NIS
Windows NT
4.3
NISPLUS
5.0
UNIXPWD
LDAP
Table 5-8 lists the plug-ins that are supported by CommandCentral Service on
UNIX, Linux, and Windows platforms.
Table 5-8
Plug-ins supported by CommandCentral Service
CC Service version UNIX/Linux
platform
Windows platform Cross platform
4.2FP1
Windows NT
NIS
LDAP
NISPLUS
UNIXPWD
The use cases show the specific version of the CommandCentral Storage and
Service products that are tested.
How Symantec Product Authentication and Authorization are used across Symantec products
About deploying an authentication hierarchy
For more information on the CommandCentral storage and service use case on
UNIX/Linux and Windows, see the following sections in the Symantec Product
Authentication and Authorization Volume II:
■
CommandCentral storage and service use case for UNIX/Linux
■
CommandCentral storage and service use case for Windows
Symantec License Inventory Manager
Symantec License Inventory Manager (SLIM) is integrated with Symantec Product
Authentication Service (AT).
Table 5-9 lists the plug-ins that are supported by SLIM on UNIX, Linux, and
Windows platforms.
Table 5-9
Plug-ins supported by SLIM
SLIM version
UNIX/Linux
platform
Windows platform Cross platform
4.0.4
NIS
Windows NT
5.0
NISPLUS
UNIXPWD
The use cases show the specific versions of the SLIM product that are tested.
For more information on the SLIM use case on UNIX/Linux and Windows, see the
following sections in the Symantec Product Authentication and Authorization
Volume II:
■
Symantec License Inventory Manager use case for UNIX/Linux
■
Symantec License Inventory Manager use case for Windows
About upgrading AT
On a computer that has a management server, you can install the agents or the
clients of other Symantec products. For example, on the computer that has a
NetBackup management server, you can install the CommandCentral and VBR
management agents. The management server and management agents or clients
may require a different version of the Symantec Product Authentication Service
(AT).
When you upgrade the AT for a Symantec product, it may involve a compatibility
issue for other Symantec products that are installed on a computer. Before you
upgrade AT, you must verify that the new version is compatible with other
Symantec products. A good practice is to maintain a test environment in your
55
56
How Symantec Product Authentication and Authorization are used across Symantec products
About deploying an authorization service
datacenter. You can use it to test new AT releases or maintenance packs before
you deploy the software to your production environment.
On a computer, a management server, agents, and clients of multiple Symantec
products may require different versions of AT. In this environment, you select
the latest version of AT and then you install it on the computer. You must use the
best practices to deploy AT across Symantec products.
Every Symantec product that is described in this document lists the AT versions
it is compatible with. The AT compatibility information for each Symantec product
is listed in the respective UNIX/Linux and Windows use cases.
See “Multiple product deployment approach” on page 59.
For more information on deploying Symantec products with the security feature,
see the following sections in Symantec Product Authentication and Authorization
Volume II:
■
Deployment of Symantec products with security on UNIX/Linux
■
Deployment of Symantec products with security on Windows
About deploying an authorization service
Deploying Symantec products with Symantec Product Authorization Service (AZ)
involves the following topics:
■
How AZ provides access control
■
About assimilating AZ into your enterprise
■
About upgrading AZ
The Symantec Product Authorization Service (AZ) provides an access control
service. After AT validates the identities of entities (principals) associated with
the Symantec products, AZ determines whether the validated entities have the
authority to perform privileged tasks on the protected resources.
How AZ provides access control
Symantec Product Authorization Service (AZ) works within the authorization
policies. The security administrators of Symantec products establish the
authorization policies. An administrator who wants to view, set, or modify a policy
can do so through the product user interface. AZ provides an authorization policy
database against which access decisions are made. After an access decision is
made, AZ allows each Symantec application to enforce that decision.
How Symantec Product Authentication and Authorization are used across Symantec products
About deploying an authorization service
About assimilating AZ into your enterprise
You can deploy Symantec products with access control in enterprises that have
setup the Symantec Product Authorization Service (AZ) . The non superusers that
are granted the access control on privileged resources enable the users to have
superuser privileges.
NetBackup
NetBackup is integrated with Symantec Product Authorization Service (AZ).
The NetBackup master server uses the AZ authentication domain, SERVICES to
hold the authentication principal that is related to the NetBackup authorization
activities. The use case chapters show the specific version of the NetBackup
product that is tested.
For more information on NetBackup use case on UNIX/Linux and Windows, see
the following sections in Symantec Product Authentication and Authorization
Volume II:
■
NetBackup use case for UNIX/Linux
■
NetBackup use case for Windows
You can use the guidelines and best practices that are available to configure
NetBackup with AZ.
For more information on NetBackup and AZ service, see the Symantec Product
Authentication and Authorization Volume III.
CommandCentral Storage
CommandCentral Storage 5.0 is integrated with Symantec Product Authorization
Service (AZ).
The use cases show the specific version of the CommandCentral Storage product
that is tested.
For more information on the CommandCentral storage and service use case on
UNIX/Linux and Windows, see the following sections in the Symantec Product
Authentication and Authorization Volume II:
■
CommandCentral storage and service use case for UNIX/Linux
■
CommandCentral storage and service use case for Windows
About upgrading AZ
On a computer that has a management server, you can install the agents or the
clients of another Symantec product. For example, on the computer with a
57
58
How Symantec Product Authentication and Authorization are used across Symantec products
About deploying an authorization service
NetBackup media server, you can install the CommandCentral Storage agent. The
management server and management agents or clients may require a different
version of the Symantec Product Authorization Service (AZ).
When you upgrade the AZ for a Symantec product, it may involve a compatibility
issue for other Symantec products that are installed on a computer. Before you
upgrade AZ, you must verify that the new version is compatible with other
Symantec products. A good practice is to maintain a test environment in your
datacenter. You can use it to test new AZ releases or maintenance packs before
you deploy the software to your production environment.
On a computer, a management server, agents, and clients of multiple Symantec
products may require different versions of AZ. In this environment, you can select
the latest version of AZ and then you install it on the computer. You must use the
best practices to deploy AZ across Symantec products.
See “Multiple product deployment approach” on page 59.
For more information on deploying Symantec products with the security feature
on UNIX/Linux and Windows, see the following sections in Symantec Product
Authentication and Authorization Volume II:
■
Deployment of Symantec products with security on UNIX/Linux
■
Deployment of Symantec products with security on Windows
Chapter
6
Deployment guidelines and
best practices
This chapter includes the following topics:
■
Multiple product deployment approach
■
How to determine the broker architecture
■
About implementing AT and AZ services in your enterprise
■
AT and AZ administration tasks
■
AT and AZ backup and recovery strategy
■
Empirical use cases
■
Use cases verification steps and troubleshooting tips
Multiple product deployment approach
Symantec Product Authentication Service (AT) and Symantec Product
Authorization Service (AZ) provide the security infrastructure for all the Symantec
products. The secure deployment of Symantec products requires careful analysis
and planning. Business requirements in your enterprise dictate the basis of both
the security architecture and the implementation approach.
Symantec recommends that you interpret your business requirements in a master
plan with short-term and long-term deliverables. A phased approach that deploys
one or two products at a time has proven to be effective in the deployment of
Symantec products with security services.
You use the implementation guidelines to create a plan to deploy all Symantec
products with the AT and the AZ enabled.
60
Deployment guidelines and best practices
Multiple product deployment approach
You must consider the following issues:
■
The authentication hierarchy (root broker).
■
The number of authentication brokers.
■
The distribution of management servers, agents, and clients.
The following Symantec products are targeted for deployment with the AT and
the AZ:
■
Storage Foundation Manager (SF Manager)
■
Veritas Cluster Server Management Console (VCS MC)
■
Storage Foundation (SF)
■
Veritas Cluster Server (VCS)
■
NetBackup (NBU)
■
NetBackup Operations Manager (NOM)
■
Veritas Backup Reporter (VBR)
■
CommandCentral Storage and Service (CC Storage/Service)
■
Symantec License Inventory Manager (SLIM)
Figure 6-1 shows a deployment scenario of these Symantec products.
Deployment guidelines and best practices
Multiple product deployment approach
Figure 6-1
Multiple product enterprise security deployment scenario
61
62
Deployment guidelines and best practices
Multiple product deployment approach
In a phased approach, you design an implementation strategy that gradually adds
more Symantec products to the security infrastructure. The implementation
strategy is accompanied by the framework and the configuration information
that is depicted in Figure 6-1.
In phase 1, an authentication hierarchy is set up for the first Symantec product
that is deployed with security. The rest of the phases add more Symantec products
with the security capability into the enterprise. Each phase deploys one or more
management servers. These management servers require the setup of one or more
authentication brokers in the authentication hierarchy.
About application servers
An application is a group of computer programs that work together to perform
specific tasks. Examples of Symantec applications include Storage Foundation
products (Veritas Cluster Server), NetBackup, Veritas Backup Reporter, and
CommandCentral Storage.
Symantec applications use the services that are available on the computer
operating system and the supporting Symantec applications. The supporting
Symantec applications include Private Branch Exchange, Authentication, and
Authorization.
See Table 2-1 on page 16.
An application server is a computer that is connected to an enterprise intranet,
and that runs a specific Symantec application. An application server typically
provides services to client computers.
Note: Application server and application service are synonymous and used
interchangeably.
About deploying application servers
On the computers that have an application server installed, the management
client or agents are also likely to be installed. These clients or agents manage the
application resources on these computers.
About deploying VCS with security
To deploy Veritas Cluster Server (VCS) with authentication service enabled, you
must configure an authentication broker on each node in the VCS cluster. Symantec
recommends that these authentication brokers use a root broker that is located
on a remote computer (outside of the VCS cluster). It is possible to configure the
root broker on one of the nodes in the VCS cluster, but it is not recommended.
Deployment guidelines and best practices
Multiple product deployment approach
About management servers
An application server that also manages client computers is called a management
server. A management server manages the resources on the client computers.
Resources on the client computers may include data, licensing information, and
storage capacity. The management server and the clients computers are connected
to the enterprise intranet.
See Table 2-1 on page 16.
Examples of Symantec management servers include NetBackup, NetBackup
Operations Manager (NOM), and CommandCentral Storage. Each of these
management servers manages a specific type of information on the client
computers. For example, NetBackup performs the backup and the recovery
operations for the data that resides on the client computers. NetBackup Operations
Manager manages the NetBackup master servers.
Note: Storage Foundation products are not categorized as management servers
because they do not manage client computers.
About deploying management servers
Symantec does not recommend that you deploy multiple product management
servers on the same computer. Management servers, like NetBackup master server
and CommandCentral Storage server, are typically installed on separate computers.
While you should deploy one product management server on a single computer,
you can set up a NOM management server on the same computer as the NetBackup
master server.
About deploying management servers with security
An authentication broker should always be configured for a management server
that is enabled with security. A management server that is set up on a computer
requires an authentication broker on the local computer. Symantec recommends
that you associate the authentication broker with an authentication hierarchy on
either the local system or on a remote system.
About management agents and clients
For a management server to manage a client computer, the product's client or
agent software must be installed on the client computer. You associate a client
with a specific management server by configuring it during or after the product
installation.
See Table 2-1 on page 16.
63
64
Deployment guidelines and best practices
How to determine the broker architecture
Note: NetBackup refers to its clients as clients. Other Symantec products refer to
their clients as agents. NetBackup clients are also referred to as agents by other
Symantec products. In this context, the agent and client are the same.
On a client computer, you can install a NetBackup client, CommandCentral, and
Veritas Backup Reporter agents. On the computers that have either management
agents or clients installed, typically, the client component of AT and AZ is installed.
You can configure a SLIM management agent on a system that has the Veritas
Cluster Server or the NetBackup master server.
See “About application servers” on page 62.
See “About management servers” on page 63.
How to determine the broker architecture
In an authentication hierarchy, there is only one root broker. The root broker
resides at the top of the hierarchy, and it is validated with a self-signed credential.
Every authentication hierarchy has a 40-byte electronic signature that is called
a root hash that uniquely identifies the root broker. The root hash is stored in a
binary file (root_hash), and an authentication command is available to display
the hash value.
See Figure 3-1 on page 28.
Note: Symantec strongly recommends that you establish one authentication
hierarchy (root broker) for your enterprise.
You can install and configure a root broker 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.
See Figure 3-2 on page 30.
Authentication brokers reside one level below the root broker. There can be
multiple authentication brokers in the authentication hierarchy. An authentication
broker serves as an intermediary registration authority between the root and the
authenticating entities. It also serves as a certification authority that can
authenticate management servers, management agents and clients, users, and
application services.
See Figure 3-3 on page 30.
Deployment guidelines and best practices
How to determine the broker architecture
An authentication broker cannot authenticate other authentication brokers. Each
authentication broker has an authentication PDR that stores the domains of
management servers such as NetBackup, VCS, CommandCentral, and other
Symantec products. Most management servers require that you configure an
authentication broker on the same computer as the management server.
You can establish an authentication hierarchy on a UNIX, Linux, or Windows
platform. You can install and configure a root broker on Windows or UNIX/Linux.
You can install and configure authentication brokers on UNIX/Linux and Windows.
On a platform, the AT product installs a list of plug-ins that are available to each
authentication broker. An authentication broker uses the authentication
mechanism that is associated with the plug-in to authenticate the users. An
authentication mechanism is either platform-specific (such as UNIXPWD, NIS,
NISPLUS, or Windows NT), or it can span across platforms (such as LDAP).
Figure 6-2 shows an authentication hierarchy with the broker architecture that
is applicable to the deployment scenario of the Symantec products.
65
66
Deployment guidelines and best practices
How to determine the broker architecture
Figure 6-2
An authentication hierarchy with a root broker and heterogenous
authentication brokers
In the high-level layout of a sample security infrastructure, an authentication
hierarchy is created with authentication brokers for the Symantec products. The
management servers and the associated authentication brokers are implemented
on the computers that run Windows and UNIX/Linux. Application servers,
management agents, or management clients are also deployed on the computers
that run Windows and UNIX/Linux operating systems.
See Figure 6-2 on page 66.
See Figure 6-1 on page 61.
Deployment guidelines and best practices
How to determine the broker architecture
On UNIX/Linux and Windows, the product administrator assigns plug-in to
authenticating entities (such as users) on computers with management agents
and clients. Symantec products that do not support cross platform plug-ins (like
LDAP) must use authentication brokers on the respective platforms that have the
management agents and clients.
Symantec recommends that you set up an authentication broker on each platform
that has the entities that need to be authenticated. All the authentication brokers
reside in one authentication hierarchy. Typically, UNIX/Linux authentication
brokers are set up to authenticate the entities that are on the UNIX/Linux
computers. You must assign all the authenticating entities on Windows to the
authentication brokers that are configured on Windows.
Using Figure 6-1 as a deployment example, an enterprise has a NetBackup master
server with media servers on Windows, HP-UX, and RedHat platforms. The master
server manages many computers with the NetBackup client installed on Windows,
HP-UX, and RedHat. NetBackup media server requires the installation of an AT
client component on each of these computers.
To authenticate entities on computers with NetBackup client, you can set up
additional authentication brokers on the computers that have the NetBackup
media servers. You can change the AT configuration on a computer from an
authentication client to an authentication broker.
The authentication broker that is configured on the computer with the media
server is used to authenticate the users that are located on other computers. These
computers may have NetBackup client installed, or other management agents
that are on the same platform.
For example, the authentication broker that is configured on the HP-UX computer
with media server can be used to authenticate all the users on the HP-UX computer
with NetBackup client. Similarly, all the users on the Windows computer with
NetBackup client can be assigned to the authentication broker that is configured
on the Windows computer with the NetBackup media server.
All the examples use one authentication hierarchy (either on UNIX/Linux or
Windows) with either stand-alone or high availability brokers. In the UNIX/Linux
use cases, the authentication hierarchy (root broker) is configured on Solaris, and
authentication brokers are configured on other UNIX/Linux and Windows. In the
Windows use cases, the authentication hierarchy (root broker) is configured on
Windows, and authentication brokers are configured on UNIX/Linux and Windows.
Root and authentication brokers placement
In an enterprise that has UNIX/Linux and Windows platforms, Symantec
recommends that you place the root broker on the platform that is more common
in your enterprise. For example, if Windows constitutes 65 percent of the
67
68
Deployment guidelines and best practices
How to determine the broker architecture
computers in your enterprise, Windows becomes the preferred platform for you
to deploy the root broker.
Similarly, in a predominantly UNIX/Linux environment, you place the root broker
on a computer that runs one of the UNIX/Linux operating systems. You may be
able to use other factors in your enterprise to determine the physical placement
of the root broker.
See “About an isolated root broker” on page 69.
After an authentication hierarchy (root broker) is successfully deployed, you must
configure additional authentication brokers. These authentication brokers are
needed to authenticate the entities that are located on heterogenous platforms.
If you have UNIX/Linux and Windows platforms deployed in your enterprise, you
may have to configure authentication brokers on each of the platforms. For
example, you must assign the Windows entities that use the Windows's NT
mechanism to an authentication broker on a Windows computer.
Figure 6-3 shows how you can place the root and the authentication brokers on
heterogenous platforms.
Figure 6-3
Root and authentication broker placement
Deployment guidelines and best practices
How to determine the broker architecture
In an enterprise that has a large number of authenticating entities (such as users),
Symantec recommends that you configure multiple authentication brokers to
authenticate these entities. Usually, the authenticating entities are dispersed over
many computers with management agents and clients. Product administrators
can assign the authenticating entities to different authentication brokers.
The use of one authentication broker to authenticate a large number of entities
has certain disadvantages. A catastrophic hardware failure can occur on the
computer where the authentication broker is located. Without an authentication
broker, the entities cannot acquire the credential to communicate with their
service providers. In addition, the entities that are located on UNIX/Linux and
Windows computers would likely require a platform-specific authentication
broker.
The number of authentication brokers to configure is based on the number of
authentication mechanisms (plug-ins) that are used in your enterprise. If your
enterprise uses NISPLUS, UNIXPWD, and Windows NT mechanisms, Symantec
recommends that you set up an authentication broker on a separate computer for
each of these mechanisms. On each of these computers, you may set up another
Symantec product.
You can use the authentication mechanism to determine the assignment of entities
to authentication brokers. If the majority of the entities use the NISPLUS
mechanism, Symantec recommends that you set up multiple authentication
brokers with this mechanism to share the load.
For example, assume that there are four computers in an enterprise with more
than three thousand NISPLUS users on each computer. You can configure an
authentication broker on four separate computers, and you can assign users on
each of the computers to one of the authentication brokers.
About an isolated root broker
You can set up an authentication hierarchy with the root broker on a computer
without any authentication broker. The root broker is isolated to a secure computer
that is accessible only to selected individuals with high privileges. For the
enterprises that want to control the creation of authentication brokers, this
configuration provides added security to the environment.
Figure 6-4 shows the isolated root broker configuration.
69
70
Deployment guidelines and best practices
How to determine the broker architecture
Figure 6-4
Isolated root broker configuration
About multiple root brokers
You can set up an authentication hierarchy (root broker) on either a Windows or
a UNIX/Linux platform. You can create Windows and UNIX/Linux authentication
brokers in an authentication hierarchy that is either on Windows or on
UNIX/Linux. You can isolate the root broker of your authentication hierarchy on
a secure computer.
The business requirements of your enterprise may require that you establish more
than one authentication hierarchy. Before you implement multiple authentication
hierarchies, you must anticipate the limitations of multiple authentication
hierarchies, and you must understand the effort that is required to maintain them.
In a typical enterprise, one authentication hierarchy (root broker) is usually
sufficient. Unless your enterprise has unique requirements, Symantec does not
recommend that you set up multiple authentication hierarchies, or that you set
up trust between hierarchies.
Deployment guidelines and best practices
How to determine the broker architecture
For example, assume that your enterprise has an authentication hierarchy that
is set up on a secure computer. When you set up another authentication hierarchy
and establish trust between these hierarchies, the configuration may defeat the
purpose of having a root broker on a secure computer.
You must set up every Symantec product that has a management server on a
dedicated computer. It is typical for a product administrator to configure a
management server (for example, CommandCentral Storage) on one computer,
and another management server (for example, Veritas Cluster Server Management
Console) on another computer.
Two different administrators may be responsible for maintaining these Symantec
products. For example, one product administrator can create an authentication
broker in a new authentication hierarchy. The other product administrator can
create an authentication broker in a new hierarchy. In this example, two
authentication hierarchies would exist in the enterprise.
Figure 6-5 shows the management servers with their authentication brokers that
are configured on two separate authentication hierarchies (private root brokers).
Figure 6-5
Management servers with private root brokers
Every root broker has a unique electronic signature. The authentication credentials
that are obtained in one authentication hierarchy are not recognized in another
authentication hierarchy. Entities that use authentication brokers in different
authentication hierarchies cannot communicate. For the entities in different
71
72
Deployment guidelines and best practices
How to determine the broker architecture
hierarchies to communicate, you must set up a trust from one hierarchy to
recognize the authentication brokers in another.
To set up the trust correctly, you must have advanced knowledge of the
authentication product, and you must understand your configuration. After the
trust is established at the root level, all the authenticating entities within the
trusting hierarchy must be made aware of the root electronic signature in the
trusted hierarchy.
For example, NetBackup and NetBackup Operations Manager (NOM) are set up
with authentication brokers in different hierarchies. For the NOM to manage the
NetBackup, NetBackup is the trusting hierarchy and the NOM's hierarchy is
considered as trusted. You must re-authenticate the entities in the trusting
hierarchy.
If your enterprise has no requirements to maintain multiple authentication
hierarchies, Symantec recommends that you avoid implementing multiple
hierarchies. You must always implement one authentication hierarchy that
contains all the authentication brokers for all the management servers.
See Figure 6-2 on page 66.
One authentication hierarchy simplifies the management and maintenance of
your authentication infrastructure. The authentication administrator installs the
NOM management server on a computer with an authentication broker that points
to an existing authentication hierarchy. The NOM and NetBackup are now under
the same authentication hierarchy, which eliminates all the trust and
re-authentication tasks.
Root brokers consolidation
You can consolidate multiple authentication hierarchies into one authentication
hierarchy.
When you choose the simple installation type during installation, the Symantec
product installation script usually sets up a new authentication hierarchy on the
computer.
Note: You can inadvertently create multiple authentication hierarchies when you
set up multiple Symantec products with management servers on different
computers.
See Figure 6-5 on page 71.
Secure communication across all the Symantec products is prohibited when all
the authentication brokers of all the management servers are in different
Deployment guidelines and best practices
How to determine the broker architecture
authentication hierarchies. You can install agents of other Symantec products on
a computer that has a NetBackup management server.
For example, agents may include NetBackup Operations Manager, Veritas Backup
Reporter, and CommandCentral Storage. When all the agents need to work with
the NetBackup management server, you must specify from which authentication
hierarchy an agent gets its credential. Because a computer can hold an
authentication credential from only one root broker at a time, you must set up
trust between different hierarchies to facilitate communication among all the
authenticating entities.
In your enterprise, you may have two management servers that are installed on
two computers. You can create an authentication hierarchy on each computer for
the management server.
For example, assume that the first management server is Symantec Licensing
Inventory Manager (SLIM) and the second management server is CommandCentral
Storage (CC Storage).
See Figure 6-6 on page 74.
You can merge the authentication brokers from one authentication hierarchy into
another. Usually, it is easier to merge the authentication hierarchy that has the
least number of authentication brokers. You can merge a hierarchy on Windows
into a hierarchy on UNIX/Linux, or vice versa.
See Figure 6-5 on page 71.
After you move all the authentication brokers in an authentication hierarchy, you
can delete the empty authentication hierarchy.
Figure 6-6 shows the single authentication hierarchy after the consolidation of
two hierarchies into one hierarchy.
73
74
Deployment guidelines and best practices
How to determine the broker architecture
Figure 6-6
Consolidating authentication hierarchies
You can move an authentication broker that is created in an authentication
hierarchy on UNIX/Linux into another authentication hierarchy that is created
on Windows. For example, you can move the SLIM authentication broker that is
created on a UNIX/Linux hierarchy into a hierarchy on Windows. The Windows
hierarchy is created for the CommandCentral storage management server. You
can also move an authentication broker that is created in a Windows hierarchy
into a hierarchy on UNIX/Linux.
For more information on the replacement of the root broker for the SLIM
management server, see the Symantec Product Authentication and Authorization
Volume III.
You can move the NetBackup and CommandCentral authentication brokers into
another authentication hierarchy.
After the SLIM authentication broker is moved into the authentication hierarchy
of the CC Storage, you must re-authenticate the SLIM management agent on all
the computers. The re-authentication is used to retrieve the electronic signature
of the root broker in the CommandCentral authentication hierarchy.
You perform the re-authentication on each computer that has the SLIM
management agent. When you consolidate the authentication hierarchies, it is
Deployment guidelines and best practices
How to determine the broker architecture
easier to move the hierarchy that has the least number of authentication brokers,
and management agents, or clients.
About the availability of brokers
An authentication hierarchy can have one root broker and many authentication
brokers.
See “Authentication hierarchy” on page 28.
The root broker must be available when you add a new authentication broker. The
root broker keeps track of all the authentication brokers in the authentication
hierarchy.
See Figure 6-2 on page 66.
An authentication broker must be available to authenticate entities and hand out
credentials.
See “How the authentication process works” on page 33.
Without the root broker, you cannot do the following tasks:
■
Add new authentication brokers.
■
Establish trust between different authentication hierarchies.
You can continue to use the existing authentication brokers to authenticate
entities, and to issue credentials when the root broker is not available. After the
root broker ceases to exist, an authentication broker can continue to function for
up to eight years.
Without the authentication broker, authenticating entities that use the
authentication broker can no longer obtain new authentication certificates or
new credentials. However, the credentials that were cached on the computers are
still valid, and continue to work until they expire.
The AT product administrator must continue to monitor the status of the root
broker and all the authentication brokers. When a user fails to authenticate or to
log on to the Web console, the AT product administrator must verify the health
of the authentication broker.
See “How the authentication process works” on page 33.
Authentication brokers are used more frequently than the root broker. It is ideal
to have multiple authentication brokers that are configured on stand-alone
computers. These authentication brokers are configured with the same
authentication plug-in to share the load, and to respond as backup.
For more information on setting up an authentication hierarchy with stand-alone
brokers, see the Symantec Product Authentication and Authorization Volume III.
75
76
Deployment guidelines and best practices
About implementing AT and AZ services in your enterprise
For example, an authentication broker that is located on a stand-alone computer
is used to authenticate the users on a computer with a management client. When
failure occurs on the computer with the authentication broker, the affected users
can be reassigned to another authentication broker that supports the same plug-in.
Instead of setting up multiple stand-alone computers with authentication brokers,
you can set up a high availability authentication broker. Assume that the high
availability authentication broker is configured with the Veritas Cluster Server
(VCS) software.
The high availability authentication broker is always online on one of the nodes
in the VCS cluster. You access to the authentication broker through the virtual
host name that is associated with the authentication broker.
See “Authentication brokers in a high availability environment” on page 36.
On a computer, you can easily determine if either a root-plus-authentication
broker or an authentication broker is configured.
For more information on the verification of the AZ service, see the Symantec
Product Authentication and Authorization Volume III.
About brokers in different time zones
Root broker and authentication brokers can span different time zones. The
Symantec Product Authentication Service (AT) and the Symantec Product
Authorization Service (AZ) perform all of their operations relative to Greenwich
Mean Time (GMT).
You must set the clock on the computers where your root broker and authentication
brokers reside within five minutes of each other. For example, you can have the
root broker located in Los Angeles and authentication brokers in London or
Singapore.
On the computers that have either the root or the authentication broker, you must
configure the time zone and clock correctly according to the local time zone.
About implementing AT and AZ services in your
enterprise
Your enterprise may already deploy some of the Symantec products with the
Symantec Product Authentication Service (AT) and the Symantec Product
Authorization Service (AZ). You can deploy multiple Symantec products in a
number of scenarios with the AT and the AZ enabled.
See Table 2-1 on page 16.
Deployment guidelines and best practices
About implementing AT and AZ services in your enterprise
For all scenarios, you must formulate a project plan, and you must transform the
implementation approach into a diagram.
See Figure 6-1 on page 61.
Typical enterprise scenarios include the following examples:
■
In the first scenario, your enterprise is ready to deploy the first Symantec
product with the AT and the AZ services enabled.
Assume that you have created the project plan diagram. Next, prioritize the
Symantec products in the order of importance, and then install them. Symantec
highly recommends that you install each management server on a computer
by itself. You can place the authentication hierarchy (root broker) on the
computer where the first Symantec product with a management server is
installed.
If your enterprise requires that you isolate the root broker on a separate
computer, Symantec recommends that you install and configure the root
broker first. After you install and configure the root broker, you can install
the first Symantec management server.
An authentication hierarchy is created when either the SF Manager or the VCS
MC Symantec product is installed first.
See Figure 6-1 on page 61.
Next, you install additional Symantec management servers. The authentication
brokers that are created for the management servers should belong to the
authentication hierarchy that the first Symantec product creates. After you
configure a management server and verify that it works, you can start the
management client or agent installation.
You must configure an authentication broker on each node of the VCS cluster
when the securable VCS is enabled with the AT service. For example, you must
configure an authentication broker on each node of the SF Oracle RAC cluster.
Symantec recommends that the VCS authentication brokers reside in the
authentication hierarchy that is set up by the first Symantec product.
Certain Symantec products (such as NOM) use the authentication service for
authenticating NOM users. The NOM installation script automatically
configures an authentication broker. The installation script of certain Symantec
products automatically configures an authentication hierarchy on the computer
where the Symantec product is installed. The authentication hierarchy includes
the root broker plus the authentication broker.
Other Symantec products (such as NetBackup) require that you install and
configure the AT and the AZ services separately after NetBackup is configured.
■
In the second scenario, your enterprise has several Symantec products that
are already deployed. Some of the Symantec products (such as VCS and VCS
MC) are deployed with the AT service. Other Symantec products (such as
NetBackup and CommandCentral Storage) are also deployed, but are not
77
78
Deployment guidelines and best practices
About implementing AT and AZ services in your enterprise
activated with the AT and the AZ services. You can enable the AT and the AZ
services for NetBackup and CommandCentral Storage. You create the
NetBackup and CommandCentral Storage authentication brokers in the
authentication hierarchy that already exist.
In this deployment scenario, you install and configure the VCS cluster and the
VCS MC management server on separate computers. You can assume that the
AT service is enabled for the VCS and the VCS MC Symantec products. The AT
and the AZ services are not enabled on the NetBackup and CommandCentral
Storage management servers. You can enable the AT and the AZ services for
the NetBackup and CommandCentral Storage management servers that are
installed and configured on stand-alone computers.
For more information on NetBackup use case on UNIX/Linux and Windows,
see the following sections in Symantec Product Authentication and
Authorization Volume II:
■
NetBackup use case for UNIX/Linux
■
NetBackup use case for Windows
For more information on the CommandCentral storage and service use case
on UNIX/Linux and Windows, see the following sections in the Symantec
Product Authentication and Authorization Volume II:
■
CommandCentral storage and service use case for UNIX/Linux
■
CommandCentral storage and service use case for Windows
The VCS application server is installed on a two-node cluster by using the SF
for Oracle RAC product. The AT service may not be enabled for the securable
VCS during the initial configuration. To enable the AT service in a securable
VCS, the instructions and procedures are described in the Storage Foundation
section in the UNIX/Linux use cases.
For more information on the Storage Foundation products use case on
UNIX/Linux, see the Symantec Product Authentication and Authorization
Volume II.
For more information on the Veritas Cluster Server use case on UNIX/Linux,
see the Symantec Product Authentication and Authorization Volume II.
The SFWHA product use cases for Windows illustrate the instructions and
procedures that you use to enable the AT service in a securable VCS.
For more information on the Storage Foundation products use case on
Windows, see the Symantec Product Authentication and Authorization Volume
II.
For more information on the Veritas Cluster Server use case on Windows, see
the Symantec Product Authentication and Authorization Volume II.
■
In the third scenario, your enterprise has deployed several Symantec products.
None of the deployed Symantec products are activated with either the AT or
Deployment guidelines and best practices
AT and AZ administration tasks
the AZ service. In this scenario, when those Symantec products are ready to
enable the AT service, a new authentication hierarchy is created.
You select the Symantec products that need the security the most by enabling
them with the AT and the AZ services. You can deploy the authentication
hierarchy (root broker) on a computer where the Symantec product is installed.
You can also deploy the authentication hierarchy on a secure computer.
In your enterprise, always remember that one authentication hierarchy is adequate
and is preferred. On a UNIX/Linux computer, you can create an authentication
broker that belongs to an authentication hierarchy (root broker) on Windows.
Similarly, you can create an authentication broker (on Windows) that belongs to
an authentication hierarchy on UNIX/Linux. The root broker and the
authentication broker can be on the same or the different platforms.
You can configure a local root broker for each of the Symantec management
servers. You must consolidate all the redundant root brokers into one
authentication hierarchy.
AT and AZ administration tasks
Administrators for the Symantec Product Authentication Service (AT) and the
Symantec Product Authorization Service (AZ) perform a number of administrative
tasks.
Typical administrative actions include the following tasks:
■
Ensure that the AT and the AZ services are configured according to the product
specifications. Their usages must meet the business requirements that are
established for your enterprise.
■
Perform regular backups of the data that is generated by the AT and the AZ
services. Administrators verify that the recovered data is usable and valid.
■
Define an upgrade procedure for the AT and the AZ products. The upgrade is
determined by the compatibility between the new versions of AT and AZ, and
the existing consuming Symantec products. The consuming Symantec products
that are configured on a computer must work with the upgraded AT or AZ
version.
■
Monitor the availability of the AT and the AZ services. Avoid disruption to
availability, either directly (the designated authentication broker is stopped),
or indirectly (AZ cannot authenticate because the authentication broker that
is needed by AZ is no longer available).
AT administrator responsibilities
Symantec Product Authentication Service (AT) maintenance consists of:
79
80
Deployment guidelines and best practices
AT and AZ administration tasks
■
Backing up the AT data.
■
Managing the root broker, all the authentication brokers, and all the
authentication clients that are deployed in the enterprise.
One of the AT administrator's most important duties is to ensure that the AT data
of the root and authentication brokers are backed up regularly by using a backup
schedule that is designed for the enterprise. After an authentication hierarchy is
configured and verified that it works, it typically requires little maintenance other
than to perform regular backups.
See “AT and AZ backup and recovery strategy” on page 90.
The AT administrator must decide which authentication domains the
authentication entities (such as users) should use, and which 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 plug-in for the NISPLUS mechanism. For a user on a management
client (like NetBackup) to use a plug-in (like NISPLUS), the product administrator
assigns an authentication broker that has the NISPLUS authentication domain
that is configured to the management client. The product administrator uses a
product configuration tool on UNIX/Linux and Windows to make the configuration
modifications. The AT administrator must also verify that the Symantec products
are properly configured with AT service.
See “Authentication plug-ins and mechanisms” on page 30.
The AT administrator sets up new authentication brokers and the AT administrator
renews the authentication broker credentials. The AT administrator must ensure
that all the authentication brokers are available to their clients all the time. Clients
contact an authentication broker whenever a user or an application on a client
computer needs to authenticate or renew a credential.
In an enterprise, credential renewals are typically the responsibility of the
application administrators who manage Symantec management servers (such as
NetBackup and CommandCentral Storage) that are configured with the AT service.
The Symantec product administrators must work with the AT administrator to
define a process for addressing the new installation and upgrade issues, especially
when the AT is installed on a computer that is shared by a management server
and agent/client of another Symantec product.
Symantec recommends that you design an AT recovery strategy, test the procedure,
and document it. The recovery process must cover the root broker, an
authentication broker, and an authentication client. In the event that you need
to rebuild the root broker on a computer, you follow the recovery procedure by
Deployment guidelines and best practices
AT and AZ administration tasks
using the AT backup. Similarly, you rely on the backup to repair an authentication
broker or an authentication client.
AZ administrator responsibilities
Symantec Product Authorization Service (AZ) maintenance consists of maintaining
the AZ server, the AZ access control list repository, and the AZ clients that are
deployed in the enterprise.
One of the most important duties for an AZ administrator is to ensure that the
AZ access control list repository is backed up regularly by using a backup schedule
that is designed for the enterprise.
See “AT and AZ backup and recovery strategy” on page 90.
The AZ administrator must ensure that the authorization groups, access control
list, and permission sets are defined and maintained correctly. The AZ
administrator must work with other Symantec product administrators to ensure
that an authentication broker is always available, and that the AZ service is
available to all the Symantec products (such as NetBackup) that need it.
For more information on NetBackup and AZ service, see the Symantec Product
Authentication and Authorization Volume III.
Symantec recommends that you design an AZ recovery strategy, test the procedure,
and document it. The recovery process must cover the AZ server and authorization
client. In the event that you need to rebuild the AZ server on a computer, you
follow the recovery procedure by using the AZ backup. Similarly, you rely on the
backup to repair an authorization client.
Platform-specific considerations
The Symantec Product Authentication Service (AT) and Symantec Product
Authorization Service (AZ) are supported on UNIX, Linux, and Windows platforms.
The AT and the AZ configuration scenarios are described on the following
operating systems:
■
AIX
■
HP-UX
■
Linux (RedHat and SuSE)
■
Solaris
■
Windows
81
82
Deployment guidelines and best practices
AT and AZ administration tasks
In the use case section, each Symantec product that is identified with the AT
service shows the operating system version that is used on each platform. The
same information is available for each Symantec product that uses the AZ service.
On a given operating system, the AT supports many plug-ins. Each plug-in has a
corresponding mechanism that the AT uses to authenticate entities, such as users.
Some of these plug-ins are available exclusively on UNIX/Linux. Others are
available only on Windows. The AT has a proprietary plug-in named VX that is
used exclusively to authenticate services, daemons (processes), and clients of
Symantec products.
To authenticate a user for a logon session, the AT must use an authentication
plug-in that is available on either the local computer or the enterprise. Users can
use material such as a user name and password for authentication. The user name
and password can be the password mechanism on the local computer or the
NISPLUS mechanism in the enterprise.
See “Authentication plug-ins and mechanisms” on page 30.
See “About assimilating AT into your enterprise” on page 49.
UNIX/Linux plug-ins and mechanisms
Mechanisms such as NIS, NISPLUS, and UNIXPWD are specific to UNIX/Linux,
and do not operate on Windows. For the Symantec Product Authentication Service
(AT) to use NIS or NISPLUS as the authentication plug-in, you must configure
this service in the enterprise.
On UNIX/Linux platforms, the UNIX password is the basic authentication plug-in
that is available to the AT for authenticating users. An authentication client uses
the UNIXPWD password mechanism that is on the computer where the
authentication broker is located, and not a password file on the client computer.
Other AT plug-ins, such as LDAP, are supported on the UNIX and Linux platforms.
However, a Symantec management server (such as CommandCentral Storage)
must support the LDAP plug-ins before users can use LDAP for authentication.
Before you integrate a mechanism (such as NISPLUS or LDAP) with the AT service,
it must be configured and verified first.
Windows plug-ins and mechanisms
On Windows, Symantec Product Authentication Service (AT) supports the NT
plug-in, which corresponds to the Windows NT mechanism. The NT plug-in uses
the Windows Security Services Provider Interface (SSPI).
During the logon session, Symantec products on Windows uses the NT plug-in to
authenticate users.
Deployment guidelines and best practices
AT and AZ administration tasks
On Windows, the AT has a plug-in that supports the LDAP mechanism. Before
you integrate a mechanism (such as LDAP) with the AT service, it must be
configured and verified.
AT and AZ installation considerations
When you set up the Symantec Product Authentication Service (AT) and the
Symantec Product Authorization Service (AZ), refer to the guidelines that are
described in the AT and the AZ use cases in the appendix .
For more information on AT use case, see the Symantec Product Authentication
and Authorization Volume III.
For more information on AZ use case, see the Symantec Product Authentication
and Authorization Volume III.
If you use a version of the AT or the AZ that is not covered in the use cases, you
may have to consult product installation guides and release notes.
The AT and the AZ products have both the service and the client components. On
a computer, when you install the service component, usually the client component
is also installed. However, on some platforms (like Linux), the service installation
requires the service and the client components be installed explicitly. You can
install the client component separately on a computer. The AZ depends on the
AT. To install the AZ in either the service or the client mode, the AT client
component must already be installed, or must be installed concurrently with the
AZ.
A product configuration is required when the AT and the AZ are installed in service
installations. To perform a product configuration, both the service and the client
components must be installed on a computer. Client installations do not require
product configuration.
On the computers that have Symantec management servers, the AT service and
client components are also installed. An authentication broker (at the minimum)
is set up on the local computer where the management server resides.
On the computers that have either management agents or clients, you need to
install only the AT client component.
On the computers that have cluster server (like VCS) installed, management agents
and/or clients of other Symantec products can be installed. An authentication
broker must be configured on each node of the cluster in order for the VCS to
communicate in secure mode. On these computers, VCS uses the service and the
client components of the AT product. The management agents and clients need
to use only the AT client component.
83
84
Deployment guidelines and best practices
AT and AZ administration tasks
Some management servers (like NetBackup master server and CommandCentral
Storage) use the AZ service for access control. On the computers that host these
management servers, the AZ service and client components are installed. Other
management servers (like NetBackup media server) that are configured on a
stand-alone computer also need the AT and the AZ client component.
In your enterprise, you start by setting up the AT and the AZ services on the
computers that have the Symantec management servers. Next, you move to the
application servers that need the AT service. After all the computers with
management and application servers are setup with the AT and the AZ services,
you can set up the AT client on the computers that host the management agents
and the clients.
For more information on the typical product deployment strategy on UNIX/Linux,
see the Symantec Product Authentication and Authorization Volume II.
About the AT product installation
The Symantec Product Authentication Service (AT) can be installed in either a
service or a client installation.
On a computer, you can install the AT product in one of these scenarios:
■
Create an authentication hierarchy with a root broker. You can also configure
an authentication broker with the root broker on the same computer.
■
Install an authentication broker for a Symantec management server. The root
broker for the authentication broker is remote on another computer. A
management server often installs an authentication broker automatically.
■
Install the AT client component. A management agent or client of other
Symantec products may be installed on the computer. A management agent
or client might install the AT client component automatically.
Starting with the AT version 4.3, you can configure the AT to use the Private
Branch Exchange (PBX) port (1556) for communication. To use PBX port for AT
communication, you must first install and configure PBX.
For more information on Private Branch Exchange use case, see the Symantec
Product Authentication and Authorization Volume III.
About the root broker installation
The Symantec Product Authentication Service (AT) can be deployed as either a
stand-alone or high availability AT service. In the authentication hierarchy where
the root broker is configured, an authentication broker is also created.
You deploy the AT service with an authentication hierarchy that has the root
broker configured in either a stand-alone mode or high availability mode.
Deployment guidelines and best practices
AT and AZ administration tasks
In the stand-alone mode, the AT authentication hierarchy is created by using one
of the following methods:
■
Use the installation script that is distributed by the AT product to install and
configure an authentication hierarchy with the root broker.
■
Use the installation script of a consuming Symantec product (such as VCS
MC), which installs the AT and configures the root broker. By default, the
product installation script installs the AT product and configures the root
broker with an authentication broker.
In an environment where an authentication hierarchy already exists, you
instruct the installation script to create only the new authentication broker
in the existing hierarchy.
Note: The installation script of some Symantec products may unconditionally
create a new authentication hierarchy with a root broker plus an authentication
broker. In this situation, you merge the authentication hierarchy to your
existing hierarchy.
The installation script of some Symantec products (such as NetBackup) cannot
create an authentication hierarchy and an authentication broker. To set up
the AT service for the NetBackup product, you must use the AT installation
script.
For more information on setting up an authentication hierarchy with stand-alone
brokers, see the Symantec Product Authentication and Authorization Volume III.
In the high availability mode, the AT authentication hierarchy is created by using
the following process:
■
Use the installation script that is distributed by the AT product to install and
configure the root broker in stand-alone mode on each of the nodes in the VCS
cluster.
■
After all the nodes in the VCS cluster are set up, use the configuration script
that is distributed by the AT product to configure the root broker in high
availability mode.
Only specific versions of AT 4.2 and 4.3 support the high availability root broker.
For more information on setting up an authentication hierarchy with high
availability brokers, see the Symantec Product Authentication and Authorization
Volume III.
Authentication broker installation
The Symantec Product Authentication Service (AT) can be deployed as either a
stand-alone or as a high availability authentication broker. In your enterprise,
85
86
Deployment guidelines and best practices
AT and AZ administration tasks
you must have an authentication hierarchy already set up for the new
authentication brokers. The root broker in the existing hierarchy can be configured
in either stand-alone or high availability mode.
A new authentication broker is configured in either stand-alone or high availability
mode.
In the stand-alone mode, the authentication broker is created by using one of the
following methods:
■
Use the installation script that is distributed by the AT to install and configure
an authentication broker with a remote root broker.
■
Use the installation script of a consuming Symantec product (such as
CommandCentral), which installs AT and configures an authentication broker.
The installation script of some Symantec products (such as NetBackup) cannot
create new authentication brokers. To set up an authentication broker for the
NetBackup product, you must use the AT installation script.
For more information on setting up an authentication hierarchy with stand-alone
brokers, see the Symantec Product Authentication and Authorization Volume III.
In the high availability mode, the authentication broker is created by using the
following process:
■
Use the installation script that is distributed by the AT product to install and
configure an authentication broker in stand-alone mode on each of the nodes
in the VCS cluster.
■
After all the nodes in the VCS cluster are set up, use the configuration script
that is distributed by the AT product to configure the authentication broker
in high availability mode.
Only the specific versions of AT 4.2 and 4.3 support the high availability
authentication broker.
For more information on setting up an authentication hierarchy with high
availability brokers, see the Symantec Product Authentication and Authorization
Volume III.
About the AT client installation
The Symantec Product Authentication Service (AT) client component can be
installed on a computer without installing the AT service component. The AT
client component is usually installed by using the AT installation script. The
installation script of other Symantec products (such as SF Manager) can also be
used to install the AT client component.
Deployment guidelines and best practices
AT and AZ administration tasks
Typically, you install the AT client component on the computers that have a
management server, an application server, and an agent or a client of other
Symantec products.
About the AZ installation
The Symantec Product Authorization Service (AZ) is dependent on the Symantec
Product Authentication Service (AT). Before the AZ is installed on a computer,
the AT client component must be installed already. The AT client component is
usually installed on the computers that have either management clients or agents.
About the AZ service installation
You can deploy the Symantec Product Authorization Service (AZ) as either a
stand-alone or as a high availability AZ service.
Symantec recommends that you install the AZ service on the same computer as
the management server that needs it. Having the AZ service and the management
server on the same computer limits the overhead of network latency that may
occur if these two applications are on separate computers.
The master copy of the authorization access control list repository is always found
on the computer where the AZ service is configured. On a computer that has the
AZ client component installed, a copy of the access control list can be kept locally.
This setup is useful in an environment that has a NetBackup media server that
communicates securely with a master server on two separate computers.
You configure a new AZ service in either stand-alone or high availability mode.
In the stand-alone mode, the AZ service is created by using one of the following
methods:
■
Use the installation script that is distributed by the AZ to install and configure
an AZ service.
■
Use the installation script of a consuming Symantec product (such as
CommandCentral Storage), which installs the AZ and configures an AZ service.
The installation script of some Symantec products (such as NetBackup) cannot
create the AZ service. To set up an AZ service for the NetBackup product, you
must use the AZ installation script.
For more information on setting up a stand-alone authorization service for access
control, see the Symantec Product Authentication and Authorization Volume III.
In the high availability mode, the AZ service is created by using the following
process:
87
88
Deployment guidelines and best practices
AT and AZ administration tasks
■
Use the installation script that is distributed by the AZ product to install and
configure an AZ service in stand-alone mode on each of the nodes in the VCS
cluster.
■
After all the nodes in the VCS cluster are set up, use the configuration script
that is distributed by the AZ product to configure the AZ service in high
availability mode.
Only specific versions of AT 4.2 and 4.3 support the high availability AZ service.
For more information on setting up a high availability authorization service for
access control, see the Symantec Product Authentication and Authorization Volume
III.
About the AZ client installation
You use the installation script that is distributed with the Symantec Product
Authorization Service (AZ) to install the AZ client component. The AZ client can
be installed without installing the AZ service component. A computer that has
the NetBackup media server requires the installation of the AZ client component.
About the AT and the AZ upgrades
All the Symantec products that are described in the use cases use the shared
installation of the Symantec Product Authentication Service (AT) and the Symantec
Product Authorization Service (AZ).
A shared installation refers to a component (such as the AT or the AZ) that is
installed on a computer that is used by all the Symantec products. For example,
NetBackup management server, SLIM management agent, and CommandCentral
management agent can use the same version of the AT on a computer.
Each Symantec product requires a specific version of the AT. Installation or
upgrade of Symantec products that require a later version of the AT would upgrade
the AT version on the computer. In this situation, you must use the latest AT
version. On the computer that has a more recent version of the AT, the installation
script skips the installation task.
The AT provides compatibility between different versions of the AT product. A
management client on a computer with AT 4.2 can communicate with its
management server on another computer that has AT 4.3. The converse
(management client with AT 4.3 and management server with AT 4.2) is also
supported.
For example, a NetBackup management server that is configured on one computer
with AT version 4.2 can operate with a NetBackup management client on another
computer that is configured with AT version 4.3. A management agent or a client
Deployment guidelines and best practices
AT and AZ administration tasks
with AT version 4.2 and a management server that has AT version 4.3 is also a
valid configuration.
The compatibility between different versions of the AT also applies to the
compatibility between different versions of the AZ.
About upgrading the AT
The upgrade of the Symantec Product Authentication Service (AT) is performed
by using the installation script that is either distributed with the AT, or distributed
with a Symantec product. You can upgrade the AT product that is deployed in
either a stand-alone or a high availability mode.
Before you upgrade the AT on a computer that has multiple Symantec products
that use the AT, Symantec recommends that you verify that the new version is
compatible with all the Symantec products. To do this upgrade, you can set up a
test environment and then verify your configuration before the new AT is deployed
to the production environment.
Each Symantec product may require a different version of the AT. Symantec
recommends that you always leave the latest version of the AT installed on the
computer. For example, a management server (such as NetBackup 6.0MP5) may
require AT 4.2, and a management agent (such as CommandCentral Storage) may
require AT 4.3. In this example, you leave AT 4.3 installed.
Note: Later versions of the AT (for example, 4.3), are always compatible with
earlier versions (such as 4.2).
Before the AT is upgraded, you must perform the following tasks:
■
Do a full backup of the AT.
See “AT and AZ backup and recovery strategy” on page 90.
■
Shut down all the Symantec applications that use the AT, so that no
authentication activities are initiated during the upgrade.
■
Verify that the AT components and all the Symantec products that use the AT
are operational, after the upgrade is complete.
Symantec recommends that the AT administrator keeps track of all the Symantec
products that use the AT service.
For more information on upgrading the stand-alone brokers in an authentication
hierarchy, see the Symantec Product Authentication and Authorization Volume
III.
For more information on upgrading the high availability brokers on a VCS cluster,
see the Symantec Product Authentication and Authorization Volume III.
89
90
Deployment guidelines and best practices
AT and AZ backup and recovery strategy
About upgrading the AZ
The Symantec Product Authorization Service (AZ) is integrated with NetBackup
and the CommandCentral storage (version 5.0) Symantec products. The AZ service
is deployed as either a stand-alone or a high availability service.
The AZ service is installed on a computer that has the NetBackup management
server and the CommandCentral storage agent installed. Before you upgrade the
AZ service, verify that the new version of the AZ is compatible with the Symantec
products.
After the upgrade of the AZ service is completed, you must verify that all the
Symantec products that use the AZ service continue to work correctly.
For more information on upgrading the stand-alone AZ service, see the Symantec
Product Authentication and Authorization Volume III.
For more information on upgrading the high availability AZ service on a VCS
cluster, see the Symantec Product Authentication and Authorization Volume III.
After you upgrade the AZ service on a computer where there is only one Symantec
product that uses the AZ service, you must verify that the AZ service and the
Symantec product work correctly.
AT and AZ backup and recovery strategy
The Symantec Product Authentication Service (AT) and the Symantec Product
Authorization Service (AZ) create operational data. The data is required to ensure
the correct operation of the AT and the AZ products. Each product generates data
during the course of its operation.
For the AT, operational data can be the credential information that is managed
by the registration authority and credential manager. For the AZ, operational data
is the access control list data repository that consists of a database where all the
permission sets are stored.
You must regularly back up the AT and the AZ operational data and product files
that are present on the computers. Each computer contains either the service
component or the client component. Symantec recommends that you include the
backup schedules for these computers as a part of the backup infrastructure for
your enterprise’s backup and recovery strategy.
On the computers that have only the client component installed, you can back up
only the binaries and libraries. You can safely keep only one backup copy of the
client component for a specified product version.
For example, if ten computers on the same platform have the same AT client
version (such as 4.2.2.34) installed, you can back up the AT client component from
Deployment guidelines and best practices
AT and AZ backup and recovery strategy
one of these computers. For either the AT or the AZ, the backup from one of the
computers is sufficient.
The backup and the recovery procedures that are used in your enterprise must
be verified through a successful restore. After the AT or the AZ data is restored,
you must verify that the Symantec products can use the recovered data. The ability
to use the recovered data from a backup is important to your backup strategy.
For more information on successfully perform a backup and a restore for the
NetBackup clients, see the Symantec Product Authentication and Authorization
Volume III.
When you implement a backup and a recovery strategy, you use the following
guidelines:
■
Install and configure the AT and the AZ on a computer.
■
Take a full backup for these products (operational data, configuration files,
product binaries, and libraries).
■
Shut down the original computer and build a new computer. The original
computer and the new computers should be on the same platform and operating
system. The new computer uses the same host name as the original.
■
Recover the AT and the AZ backups to the new computer.
■
Verify that the services that were hosted in the original computer are now
available through the new computer.
Keeping track of all computers that have the AT and the AZ components installed
is a manual process. The security administrators who are responsible for the AT
and the AZ must verify that the critical components on all the computers are
backed up.
Backup and recovery of AT data
On the computers that host the root broker and authentication brokers, Symantec
recommends that you back up the operational data and configuration files. A
backup should include the AT product binaries and libraries. On the computers
that have the AT client component, backing up the product files is sufficient.
The operational data the root broker maintains includes the registration
information, private domain repositories, and credential stores. Every
authentication broker also maintains operational data.
The operational data that the authentication broker maintains includes the private
domain repositories that are created by the Symantec application or management
servers. Symantec recommends that you regularly back up the operational data
and the AT product files on all the computers that have the AT product installed.
91
92
Deployment guidelines and best practices
Empirical use cases
For more information on successfully backing up and restoring AT data, see the
Symantec Product Authentication and Authorization Volume III.
You must track the computers in your enterprise that have the AT product
installed. The AT installation can be a root-plus-authentication broker, an
authentication broker, or a client installation. To assist with maintenance and
administration, you can keep an up-to-date layout of all the computers in your
enterprise.
See Figure 6-1 on page 61.
On the same computers, there may be other Symantec products and home grown
applications that need backup.
Backup and recovery of AZ data
On the computers that have the AZ service installed, Symantec recommends that
you back up the access control list repository. A backup should also include the
AZ product binaries and libraries. On the computers that host the AZ client
component, backing up the product files is sufficient.
For more information on successfully backing up and restoring AZ data, see the
Symantec Product Authentication and Authorization Volume III.
It is important to track the computers in your enterprise that have the AZ product
installed. To assist with maintenance and administration, you must keep an
up-to-date layout of all the computers in your enterprise.
See Figure 6-1 on page 61.
On the same computers, there may be other Symantec products and home grown
applications that need backup.
Empirical use cases
To support the guidelines and best practices, deployment scenarios are described
in the use cases that were validated in the Symantec products testing lab.
Installations and configurations of the use cases were tested and verified on both
UNIX/Linux and Windows platforms. Procedures that pertain to the Symantec
products that use the services of the AT and the AZ products are described in the
use cases chapters.
For more information on deploying Symantec products with the security feature
on UNIX/Linux, see the Symantec Product Authentication and Authorization
Volume II.
Deployment guidelines and best practices
Empirical use cases
For more information on deploying Symantec products with the security feature
on Windows, see the Symantec Product Authentication and Authorization Volume
II.
UNIX/Linux use cases
The UNIX/Linux use cases are for the enterprises that deploy the majority of their
Symantec products on UNIX/Linux platforms. The UNIX/Linux platforms include
Solaris, AIX, HP-UX, RedHat, and SuSE. The Symantec application server,
management server, management agent, and management client are validated
on one (or more) of these UNIX/Linux platforms. The procedures apply to all the
UNIX/Linux platforms, unless otherwise noted.
In an enterprise, it is typical to have Symantec products deployed on UNIX/Linux
and Windows platforms. To create a real-world environment, the UNIX/Linux use
cases also include Windows platforms. The application server, management agent
or client, and management server (such as the NetBackup media server) are added
to the UNIX/Linux deployment scenario.
Windows use cases
The Windows use cases are for the enterprises that deploy the majority of their
Symantec products on the Windows platform. The application server, management
server, and management agent or client are validated on the Windows platform.
In an enterprise, it is possible to have Symantec products deployed on Windows
and UNIX/Linux platforms. The Windows use cases also include information on
Symantec products that are deployed on UNIX/Linux platforms. The application
server, management agent or client, and management server (such as the
NetBackup Media server) are deployed on UNIX/Linux and managed by the
management servers on Windows.
Recommended approach to the use cases
After you install the Symantec Product Authentication Service (AT) and the
authentication hierarchy, you can deploy Symantec products. Typically, you
deploy Symantec products one at a time with the security enabled. After you verify
the security configuration of a Symantec product, you can add the next Symantec
product. You can independently deploy the Symantec products that are described
in the use cases.
The Symantec Product Authorization Service (AZ) is created for each Symantec
product that needs the AZ service.
93
94
Deployment guidelines and best practices
Use cases verification steps and troubleshooting tips
You can create an enterprise environment and install all the Symantec products
that are configured with the AT and the AZ services enabled.
See Figure 6-1 on page 61.
You can use the information that is presented in the use cases (UNIX/Linux and
Windows) as a guide to performing the following tasks:
■
Enable the AT and the AZ capabilities for an already-installed Symantec
product.
■
Install and configure a new Symantec product into an existing enterprise with
the AT and the AZ service enabled. Some of the Symantec products in an
existing enterprise may already have the AT and the AZ services configured.
Use cases verification steps and troubleshooting tips
The verification steps and troubleshooting tips are provided for the Symantec
products that are configured with the AT and the AZ services. The information
on authentication, verification, and troubleshooting is found in the product use
case and the appendix sections. Platform-specific information is available in the
use cases (UNIX/Linux and Windows). In a product appendix, you can also find
procedure to consolidate multiple authentication hierarchies into one hierarchy.
Index
A
access control 44
access control information data repository
definition 41
acronyms
list of 16
administration tasks
AT and AZ 79
administrator responsibilities 83
AT 79
AT installation considerations 83
AZ 81
AZ installation considerations 83
platform-specific considerations 81
application client
definition 32
application server
defined 62
deploying 62
deploying in a cluster environment 62
application service
definition 32
approach
multiproduct deployment 59
architecture
Authentication 27
Authorization 39
AT
administrator responsibilities 79
benefits of using 23
client installation 86
configuring with PBX 84
data backup overview 91
installation overview 84
overview 47
upgrade overview 89
upgrade with multiple products 89
AT and AZ
administration tasks 79
backup and recovery strategy overview 90
upgrade overview 88
AT upgrade
preparing for 89
audience for Yellow Book 10
authentication
architecture 27
components 27, 49
overview 22
authentication broker
details 30
in a heterogenous environment 64
installation overview 85
load balancing 67
placement 67
authentication client
details 32
authentication hierarchy
definition 28
authentication module
components 33
description 33
authorization
architecture 39
high availability 44
overview 22
steps 45
authorization principal
definition 43
authorization service
definition 41
AZ
administrator responsibilities 81
benefits of using 23
client installation 88
data backup overview 92
installation overview 87
upgrade overview 90
B
backup and recovery strategy overview 90
benefits
of using AT and AZ 23
96
Index
broker architecture
determining 64
C
chief security officers
what to read 10
CommandCentral
integration 54
CommandCentral Service
plug-ins 54
CommandCentral Storage
plug-ins 54
component details
Norton 360 29
components
authentication 27, 49
authorization 40
Norton 360 56
Symantec Product Authentication Service 49
D
data backup overview
AT 91
AZ 92
definitions
acronym list 16
authorization principal 43
terms used in this book 22
detail
authentication broker 30
authentication client 32
E
expiry periods 37
I
integration
CommandCentral with common service
framework products 54
NetBackup Operations Manager with common
service framework products 50
NetBackup with Authentication product 50
Storage Foundation Manager with common core
services products 53
Symantec License Inventory Manager with
common core services products 55
Veritas Backup Reporter with common core
services products 51
integration (continued)
Veritas Cluster Server Management Console with
common core services products 53
Veritas Cluster Server with common core
services products 52
Veritas Storage Foundation with common core
services products 51
isolated root broker 69
L
load balancing
authentication broker 67
local authorization service
definition 42
M
management agent
defined 63
management client
defined 63
management server
defined 63
deploying 63
deploying with AT 63
master authorization service
definition 42
multiple root brokers 70
multiproduct deployment
approach 59
N
NetBackup
Authentication 50
supported plug-ins 50
NetBackup Operations Manager
integration 50
supported plug-ins 51
Norton 360
component details 29
P
plug-in mechanisms
UNIX and Linux, overview 82
Windows, overview 82
plug-ins
supported by CommandCentral Service 54
supported by CommandCentral Storage 54
supported by NetBackup 50
Index
plug-ins (continued)
supported by NetBackup Operations Manager 51
supported by Symantec License Inventory
Manager 55
supported by Veritas Cluster Server 52
product integration
enterprise 49
R
resource management application
definition 42
root broker
consolidation 72
definition 29
in a heterogenous environment 64
installation overview 84
isolated 69
multiple 70
placement 67
root brokers consolidation 72
S
security administrators
what to read 10
Storage Foundation Manager
integration 53
plug-ins 53
Symantec License Inventory Manager
integration 55
plug-in support 55
Symantec Product Authorization Service
about 56
Symantec products
current edition 16
systems programmers
what to read 10
T
terms and definitions 22
U
use cases
overview 92
recommended approach 93
troubleshooting tips 94
UNIX/Linux 93
verification 94
Windows 93
V
validity period
certificate 36
Veritas Backup Reporter
integration 51
plug-ins
UNIX/Linux 51
Veritas Cluster Server
integration 52
plug-ins
UNIX/Linux 52
Windows 52
Veritas Cluster Server Management Console
integration 53
plug-ins 54
Veritas Storage Foundation
integration 51
Y
Yellow Book
audience 10
contrast with product guides 14
overview 13
scope 14
97