Introducing Tivoli Kernel Services Administration

Introducing Tivoli Kernel Services Administration Version 1.2

Introducing Tivoli Kernel Services Administration Version 1.2

Introducing Tivoli Kernel Services Administration Copyright Notice Copyright IBM Corporation 2000, 2001 All rights reserved. May only be used pursuant to a Tivoli Systems Software License Agreement, an IBM Software License Agreement, or Addendum for Tivoli Products to IBM Customer or License Agreement. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without prior written permission of IBM Corporation. IBM Corporation grants you limited permission to make hardcopy or other reproductions of any machine-readable documentation for your own use, provided that each such reproduction shall carry the IBM Corporation copyright notice. No other rights under copyright are granted without prior written permission of IBM Corporation. The document is not intended for production and is furnished as is without warranty of any kind. All warranties on this document are hereby disclaimed, including the warranties of merchantability and fitness for a particular purpose. U.S. Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corporation. Trademarks IBM, the IBM logo, Tivoli, the Tivoli logo, AIX, NetView, RS/6000, and TME are trademarks or registered trademarks of International Business Machines Corporation or Tivoli Systems Inc. in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Other company, product, and service names may be trademarks or service marks of others. Notices References in this publication to Tivoli Systems or IBM products, programs, or services do not imply that they will be available in all countries in which Tivoli Systems or IBM operates. Any reference to these products, programs, or services is not intended to imply that only Tivoli Systems or IBM products, programs, or services can be used. Subject to valid intellectual property or other legally protectable right of Tivoli Systems or IBM, any functionally equivalent product, program, or service can be used instead of the referenced product, program, or service. The evaluation and verification of operation in conjunction with other products, except those expressly designated by Tivoli Systems or IBM, are the responsibility of the user. Tivoli Systems or IBM may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to the IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, New York 10504-1785, U.S.A. See also Additional Notices on page ix.

Contents Preface... v Who Should Read This Guide... v Prerequisite and Related Documents... v What This Guide Contains.... v Conventions Used in This Guide... vi Accessing Publications Online... vi Ordering Publications... vii Providing Feedback about Publications... vii Contacting Customer Support... vii Additional Notices... ix OpenSSL License.... ix Original SSLeay License... ix Apache and Apache Tomcat.... x Chapter 1. Overview of Tivoli Kernel Services... 1 Tivoli Kernel Services Components and Services... 2 Administering Tivoli Kernel Services Using the Tivoli Console... 3 Administering Tivoli Kernel Services Using the Command Line Interface (CLI).... 4 Chapter 2. A New Tivoli Console... 5 Layout of the Tivoli Console... 5 Locating and Performing Tasks... 6 Embedded User Assistance... 7 Tivoli Console Guided Tour... 8 Chapter 3. Administer Security... 9 Adding Users... 10 Associating Users with Accounts... 11 Signon Methods... 12 Adding a Kernel Account to a User... 13 Adding a Native Account to a User... 14 Super Administrators... 16 Creating Roles.... 16 Assigning Roles to a User... 18 Tivoli Kernel Services Roles... 20 Introducing Tivoli Kernel Services iii

Viewing User Properties... 23 Viewing Users, Resources, and Roles.... 24 Administering the Security Registry.... 24 Copying Objects in the Security Registry.... 25 Searching for Objects within the Security Registry.... 25 Chapter 4. Administer Logging... 27 Viewing Logs... 28 Configuring Loggers, Handlers, and Masks... 29 Chapter 5. Administer Management Software... 31 Managing ORBs and ORB Sets... 31 Managing and Deploying Components.... 33 Managing the Directory.... 36 Managing Events.... 37 Managing Communications... 38 Managing Gateways... 38 Managing SNMP Device Configuration... 40 Appendix A. System-Defined Roles... 43 Appendix B. Using the NEL Service and Gateway in a Secure Environment... 47 Accessing a NEL Service Instance... 47 Accessing a Gateway Instance... 51 Accessing a Network Device (Endpoint)... 55 Example 1.... 59 Solution 1... 59 Solution 2... 59 Solution 3... 59 Example 2.... 60 Solution 1... 60 Solution 2... 60 Example 3.... 60 Index... 63 iv Version 1.2

Preface Introducing Tivoli Kernel Services Administration provides an introduction to using the Tivoli Console to accomplish Tivoli Kernel Services administrative functions. This document does not provide step-by-step instructions for performing specific tasks. For task details, see the embedded user assistance provided with the Tivoli Console. Who Should Read This Guide This document is written for the Tivoli Kernel Services administrator who is using the Tivoli Console. Prerequisite and Related Documents Tivoli Kernel Services provides the following related documentation: Planning for Tivoli Kernel Services Explains how to plan for deploying Tivoli Kernel Services in your operating environment. Installing Tivoli Kernel Services Provides information about installing, deploying, and configuring Tivoli Kernel Services. Tivoli Kernel Services Command Reference Provides information about the command line interface to Tivoli Kernel Services. Tivoli Kernel Services Command Quick Reference Card A quick reference showing a summary of the command line interface for Tivoli Kernel Services. Troubleshooting Tivoli Kernel Services Provides information about troubleshooting and maintaining the services, components, and databases that comprise Tivoli Kernel Services. Tivoli Kernel Services README Provides late-breaking information, such as problems and workarounds and patch availability. Guided Tour of the Tivoli Console An HTML-based introduction to the Tivoli Console, the graphical user interface used to administer Tivoli Kernel Services. The documentation for Tivoli Kernel Services, with the exception of the integrated online help and the product README, is located in the tivolidocs subdirectory on both the Tivoli Kernel Services Installation CD-ROM and the Bootprint CD-ROM, in both HTML and PDF formats. The product README is located in the root directory of the Installation CD-ROM. What This Guide Contains Introducing Tivoli Kernel Services Administration contains the following sections: Overview of Tivoli Kernel Services on page 1 Provides a brief overview of Tivoli Kernel Services. A New Tivoli Console on page 5 Introducing Tivoli Kernel Services v

Presents details about the Tivoli Console, a role-based graphical user interface (GUI) in which tasks are organized to support specific roles. Administer Security on page 9 Provides details about managing security, including information about adding and editing users and managing security roles. Administer Logging on page 27 Explains how to manage the messages and data created from within a component or application and sent to an output destination. Administer Management Software on page 31 Provides information about administering the Tivoli Kernel Services system, including managing ORBs and ORB sets, configuring components, and managing the database and directory. System-Defined Roles on page 43 Provides descriptions of all the system-defined roles provided with Tivoli Kernel Services. Using the NEL Service and Gateway in a Secure Environment on page 47 Explains the security considerations for accessing network devices, or endpoints. Conventions Used in This Guide The document uses several typeface conventions for special terms and actions. These conventions have the following meaning: Bold Italics Monospace Commands, keywords, authorization roles, or other information that you must use literally appear like this, in bold. Names of windows, dialogs, and other controls also appear like this, in bold. Variables and values that you must provide appear like this, in italics. Words and phrases that are emphasized also appear like this, in italics. Code examples, output, system messages, XML tags, and Java class, method, and interface names appear like this, in a monospace font. This document uses the UNIX convention for specifying environment variables and for directory notation. When using the Windows NT command line, replace $variable with %variable% for environment variables and replace each forward slash (/) with a backslash (\) in directory paths. Note: When using the bash shell on a Windows NT system, you can use the UNIX conventions. Accessing Publications Online The Tivoli Customer Support Web site (http://www.tivoli.com/support/) offers a guide to support services (the Customer Support Handbook); frequently asked questions (FAQs); and technical information, including release notes, user s guides, redbooks, and white papers. You can access Tivoli publications online at http://www.tivoli.com/support/documents/. The documentation for some products is available in PDF and HTML formats. Translated documents are also available for some products. vi Version 1.2

To access most of the documentation, you need an ID and a password. To obtain an ID for use on the support Web site, go to http://www.tivoli.com/support/getting/. Resellers should refer to http://www.tivoli.com/support/smb/index.html for more information about obtaining Tivoli technical documentation and support. Business Partners should refer to Ordering Publications for more information about obtaining Tivoli technical documentation. Ordering Publications Order Tivoli publications online at http://www.tivoli.com/support/prodman/html/pub_order.html or by calling one of the following telephone numbers: U.S. customers: (800) 879-2755 Canadian customers: (800) 426-4968 Providing Feedback about Publications We are very interested in hearing about your experience with Tivoli products and documentation, and we welcome your suggestions for improvements. If you have comments or suggestions about our products and documentation, contact us in one of the following ways: Send e-mail to pubs@tivoli.com. Fill out our customer feedback survey at http://www.tivoli.com/support/survey/. Contacting Customer Support The Tivoli Customer Support Handbook at http://www.tivoli.com/support/handbook/ provides information about all aspects of Tivoli Customer Support, including the following: Registration and eligibility. How to contact support, depending on the severity of your problem. Telephone numbers and e-mail addresses, depending on the country you are in. What information you should gather before contacting support. Introducing Tivoli Kernel Services vii

viii Version 1.2

Additional Notices OpenSSL License Copyright (c) 1998-2000 The OpenSSL Project. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgment: This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/) 4. The names OpenSSL Toolkit and OpenSSL Project must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact openssl-core@openssl.org. 5. Products derived from this software may not be called OpenSSL nor may OpenSSL appear in their names without prior written permission of the OpenSSL Project. 6. Redistributions of any form whatsoever must retain the following acknowledgment: This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/) THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT AS IS AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). This product includes software written by Tim Hudson (tjh@cryptsoft.com). Original SSLeay License Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com) All rights reserved. This package is an SSL implementation written by Eric Young (eay@cryptsoft.com). The implementation was written so as to conform with Netscape s SSL. Introducing Tivoli Kernel Services ix

This library is free for commercial and non-commercial use as long as the following conditions are adhered to. The following conditions apply to all code found in this distribution, be it the RC4, RSA, lhash, DES, etc., code; not just the SSL code. The SSL documentation included with this distribution is covered by the same copyright terms except that the holder is Tim Hudson (tjh@cryptsoft.com). Copyright remains Eric Young s, and as such any Copyright notices in the code are not to be removed. If this package is used in a product, Eric Young should be given attribution as the author of the parts of the library used. This can be in the form of a textual message at program startup or in documentation (online or textual) provided with the package. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). The word cryptographic can be left out if the routines from the library being used are not cryptographic related. 4. If you include any Windows-specific code (or a derivative thereof) from the apps directory (application code) you must include an acknowledgement: This product includes software written by Tim Hudson (tjh@cryptsoft.com) THIS SOFTWARE IS PROVIDED BY ERIC YOUNG AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The license and distribution terms for any publicly available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution license [including the GNU Public License.] Apache and Apache Tomcat This product includes software developed by The Apache Group for use in the Apache HTTP Server project (http://www.apache.org/). This product includes software developed by Greg Stein <gstein@lyra.org> for use in the mod_dav module for Apache (http://www.webdav.org/mod_dav/). x Version 1.2

This product includes software derived from software developed by Henry Spencer. This product includes software derived from the RSA Data Security, Inc. MD5 Message-Digest Algorithm. Portions of certain components of the Program are copyrighted by MERANT, 1991-1999. Introducing Tivoli Kernel Services xi

xii Version 1.2

1 Overview of Tivoli Kernel Services 1. Overview of Administration Tivoli Kernel Services provides applications with a set of components and functions for managing a wide variety of users, devices, and services. Built on common communications, messaging, data storage, and logging services, and enhanced with security and a new role-based user interface, Tivoli Kernel Services provides: Greatly extended scalability. With Tivoli Kernel Services, you can manage more devices than is possible with any other current Tivoli systems management products. A single management infrastructure around which you can grow your systems management environment. An environment optimized for management of multiple customers (rather than single enterprise). Flexible deployment solutions that can address huge enterprises with many devices to manage or small shops with fewer devices. Tivoli Kernel Services grows with your company. Tivoli s next-generation graphical user interface. A dependable, fault-tolerant environment. Continuous availability through modular updates that do not require taking the entire system down to make upgrades. Integrated services for systems, applications, and network management Much like an operating system, Tivoli Kernel Services provides the following major functions of a distributed system (as shown in Figure 1 on page 2): Base services, such as communications, data storage, and security The Tivoli Console, a role-based, intuitive graphical user interface Device management, such as SNMP devices and storage devices Introducing Tivoli Kernel Services 1

Tivoli Console Applications Device Management User Hardware Tivoli Kernel Services Figure 1. Distributed system environment Tivoli Kernel Services Components and Services Tivoli Kernel Services is composed of the following types of components and services: Core services The core services of Tivoli Kernel Services provide basic capabilities that are fundamental to the operation of the distributed system or that provide services that should be used consistently across the system by all other components. This group of components includes the ORB (the central routing and and control component for Tivoli Kernel Services) and services for validating a user s identity and access rights, sharing and storing data, and delivering messages throughout the distributed system. Component level components The component level components of Tivoli Kernel Services provide a means by which the pieces of applications and services can be managed across the Tivoli Kernel Services system. This group of components includes services for deploying components for the most efficient operation of Tivoli Kernel Services, installing the software, and deploying the software to the correct locations. Resource level components The resource level components of Tivoli Kernel Services are those that provide direct access to resources in the distributed system. This group of components includes the gateways, the locator service that determines which gateway to use for a particular resource, and the protocol stacks and metadata used to communicate with the resources. Application level components In addition to the base functions provided by Tivoli Kernel Services, a few components are provided that can be considered applications in their own right, or at least parts of an application rather than part of Tivoli Kernel Services. This group of components includes the Tivoli Console and the command line interface (CLI) that allow for the operation of Tivoli Kernel Services itself. 2 Version 1.2

Administering Tivoli Kernel Services Using the Tivoli Console The Tivoli Console is the graphical user interface (GUI) for Tivoli Kernel Services Administration. The Tivoli Console is the primary interface used to perform user and systems management tasks for Tivoli Kernel Services and the applications running on Tivoli Kernel Services. The Tivoli Console provides a single interface in which to perform system administration tasks, regardless of applications or components installed. For details describing the Tivoli Console and its features, see A New Tivoli Console on page 5. 1. Overview of Administration Using Tivoli Kernel Services Administration, you can manage the following components and services of Tivoli Kernel Services: Data Connections Provide uniform access to a wide range of data stores. Directory Deployment Gateway Maps objects to their location in the system. It also stores some of the attributes for those objects, providing a system-wide, distributed, hierarchical data store. Makes components and services available throughout the distributed system. Manages the communications and connections between a group of endpoints and Tivoli Kernel Services. The gateway converts server protocols to endpoint protocols, and vice versa. Logging Manages the logging of component messages and trace data within the distributed system. Messaging Service Provides the backbone for messages between components and applications. These messages include things like system events and notification of configuration changes. Network Endpoint Locator Service Checks security access to a resource and establishes the best gateway possible for an application to pass commands and data to and from an endpoint. Security Provides authorization and authentication to a Tivoli Kernel Services installation. SNMP Device Configuration Manages SNMP configuration information for IP resources in a Tivoli Kernel Services installation. Tivoli Kernel Services Administration is organized into the three task groups, which cover overall system administration, system security administration, and system logging administration. See the following chapters for more details describing the tasks provided in each of the task groups: Administer Security on page 9 Administer Logging on page 27 Administer Management Software on page 31 Introducing Tivoli Kernel Services 3

Administering Tivoli Kernel Services Using the Command Line Interface (CLI) Tivoli Kernel Services also provides a CLI that allows you to perform system operations from a command line instead of using the Tivoli Console. The command line interface can be run without the GUI running or in a separate window while the GUI is also running. The CLI provides complete control of the managed environment and can easily be used by shell scripts to perform complex sequences of commands. This document focuses on administering Tivoli Kernel Services using the Tivoli Console. For details about the CLI and the syntax of commands, see the Tivoli Kernel Services Command Reference. 4 Version 1.2

2 A New Tivoli Console The Tivoli Console is the role-based graphical user interface (GUI) for performing tasks using Tivoli management software. It presents only the tasks that are relevant to your particular role, and enables you to perform tasks without having to understand the details of the underlying software. The Tivoli Console also provides consistent controls and behaviors across tasks and includes embedded user assistance. A role is a job function, such as software distributor, that identifies the tasks that you can perform and the resources to which you have access. You might be assigned one or more roles depending on the duties that you perform. A task represents one or more Tivoli software components that run as an independent entity to accomplish your work. 2. A New Tivoli Console Layout of the Tivoli Console Figure 2 shows an example of the Tivoli Console in Tivoli Kernel Services. Banner area Tivoli Assistant Portfolio Work area Status bar Task button Taskbar Figure 2. Key components of the Tivoli Console The key components of the Tivoli Console include the following: Banner area The area between the title bar and the menu bar that can serve as a Web browser. This optional area can be customized by a system administrator to include relevant Introducing Tivoli Kernel Services 5

information for a particular organization. For example, an organization might want to include the role description for a particular user, the company logo, or links to Internet and intranet sites in this area. Portfolio A container for the tasks that are relevant for a given role. When open, the portfolio displays within the Tivoli Console to the left of the work area. When closed, the portfolio is indicated by the portfolio handle. Status bar A bar located below the work area that is divided into two sections. The section on the left contains information about the object over which the mouse pointer is hovering. The section on the right contains a progress indicator or status information about the task that is running. To lengthen one section of the status bar and shorten the other, drag the sectional divider to the left or to the right. Taskbar A bar located at the bottom of the window that contains a button, called a task button, for each task that is running. When you right-click the background of the taskbar, the context menu for the taskbar opens. Task button A button on the taskbar that represents a task that is running. A task might have multiple windows associated with it. When you click a task button, the window associated with the task opens in the work area. When you right-click a task button, the context menu for that task opens. Each task button also includes a small icon that conveys the current status of the task. Work area The area in which the GUI for a task is displayed. This area does not include the portfolio and the Tivoli Assistant. Tivoli Assistant The place to go for answers to your questions. The Tivoli Assistant is opened by the question mark located on the far right of the toolbar or in the upper right of any detached window. When it is open, the Tivoli Assistant displays within the Tivoli Console to the right of the work area. It provides contextual help information for the task that you are performing, as well as reference information. Locating and Performing Tasks Your tasks are arranged into task groups, which organize your tasks into logical categories. These task groups are displayed in the portfolio of the Tivoli Console. To view the list of tasks under a particular task group, click the task group to expand it. When the task group is expanded, click the task that you want to start within that group. Clicking a task either opens a dialog that guides you through an activity or presents you with a list of resources on which you can perform actions. When presented with a list of resources, you can right-click a resource to open a context menu. The context menu displays only those actions that are relevant for that resource. The menu and the toolbar are task-specific and contain the available menus and tools for the task that is active in the work area. However, several menu items and tools remain the same for all tasks. 6 Version 1.2

In addition to the items listed here, some of the applications using the Tivoli Console make use of a field description area, which displays descriptive text and instructions within the interface and is automatically updated as a user moves from field to field. However, this area is not being used by Tivoli Kernel Services in this release. Embedded User Assistance The Tivoli Console offers an important new feature, embedded user assistance through the use of the Tivoli Assistant. The Tivoli Assistant can be opened by: Clicking the question mark located on the far right of the toolbar of the Tivoli Console or in the upper right of a detached window. Selecting Open Tivoli Assistant from the Help menu item. Pressing F1. The Tivoli Assistant replaces the User s Guide that accompanies most software products. Information about Tivoli Kernel Services, the Tivoli Console, and the Tivoli Assistant itself is all included in the Tivoli Assistant. When you install an application, application information is seamlessly integrated into the Tivoli Assistant as well. 2. A New Tivoli Console The information in the Tivoli Assistant is organized by topic. The topic relevant to the task that you are performing is displayed to the right of the work area when you initially open the Tivoli Assistant, as illustrated in Figure 3. Tivoli Assistant toolbar Tivoli Assistant Figure 3. Tivoli Console with Tivoli Assistant open You can search the information available, review overview information, or view the table of contents and index to locate the information you want. Once you ve located the information, you can resize the Tivoli Assistant window for easier viewing, detach the window from the work area entirely, or print the information. These tasks can be performed by using the Tivoli Assistant toolbar, shown in Figure 4 on page 8. Introducing Tivoli Kernel Services 7

Message Index Topic Index Table of Contents Previous/Next Search Print Detach/Reattach Snap Figure 4. Tivoli Assistant toolbar From the Tivoli Assistant toolbar, you can access a Message Index that contains pointers to message help topics for all installed applications. It is sorted alphanumerically by message identifier and has a search function. Generally, these messages are displayed in pop-up dialogs that require user action as shown in Figure 5. You can get help information for message dialogs just like any other dialog by clicking the question mark in the upper right of the dialog box. Figure 5. Message window Tivoli Console Guided Tour Before you begin using the Tivoli Console, you might be interested in taking a Web-based guided tour to reinforce the concepts presented in this chapter. The guided tour is included on the installation CD-ROM in the tivolidocs subdirectory. You can also download the guided tour from the following Web site: http://www.tivoli.com/products/demos 8 Version 1.2

3 Administer Security The Administer Security task group includes tasks to administer system security. These tasks provide authentication and authorization services for components, applications, services, and users. Figure 6. Administer Security task group The Security subsystem is composed of the Authentication Service, which validates a user s identity, and the Authorization Service, which determines whether a user has the right to execute a specific action or access a specific resource. These two services are run on objects contained within the security registry. The security registry is a data management server that provides a consistent representation and repository of information related to users and access control of resources. For more information on the security registry, its organization, and planning aspects of security, see Planning for Tivoli Kernel Services. 3. Administer Security The first step in securing the distributed system is to create users. A user is a person who will use Tivoli Kernel Services to perform tasks. This user, in order to access the system, needs one or more accounts. These accounts contain the user s credentials, such as a user name and password. When a user signs on to the system, the Authentication Service checks that the user name and password entered match the information contained within that user s account. (See Associating Users with Accounts on page 11 for more information on accounts.) Once the user has access to the system, the tasks that he can perform will be determined by the roles he is assigned. A role is a job function that defines the access conditions that a user has on a set of resources. Introducing Tivoli Kernel Services 9

Adding Users To create a new user within Tivoli Kernel Services, select the Add User task in the Administer Security task group in the portfolio. From the User window, as shown in Figure 7, you can create users. Figure 7. User window Note: When creating a new user using the Add User task, a Directory Chooser window is displayed that allows you to choose the security registry directory in which the new user will be located. Alternatively, you can select the directory in the security registry where you want the user to be located and then click the Add User icon ( create the new user in the selected directory. )to 10 Version 1.2

Once the user is created, the User Properties window is displayed. From this window, shown in Figure 8, you can view and edit user properties and create, edit, or delete a user s accounts. See the Tivoli Assistant online help topics for step-by-step instructions on how to accomplish these tasks. Figure 8. User Properties window Associating Users with Accounts After a user has been created in Tivoli Kernel Services, you can associate an account, or accounts, with that user. A user requires an account to enter the system. There are two main types of accounts in Tivoli Kernel Services: 3. Administer Security Kernel accounts This type of account is defined within the Tivoli Kernel Services security registry and requires a user name and password to sign on with. The account type is named Kernel account. Native accounts This type of account is defined on a native operating system, such as the Windows or UNIX platforms, and requires a user name, host name, and password to sign on with. Native account types include the following: v v NT account Unix account When creating a native account, you must ensure the account name is unique within the installation. If two accounts are created with the same name, both accounts will be invalidated. Note: The following account types exist in Tivoli Kernel Services, but are not currently used: Introducing Tivoli Kernel Services 11

v v Web account DB2 account A user can have multiple accounts and multiple types of accounts. For example, a user can sign on using an NT account, Unix account, or Kernel account. If you want to sign on to the Tivoli Console using an account that differs from what was originally used to sign on, close and restart the Tivoli Console, and then enter the user name and password in the signon window. Signon Methods The following signon methods can be used to sign on to the Tivoli Kernel Services command line interface or GUI. When associating accounts with a user, consider the signon method they will be using to perform their work. Kernel account signon method The Kernel account signon method allows you to sign on using both the GUI and command line interface with a Kernel account. This method requires users to enter the u option with the wcmd command. Kernel account passwords are stored in the security registry. Native local signon method The native local signon method can perform native local authentication by way of the command line interface only. This type of signon eliminates the need to enter the u option with the wcmd command and enables batch processing of the commands. Native remote signon method The native remote signon method can be used for signing on using both the GUI and command line interface by entering user@hostname for the user name. Notes: 1. The native remote signon method requires that the RemoteAuthenticationService be deployed to the ORB on the machine where the users you want to remotely authenticate are defined. If you want to support Windows NT domains and native remote authentication, there must not be any local account name conflicts with the domain on this machine. (For more information on deploying components, see Managing and Deploying Components on page 33). 2. In a Windows environment, the ORB should be started from the Control Panel to use the native remote signon method on that ORB. If the command line is used instead, the user starting the ORB must have act as part of the operating system user right assigned to use the native remote signon method. To set the user rights on Windows 2000 systems: a. From the Start menu, select Settings Control Panel Administrative Tools Local Security Policy Local Policies User Rights Assignment. b. Right-click the Act as part of the operating system policy and select Security. c. Add the user. To set the user rights on Windows NT systems: a. From the Start menu, select Programs Administrative Tools User Manager. 12 Version 1.2

b. From the Policies menu, select User Rights. c. Select the Show Advanced User Rights check box. d. From the Right drop-down list, select Act as part of the operating system. e. In the Grant To list, select the user name or group and click OK. Adding a Kernel Account to a User The following steps demonstrate how to add a Kernel account to a user. 1. From the portfolio, select Administer Security View Users, Resources, Roles. 2. In the Security Registry window, locate the person object that you want to add the account to. 3. Double-click the person. 4. In the User Properties window (next to the Accounts table), click New. 5. Select Kernel account and click OK. 3. Administer Security 6. In the Account window: a. In the Full name field, type the user name that this person will use to sign on to the system. For example, eap. b. Leave the Computer hostname field empty. Host names are not used for Kernel accounts. c. In the Password field, type a password that this person will use to sign on to the system. d. Click OK to create the account. Introducing Tivoli Kernel Services 13

Adding a Native Account to a User The following steps demonstrate how to add a new native account to a user. 1. From the portfolio, select Administer Security View Users, Resources, Roles. 2. In the Security Registry window, locate the person object that you want to add the account to. 3. Double-click the person. 4. In the User Properties window (next to the Accounts table), click New. 5. Select either NT account or Unix account corresponding to the native operating system type and click OK. 6. In the Account window: a. In the Full name field, type the user name that the user signs on with on the native operating system. For example, epresley. 14 Version 1.2

b. In the Computer hostname field, type the fully qualified host name of the machine the user signs on with. For example, machine1.dev.tivoli.com. c. Leave the Password field empty. The native operating system password is used to authenticate the user. Not entering a password prevents you from having to keep the password that is stored in the security registry in synch with the operating system password. d. Click OK to create the account. To test the new account, the user can enter wcmd list from a command prompt. If the account was created successfully, the command will not require the u option to specify a user name. To use this same account to sign on to the Tivoli Console, ensure that the RemoteAuthenticationService has been deployed to the ORB where the users you want to remotely authenticate are defined. In the signon window, the user must enter their user name in the format user@hostname as shown in Figure 9 and enter their operating system password for the password. 3. Administer Security Figure 9. Native remote signon method Introducing Tivoli Kernel Services 15

Super Administrators Tivoli Kernel Services provides a special user and account called a super administrator. This super administrator has access to the entire Tivoli Kernel Services installation including the security registry, and is automatically assigned to all roles, predefined or newly created, in the system. The user is located in the security/superadministrators/ directory of the security registry, and the user name is John D. Super. By default this user is associated with a Kernel account named superadmin. To create additional super administrators, you should copy this user, rename it making sure to keep it within the SuperAdministrators directory, and assign it a new signon account with an updated user ID and password. For step-by-step instructions, see Copying Objects in the Security Registry on page 25. Any additional super administrators created in the SuperAdministrators directory are also automatically assigned to all roles, predefined or newly created, in the system. Creating Roles Tivoli Kernel Services uses the concept of role-based access control to manage system security. Rather than specifying security permissions for individual users or groups, you create capabilities that a user assigned to the role can perform on a set of targets. Capabilities are a set of access conditions, which are permissions to perform certain actions, on a group of resources (targets). A capability can group together several conditions such as READ, WRITE, and DELETE. Consider these guidelines when you create your own roles: The role name should reflect job function. A role corresponds to a job function and has a name that should describe that job function. It seems intuitive that a person s (or an application s) access to resources should be based on that person s (or that application s) function or functions within the organization. A user can have zero, one, or more than one role. Each role contains a set of capabilities. Each capability has an identifier that is unique within the role. Each capability confers a set of access conditions to a set of resources. A role is a combination of rights plus conditions. Each access condition represents an action that a user is allowed to perform on a resource. Each type of resource may support a different set of actions, so the set of valid rights will depend on the type of resource. Users are assigned dynamically or statically to roles. After you create a user and determine which roles are appropriate for that user, you can statically assign the roles to the user or create filters to dynamically assign the roles to users. Resources are assigned dynamically or statically to capabilities. After you have created a capability and determine which resources are appropriate for that capability, you can statically assign resources to the capability or create filters to dynamically assign resources to the capability. To create a new role within Tivoli Kernel Services, select the Add Role task in the Administer Security task group in the portfolio. From the Role window, as shown in Figure 10 on page 17, you can create and edit roles. Note: When creating a new role using the Add Role task, a Directory Chooser window is displayed that allows you to choose the security registry directory in which the new role will be located. Alternatively, you can select the directory in the security registry 16 Version 1.2

where you want the role to be located and then click the Add Role icon ( create the new role in the selected directory. )to Figure 10. Role window 3. Administer Security Introducing Tivoli Kernel Services 17

Once the role is created, the Role Properties window is displayed. From this window, shown in Figure 11, you can view and edit role properties and create, edit, or delete a role s capabilities and access conditions. See the Tivoli Assistant online help topics for step-by-step instructions on how to accomplish these tasks. Figure 11. Role Properties window Assigning Roles to a User Users can be associated with roles either statically or dynamically. The following steps demonstrate how to statically associate a user with a role. 1. From the portfolio, select Administer Security View Users, Resources, Roles. 2. In the Security Registry window, double-click a user. The User Properties window is displayed. 3. In the User Properties window, click Edit. 18 Version 1.2

4. In the User window, select Statically Assigned Roles. The roles that are currently statically assigned to the user are displayed. 5. Click New to display any additional roles that are available to assign to the user. 6. Select the desired roles and click OK. 7. In the User window, click OK to save the changes. Users can be associated with a role dynamically by way of a role member filter. To add a member filter to a role: 1. From the portfolio, select Administer Security View Users, Resources, Roles. 2. In the Security Registry window, double-click the role. 3. In the Role Properties window, click Edit. 4. In the Role window, select Member Filter. 5. Select a property from the Property drop-down list. For example, Department. 3. Administer Security Introducing Tivoli Kernel Services 19

6. Type a value for the property in the text field. For example, 123. 7. Click OK to save the member filter. In this example, all users added to the system (in addition to any existing users) with the attribute Department=123, will be dynamically assigned to this role. After you have set up the users, roles, accounts, and capabilities in the system, the Authorization Service uses that information when a user tries to perform an action on a resource, and it checks that the user has the proper role, capability, and access conditions to perform the specified actions on or against the resource. Once the user has been authenticated and authorized to perform actions, it is called a principal. Tivoli Kernel Services Roles Two types of roles exist within Tivoli Kernel Services: Tivoli Kernel Services roles, which control the actions a user can perform when using the portfolio tasks. These roles are located in the security/roles/, system/services/roles/, or system/roles/ directories in the security registry. Tivoli Kernel Services Administration roles, which indicate which portfolio tasks are available to a user assigned to that role. These roles are located in the PS/PSServer/Roles/MACImpl/5.2.0/ directory in the security registry. You must assign both types of roles to a user so that users have access to the appropriate portfolio tasks and can perform the proper actions with these portfolio tasks. For a full list of system-defined roles available within Tivoli Kernel Services, see System-Defined Roles on page 43. Table 1, Table 2 on page 21, Table 3 on page 21, and Table 4 on page 22 show the location within the security registry and a description for the Tivoli Kernel Services and Tivoli Kernel Services Administration roles needed to give a user access to portfolio tasks. Table 1. Roles located in the PS/PSServer/Roles/ directory of the security registry PS/PSServer/Roles/ MACImpl/5.2.0/MACInstallUser Role that allows users to perform all system administration functions. Provides access to all tasks within all task groups. 20 Version 1.2

Table 1. Roles located in the PS/PSServer/Roles/ directory of the security registry (continued) PS/PSServer/Roles/ MACImpl/5.2.0/MACLimitedSecurityUser Role that allows users to view security information for the user and account the user signed on to the console with, and search for security resources. Provides access to View User Properties and Search Security tasks within the Administer Security task group. MACImpl/5.2.0/MACLoggingUser Role that allows users to perform logging administration functions. Provides access to all tasks within the Administer Logging task group. MACImpl/5.2.0/MACOrbUser Role that allows users to perform ORB, ORB set, component, and data connection administration functions. Provides access to Manage ORBs, View Data Connections, and View SNMP Configuration tasks. MACImpl/5.2.0/MACResourceUser Role that allows users to perform directory administration functions. Provides access to the View Directory task. MACImpl/5.2.0/MACSecurityUser Role that allows users to perform security administration functions. Provides access to all tasks within the Administer Security task group. MACImpl/5.2.0/MACSeniorUser Role that allows users to perform all system administration functions. Provides access to all tasks within all task groups. 3. Administer Security Table 2. Roles located in the security/roles/ directory of the security registry security/roles/ Administrator Role that provides full access to all objects in the security registry. User Administrator Role that grants authority to work with accounts and persons only, does not have authority to work with roles. Can add, delete, and edit accounts and persons anywhere in the security registry with the exception of the security directory. Does not have the authority to use the security CLI commands. Table 3. Roles located in the system/services/roles/ directory of the security registry system/services/roles/ DirectoryService Role that grants full access to the Directory Service. Do not delete this role as it is used by internal services. Introducing Tivoli Kernel Services 21

Table 4. Roles located in the system/roles/ directory of the security registry system/roles/ Logging Administrator System Administrator Role that grants authority to manage loggers, handlers, and filters (masks). Role that provides end-user access to all Tivoli Kernel Services except for the security registry. Provides access to all CLI commands except for security commands. Table 5 shows the combination of Tivoli Kernel Services Administration roles and Tivoli Kernel Services roles needed to give a user access to portfolio tasks. For example, if you want to give someone the authority to work with accounts and persons in the security registry, but want to limit their ability to edit or assign roles, then you could assign them the MACLimitedSecurityUser role and the User Administrator role. The first role grants a user access to a limited set of portfolio tasks, and the second role gives that user the permissions necessary to work with account and persons in the security registry. Table 5. Roles and access to portfolio tasks Tivoli Kernel Services Tivoli Kernel Services Role Administration Role MACSeniorUser System Administrator and Administrator MACInstallUser MACLoggingUser MACOrbUser MACResourceUser System Administrator and Administrator Logging Administrator System Administrator DirectoryService Access Available All tasks are available Grants full authority to all of Tivoli Kernel Services and the security registry All tasks are available Grants full authority to all of Tivoli Kernel Services and the security registry Access to all tasks within the Administer Logging task group Grants authority to manage loggers, handlers, filters (masks) Access to Manage ORBs, View Data Connections, and View SNMP Configuration tasks Can perform ORB, ORB set, component, and data connection administration functions Grants full access to Tivoli Kernel Services except for the security registry Access to the View Directory task Grants full access to the Directory Service 22 Version 1.2

Table 5. Roles and access to portfolio tasks (continued) Tivoli Kernel Services Administration Role MACLimitedSecurityUser MACSecurityUser Tivoli Kernel Services Role User Administrator Administrator Access Available Access to View User Properties and Search Security tasks Grants authority to work with accounts and persons only Can add, delete, and edit accounts and persons anywhere in the security registry with the exception of the security directory Access to all tasks within the Administer Security task group Grants full access to all objects in the security registry Viewing User Properties To display account and user information for the account and user you signed on as, select the View User Properties task in the Administer Security task group in the portfolio. From this window, shown in Figure 12, you can view and update user and account information. See the Tivoli Assistant online help topics for step-by-step instructions on how to accomplish these tasks. 3. Administer Security Figure 12. View User Properties window Introducing Tivoli Kernel Services 23

Viewing Users, Resources, and Roles To display the main navigation window for the security registry, select the View Users, Resources, Roles task in the Administer Security task group in the portfolio. From this window, as shown in Figure 13, you can move or rename objects, and create or edit accounts, users, roles, principals, organizational units, and capabilities. See the Tivoli Assistant online help topics for step-by-step instructions on how to accomplish these tasks. Figure 13. Security Registry window Administering the Security Registry Once users, accounts, and roles have been created, they can be organized into logical parts. Within the security registry, you can create organizational units, which are containers for all security objects. These containers can be used to organize security objects according to departments or business units within an organization, or any other logical division. After you define organizational units, you can associate those security objects with each other. You can manually form and maintain these associations, or you can create filters to dynamically create those associations. These filters, or queries, associate users with roles and accounts, or capabilities and access conditions to targets, and so on. Queries are created using object class types, which are data entries or objects within the security registry. Queries using object class types can be very general and high-level, such as filtering for all users or roles, as well as more detailed, such as filtering based on a user s last name or telephone number. As the data changes, associations between objects change. For more information on the security registry, its organization, and planning aspects of security, see Planning for Tivoli Kernel Services. 24 Version 1.2

Copying Objects in the Security Registry There are several reasons you might want to copy objects in the security registry. For example, you might want to create a role that is only slightly different from another role. You can clone, or copy and rename, the role as follows: 1. From the portfolio, select Administer Security View Users, Resources, Roles. 2. In the Security Registry window, locate the role you want to copy. 3. Right-click the role and select Copy from the context menu. 4. Select the directory where you want the new role to be located. 5. From the Edit menu, select Paste. 6. Right-click the new role and select Rename from the context menu. 7. Enter a meaningful name for the new role. The person objects in the SuperAdministrators folder are treated specially. As new roles get added to the system, any person object in the SuperAdministrators folder will be assigned the new role. The person will accumulate all roles added after the person was added. For this reason if you want to create persons that have all system roles, you must copy and rename the person. For example: 1. From the portfolio, select Administer Security View Users, Resources, Roles. 2. In the Security Registry window, open the security SuperAdministrators folder. 3. Right-click the John D. Super person and select Copy from the context menu. 4. Select the SuperAdministrators folder. 5. From the Edit menu, select Paste to make a copy of the person object. By default the new name will be John D. Super1. 6. Double-click John D. Super1 and edit the user information to correctly identify the person. 7. Assign the user a new signon account with an updated user name and password. Searching for Objects within the Security Registry To create a filtering query that will search through the security registry for matching objects, select the Search Security task in the Administer Security task group in the portfolio. From this window, shown in Figure 14 on page 26, you can search for users, roles, accounts, capabilities, and targets within the security registry. See the Tivoli Assistant online help topics for step-by-step instructions on how to accomplish these tasks. 3. Administer Security Introducing Tivoli Kernel Services 25

Figure 14. Searching within the security registry 26 Version 1.2

4 Administer Logging 4. Administer Logging The Administer Logging task group displays system logging administrative tasks. Logging refers to the messages and data created from within a component or application and sent to an output destination such as a file, a database, a console screen, and so on. Tivoli Kernel Services supports two types of logging: Local, which is logging within a single environment Distributed, which is logging across multiple environments Figure 15. Administer Logging task group The Logging subsystem of Tivoli Kernel Services uses several objects to record system events. These objects include loggers, handlers, and filters (also referred to as masks). Loggers are software objects that record events that occur while a component is operating. The Logging subsystem supports two types of loggers: message loggers and trace loggers. Message loggers are used to record textual messages from a Tivoli Kernel Services component. These messages are internationalized for individual locales. The message types associated with a message logger, which are all enabled by default, include: Informational messages Indicate conditions that are worthy of noting but that do not require a user to take any precautions or perform an action. Warning messages Inform a user that a condition has been detected that they should be aware of, but it does not necessarily require them to take action. For example, this message type might indicate some aspect of a program did not perform as intended, but the defaults were applied so the program could continue to operate, but the output should be examined for validity. Introducing Tivoli Kernel Services 27

Viewing Logs Error messages Inform a user of serious events, such as a component failed to write a database entry. Fatal messages Indicate the most serious errors, such as errors that require an ORB to be restarted or that a component has shut down because attempts to recover from an error have failed. Trace loggers are used to capture information about the operating environment when component code fails to operate as intended. Tivoli Customer Support personnel use the information captured by trace loggers to trace a problem to its source or to determine why an error occurred. Generally, this information is not enabled by default. Because trace messages are intended for support personnel, they are generally written to a file that can be viewed during a postmortem examination. Handlers are software objects that direct messages recorded by a logger to a destination. Messages can be directed to a file, a database, a console screen, or to other destinations. You associate handlers with loggers to send information recorded by a logger to the desired destination. Filters can be applied to loggers, to handlers, or to both loggers and handlers. When applied to a logger, the filter determines which types of message and trace records the logger processes. When applied to a handler, the filter determines which types of message and trace records the handler sends to a destination. Filters work by comparing a log record type against a set of criteria, or a query, contained within the filter. Having numerous loggers, handlers, and filters can cause you to have an undue amount of logging administration to perform. To reduce the administration burden, you can create groups. A group contains loggers, handlers, or masks that have common properties. By creating groups, a newly created logger, handler, or mask with unset properties can inherit values for those properties from the group. If a logger, handler, or mask belongs to a group and its properties are updated, all other loggers, handlers, or masks in that group will also have that property updated. This eliminates the need for manually updating individual logger, handler, and mask properties. To view all system logs, select the View All Logs task in the Administer Logging task group in the portfolio. To view detailed information about translatable system logs, select the View Translated Logs task in the Administer Logging task group in the portfolio. The View Translated Logs window is the same as the View All Logs window. From the View All Logs window, as shown in Figure 16 on page 29, you can select a particular log entry and view its contents in more detail. See the Tivoli Assistant online help topics for step-by-step instructions on how to accomplish these tasks. 28 Version 1.2

4. Administer Logging Figure 16. View All Logs window Configuring Loggers, Handlers, and Masks To view, configure, and access system loggers, handlers, and masks within a Tivoli Kernel Services installation, select the Configure Logging task in the Administer Logging task group in the portfolio. From the Configure Logging window, as shown in Figure 17 on page 30, you can manage loggers, handlers, and masks, such as editing their properties, listing their associated logging objects, or deleting them. See the Tivoli Assistant online help topics for step-by-step instructions on how to accomplish these tasks. Before performing these tasks, see Troubleshooting Tivoli Kernel Services for information on configuring and setting up logging, including configuring database handlers. Introducing Tivoli Kernel Services 29

Figure 17. Configure Logging window 30 Version 1.2

5 Administer Management Software In a large-scale distributed system like Tivoli Kernel Services, applications require preference and configuration data to adapt to different environments. Applications also need a way to store, retrieve, and modify this data, regardless of where the data is located. This is accomplished by configuring and managing system objects and system communications. The Administer Management Software task group provides these overall system administrative tasks, including tasks for managing and deploying components, in addition to tasks for managing the directory, events, communications, and ORBs and ORB sets. 5. Administer Management Software Figure 18. Administer Management Software task group Managing ORBs and ORB Sets A Tivoli Kernel Services ORB (object request broker) provides remote access and communications to system components, services, and managed objects. ORBs also handle an object throughout its lifecycle, routing objects throughout the distributed system. Each ORB provides communication mechanisms, which are used by other system components to communicate. When an ORB runs, various services and components communicate remotely, either to or from the ORB. To handle this remote access, the ORB generates proxies, special objects that serve as stand-ins for remote objects. In Tivoli Kernel Services, there is a logical grouping of ORBs that contain components that together perform a particular function (security, for example). These logical groups are called domains and they are implemented using ORB sets. Grouping ORBs into ORB sets reduces the configuration burden by associating specific configuration data to a resource with a group of ORBs that is represented by an ORB set. As components are maintained or Introducing Tivoli Kernel Services 31

upgraded, or as machines and ORBs are added to the distributed system, the ORBs automatically pick up the configuration information of the ORB set in which you place the ORBs. One default ORB set, called.allorbs, was created for you when Tivoli Kernel Services was installed. This ORB set allows the user to set configuration data that will be read by every ORB in the system. Another default ORB set, which includes the default read-only configuration data for all ORBs and components within Tivoli Kernel Services, is.orbdefaults. You can create other ORB sets to help you manage Tivoli Kernel Services applications. The ORB sets you create provide the specific configuration data and override the default values provided by.allorbs and.orbdefaults. Additionally, any configuration data you set for the individual ORBs within that ORB set override the values provided for the ORB set to which it belongs. This reverse kind of inheritance is called coalescing. The order for applying configuration data is as follows: 1. ORB-specific configuration data 2. ORB set configuration data 3..allorbs configuration data 4..orbdefaults configuration data Additionally, the following ORB sets are created automatically for you when you deploy Tivoli Kernel Services: DefaultRegion, which nests all ORBs that are part of the default region, currently defined as all the ORBs in your installation, as follows: v orbsindefaultregion, which is all the ORBs that are part of the default region, which nests the following ORB sets: endpointsindefaultregion, which is an ORB set of all the endpoint servers managed by this Tivoli Kernel Services installation. consolesindefaultregion, which is an ORB set of all the machines where the Tivoli Console has been enabled to run in this Tivoli Kernel Services installation. serversindefaultregion, which is an ORB set of all servers in this Tivoli Kernel Services installation that have been dedicated to run Tivoli Kernel Services code. Tivoli Kernel Servers servers can be defined as gateways or general purpose servers. installationdepotorbset, which is an ORB set of one ORB, the installation depot, from which all Tivoli Kernel Services components are served. default_nat, which is an ORB set that is used to store configuration for the default NAT (network address translation) in an installation. Do not modify this ORB set or deploy components to this ORB set. To view, configure, and access the ORBs, ORB sets, and deployed components within a Tivoli Kernel Services installation, select the Manage ORBs task in the Administer Management Software task group in the portfolio. The Manage ORBs window, as shown in Figure 19 on page 33, displays the ORBs, ORB sets, and deployed components (including the default ORB sets previously discussed) within a tree structure. 32 Version 1.2

5. Administer Management Software Figure 19. Manage ORBs window From this window, you can navigate through the ORBs, ORB sets, and components, rename objects, upgrade components, and create new ORB sets. See the Tivoli Assistant online help topics for step-by-step instructions on how to accomplish these tasks. Managing and Deploying Components Everything in Tivoli Kernel Services is considered a component, which is a piece of code or data that can be installed, run, and upgraded. A component can be a service or it can be a set of code used to implement function directly used by another part of the distributed system. It can also be used by other components to form a fully functioning distributed system. All installation and maintenance of the system is handled in terms of components. The component depot is the repository of all components that can be deployed throughout the distributed system. To view detailed information about the components that are installed on the component depot, select the View Component Depot task in the Administer Management Software task group in the portfolio. From the View Component Depot window, shown in Figure 20 on page 34, you can configure and remove components. See the Tivoli Assistant online help topics for step-by-step instructions on how to accomplish these tasks. Introducing Tivoli Kernel Services 33

Figure 20. View Component Depot window To view detailed information about namespaces, ORB sets, and components deployed to ORB sets, select the Deploy to ORB Sets task in the Administer Management Software task group in the portfolio. From the Deploy to ORB Sets window, shown in Figure 21 on page 35, you can deploy components to existing ORB sets. You can also manage namespaces and ORB sets and perform various component-related tasks such as configuring, upgrading, removing, and rolling back components. See the Tivoli Assistant online help topics for step-by-step instructions on how to accomplish these tasks. 34 Version 1.2

5. Administer Management Software Figure 21. Deploy to ORB Sets window A Tivoli Kernel Services installation consists of a large number of components, which are displayed in the View Component Depot window. However, there is only a small number of these components that you might need to consider deploying, or making available, to a specific ORB or ORB set. These components include the following: Component Manager components v ComponentDistributionService v PndScheduler Note: The ComponentDistributionService and PndScheduler components must be deployed together (to the same ORB set using the same deploy action). Directory components v slash v dirservice Gateway components v GatewayIPService v GatewaySNMPService v NelService Logging component v logging Introducing Tivoli Kernel Services 35

Security components v AuthenticationService v SecurityDirectoryService v RemoteAuthenticationService Service Manager component v dsm Managing the Directory The Tivoli Kernel Services directory is primarily used as an anchor point for accessing information within the distributed system. All ORBs have access to the directory; therefore, every component running on an ORB has access to the directory. The directory provides access to information using contexts. A context is a container that holds objects at a certain level in the directory. There are two types of contexts: ORB local context and slash context. The ORB local context represents the top-level context of an ORB and is the primary object on which all directory service operations are performed. The slash context provides and maintains directory services across session boundaries for an entire Tivoli Kernel Services installation. The slash context is contained in the directory database, a relational database whose location is defined during installation. This database is used to store configuration information. The directory service also depends on the database for secure storage of data source information. The slash context runs as a service (named slash) and is started by the Service Manager when the slash service is configured to run on an ORB. To view and access directory objects within a Tivoli Kernel Services installation, select the View Directory task in the Administer Management Software task group in the portfolio. The View Directory window, shown in Figure 22 on page 37, displays directory objects within a tree structure. 36 Version 1.2

5. Administer Management Software Figure 22. View Directory window Managing Events From this window, you can navigate through the directory, access the local ORB and slash contexts, create new directory folders, rename existing directory folders, and view and configure directory attributes. See the Tivoli Assistant online help system for step-by-step instructions on how to accomplish these tasks. The Messaging Service provides a generic event service. It accomplishes this by using the publish/subscribe communication model. In this model a publisher is a component that publishes messages to a topic. Publishing to a topic causes a message to be generated by the publisher and sent to the topic. A topic is a software object that defines message criteria. Topics are organized hierarchically, so that components and services can subscribe to high or low level topics. A subscriber is a component that requests information about a topic. Subscribers use filters to receive specific, persistent messages. To view system components using the Messaging Service, select the Manage ORBs task in the Administer Management Software task group in the portfolio. From the Manage ORBs window, shown in Figure 19 on page 33, right-click an ORB and select Display Messaging Service Statistics. From the Messaging Service Statistics window, shown in Figure 23 on page 38, you can view or change Messaging Service statistics. See the Tivoli Assistant online help system for step-by-step instructions on how to accomplish these tasks. Introducing Tivoli Kernel Services 37

Figure 23. Messaging Service Statistics window Managing Communications A Tivoli Kernel Services installation consists of the following: A set of servers, which support the management infrastructure and applications A set of devices, which represent the physical resources to be managed. Devices, or endpoints, are managed and controlled through agents, which are software entities that run on endpoints and provide management capability for other software or hardware. Tivoli Kernel Services supports SNMP agents through the appropriate gateway and communicates with them using the correct protocol. Note: Each object in the path to accessing a network device the NEL Service, the Gateway, and the device itself is subject to authorization checks. For information describing the security requirements for using these components, see Using the NEL Service and Gateway in a Secure Environment on page 47. Managing Gateways The Gateway Service manages the communications and connections between a group of endpoints and Tivoli Kernel Services. The gateway receives events from resources and passes the events to interested parties within the distributed system. The Network Endpoint Locator (NEL) Service is the Tivoli Kernel Services component that checks the security access to a resource and establishes the best gateway possible for an application to 38 Version 1.2

communicate with the endpoint using an action object. An action object represents the connection between an application and a resource. Action objects are created by components and travel to the location (usually a gateway) where the underlying operation can be performed. Action objects pass commands and data to and from the resource through whatever paths they require. To view and edit the NEL Service, select the View Component Depot task in the Administer Management Software task group in the portfolio. From the View Component Depot window, shown in Figure 20 on page 34, right-click the NelService component and select Edit Properties. From the Edit Configuration of NelService window, shown in Figure 24, default and user-defined gateways are displayed. 5. Administer Management Software Figure 24. Edit properties of NelService From this window, you can navigate through the list of user-defined gateways, create new gateways, and configure gateways. See the Tivoli Assistant online help system for step-by-step instructions on how to accomplish these tasks. To view and edit the IP Gateway or SNMP Gateway, select the View Component Depot task in the Administer Management Software task group in the portfolio. From the View Component Depot window, right-click the GatewayIPService component or GatewaySNMPService component and select Edit Properties. In the Edit Configuration of GatewayIPService window, shown in Figure 25 on page 40, (or the Edit Configuration of GatewaySNMPService window), IP gateway configuration information is displayed. Introducing Tivoli Kernel Services 39

Figure 25. Edit properties of GatewayIPService From this window you can configure an IP gateway. See the Tivoli Assistant online help system for step-by-step instructions on how to accomplish these tasks. Managing SNMP Device Configuration You can configure SNMP device information, such as read and write community names, SNMP port number, retry counters, and timeout thresholds. The information, which is stored as configuration data and is used when establishing sessions with SNMP agents, can be configured for a single resource, a group of resources, or an entire subnet, based on the network address specified. You can also create and associate SNMP configurations with a network address translation (NAT). A NAT represents a namespace within which IP addresses are unique. By creating a NAT, you can partition the installation into private IP network namespaces to ensure a unique destination for data sent to an IP address that might exist in more than one IP network namespace. Before the SNMP configuration GUI views can be used, you must deploy the IpConfigImpl service to either orb.1 or orb.2. To deploy the service from the command line, use the following command, where orb_oid and orbset_oid represent the object identifier of the ORB or ORB set to which you want to deploy the service: wcmd cds deploy IpConfigImpl@5.2.0 {orb_oid orbset_oid} For example: wcmd cds deploy IpConfigImpl@5.2.0 2.d3b096df447cef5f.1.2c27b7076f1e5965 Note: This deploy command must be issued from orb.1. To view and configure SNMP device information, select the View SNMP Configuration task in the Administer Management Software task group in the portfolio. The View SNMP Device Configuration window, shown in Figure 26 on page 41, displays the configuration information in a tree structure organized by NAT. 40 Version 1.2

5. Administer Management Software Figure 26. View SNMP Device Configuration window From this window you can create new NATs, manage default SNMP device configuration for a NAT, and manage SNMP device configuration for individual IP addresses or a range of IP addresses. See the Tivoli Assistant online help topics for step-by-step instructions on how to accomplish these tasks. Introducing Tivoli Kernel Services 41

42 Version 1.2

A System-Defined Roles A number of security roles have been defined in Tivoli Kernel Services for your use. These roles have a predefined set of access conditions and are provided to help you grant users the proper system access. These roles can be copied or modified to meet your needs. Several roles are used internally by Tivoli Kernel Services and should not be modified. The following tables list and describe all system roles. The roles are divided into the various directory paths where they exist within the security registry. Table 6. Roles located in the Applications/ directory of the security registry Applications/ TES/01/roles/MetaTESAdmin Administrator role for MetaTES resource. Table 7. Roles located in the PS/PSServer/Roles/ directory of the security registry PS/PSServer/Roles/ com.tivoli.pf.pfconsole.impl/1.2.0/consoleusers Base role that is automatically assigned to any user in the security registry. Provides access to sign on to the Tivoli Console. com.tivoli.pf.pfconsole.impl/1.2.0/mcfulrole Base role that is automatically assigned to any user in the security registry. Provides access to users to perform tasks in the Tivoli Console. MACImpl/5.2.0/MACInstallUser Role that allows users to perform all system administration functions. Provides access to all tasks within all task groups. MACImpl/5.2.0/MACLimitedSecurityUser Role that allows users to view security information for the user and account you signed on to the console with, and search for security resources. Provides access to View User Properties and Search Security tasks within the Administer Security task group. MACImpl/5.2.0/MACLoggingUser Role that allows users to perform logging administration functions. Provides access to all tasks within the Administer Logging task group. MACImpl/5.2.0/MACOrbUser Role that allows users to perform ORB, ORB set, component, and data connection administration functions. Provides access to Manage ORBs, View Data Connections, and View SNMP Configuration tasks. A. System-Defined Roles Introducing Tivoli Kernel Services 43

Table 7. Roles located in the PS/PSServer/Roles/ directory of the security registry (continued) PS/PSServer/Roles/ MACImpl/5.2.0/MACResourceUser Role that allows users to perform directory administration functions. Provides access to the View Directory task. MACImpl/5.2.0/MACSecurityUser Role that allows users to perform security administration functions. Provides access to all tasks within the Administer Security task group. MACImpl/5.2.0/MACSeniorUser Role that allows users to perform all system administration functions. Provides access to all tasks within all task groups. Table 8. Roles located in the security/roles/ directory of the security registry security/roles/ Administrator Role that provides full access to all objects in the security registry. User Administrator Role that grants authority to work with accounts and persons only, does not have authority to work with roles. Can add, delete, and edit accounts and persons anywhere in the security registry with the exception of the security directory. Does not have the authority to use the security CLI commands. wcmdrole Role that grants access to all security CLI commands. Should only be assigned to your super administrators. Table 9. Roles located in the system/roles/ directory of the security registry system/roles/ Bootprint Installer Role that provides access to install bootprints. Database Admin Role that provides access to work with all SimpleDataSource objects in the system directory of the security registry. Logging Administrator Role that grants authority to manage loggers, handlers, and filters (masks). System Administrator Role that provides end-user access to all Tivoli Kernel Services except for the security registry. Provides access to all CLI commands except for security commands. View Application Data Role that provides access to view all security registry objects in the application directory of the security registry. View System Data Role that provides access to view all security registry objects in the system directory of the security registry. 44 Version 1.2

Table 10. Roles located in the system/services/roles/ directory of the security registry system/services/roles/ CfgUsingDirectory Internal-use-only role used by the configuration service. Do not edit, delete, or assign this role. DirectoryService Role that grants full access to the Directory Service. Do not delete this role as it is used by internal services. gateway/jrdeviceadmin Role that grants deviceexe access to the device groups that a security registry administrator configures as targets. gateway/deviceadmin Role that grants deviceread and deviceexe access to the device groups that a security registry administrator configures as targets. gateway/srdeviceadmin Role that grants deviceread, devicewrite, and deviceexe access to the device groups that a security registry administrator configures as targets. gateway/superdeviceadmin Role that grants deviceread, devicewrite, and deviceexe access to all devices. gateway/jrgatewayadmin Role that grants read access to the Gateway instances that a security registry administrator configures as targets. gateway/gatewayadmin Role that grants read and execute access to the Gateway instances that a security registry administrator configures as targets. gateway/srgatewayadmin Role that grants read, write, and execute access to the Gateway instances that a security registry administrator gateway/supergatewayadmin Role that grants read, write, and execute access to all Gateway instances. KernelService Internal-use-only role for Tivoli Kernel Services. Do not modify or delete this role. nels/jrnelsadmin Role that grants read access to the NEL Service instances that a security registry administrator configures as targets. nels/nelsadmin Role that grants read and execute access to the NEL Service instances that a security registry administrator configures as targets. nels/srnelsadmin Role that grants read, write, and execute access to the NEL Service instances that a security registry administrator configures as targets. nels/supernelsadmin Role that grants read, write, and execute access to the NEL Service instances. A. System-Defined Roles Introducing Tivoli Kernel Services 45

46 Version 1.2

B Using the NEL Service and Gateway in a Secure Environment The Network Endpoint Locator (NEL) Service and Gateway components are designed to support a multi-customer environment, while protecting individual network devices from access by unauthorized parties. Each object in the path to accessing a network device the NEL Service, the Gateway, and the device itself is subject to authorization checks. Therefore, a user trying to access a given device must be authorized to access three things: (1) the NEL Service that locates the Gateway to the device, (2) the Gateway to the device and (3) the device (endpoint). The user gains access rights by authenticating as a principal in the security registry, which has been configured to have the required access conditions. Accessing a NEL Service Instance There are objects in the security registry that represent each individual NEL Service instance in a Tivoli Kernel Services installation. The NEL Service objects have the following names, where orbname is in the format machine_port. system/services/nels/nels_orbname In addition, there is an object that represents all NEL Service instances. This NEL Service object has the following name: system/services/nels/nels There are three access rights associated with a NEL Service object: read, write, and execute. One of these rights is needed when performing a NEL Service action. For example, to display the names of network address translations (NATs) in the installation, the user must have read access to the NEL Service instance and to resolve an endpoint using configuration data, the user must have execute access. The security registry contains predefined roles with specific access rights. The predefined roles for NEL Service access are as follows: system/services/roles/nels/supernelsadmin This role has read, write, and execute access to all NEL Service instances. system/services/roles/nels/srnelsadmin This role has read, write, and execute access to the NEL Service instances that a security administrator configures as targets. system/services/roles/nels/nelsadmin This role has read and execute access to the NEL Service instances that a security administrator configures as targets. B. Security for NEL Service and Gateway Introducing Tivoli Kernel Services 47

system/services/roles/nels/jrnelsadmin This role has read access to the NEL Service instances that a security administrator configures as targets. In addition, the system/services/roles/kernelservice role has read, write, and execute rights to all NEL Service instances. The SuperNELSAdmin role applies to the overall NEL Service object, which means that the access applies to all NEL Service instances. However, most of the roles do not have any target object defined and the security administrator must configure which NEL Service instances the roles apply to. To configure a target for a role, the administrator must associate a securable object with a capability within the role. The predefined NEL Service roles that require a target to be configured have the following capabilities: SuperNELSAdmin has system/services/roles/nels/supernelsadmin/supernelscapability capability. SrNELSAdmin has system/services/roles/nels/srnelsadmin/srnelscapability capability. NELSAdmin has system/services/roles/nels/nelsadmin/nelscapability capability. JrNELSAdmin has system/services/roles/nels/jrnelsadmin/jrnelscapability capability. Note: Before attaching static targets to a role, it is recommended that you create a new role by cloning, or copying and renaming, the predefined role. As an example, suppose you want to configure a role that has read, write, and execute access to the NEL Service instance running on machine sys1, port 9990. The NEL Service object in the security registry would be named system/services/nels/nels_sys1_9990 and the applicable role would be SrNELSAdmin because it has read, write, and execute access. To associate the desired target with the capability in the role: 1. From the portfolio, select the Administer Security View Users, Resources, Roles. 48 Version 1.2

2. In the Security Registry window, double-click system services roles nels to display the predefined NEL Service roles. 3. Copy and rename the SrNELSAdmin role as described in Copying Objects in the Security Registry on page 25. In this example, the new role is renamed SrNELSAdmin1. 4. To edit the newly created role, double click the role. 5. In the Role Properties window, select SrNELSCapability (from the Capabilities table) and click Edit. B. Security for NEL Service and Gateway Introducing Tivoli Kernel Services 49

6. In the Capability window, select Static Targets and click New. 7. In the Select Members window: a. Select Full name from the Property drop-down list and type the resource name, for example NELS_sys1_9990, in the text box. b. Click Run to locate the resource. (When the resource is located, it is displayed in the bottom half of the window.) c. Select the resource and click OK to add it to the list of static targets. 8. In the Capability window, click OK to save the changes. You can also use the wcmd ssm interface to associate the desired target with the capability in the role as follows: 50 Version 1.2

wcmd ssm modifyattributes -p system/services/roles/nels/srnelsadmin/srnelscapability -op add statictarget=system/services/nels/nels_sys1_9990 Roles only become useful when they are assigned to security principals. A person can then sign on as the principal and gain the accesses of any roles the principal has. Principals are objects within the security registry and can be created by installation security administrators as needed. Assume that the principal User1 has been created with the following path in the registry: applications/test/principals/user1 To assign a role to a principal, you can use either the procedure outlined in Assigning Roles to a User on page 18 or the wcmd ssm command line interface as follows: wcmd ssm modifyattributes -p applications/test/principals/user1 -op add staticrole=system/services/roles/nels/srnelsadmin Users that sign on as the User1 principal would then have read, right, and execute access to the NEL Service service running on sys1. Accessing a Gateway Instance The security aspects of the Gateway service are analogous to those of the NEL Service. There are objects in the security registry that represent each individual Gateway instance in a Tivoli Kernel Services installation. The Gateway objects have the following names, where type is either SNMP or IP and orbname is in the format machine_port. system/services/gateway/gatewaytype_orbname In addition, there is an object that represents all Gateway instances. This Gateway object has the following name: system/services/gateway/gateway There are three access rights associated with a Gateway object: read, write, and execute. One of these rights is required when performing any Gateway action. For example, to get the status of the Gateway service, the user must have read access to the Gateway instance. The security registry contains predefined roles with specific access rights. The predefined roles for Gateway access are as follows: system/services/roles/gateway/supergatewayadmin This role has read, write, and execute access to all Gateway instances. system/services/roles/gateway/srgatewayadmin This role has read, write, and execute access to the Gateway instances that a security administrator configures as targets. system/services/roles/gateway/gatewayadmin This role has read and execute access to the Gateway instances that a security administrator configures as targets. system/services/roles/gateway/jrgatewayadmin This role has read access to the Gateway instances that a security administrator configures as targets. B. Security for NEL Service and Gateway Introducing Tivoli Kernel Services 51

In addition, the system/services/roles/kernelservice role has read, write, and execute rights to all Gateway instances. The SuperGatewayAdmin role applies to the overall Gateway object, which means that the access applies to all Gateway instances. However, most of the roles do not have any target object defined and the security administrator must configure which Gateway instances the roles apply to. To configure a target for a role, the administrator must associate a securable object with a capability within the role. The predefined Gateway roles that require a target to be configured have the following capabilities: SuperGatewayAdmin has system/services/roles/gateway/supergatewayadmin/supergatewaycapability capability. SrGatewayAdmin has system/services/roles/gateway/srgatewayadmin/srgatewaycapability capability. GatewayAdmin has system/services/roles/gateway/gatewayadmin/gatewaycapability capability. JrGatewayAdmin has system/services/roles/gateway/jrgatewayadmin/jrgatewaycapabilit capability. Note: Before attaching static targets to a role, it is recommended that you create a new role by cloning, or copying and renaming, the predefined role. As an example, suppose you want to configure a role that has read access only to the GatewayIP instance running on machine sys1, port 9990. The Gateway object in the security registry would be named system/services/gateway/gatewayip_sys1_9990 and the applicable role would be JrGatewayAdmin because it has read access only. To associate the desired target with the capability in the role: 1. From the portfolio, select the Administer Security View Users, Resources, Roles. 52 Version 1.2

2. In the Security Registry window, double-click system services roles gateway to display the predefined Gateway roles. 3. Copy and rename the JrGatewayAdmin role as described in Copying Objects in the Security Registry on page 25. In this example, the new role is renamed JrGatewayAdmin1. 4. To edit the newly created role, double click the role. 5. In the Role Properties window, select JrGatewayCapability (from the Capabilities table) and click Edit. B. Security for NEL Service and Gateway Introducing Tivoli Kernel Services 53