Patrol Security User Guide

PATROL® SecurityUser Guide

Supporting

PATROL Central Console 7.5

February 28, 2005

Contacting BMC Software

You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information about the company, its products, corporate offices, special events, and career opportunities.

United States and Canada

Address BMC SOFTWARE INC2101 CITYWEST BLVDHOUSTON TX 77042-2827 USA

Telephone 713 918 8800 or800 841 2031

Fax 713 918 8000

Outside United States and Canada

Telephone (01) 713 918 8800 Fax (01) 713 918 8000

Copyright 2005 BMC Software, Inc., as an unpublished work. All rights reserved.

BMC Software, the BMC Software logos, and all other BMC Software product or service names are registered trademarks or trademarks of BMC Software, Inc.

IBM is a registered trademark of International Business Machines Corporation.

All other trademarks belong to their respective companies.

BMC Software considers information included in this documentation to be proprietary and confidential. Your use of this information is subject to the terms and conditions of the applicable End User License Agreement for the product and the proprietary and restricted rights notices included in this documentation.

Restricted rights legend

U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC SOFTWARE INC, 2101 CITYWEST BLVD, HOUSTON TX 77042-2827, USA. Any contract notices should be sent to this address.

http://www.bmc.com

3

Customer support

You can obtain technical support by using the Support page on the BMC Software website or by contacting Customer Support by telephone or e-mail. To expedite your inquiry, please see “Before Contacting BMC Software.”

Support website

You can obtain technical support from BMC Software 24 hours a day, 7 days a week at http://www.bmc.com/support_home. From this website, you can

■ read overviews about support services and programs that BMC Software offers■ find the most current information about BMC Software products■ search a database for problems similar to yours and possible solutions■ order or download product documentation■ report a problem or ask a question■ subscribe to receive e-mail notices when new product versions are released■ find worldwide BMC Software support center locations and contact information, including e-mail addresses, fax

numbers, and telephone numbers

Support by telephone or e-mail

In the United States and Canada, if you need technical support and do not have access to the web, call 800 537 1813 or send an e-mail message to [email protected]. Outside the United States and Canada, contact your local support center for assistance.

Before contacting BMC Software

Before you contact BMC Software, have the following information available so that Customer Support can begin working on your problem immediately:

■ product information

— product name— product version (release number)— license number and password (trial or permanent)

■ operating system and environment information

— machine type— operating system type, version, and service pack or other maintenance level such as PUT or PTF— system hardware configuration— serial numbers— related software (database, application, and communication) including type, version, and service pack or

maintenance level

■ sequence of events leading to the problem

■ commands and options that you used

■ messages received (and the time and date that you received them)

— product error messages— messages from the operating system, such as file system full— messages from related software

http://www.bmc.com/support_home

mailto:[email protected]

4 PATROL Security User Guide

ContentsChapter 1 Introduction 15

Overview of Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Security Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Security Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Protection Provided by PATROL Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Levels of Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Interoperability of Security Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Security versus Usability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Password Requirements for Levels 3 and 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Summary of Costs and Benefits of Various Security Levels . . . . . . . . . . . . . . . . . . 22

PATROL Security Installation Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Startup Modes: Unattended and Attended . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Unattended Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Attended Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Considerations For Choosing a Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Mode Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Startup Modes for PATROL Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Keys, Key Databases, and Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Communications-Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Anonymous Communications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Authenticated Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31SSL Communications Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Default Key Databases and Certificate Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34PATROL Knowledge Module Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Chapter 2 Planning 35

Setting Up and Configuring Security Content. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Overview of the Setup and Configuration Process . . . . . . . . . . . . . . . . . . . . . . . . . 36

Preparing to Install. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Installing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Installation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Configuring Security Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Contents 5

Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Setup Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Maintaining Security Content and Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Maintenance and Management Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Verifying Security Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Test Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Performing Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Troubleshooting Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Chapter 3 Installation 47

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Installation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Over-the-Top Installation and Policy Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Compatibility with the Previous Version of PATROL Security . . . . . . . . . . . . . . . 49Customizations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Selecting the Level of Security and Overwriting of Existing Security . . . . . . . . . . 53Selecting Advanced Security Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Selecting Connection Type for Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Location and Storage of Security Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Directories, Files Types, and Registry Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Chapter 4 Keys and Certificates 59

Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Types of Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Concepts and Components of Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Default Key Databases and Certificate Authorities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Workflow for Configuring PKI-Based Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Utilities for Key Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

sslcmd Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67bmckeycli Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Management of Keys and Key Databases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Key Databases Shipped with PATROL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Creating an SSL Key Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Changing the Password for the Key Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Transferring a Keyfile.kdb from Unix to Windows Environment . . . . . . . . . . . . . 71Generating Public and Private Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Listing Public–Private Key Pairs in the Key Database . . . . . . . . . . . . . . . . . . . . . . . 73Changing the Label of a Key Pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Deleting Private and Public Key Pairs and Certificates . . . . . . . . . . . . . . . . . . . . . . 75Exporting Key Pairs and Assigned Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Importing Key Pairs and Assigned Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Management of User Credential (Labeled Password) . . . . . . . . . . . . . . . . . . . . . . . . . . 80Purpose and Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Adding User Credentials (Labeled Passwords) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Listing User Credentials (Labeled Passwords) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81


Deleting User Credentials (Labeled Passwords) . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Management of Certificate Authority. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Establishing a CA Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Installing a CA Certificate in the Key Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Verifying Trusted Root Authority Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Viewing Field Information for CA Certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Deleting Trusted Root Authority Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Management of User Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Certificate Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Creating a Certificate Signing Request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Installing a User Certificate in the Key Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Listing Certificates in the Key Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Deleting a Certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Management of Certificate Revocation Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Description of a Certificate Revocation List (CRL). . . . . . . . . . . . . . . . . . . . . . . . . . 94Missing Certificate Revocation List Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Acquiring a Certificate Revocation List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Installing a Certificate Revocation List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Chapter 5 Security Policies 97

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Site Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Application Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Policy Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Policy Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Inheritance and Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106PATROL Configuration Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Format and Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Microsoft Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Utilities for Policy Testing and Password Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 111esstool Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112plc_password Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113bmcryptpw Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113signFile and verifyFile Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Policy and Role Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Creating a Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Viewing the Policies and Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Viewing Version Information for Security Modules . . . . . . . . . . . . . . . . . . . . . . . 117

Authentication and Encryption Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Specifying an Authentication Provider and Service . . . . . . . . . . . . . . . . . . . . . . . 119Testing Authentication Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Selecting an Encryption Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Listing the Encryption Algorithms Supported by the Encryption Module . . . . 130Testing Encryption Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Contents 7

Key Database and Password Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Designating a Key Database for an Application’s Role . . . . . . . . . . . . . . . . . . . . . 133Setting the Attended or Unattended Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Adding or Editing a Password Stored in a Policy. . . . . . . . . . . . . . . . . . . . . . . . . . 135Encrypting a Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Signer and Verifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Operation of Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Operation of Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Testing Digital Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Testing the Verification of a Digital Signature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Client-Server Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Testing a Secure TCP/IP Channel for the Client and Server. . . . . . . . . . . . . . . . . 145

Policy Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151PATROL Security versus Extended Security System . . . . . . . . . . . . . . . . . . . . . . . 151ESS 3.0.00 and ESS 3.0.05. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Migration Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152Migrate or Overwrite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Migration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Chapter 6 Configuration Files 155

PATROL Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156patrol.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157config.default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Working with Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Configuring the SSL access File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Operating System and Application-Specific Configurations. . . . . . . . . . . . . . . . . . . . 168Configuring the dlls.conf for PATROL for Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . 168Using PATROL Event Manager Applications with PATROL Security . . . . . . . . 170

Appendix A Changing the Security Level 171

Changing the Security Level for the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

Appendix B Troubleshooting 177

Issues and Workarounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Character @ Interpreted as Kill Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Attempt to Generate a Key Results in Extended Error Message . . . . . . . . . . . . . 179Defaults to Security Level 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Missing bindir Error Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Missing securitydir Error Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Password Prompter Canceled Error Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Password Attribute Requires 2 Fields Error Message . . . . . . . . . . . . . . . . . . . . . . 182Key File Cannot Be Reached Error Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182Decrypting Stored Password Error Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Identity Missing from Key Database Error Message . . . . . . . . . . . . . . . . . . . . . . . 183Unexpected Password Prompt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184


Installation Fails. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184Uninstallation Fails to Remove Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . 185Key Database Will Not Open With Correct Password . . . . . . . . . . . . . . . . . . . . . 185No Key for Negotiated Cipher Error Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Cannot Install a Certificate into a Key Database. . . . . . . . . . . . . . . . . . . . . . . . . . . 186Cannot Install a CRL into a Key Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Windows CA Rejects a CSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Password Not Configured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Password Prompt Does Not Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Typed Password Does Not Appear in Password Dialog Box. . . . . . . . . . . . . . . . 188Password Dialog Prompt Does Not Appear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188PATROL KM for Microsoft Cluster Server Does Not Support Attended Mode at

Level 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Cannot Find Shared Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Discovery Fails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Password for 64-bit Key Files Is Not Validated . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Password Dialog Prompt Does Not Appear When Running at Level 4 . . . . . . . 191

Error Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Invalid Policy Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Invalid Policy Keyfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Incorrect Encrypted Password Used During Security Bootstrap . . . . . . . . . . . . . 193Invalid Policy Identity Field (Non-Existing Key) . . . . . . . . . . . . . . . . . . . . . . . . . . 193Mutual Authentication Nominal Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195Missing Key On Level 4 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196Missing Trusted Root (client). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Missing Certificate (Server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Expired Certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Appendix C Valid Country Codes 203

Glossary 211

Index 217

Contents 9


FiguresUnattended Mode Settings in Policy File on Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Unattended Mode Settings in Registry Key on Windows . . . . . . . . . . . . . . . . . . . . . . 27Select Level of Security Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Select Advanced Level of Security Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55sslcmd Example keyfile.kdb not found . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Example of a CRL Stored in a Key Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Sample Site Policy File (site.plc) for Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Edit String Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Sample Site Policy Registry Key for Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Regedit View of Site Policy Registry Key for Windows . . . . . . . . . . . . . . . . . . . . . . . 110esstool policy Example on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115esstool policy Example on Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116esstool policy Example Output on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116esstool query Example on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117esstool query Result Example on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118pam.conf Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Authenticator Role of Site Policy on Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Example of Reference to pam_krb5 in pam.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124krb5.conf Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124esstool authenticator Example on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126esstool authentication Results Example on Windows . . . . . . . . . . . . . . . . . . . . . . . . . 127Sample List of Cipher Types for bmcpwk.dll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130esstool encryptor Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131esstool encryptor Example of Encryption Command and Output . . . . . . . . . . . . . . 132esstool encryptor Example of Decryption Command and Output . . . . . . . . . . . . . . 132plc_password Example Setting Mode to Unattended . . . . . . . . . . . . . . . . . . . . . . . . . 134plc_password Example Setting Mode to Unattended . . . . . . . . . . . . . . . . . . . . . . . . . 135plc_password Example of Policy File Contents on Unix . . . . . . . . . . . . . . . . . . . . . . 137bmcryptpw Example on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138bmcryptpw Results Example on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139bmcryptpw Test Example on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139bmcrypt Test Results Example on Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139signFile Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141signFile Example of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142verifyFile Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143verifyFile Example of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144esstool server Example Command on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145esstool server Example Startup Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147esstool client Example Command on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148esstool client Example Startup Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Figures 11

esstool server Example of Message Received from esstool client . . . . . . . . . . . . . . . 150Result of the Migration of the pamservice Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . 152patrol.conf File Example of the ESI Section on Unix . . . . . . . . . . . . . . . . . . . . . . . . . . 159patrol.conf Example of the ESI Section on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 160access File Example Restricting Access to Two Users . . . . . . . . . . . . . . . . . . . . . . . . . 166access File Example Allowing Access to a Group and Denying Access to an

Individual User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167ESI Variable Configured for PATROL Event Manager Applications . . . . . . . . . . . . 170ESI Library Location for PATROL Event Manager Applications . . . . . . . . . . . . . . . . 170Registry Keys for PATROL Agent and PATROL Security . . . . . . . . . . . . . . . . . . . . . 170p7_change_security_level Example on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173p7_change_security_level Example on Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173p7_change_security_level Script Sample Log on Windows . . . . . . . . . . . . . . . . . . . . 175Generate a Key Extended Error Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Password Prompter Canceled Error Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Password Attribute Requires 2 Fields Error Message . . . . . . . . . . . . . . . . . . . . . . . . . 182Identity Missing from Key Database Error Message . . . . . . . . . . . . . . . . . . . . . . . . . . 183Key Database Will Not Open With Correct Password Error Message . . . . . . . . . . . 185Invalid Policy Password Error Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Invalid Policy Keyfile Error Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Incorrect Encrypted Password Used During Security Bootstrap Error Message . . 193Invalid Policy Identity Field (Non-existing Key) Error Message, Client Log . . . . . . 193Invalid Policy Identity Field (Non-existing Key) Error Message, Server Log . . . . . 194Mutual Authentication Nominal Case Error Message, Client Log . . . . . . . . . . . . . . 195Mutual Authentication Nominal Case Error Message, Server Log . . . . . . . . . . . . . . 195Missing Key on Level 4 Client Error Message, Client Log . . . . . . . . . . . . . . . . . . . . . 196Missing Key on Level 4 Client Error Message, Server Log . . . . . . . . . . . . . . . . . . . . . 197Missing Trusted Root (client) Error Message, Client Log . . . . . . . . . . . . . . . . . . . . . . 198Missing Trusted Root (client) Error Message, Server Log . . . . . . . . . . . . . . . . . . . . . . 199Missing Certificate, Client Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Missing Certificate, Server Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Expired Certificate, Client Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201Expired Certificate, Server Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202


TablesSecurity Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18PATROL 3.x Security Level Interoperability Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Usability versus Security for the Security Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Password Usage in PATROL Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Default Modes (Unattended and Attended) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Anonymous Communications and Security Levels 0, 1, and 2 . . . . . . . . . . . . . . . . . . 31Authenticated Communications and Security Levels 3 and 4 . . . . . . . . . . . . . . . . . . . 31Overview of Preinstallation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Overview of Installation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Overview of Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Overview of Maintenance Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Overview of Testing Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Policy installation location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Installation location for versions of PATROL Security . . . . . . . . . . . . . . . . . . . . . . . . . 50Installation Paths of Security Files and Registry Keys . . . . . . . . . . . . . . . . . . . . . . . . . 57Default Certificate Expiration Dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Order of Configuration Tasks for Authentication Security . . . . . . . . . . . . . . . . . . . . . 66sslcmd Installation Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67bmckeycli Installation Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Distinguished Name Prompts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Policy Installation Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100PATROL Applications and Their Corresponding Application Policy Names . . . . 101Policy Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Policy Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Order of Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106esstool Installation Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111plc_password Installation Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112bmcryptpw Installation Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113signFile and verifyFile Installation Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114esstool policy Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Security Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Location of the PAM Configuration File by Operating System . . . . . . . . . . . . . . . . . 121IBM Updates for AIX 5.2 or Later . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123esstool authenticator Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Supported Encryption Algorithms and Their Cipher Values . . . . . . . . . . . . . . . . . . 128esstool encryptor Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131plc_password Utility Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135bmcryptpw Utility Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138signFile Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142verifyFile Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Tables 13

esstool server Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146esstool client Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Installation and Migration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154PATROL Configuration Files That Contain Security Information . . . . . . . . . . . . . . . 156Location of patrol.conf File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Security Configuration Data of patrol.conf File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158ESI Variables in patrol.conf File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Location of config.default File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Agent and Console Features in config.default File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Location of access File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Configuration Data in access File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165Location of the dlls.conf File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168p7_change_security_level Script Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172p7_change_security_level Script Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Valid Country Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203


C h a p t e r 1
1 Introduction
This chapter provides an overview of security concepts that will help you understand the issues involved in securing your PATROL environment.

This chapter contains the following topics:

Overview of Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Security Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Security Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Protection Provided by PATROL Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Levels of Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Interoperability of Security Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Security versus Usability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Password Requirements for Levels 3 and 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Summary of Costs and Benefits of Various Security Levels . . . . . . . . . . . . . . . . . . 22

PATROL Security Installation Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Startup Modes: Unattended and Attended . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Unattended Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Attended Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Considerations For Choosing a Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Mode Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Startup Modes for PATROL Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Keys, Key Databases, and Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Communications-Level Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Anonymous Communications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Authenticated Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31SSL Communications Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Default Key Databases and Certificate Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34PATROL Knowledge Module Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Chapter 1 Introduction 15

Overview of Security

Overview of SecurityAll systems in any environment are susceptible to potentially harmful events if the proper security is not in place. Both internal and external users can instigate critical events, either maliciously or unintentionally. Careful implementation of security controls and restrictions minimizes the occurrences of security violations.

To protect against these violations, PATROL Security uses a combination of

■ security roles to categorize the functions of an application and the security challenges that each function presents

■ security levels to determine the amount of security applied to the applications as they operate in different roles and interact with other applications

Security Roles

PATROL Security associates the potential security violations with the types of applications that interact within the PATROL environment. To address these concerns, PATROL provides security roles. The PATROL Security roles are as follows:

■ authenticator■ encryptor■ keystore■ client■ server■ signer■ verifier

When properly configured, these roles can address any security problem posed by applications fulfilling these roles. For more information about security roles, see “Policy Roles” on page 101.

Security Levels

PATROL employs a graduated security system that is divided into security levels. This approach enables you to configure the security of your PATROL environment to your security needs and usability requirements. You can install the level of security that you want and configure the chosen security level to your specifications.


Protection Provided by PATROL Security

For more information about security roles, see “Levels of Security” on page 18.

Protection Provided by PATROL SecurityProtecting data within PATROL means that the data delivered by PATROL users is private and secure. After you install PATROL, the implementation of security within PATROL delivers the following protection:

■ Communications privacy and encryption—PATROL Security provides message privacy for communications between PATROL components.

■ Authentication—Additional security is provided for communications between PATROL components by verifying the identity of each component.

■ Password privacy and configuration—With password encryption inherent in PATROL, you can control and change encryption keys, thus helping to prevent unwanted access to your PATROL environment. You can change your password to prevent infiltration of your accounts and to secure your personal environment and settings.

■ Digital signing—To ensure the integrity of data that you create in PATROL, PATROL implements digital signing and verification tools. Signature verification proves that the signer's certificate is valid and was granted by a trusted certificate authority (CA). After a signer's certificate has been verified, the certificate's public key is used for signature verification. The method of digital signature is only as secure as the signing keys that that CA uses. Digital signing maintains the integrity of product-related files by helping to ensure that the PATROL Knowledge Module® (KM) file or PATROL configuration file is original and unaltered.

■ User privileges—PATROL Security administrators can define an account or group and can assign specific permissions and access rights to that account or group. As an administrator, you can add privileges to or remove them from a user or group of users.

■ Access control lists (ACLs)—To stop unwanted connections to a server that is running the PATROL Agent, the communication to and from the agents and consoles might require restricted access. PATROL ACLs specify which user names are granted access, from which hosts access will be granted, and what type of

NOTE Throughout this document, discussion of PATROL Security refers to the security employed by PATROL to address those security issues introduced by PATROL components; PATROL Security does not provide comprehensive network security.


Levels of Security

access will be granted to the PATROL Agent. PATROL Security administrators can manipulate the access control for any object in the PATROL namespace. Administrators can grant or deny access on a hierarchical basis for any object and for any user or group.

In addition to ACLs maintained for PATROL consoles and agents, security level 4 also maintains its own set of ACLs in the access file. For more information about the file, see “access” on page 164.

■ Impersonation control—To facilitate seamless functioning of PATROL across multiple hosts and security domains, PATROL incorporates an impersonation table, which a PATROL Security administrator can use to specify user names and passwords for connecting to a new host.

For more specific information about how to use PATROL to modify or create these security functions, see the PATROL Security information in the PATROL Agent Reference Manual.

Levels of SecurityEach security level is defined by a specific set of configuration variables residing in configuration files (as described in Chapter 5, “Security Policies”). Table 1 defines the five principal levels of security policy.

Table 1 Security Levels (Part 1 of 2)

Level Description

0 (basic) Level 0 (basic security) is the default level of security. Basic security provides neither cryptographic protection of network traffic (messages traverse the network in plain text) nor authentication of peers (the user providing the user name and password is not required to prove that he or she is the originator or owner of that information).

This level offers the lowest level of security in exchange for greater ease of use. This level does not provide communication security or authentication security. Access control lists (ACLs) are minimized in favor of usability and performance.

1 Level 1 provides communications privacy using anonymous Diffie-Hellman public keys exchange and triple data encryption standards-cipher block chain (DES-CBC) encryption to ensure privacy. It does not require that the user perform additional configuration or store a secret key. Additional cryptographic services include communication channel privacy, data integrity, and audit logging.

As with basic security, PATROL ACLs are relaxed. Level 1 provides communication security, but it does not provide SSL authentication of the console or agent.


Levels of Security

2 Levels 2 and higher use Secure Socket Layer (SSL) protocol, the essential ingredient in providing high-level communications security. The agent provides a certificate to the console as part of the SSL handshake. The console accepts this certificate unconditionally—whether or not it can verify the certificate to a trusted root authority.

Because there is no SSL authentication of the client (console) or the server (agent), the actual degree of security is no greater than that of level 1. The difference lies in the use of the SSL protocol for encryption to ensure message privacy, making communications more secure. Level 2 defaults to unattended mode, allowing the agent to restart without requiring manual password entry.

3 Level 3 uses SSL protocol for message privacy and authentication on the server (agent side) only. Level 3 security assures that the server is not an imposter by requiring the agent to provide a certificate to the client (console), which must then authenticate the server’s certificate to a trusted root authority. The certificate of the trusted root authority must be present in the client’s encrypted database. The client opens this database by supplying a password.

Level 3 defaults to unattended mode, allowing the agent to restart without requiring manual password entry, but can be configured to run in attended modea. Level 3 provides communication security and authentication of the server (agent) to verify that the client (console) is receiving valid data from a legitimate server.

4 Level 4 uses SSL for message privacy and authentication of both the server (agent) and the client (console). The server and the client provide each other a certificate that proves their respective identities. Each certificate must be verified to a trusted root authority present in the server and client databases. This level of security has the most configuration requirements and provides the most rigorous form of security available.

Level 4 defaults to unattended mode, allowing the agent to restart without requiring manual password entry, but can be configured to run in attended modea. Level 4 provides communication security and both client (console) and server (agent) authentication.

a See “PATROL Security Installation Options” on page 23 and “Startup Modes: Unattended and Attended” on page 25.

Table 1 Security Levels (Part 2 of 2)

Level Description


Interoperability of Security Levels

Interoperability of Security Levels

Interoperability of PATROL applications varies based on the PATROL architecture and the PATROL Security level implemented on each component.

PATROL 7.3.x or Earlier

Security level interoperability is restricted to the same level. For example, clients running at level 2 can interact only with servers running at level 2.

PATROL 7.3.x or Later and PATROL 3.x

Table 2 describes the interoperability between security levels in the PATROL 3.x architecture.

Table 2 PATROL 3.x Security Level Interoperability Matrix

Server

Level 1 Anonymous Diffie-Hellman

Level 2 Anonymous SSLTrusted Root CA, Server Key

Level 3 Server AuthenticationTrusted Root CA, Server Key, certificate

Level 4 Mutual AuthenticationTrusted Root CA, Server Key, certificate, ACL

Clie

nt

Level 1 Anonymous Diffie-Hellman

yes no no no

Level 2 Anonymous SSLTrusted Root CA, Server Key

no yes yes yesa

a Interoperabililty in this instance assumes that a key database has been set up for the client so that the client supports mutual authentication.

Level 3 Server AuthenticationTrusted Root CA, Server Key, certificate

no yes yes yesa

Level 4 Mutual AuthenticationTrusted Root CA, Server Key, certificate, ACL

no yes yes yes


Security versus Usability

Security versus UsabilityThe security policies allow you to install the least secure (basic security) up to the most secure (level 4) features of PATROL Security, depending on your system needs and how much complexity you can allow in securing your systems. High levels of security require additional configuration of the communicating components (the agent and console), are more difficult to use, and may affect network performance. Lower levels of security are much easier to configure and use, but provide less security.

Before installing PATROL, decide how much of a trade-off you are willing to make between security and usability by examining the differences among the policy levels, as described in “Levels of Security” on page 18. Basic security provides a minimal level of security with no configuration requirements. At the highest security level (4), all communicating components must authenticate with each other, and key databases must validate connection requests.

Password Requirements for Levels 3 and 4

Both levels 3 and 4 require a password to open the encrypted key and certificate database. The key database stores private and public key pairs, certificates, and trusted roots required for SSL operations. Triple DES-CBC cipher with a user-provided password protects the database.

A key material file computes the password encryption key. The key material file is a file that is provided and protected by the user and can be virtually any binary file. To ensure optimal security protection, users can carry this on their person, such as on a floppy disk. Chapters 2 and 3 provide detailed information about password encryption and policy definitions.

To allow greater usability at levels 2, 3, and 4 and support autonomous agent operations, PATROL Security gives you the option to store the encrypted password in the policy. This feature enables an application to start up without a user in attendance and is referred to as running in unattended mode. For more information, see “Startup Modes: Unattended and Attended” on page 25.


Summary of Costs and Benefits of Various Security Levels

Summary of Costs and Benefits of Various Security Levels

Table 3 summarizes usability issues and configuration requirements for each of the policy levels.

Table 3 Usability versus Security for the Security Levels

Security Level Description

Basic security ■ does not introduce any overhead in performance or configuration

■ does not provide any additional security beyond basic PATROL Security features (see “Protection Provided by PATROL Security” on page 17)

Level 1 ■ introduces no overhead in usability or maintenance

■ provides message confidentiality and integrity by using Diffie-Hellman key exchange and 3DES encryption

■ introduces a minimal amount of overhead associated with performance and disk space

Level 2 ■ preconfigured with demo keys out of the box; they have expiry dates as indicated in Table 16 on page 65

■ can use SSL but it requires a set of CA and configuration; use your own CA and certificates

■ preconfigured upon installation and does not require any additional configuration efforts

■ increases performance overhead and maintenance costs because of the use of SSL and X.509 certificates

Level 3 ■ introduces SSL-based authentication

■ provides substantially increased traffic security and general data integrity

■ requires more configuration due to the requirement of a certificate for each authenticating agent.

Level 4 ■ provides mutual authentication, which requires a certificate for each authenticating agent and console

■ can use SSL but requires you to acquire a set of CA and configuration; use your own CA and certificates

■ requires the most configuration due to the requirement of a certificate for each authenticating agent and console


PATROL Security Installation Options

PATROL Security Installation OptionsInstalling security levels 3 and 4 affects PATROL operations in the following ways:

■ Default operation for the PATROL Console version 3.x is in operator mode.

■ If you choose levels 3 or 4 during installation, a screen will prompt you to select TCP or UDP or both for the Network connection allowed option. (For details about installation, see “Selecting the Level of Security and Overwriting of Existing Security” on page 53.)

If you select the TCP option only, traffic defaults to TCP instead of UDP on the PATROL Agent. To use the pconfig utility at levels 3 and 4, you must specify pconfig ...+tcp to connect to an agent. (If you selected the UDP option, pconfig defaults to UDP).

In order to use xpconfig, you can connect to the agent only by selecting the TCP connection mode.


Passwords

PasswordsPasswords provide authentication security. A user proves its identity by supplying a password that only that user should know. PATROL Security implements this type of authentication to prove the identity of users trying to establish communications from one PATROL application to another. It also uses passwords to protect some of its own components such as key databases.

Usage

Table 4 provides a list of the different components and usages of passwords and reference the section in this manual where you can learn more about managing passwords in that context.

Table 4 Password Usage in PATROL Security

Protected Component Location Usage Information

PATROL applications

in key database

access PATROL application “Adding User Credentials (Labeled Passwords)” on page 80

local key database

attached to key database

access key database “Changing the Password for the Key Database” on page 71

remote key database

policy, password attribute

access key databases that supports the role under which an application is operating

“Adding or Editing a Password Stored in a Policy” on page 135


Utilities

Utilities

PATROL Security provides several utilities that you can use to encrypt passwords and distribute them. They include

■ plc_password—enables you to encrypt a password using a key material file and insert the password in a policy file; see “plc_password Utility” on page 112

■ bmcryptpw—enables you to encrypt and verify a password using a key material file; see “bmcryptpw Utility” on page 113

■ sslcmd—enables you to manage the following types of passwords;— user passwords (referred to as Labeled Passwords) stored in a key database by

PATROL applications; you can apply a label to these user passwords to help you identify and manage them

— key database passwords, which are required to manage key databases; see “sslcmd Utility” on page 67

Startup Modes: Unattended and AttendedThe distinction between attended and unattended modes refers to how much user intervention an application requires to startup and run. The start-up mode is determined by the presence or absence of an encrypted password in the password parameter of either the site or application policy.

The startup mode affects applications running at levels 2, 3, and 4. Applications with security level 0 and 1 start up in unattended mode exclusively.

Unattended Mode

In unattended mode, a password entry is present in the policy file or registry key depending upon the operating system. You launch the application, the application retrieves the encrypted password from attribute in the policy, verifies it against the password to access the key database, and if the password is correct, then the application starts up and runs.


Attended Mode

Attended Mode

In attended mode, password information is missing from the policy. You launch the application, the application attempts to retrieve the encrypted password from the policy. When it does not find the password, it presents a user name and password dialog box to the user. The user types in the information and submits it to the application. The application verifies it, and if the password is correct, then the application starts up and runs.

Considerations For Choosing a Mode

When deciding whether to employ attended or unattended mode, consider the following factors.

Security versus Usability

Attended mode is more secure than unattended operation using an encrypted password; however, attended mode requires you to enter a password every time you restart the application.

For example, if you ran the PATROL Agent in attended mode, you or another system administrator would have to physically attend the restart of an agent so that you could type in the account name and password.

Physical Security

The degree of physical security in your network environment is relevant deciding whether to run a server in unattended mode. A server that is not physically secured from unauthorized users is inherently more vulnerable to unauthorized access if it is running in unattended mode.

Virtual Security

The degree of virtual security in your network environment is also relevant when deciding whether to run a server in unattended mode. Storing a password on a computer makes it vulnerable to discovery by intruders that gain ownership of a service. To secure your computer, shut down unnecessary services such as inetd, telnet, netbios, ftp, and other similar services that can be exploited by intruders.


Mode Settings

Mode Settings

Attended and unattended mode settings depend upon the presence or absence of the following policy parameters in the policy file for Unix or registry key for Windows. These parameters must be specified as described in “Setting the Attended or Unattended Mode” on page 134.

■ password, key material file■ key database

Figure 1 illustrates the attribute settings for unattended mode in a Unix environment.

Figure 2 illustrates the attribute settings for unattended mode in a Windows environment.

Figure 2 Unattended Mode Settings in Registry Key on Windows

Changing Between Unattended and Attended Mode

To set a component to run in unattended or attended mode, use the plc_password utility as described in “plc_password Utility” on page 112.

Figure 1 Unattended Mode Settings in Policy File on Unix

[client]logfile = console_client.logpassword = 82a153ecffbc901bb73fefe0c23c84b8b76d422a1e6ed83d, /opt/Tuscany/JA/011016/common/security/keys/tree.binkeyfile = /home/patrol/patrol.kdb


Startup Modes for PATROL Components

Startup Modes for PATROL Components

Table 3 shows the default mode for various PATROL components.

Table 5 Default Modes (Unattended and Attended)

PATROL ComponentDefault Mode (Security levels 3 and 4)

PATROL 3.x console attended

PATROL Central – Microsoft Windows Edition attended

PATROL Central – Web Edition unattended

PATROL Agent 3.5 and 3.4 unattended

PATROL Console Server unattended

PATROL Event Manager 3.5 PATROL CLIPATROLLinkpconfig utilityxpconfig utilitywpconfig utilityclient applications

unattended

NOTE For level 4 security, the client section in the site policy does not contain a password. Therefore, if the application policy (client, server, and so forth) does not exist or cannot be loaded, the site policy will be used and the mode will default to attended.


Keys, Key Databases, and Certificates

Keys, Key Databases, and CertificatesKeys, key databases, and certificates are used to protect data as it travels from one point in a network to another. They are also used to prove the origin of that data.

As the name implies, keys are used to lock or encrypt data. The process of locking data ensures that it is safe from being tampered with, either by being altered or being read. Key databases (also referred to as keystores) store keys that are used to unlock or decrypt data. Certificates are documents that confirm the identity of a user and they are issued by a Certificate Authority (CA, also referred to as trusted root authority). The CA certificate is installed into the key database and used to verify a user certificate. The user certificates are linked to private and public key pairs and used to digitally sign data and to verify digitally signed data. Certificate Revocation Lists (CRL) are periodically retrieved from the CA and installed into the key database. If a user certificate appears on the CRL, the certificate is compromised and any requests with which it is associated are denied.

For more information about keys, key databases, and certificates, see Chapter 4, “Keys and Certificates.”

PoliciesSecurity policies contain setup and configuration information for implementation of PATROL Security, which addresses potential security violations. A security policy consists of roles and attributes. Roles categorize applications according to their functions and the potential security threats that they pose. Attributes define the security behavior. When roles are properly configured through attributes, the roles can address any security problem posed by applications that fulfill these roles.

Policy roles link PATROL applications to key databases, which provide them with the means for encryption and authentication. Each roles can reference a different key database or all roles can reference the same key database.

For more information about keys, key databases, and certificates, see Chapter 5, “Security Policies.”


Communications-Level Security

Communications-Level SecurityThe term “security” covers a wide territory, even in the restricted domain of computer networks. Conventional logon passwords, for example, ensure that only authorized users can access computing resources. Just as access security protects access to computing resources, communications security protects information that is transmitted over a communications channel.

Communications security protects such information only in the context of a transaction between communicating parties. After that information is received, it moves from being a transaction requiring communications security into some other format (such as data stored on a disk), where it must be protected by other forms of security.

This section covers how security is implemented at the communications level. It discusses in detail the ways in which the transactions between PATROL components are secured so that message privacy is secured and the communicating components are authenticated. These two aspects of security (privacy and integrity) are addressed by communications-level security. Verification of the rights and privileges of communicating components (authorization) is addressed by user administration.

The level of security that you install determines whether or not the communicating components are authenticated with SSL communications security.

Security levels 0, 1, and 2 do not employ SSL to authenticate the communicating components. Levels 3 and 4 do provide SSL-authentication: level 3 authenticates the client to the server, and level 4 authenticates both the client and the server to each other.

Anonymous Communications

Anonymous communications are exactly what they claim: communications between two applications that have no means of verifying that the other application is what or who it says it is. Anonymous communications are vulnerable to impersonation attacks. Levels 1 and 2 encrypt these communications, which prevents eavesdropping. Level 0 does not encrypt communications, sending clear text messages back and forth.

Table 6 describes in detail the differences in security levels with regard to anonymous communications. For more information about differences between security levels, see “Levels of Security” on page 18.


Authenticated Communications

Authenticated Communications

Authenticated communications are communications between two applications, that can verify the authenticity of the other. At level 3, the client verifies that the server application is what it claims to be. At level 4, both the client and server verify each other’s authenticity. Both levels provide for SSL encryption of communications to prevent eavesdropping.

Table 7 describes in detail the differences in security levels with regard to authenticated communications.

Table 6 Anonymous Communications and Security Levels 0, 1, and 2


0 Security level 0 (basic security, the default level) does not employ either Diffie-Hellman or SSL for message privacy.

1 Security level 1 is based on anonymous Diffie-Hellman public key exchange, which provides a high degree of privacy protection but no authentication. Diffie-Hellman key exchange does not require any configuration and thus has no configuration cost and no configuration vulnerabilities. This protocol is a desirable choice for environments where only message privacy is required.

2 Security level 2 employs SSL for message privacy, but does not use SSL to authenticate the client or the server. SSL is considered more secure because it is more difficult to decrypt.

Table 7 Authenticated Communications and Security Levels 3 and 4


3 Security level 3 employs SSL communications security to authenticate the server to the client (for example, the agent to the console). Authentication requires that a trusted third party, the certificate authority (CA), verify the server’s certificate. The integrity of this authentication process relies on the integrity of the key database that stores the trusted CA certificate.

4 Security level 4 provides mutual client-server SSL authentication. This level requires the proper maintenance of the authentication credentials on each of the communicating peers (clients and servers).


SSL Communications Security


Security levels 2 and higher use SSL communications security for

■ message privacy (levels 2, 3, and 4) ■ authentication (levels 3 and 4)

To provide communication security at level 2 or higher, you must set up an SSL key database for each user or PATROL component that presents or verifies certificates. To maintain communications security, an SSL key database contains

■ public and private cryptographic keys ■ trusted authority certificates ■ user certificates■ certificate revocation lists

PATROL components require a naming convention for both the key database filename and for the SSL identity that the database contains. To operate at levels 2, 3, and 4, the agent requires a key database named server.kdb, which must also contain an SSL identity named server. This identity provides the agent with its own keypair (one public key and one private key) and corresponding certificate.

The bmcuser.kdb file contains default keys and certificates (security content) for the agent and client with the default user name bmcuser. This default configuration enables PATROL Security to run without further configuration at level 3, but is not secure because the default is publicly available.

At level 3, the agent sends its certificate to the console for validation. The certificate contains the name of an issuer (the trusted root authority); the console searches for this name in the console database in order to verify the agent’s authenticity.

For level 4, the database must also contain an SSL identity key for the user name (for example, user1). This design permits a separate key database and password for each user. The console must provide its certificate so that the agent can verify the authenticity of the console. At this level, the console database must contain the signed certificate for the user while the agent database must also contain the certificate for the signing authority that signed the console's certificate.

To operate at security level 4, the SSL communications console requires a key database corresponding to the user name of the person starting the console. For example, user1 requires a database named user1.kdb.



NOTE To operate at level 4, server.kdb must contain certificates for all signing authorities that have signed the certificates of valid users. If multiple signing authorities sign user certificates, server.kdb must contain certificates for each of these signing authorities in order to grant all users access to the agent.


Default Key Databases and Certificate Authorities


Default keys and certificate authority (CA) certificates supplied by BMC and stored in keyfiles with .kdb extensions are provided only to demonstrate a turnkey security configuration, for purposes such as demonstrations and trial installations. Before using BMC Software products, replace the default keys and certificates with your own unique entities. For instructions, see “Setting Up and Configuring Security Content” on page 36 and “Establishing a CA Certificate” on page 83.

PATROL Knowledge Module SecurityPATROL Knowledge Modules (KMs), along with configuration files, directly control the behavior of PATROL, and thus play an integral role in preserving the integrity of the PATROL user environment.

Because KMs require the PATROL infrastructure to deliver their functionality, KMs already include many security components that are handled by the infrastructure, such as traffic encryption, execution of the script in the proper accounts, and auditing. However, older KMs may offer less security.

Presently, all KMs use DES-encrypted storage in agent configuration. In addition, BMC Software is adding a set of basic rules for KM security that future KM development and certification processes will require.

WARNING This product is delivered with default keys and certificates that are not unique to you. BMC Software highly recommends that you promptly change these default keys and certificates to ones that are unique. If you do not make these changes, there is a higher risk that any third party who gains physical access to your network, or to the data that you send over the internet, might have a better opportunity to use these default keys and certificates to gain unauthorized access to your system. BMC Software is not responsible for any damage or liability associated with your use of default keys and certificates.


C h a p t e r 2
2 Planning
This chapter describes the process of planning the installation and it discusses the considerations that you must make relating the actual tasks that you need to perform to set up and configure your PATROL Security environment. It references the sections in this document that describe how to perform the individual tasks.

This chapter presents the following topics:

Setting Up and Configuring Security Content. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Overview of the Setup and Configuration Process . . . . . . . . . . . . . . . . . . . . . . . . . 36

Preparing to Install. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Installing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Installation Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Configuring Security Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Setup Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Maintaining Security Content and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Maintenance and Management Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Verifying Security Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Test Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Performing Diagnostics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Troubleshooting Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45


Setting Up and Configuring Security Content

Setting Up and Configuring Security Content

Because PATROL Security is shipped with and installs keys and certificates for demonstration purposes only (see “Default Key Databases and Certificate Authorities” on page 34), to create a secure environment, you must acquire your own unique keys and certificates and then modify key databases, passwords, and policies to use this unique content. This section lists all the tasks that you must perform and refers you to instructions and additional information about how to complete those tasks.

Overview of the Setup and Configuration Process

The tasks that you have to perform to set up PATROL Security depend upon the security level at which you want to run your PATROL environment and the security roles of the PATROL applications that you run and install. The tasks can be categorized and ordered as follows:

1. preparation for installation

2. installation of PATROL Security

3. configuration of PATROL Security

4. verification of PATROL Security

5. diagnosis of problems if they occur



Preparing to Install

Preparing to InstallPATROL Security is packaged with a demonstration set of key databases, certificates and certificate authorities, policies, and passwords. While this information is extremely valuable in setting up demonstrations of PATROL Security, it is publicly available to all PATROL customers and therefore is insecure.

To create a secure environment, you must identify a certificate authority from which you can acquire the certificates and trusted root certificate and certificate revocation list (CRL).

Considerations

When preparing to install PATROL Security, consider the following questions:

■ Do you want to use a third party as your Certificate Authority (CA)? If so, does the CA provide certificates in an ASCII text file in version 3 of the X.509 PEM (Privacy-Enhanced Mail) Base64 format?

■ Do you want to manage your own CA in-house?

Tasks

Table 8 lists tasks to perform when preparing to install PATROL.

Table 8 Overview of Preinstallation Tasks

Order Task Procedural InstructionsApplicable Security Level

1. Establish a Certificate Authority. “Establishing a CA Certificate” on page 83 all


Installing

InstallingPATROL Security is automatically installed with such PATROL applications as the PATROL consoles, the PATROL Agent, and the Console Server. BMC Software does not provide an independent installation of PATROL Security.

Considerations

Before you install PATROL Security, consider the following questions:

■ Does PATROL Security already exist on this computer?

— Which version is it? — Do you want to overwrite customizations to security contents such as unique

keys, certificates, and modified policies?

■ What level of security do you want to install and will it operate with the rest of your PATROL environment?

Installation Tasks

Table 9 lists tasks to perform during the installation of PATROL.

Table 9 Overview of Installation Tasks


1. Choose basic or advanced security. “Selecting the Level of Security and Overwriting of Existing Security” on page 53

all

2. Specify whether to overwrite existing security.

same as the previous action all

3. Depending on what you choose in the first task, select an advanced security level.

“Selecting Advanced Security Level” on page 55

1 – 4

4. Verify that the security components were properly installed.

Appendix B, “Installed Files, Directories, and System Changes”

all


Configuring Security Content

Configuring Security ContentAfter PATROL Security is installed, you can run PATROL with the default security contents. However, this content is for demonstration purposes only and is NOT secure.

This section outlines the procedures that you must perform to configure PATROL Security to be secure. The content that you need to modify, replace, or add includes

■ key databases■ passwords■ public and private key pairs■ certificates■ Certificate Authority (trusted root authority)■ authentication provider■ encryption algorithm■ security ACL (level 4 only)

Considerations

Before configuring your security content, consider the following questions:

■ Do you want to create your own SSL key databases or modify the ones packaged with PATROL Security?

■ Do you want to run your applications in attended or unattended mode?

■ What naming conventions will you use for key databases and labeled key pairs?

■ Do you want to use the default authentication method for your operating system or set up Pluggable Authentication Module (PAM) on Unix or UserLogon( ) on Windows?

■ Which applications polices are being used by which PATROL applications? (See “PATROL Applications and Their Policies” on page 100.)


Setup Tasks

Setup Tasks

Table 10 lists tasks to perform after installation.

Table 10 Overview of Configuration Tasks


1. Create an SSL key database. “Creating an SSL Key Database” on page 70

required for 3 – 4,optional for 2

2. Install a CA certificate (trusted root certificate) into the key database.

“Installing a CA Certificate in the Key Database” on page 85


3. Verify CA certificate (trusted root certificate) is installed into the key database

“Verifying Trusted Root Authority Certificates” on page 86


4. Generate public and private keys. “Generating Public and Private Keys” on page 72


5. Create a certificate signing request (CSR).

“Creating a Certificate Signing Request” on page 89


6. Install a key pair certificate into the key database.

“Installing a User Certificate in the Key Database” on page 92


7. List signed certificates in the key database.

“Listing Certificates in the Key Database” on page 93


8. Discover which polices are employed by your PATROL applications.

“PATROL Applications and Their Policies” on page 100

all

9. Designate a key database for an applications.

“Designating a Key Database for an Application’s Role” on page 133


10. Set the Attended or Unattended Mode.

“Setting the Attended or Unattended Mode” on page 134


11. Edit the security access control list (ACL).

“Configuring the SSL access File” on page 166

4


Maintaining Security Content and Configuration

Maintaining Security Content and Configuration

PATROL Security provides a number of utilities that help you manage and maintain security in your PATROL environment.

This section groups these procedures by the security content that they affect.

Considerations

After you have performed the minimal configuration for your security content, consider the following ways in which you can manage and maintain security.

■ Do you want to be able to change the password to your key databases?

— If so, how often?

■ How will you manage and distribute passwords to key databases and policies?

■ How often will you update your certificate revocation list, which prevents compromised certificates from being accepted?

■ How will you manage key content over the network?

— by generating individual keys for each computer and distributing them— by exporting one key pair and importing it into key databases on all other

computers

■ Are you satisfied with the security level you chose during installation or would you like to change the security level for one or more computers?


Maintenance and Management Tasks


Table 11 lists tasks to manage and update various aspects of security.

Table 11 Overview of Maintenance Tasks (Part 1 of 2)


Key Database

1. Change the password for the key database.

“Changing the Password for the Key Database” on page 71

2 – 4

Key Pair and Certificates

1. Export and import key pairs and certificates.

“Exporting Key Pairs and Assigned Certificates” on page 76

“Importing Key Pairs and Assigned Certificates” on page 78

2 – 4

2. Change label (identity) of an imported key pair.

“Changing the Label of a Key Pair” on page 74

2 – 4

3. Delete private and public key pairs and certificates.

“Deleting Private and Public Key Pairs and Certificates” on page 75

2 – 4

4. List a certificate in the key database. “Listing Certificates in the Key Database” on page 93

2 – 4

5. Delete a certificate from the key database.

“Deleting a Certificate” on page 93 2 – 4

User Credentials (Labeled Passwords) in Key Databases

1. Add, list, and delete user credentials (labeled passwords), which are stored in key databases and used by PATROL applications to authenticate users.

“Adding User Credentials (Labeled Passwords)” on page 80

“Listing User Credentials (Labeled Passwords)” on page 81

“Deleting User Credentials (Labeled Passwords)” on page 82

2 – 4

Certificate Authority\Trusted Root

1. View field information for CA certificate (trusted root certificate).

“Viewing Field Information for CA Certificates” on page 87

2 – 4

2. Delete CA certificate (trusted root certificate).

“Deleting Trusted Root Authority Certificates” on page 88

2 – 4

Certificate Revocation List (CRL)

1. Acquire a CRL. “Acquiring a Certificate Revocation List” on page 95

2 – 4

2. Install a CRL. “Installing a Certificate Revocation List” on page 95

2 – 4



Policies

1. Learn the policy content and role. “Viewing the Policies and Roles” on page 115

2 – 4

2. List version information for security modules.

“Viewing Version Information for Security Modules” on page 117

2 – 4

3. Specify an authentication provider and service.

“Specifying an Authentication Provider and Service” on page 119

2 – 4

4. Select an encryption algorithm. “Selecting an Encryption Algorithm” on page 128

2 – 4

Passwords in Policies

1. Add or edit a password stored in a policy.

“Adding or Editing a Password Stored in a Policy” on page 135

2 – 4

Password Encryption

1. Encrypt a password for use as a key database password in a policy or user credential (labeled password).

“Encrypting a Password” on page 138 2 – 4

Security Level

1. Adjust security level for PATROL applications in your enterprise.

“Changing the Security Level for the Enterprise” on page 172

all

Table 11 Overview of Maintenance Tasks (Part 2 of 2)



Verifying Security Configuration

Verifying Security ConfigurationAfter you have customized the security content to suit your environment, verify that the changes have been implemented and that they were successful.

Considerations

Changes are opportunities for error, which can leave your environment exposed to security risk. Test any security configuration changes that you make.

Test Tasks

Table 12 lists tasks to perform when confirming the integrity of the configuration for PATROL Security.

Table 12 Overview of Testing Tasks


1. Test authentication provider. “Testing Authentication Configuration” on page 126

2 – 4

2. Test encryption algorithm. “Testing Encryption Algorithm” on page 131

2 – 4

3. Test client–server communication. “Testing a Secure TCP/IP Channel for the Client and Server” on page 145

2 – 4

4. Verify that the security components were properly installed.

“Viewing the Policies and Roles” on page 115

2 – 4

5. Test digital signing. “Testing Digital Signing” on page 141 2 – 4

6. Test the verification of a digital signature.

“Testing the Verification of a Digital Signature” on page 143

2 – 4


Performing Diagnostics

Performing DiagnosticsIf, even after you have verified your customization of security content, you encounter problems with PATROL Security, you can review your setup for the most common problems.

Considerations

When you encounter problems, check

■ the rights and privileges of the accounts under which you are running PATROL applications

■ the logs for the application policies and roles under which the application is running; the location of the log file for each role is specified in logdir and logfile attributes of that role section

Troubleshooting Tasks

Appendix B, “Troubleshooting” lists some common problems that can arise with regard to security. This appendix provides symptoms and their causes to assist you in diagnosing the problems and offers solutions to resolve the problems.

TIP The log files provide multilevel tracing of all conditions and the root cause of the condition.


Troubleshooting Tasks


C h a p t e r 3
3 Installation
PATROL Security and the Extended Security System (ESS) are installed during the installation process of the PATROL products with which ESS is integrated. Most of the installation options are determined by the product with which it is installed. However, you do get to specify the level of security, whether an existing security configuration is overwritten, and indirectly, where security components are installed.


Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Installation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Over-the-Top Installation and Policy Migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Compatibility with the Previous Version of PATROL Security . . . . . . . . . . . . . . . 49Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Selecting the Level of Security and Overwriting of Existing Security. . . . . . . . . . 53Selecting Advanced Security Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Selecting Connection Type for Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Location and Storage of Security Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Directories, Files Types, and Registry Keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56


Overview

OverviewThe PATROL Security and the Extended Security System components are packaged with all software infrastructure pieces. These components compose the foundation of the 3-tier architecture and include console systems such as the PATROL Central –Windows, common services such as the Console Server, and managed systems such

as PATROL Agents.

The necessary security components are installed when you install one or more of the infrastructure components.

Installation ProcessThe Extended Security System (ESS) is integrated with a number of PATROL products and does not have its own, separate installation process. The ESS components are installed during installation of these products. The position of the few security screens within the installation process varies depending upon the product with which it is packaged.

Over-the-Top Installation and Policy Migration

PATROL Security 3.0.05, which contains Extended Security System 3.0 (ESS3.0), can be installed over the previous version of PATROL Security 1.2.07, which contains Extended Security System 2.0 (ESS2.0). You do not have to uninstall the old version. The first time that you perform an over-the-top installation, the installation utility creates separate directories for the ESS3.0 files and then copies any customizations of the ESS2.0 configuration to the new ESS3.0 configuration.

The goal of the migration process during installation is to preserve the customizations that you have made to existing security content such as key databases, acquired key pairs, unattended passwords and other aspects.

The migration process preserves your ESS2.0 configuration while copying changes to your security content and configuration to the ESS3.0 configuration. This approach enables PATROL applications that use the ESS2.0 version (such as PATROL Agent 3.5.20.x) and other applications (such as the Console Server 7.5.x) that use ESS3.0 to operate on the same computer.

For information about migration, see “Policy Migration” on page 151.


Compatibility with the Previous Version of PATROL Security


PATROL Security 3.0.05, which contains Extended Security System 3.0 (ESS3.0), is fully compatible PATROL Security 1.2.07, which contains Extended Security System 2.0 (ESS2.0). This compatibility enables PATROL applications that use the ESS2.0 version, such as PATROL Agent 3.5.20.x, and other applications that use ESS3.0, such as the Console Server 7.5.x, to operate simultaneously on the same computer.

Compatibility is achieved by means of

■ separating policy locations■ separating runtime environments and directory structures■ sharing security contents■ providing network security protocols that are compatible over the wire

Separate policy locations

To preserve your custom configuration of the security policies in PATROL Security 1.2.07, the installation process creates a separate location in which to store PATROL Security 3.0.05 policy information. During migration, policy information is copied from PATROL Security 1.2.07 to the PATROL 3.0.05 location.

Table 13 lists the location of policies for both PATROL Security 1.2.07 (ESS2.0) and PATROL Security 3.0.05 (ESS3.0).

Table 13 Policy installation location

Operating system

Version of

PATROL Security Location

Windows 3.0.05(ESS3.0)

HKEY_LOCAL_MACHINE\Software\BMC Software\Patrol\SecurityPolicy_v3.0

1.2.07 (ESS2.0)

HKEY_LOCAL_MACHINE\Software\BMC Software\Patrol\SecurityPolicy

Unix 3.0.05(ESS3.0)

/etc/patrol.d/security_policy_v3.0

1.2.07(ESS2.0)

/etc/patrol.d/security_policy



Separate directory structures

To enable both PATROL Security 3.0.05 and PATROL Security 1.2.07 to run simultaneously on the same computer, the runtime environments have been separated into two distinct locations. Table 14 lists the installation path for both PATROL Security 1.2.07 (ESS2.0) and PATROL Security 3.0.05 (ESS3.0).

Shared security contents

To preserve customized security contents, such as unique key pairs, acquired certificates, and modified key databases, both PATROL Security versions use the same locations (keys and sks directories) to retrieve and store their security contents, as listed in Table 14.

Network protocols

All network security protocols modules are backward compatible to assure on-the-wire compatibility.

Table 14 Installation location for versions of PATROL Security

Installation path

PATROL Security 1.2.07 (ESS2.0)

PATROL Security 3.0.05(ESS3.0) File Types

%BMC_ROOT%\common\security (Windows)

$BMC_ROOT/common/security (Unix)

bin bin_v3.0 libraries and executables (.dll, .exe, .so)

log log_v3.0 log file (.log)

lib lib_v3.0 libraries (.a and .lib)

config config_v3.0 scripts, templates, and executables (.cmd, .conf, .exe, .plc, .reg, .sh)

keysa

a The keys directory and the sks directory are shared between PATROL Security 1.2.07 and PATROL Security 3.0.05.

key databases (.kdb) created at install or by user

sksa key databases (.kdb) created by PATROL applications


Customizations

Customizations

You can define the following aspects of the security system:

■ overwriting existing security settings in an over-the-top installation■ choosing the level of security level■ choosing connection type■ determining the installation path of the security components

Overwriting Existing Security Content

The installation process for PATROL Security enables you to overwrite existing security content and configuration.

Upgrading from PATROL Security 1.2.07 to 3.0.05

When you select the overwrite option during the installation, the installation process will replace the security content in the keys directory with the BMC Software default security content. If you have made any changes to that content such, as installed a Certificate Authority, generated unique key pairs, or install a certificate, you will lose those changes.

Installing PATROL Security 3.0.x over an existing 3.0.x installation

When you select the overwrite option during the installation, the installation process will replace the security content in the keys directory as described in “Upgrading from PATROL Security 1.2.07 to 3.0.05.” The process will also replace your security policies with the default policies. If you have made any changes to the security policies, such as configured authentication, changed the key databases used by a particular role, or added or changed a password, you will lose those changes.

Basic or Advanced Security

During installation, you are prompted to select the level of security that you want to implement for your PATROL installation. If you select Advanced Security, the installation utility presents a second screen that prompts you to select the level of security that you want.

WARNING BMC Software does not recommend selecting the Overwrite check box during the installation process to modify existing security content and configuration. This option will erase all changes to existing security content (acquired Certificate Authority certificates, updated key databases, custom-generated key pairs and certificates, modifications to policies) and require you to begin the security configuration process from the beginning.


Customizations

Location

The installation location of the security components is determined by the installation path that you choose for the product. Relative to the product, the installation utility always installs the security components in the same directory structure: BMC_ROOT\common\security.

For more information about the security components directory structure, see “Directories, Files Types, and Registry Keys” on page 56.

NOTE If you select Advanced Security (levels 1-4), you must configure various security components to create a secure environment.


Selecting the Level of Security and Overwriting of Existing Security


The first screen in the installation process that pertains to security is the Select Level of Security screen. As illustrated in Figure 3, the screen contains two user options: the security option and the overwrite option.

Figure 3 Select Level of Security Screen



Security Option

By using the security option, you can determine the type of security that you want to use in your PATROL installation:

■ Advanced security options—encompasses levels 1 through 4, which provide varying degrees of encryption and authentication but also require varying degrees of post installation configuration to make them secure, such as identifying a Certificate Authority, generating key pairs, acquiring certificates and so forth

■ Basic security—encompasses level 0, which does not require any additional configuration

Selecting the advanced option invokes the Select Level of Security Screen screen.

Overwrite Current Security Configuration

If you are installing into an environment that already has an existing PATROL installation, this option specifies whether to overwrite the existing security configuration information. Overwriting your security configuration means that you will have to reinstall

■ keys■ key databases■ certificates■ Certificate Authority certificate (also referred to as trusted root authority certificates)■ certificate revocation list

It may also involve re-entering changes or customizations to policy files and policy registry entries, patrol.conf, and config.default.


Selecting Advanced Security Level

Selecting Advanced Security Level

The installation process presents the screen that is show in Figure 3 to you only if you selected the Advance security options on the Select Level of Security Screen screen.

Figure 4 Select Advanced Level of Security Screen

Advanced Security Level

The Advanced security level option enables you to select the level of security at which you want PATROL to run.

For information about the levels of PATROL Security, see “Levels of Security” on page 18.


Selecting Connection Type for Security

Selecting Connection Type for Security

If you select advanced security levels 3 or 4, the installation process presents the Select Connection Type for Security screen.

Choose the network protocol for security communication, either

■ TCP■ UDP

Location and Storage of Security InformationThe components of the security infrastructure are installed in a dedicated subdirectory structure. This structure contains executables, shared libraries, key files, and logs related to security. The policy files, which define the level of security and store crucial information about how the security system is implemented, are stored in a subdirectory of /etc on Unix systems and in the Registry on Windows systems.

Directories, Files Types, and Registry Keys

Table 15 outlines the directory structure and registry paths (for Windows) in which the installation utility installs security information.

WARNING To ensure the integrity of your security components, limit access to the security directory structure and ownership of the security files.

Group access should be allowed only in environments where membership to groups is strictly defined, tightly controlled, and routinely monitored.



Table 15 Installation Paths of Security Files and Registry Keys

Location of Information Directory or Registry Path File Types or Registry Keys

Unix

BMC security directory $BMC_ROOT/common/security

Shared Libraries and Utilities

../common/security/bin_v3.0/Unix_platform

../common/security/lib_v3.0/Unix_platform

shared libraries (*.so)

executables (*.*)

Key databases ../common/security/keys key database files (*.kdb)

Configuration scripts and templates

../common/security/config_v3.0

Java ../common/security/java/v.r.mm Java archive (*.jar)

Log files ../common/security/log_v3.0 text file (*.log)

PATROL Security directory /etc/patrol.d

Policy files /etc/patrol.d/security_policy_v.30. policy file (*.plc)

Windows

security directory %BMC_ROOT%\common\security

Shared Libraries and Utilities

..\common\security\bin_v3.0\Windows-x86

..\common\security\lib_v3.0\Windows-x86

shared libraries / dynamically linked libraries (*.dll)

executables (*.exe)

Key databases ..\common\security\keys key database files (*.kdb)

Configuration scripts and templates

..\common\security\config_v3.0 registry entries (*.reg)

registry entry template (*.reg_tmpl)

Windows command scripts (*.cmd)

executables (*.exe)

Java ..\common\security\java\v.r.mm Java archive (*.jar)

Log files ..\common\security\log_v3.0 text file (*.log)

Registry Entries My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\BMC Software\PATROL\Security Policy_v3.0

policy keys esi

site

signer

verifier




C h a p t e r 4
4 Keys and Certificates
This chapter describes the roles that keys and certificates play in securing your environment and how to set up and configure them based upon the level of security that you select. This chapter provides both conceptual and practical information. It discusses the concept of authentication and explains how it uses keys and certificates for implementation. The tasks provide step-by-step instructions for configuring your security environment to support authentication by means of keys and certificates.


Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Types of Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Concepts and Components of Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Default Key Databases and Certificate Authorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Workflow for Configuring PKI-Based Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Utilities for Key Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

sslcmd Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67bmckeycli Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Management of Keys and Key Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Key Databases Shipped with PATROL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Creating an SSL Key Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Changing the Password for the Key Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Transferring a Keyfile.kdb from Unix to Windows Environment . . . . . . . . . . . . . 71Generating Public and Private Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Listing Public–Private Key Pairs in the Key Database. . . . . . . . . . . . . . . . . . . . . . . 73Changing the Label of a Key Pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Deleting Private and Public Key Pairs and Certificates. . . . . . . . . . . . . . . . . . . . . . 75Exporting Key Pairs and Assigned Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Importing Key Pairs and Assigned Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Management of User Credential (Labeled Password) . . . . . . . . . . . . . . . . . . . . . . . . . . 80Purpose and Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Adding User Credentials (Labeled Passwords) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Listing User Credentials (Labeled Passwords) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Deleting User Credentials (Labeled Passwords) . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Management of Certificate Authority. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Establishing a CA Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83


Installing a CA Certificate in the Key Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Verifying Trusted Root Authority Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Viewing Field Information for CA Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Deleting Trusted Root Authority Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Management of User Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Certificate Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Creating a Certificate Signing Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Installing a User Certificate in the Key Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Listing Certificates in the Key Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Deleting a Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Management of Certificate Revocation Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Description of a Certificate Revocation List (CRL) . . . . . . . . . . . . . . . . . . . . . . . . . . 94Missing Certificate Revocation List Warning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Acquiring a Certificate Revocation List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Installing a Certificate Revocation List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95


Authentication

AuthenticationKeys, key databases, and certificates facilitate the type of security referred to as authentication. In the context of PATROL, authentication is a means of security by which software components (consoles, servers, agents, and so forth) can programmatically verify that a component or the user of a component is who it states it is. For a component to authenticate the certificate of another component, the original component must trust the Certificate Authority (CA) of the component attempting the communication. In terms of keys and certificates, the original component must have in its key database a copy of the communicating component’s CA certificate.

Types of Authentication

Communication and the transfer of information or data involves two parties or components: a client and a server. SSL protocol authentication enables PATROL applications to positively authenticate the identity of the server, and optionally, of a client.

The different types of authentication protect against different susceptibilities in an enterprise.

■ SSL Protocol Server Authentication—A server, such as a PATROL Agent, presents a certificate to a client, such as a PATROL console 3.x or Console Server, so that the client can authenticate the server. In this type of authentication, the server is required to prove its identity.

Security level 2 and 3 supports server authentication; however, at level 2, the client does not discontinue communications if it cannot prove the server’s identity.

■ SSL Protocol Mutual Authentication—Both clients and servers present certificates to each other so that each can verify the identity of the other. Mutual authentication requires that both components, client and server, have the other’s CA certificate installed in its key database. In this type of authentication, both the server and the client are required to prove their identities.

Security level 4 supports mutual authentication.


Concepts and Components of Authentication


This section defines some concepts basic to authentication and describes the various components need to implement authentication.

Concepts

The following concepts apply to keys and certificates.

Chain of Trust

This is a principle of security by which a software component verifies the identity of an unknown party by accepting the assurance of a third party whose identity it knows is genuine. It is possible that this party’s identity is trusted because of the assurance of yet another party. This series of verifications by a trusted party continues (in a chain) until it is traced back to a trusted root (also known as a Certificate Authority) that the software component knows is trustworthy because it is provided by its own company or an approved vendor.

Digital Signing

This is the process of generating a hash value or check sum by applying an algorithm to a file. The check sum is then used by the recipient of the file to verify that the contents of the file have not been altered during transmission from the sender to the receiver. The check sum is protected by its being encrypted with the signer’s private key. The resulting value is called a signature.

BMC Software generates digital signatures in compliance with the Public-Key Cryptography Standard # 1 (PKCS#1) standard.

Digitial Verification

This is the process of decrypting a signature with the public key of the signer. The signer’s public key resides in the signer’s certificate, which must be stored in the key database used by an application operating in the verifier role.

Components

Certificate

This is a digital document containing a public key and a name used to authenticate the identity of the source of the data accompanying the certificate.



Certificate Authority

This is an issuer of an x509 certificate used in Secure Socket Layer (SSL) connections. It is also referred to as a trusted root authority.

Key

A key is a number (large) or set of numbers that possess mathematical properties that support both

■ encryption with a private key and decryption with a public key ■ encryption with a public key and decryption with a private key

Key Database

Also referred to as a key file and designated by the extension *.kdb, this file contains all the information necessary to verify a certificate. The file is encrypted with 3DES-CBC encryption and protected by a password. Its contents include

■ public keys for the software application and for the trusted roots■ private keys for the software application■ user certificates and trusted roots■ Certificate Revocation Lists (CRL)

Depending upon the various roles of a computer, more than one key database can exist on a single computer. The key database can contain any number of CAs, private and public keys, and user certificates.

Label

This is a descriptive, alphanumeric text string that is assigned to a key pair or password in the key database to help an administrator identify and manage the key and/or password.

In the sslcmd utility, a label is also referred to as identity.

Labeled Password

Sometimes the need arises for some means of securely storing the passwords to other systems in the key database. The sslcmd utility provides a means to assign to a password or other string of bytes a descriptive text string to help identify and manage the password.



Public Key Infrastructure (PKI)

This infrastructure provides the means for performing public and private key cryptography. PKI-based security includes Secure Socket Layer (SSL), digital signing, and verification.

Self-Signed Certificate

A self-signed certificate is a certificate issued directly by the Certificate Authority (CA). It is also referred to as a trusted root authority’s certificate.

sslcmd

This is the key management utility used to create, set up, and manage key databases and certificates.

User Credentials

This is the user name and password used by an application to verify the identity of a user. Some PATROL applications store user credentials in a key database. User credentials can be added to, viewed, or deleted from a key database using the sslcmd key management utility. User credentials are also referred to as Labeled Password.




Default keys and Certificate Authority (CA) certificates supplied by BMC Software and stored in key database files with .kdb extensions are provided only to demonstrate a turnkey security configuration, for purposes such as demonstrations and trial installations. Before using BMC Software products, replace the default keys and certificates with your own unique entities.

A password is required to open the default key files. The password for all default key files is password.

PATROL installs the BMC Software-provided default CA certificates in the key database in keys directory. The default certificates will expire on the date specified in the certificate, as shown in Table 16.


Table 16 Default Certificate Expiration Dates

Certificate Expiration

server Valid Begin: Fri Dec 17 11:08:29 2004

Valid End: Sun Dec 17 11:08:29 2006

bmcuser Valid Begin: Fri Dec 17 11:02:36 2004


signer Valid Begin: Fri Dec 17 11:15:08 2004



Workflow for Configuring PKI-Based Security

Workflow for Configuring PKI-Based SecurityConfiguration consists of the following key management operations:

■ selecting a Certificate Authority (or choosing to implement your own)■ obtaining a root authority’s certificate (a certificate from your chosen CA)■ creating a key database file■ inserting the root authority’s certificate (CA certificate) into the key database■ generating a public and private key■ generating a certificate signing request (CSR) for the public key■ obtaining a certificate■ viewing and deleting a certificate■ distributing key pairs and certificates throughout an enterprise

Table 17 suggests an order in which you may perform the configuration tasks for PKI-based security. In this chapter, the documented tasks have been organized according to the security entity (key database, certificate authority, certificate) that they affect.

NOTE This process applies to security level 2 or greater. If your PATROL installation runs at security levels 0 or 1, you do not need to perform these tasks.

Table 17 Order of Configuration Tasks for Authentication Security

Order Task Documentation Section Page

1. “Creating an SSL Key Database” Key and Key Database Management

70

2. “Installing a CA Certificate in the Key Database”

Certificate Authority Management

85

3. “Verifying Trusted Root Authority Certificates”


86

4. “Generating Public and Private Keys” Key and Key Database Management

72

5. “Creating a Certificate Signing Request”

Certificate Management 89

6. “Installing a User Certificate in the Key Database”


92

7. “Listing Certificates in the Key Database”


93


Utilities for Key Management

Utilities for Key ManagementThis section briefly describes the key management utilities installed with PATROL Security.

sslcmd Utility

The sslcmd utility is the key management utility with which you manage the key database and certificates to enable authentication.

Capabilities

This utility enables you to perform the following tasks:

■ generating, listing, and deleting keys■ adding, listing, viewing, and deleting a Certificate Authority■ adding, listing, and deleting certificates■ generating a Certificate Signing Request■ adding a Certificate Revocation List■ changing a password for the key database

Location

Table 18 provides the installation path of the sslcmd utility based upon the operating system.

Table 18 sslcmd Installation Location

Operating System Path

Windows %BMC_ROOT\..\common\security\bin_v3.0\OS

Unix $BMC_ROOT/../common/security/bin_v3.0/OS


bmckeycli Utility

bmckeycli Utility

The bmckeycli utility is a noninteractive version of the key management utility sslcmd. bmckeycli supports key management commands to be executed by CGI scripts, batch files or other scripts.

Capabilities


■ generating RSA/DSA key pair with selectable key length of 512 or 1024 ■ installing Certificate Authority (CA) certificate (trusted root authority’s certificate)■ generating certificate signing request (CSR)■ installing certificates■ listing and removing keys and certificates■ listing certificates only■ listing, viewing, and deleting trusted roots■ installing a new CRL from file■ importing and exporting key pairs in PKCS#12 format■ adding a password to password storage■ listing and deleting an application’s labeled passwords retrieved from storage■ changing the label of a key pair

For more information about bmckeycli, use the -h option.

Location

Table 19 provides the installation path of the bmckeycli utility based upon the operating system.

Table 19 bmckeycli Installation Location


Windows %BMC_ROOT%\..\common\security\bin_v3.0\OS

Unix $BMC_ROOT/../common/security/bin_v3.0/OS


Management of Keys and Key Databases

Management of Keys and Key DatabasesThis section describes key and key database tasks that you will perform using the sslcmd utility, including the configuration tasks listed in “Workflow for Configuring PKI-Based Security” on page 66 and the following tasks:

■ listing public and private key pairs in the key database■ exporting key pairs and assigned certificates■ importing key pairs and assigned certificates■ deleting private and public key pairs and certificates■ changing the key database file password

You can perform these tasks on the key databases shipped with PATROL or on the key databases that you create.

Key Databases Shipped with PATROL

During the installation process, depending upon the products that you select, the Common Installation utility may install the following key database files:

■ bmcuser.kdb

■ server.kdb

■ signer.kdb

■ verifier.kdb

■ trustedroots.kdb

In the client policy, the keyfile attribute is left blank. It defaults to bmcuser.kdb. The client requires a key database when running at security levels 2 through 4.

WARNING Do not delete or replace the trustedroots.kdb. This file is used by PATROL to verify the integrity of PATROL applications.

If you are concerned about the presence of the BMC Software Demo Certificate Authorities (CN = Demo Certificate Authority and CN = WWWQA Testing Certificate Authority) in this database, you can remove them from the database. For information about how to remove a CA, see “Deleting Trusted Root Authority Certificates” on page 88.


Creating an SSL Key Database

Creating an SSL Key Database

This procedure describes how to create a custom key database, also referred to as a keyfile.

To Create Your Own SSL Key Database

1 At a command-line prompt, change to the directory that contains the sslcmd utility. The path to the sslcmd utility is given in “Location” on page 67.

2 Start the sslcmd utility by entering sslcmd -k path\keyfile.kdb, where keyfile can be any alphanumeric string, except trustedroots.

To create the file in a directory (such as keys in which the default *.kdb files are installed), you must to provide the relative path, such as ..\..\keys\keyfile.kdb, because the keyfile does not exist. Figure 5 displays the sslcmd utility message.

3 Enter a password (at least eight characters and a combination of letters, numbers, or special characters).

4 Re-enter the password when prompted.

The system creates a new key database in the location that you specified (or in the default location, bin_v3.0, if you did not provide one) and displays the sslcmd menu.

For information about how to change the password, see “Changing the Password for the Key Database” on page 71.

NOTE These procedures are written using Microsoft Windows conventions. Users of Unix should make the appropriate substitutions where necessary.

Figure 5 sslcmd Example keyfile.kdb not found

File <keyfile> not found. Enter new key file <keyfile> password (at least 8 characters):

NOTE BMC Software recommends that you back up your key database file on a regular basis and keep the backup copy in a secure location.


Changing the Password for the Key Database

Where to go from here

After you have created a key database, you must edit the appropriate policy’s keyfile attribute so that the software application will use the correct key database. For information about how to edit a policy, see Chapter 5, “Security Policies.”

Changing the Password for the Key Database

This procedure describes how to change the password for a key database.

To Change the Password

1 At a command-line prompt, change to the directory that contains the sslcmd utility.

The path to the sslcmd utility is given in “Location” on page 67.

2 Start the sslcmd utility by enter sslcmd -k path\keyfile.kdb.

3 Enter the password for the SSL key database file that you want to access.

The system displays the menu.

4 At the Enter a choice prompt, enter 12 for Change KDB Password to change the current password, and then press Enter.

5 At the Enter new key file password (key_database_filename) prompt, type the new password and press Enter.

The password must a minimum of eight printable characters and a maximum of 255.

6 At the Retype password prompt, retype the new password and press Enter.

If the password change is successful, sslcmd displays the message, Command successful: Change KDB Password.

Transferring a Keyfile.kdb from Unix to Windows Environment

If you set a key database file using a Unix computer, you can use file transfer protocol (FTP) to transfer the file to a Windows computer. It is important to transfer the file using the bin command so that the file is transferred as a binary file rather than an ASCII file.


Generating Public and Private Keys

Generating Public and Private Keys

Before you can request a certificate from the Certificate Authority, you must generate a public and private cryptographic key pair as described below. A cryptographic key pair is a set of two cryptographic keys (one publicly shared and one private) used to start an SSL session. Next, assign that key pair to the new certificate for a BMC Software product user or product component.

To Generate Public and Private Keys (Key Pair)






4 At the Enter a choice prompt, enter 1 for Generate Key to generate a public–private key pair to be assigned to a new certificate, and then press Enter.

5 At the Enter identity prompt, enter an identity (alias) name for the key pair, and then press Enter.

The identity name is the ID that identifies the public–private key pair. The identity is usually the same as the name of the key database file.

6 At the Enter keypair type, D for DSA, <other> for RSA prompt, select an RSA algorithm by pressing Enter. (DSA, otherwise known as DSS, the USA's federal Digital Signature Standard, is not implemented).

7 At the Enter key length 512|1024 prompt, enter the size for the public–private key pair that you want to create, and then press Enter.

You can specify either a 512-bit or a 1024-bit key.

If the key generation is successful, sslcmd generates the public–private key pair and displays the message, Command successful: Generate key.


To verify that the key pair has been created, see “Listing Public–Private Key Pairs in the Key Database” on page 73.


Listing Public–Private Key Pairs in the Key Database

Listing Public–Private Key Pairs in the Key Database

This procedure describes how to display the identity (alias name) of the generated key pair and any certificates that use the key pair.

To List Keys






4 At the Enter a choice prompt, enter 5 for List keys to list the public–private key pairs in the SSL key database, and then press Enter.

For each key pair, the utility displays the label assigned to the certificate that uses the public–private key pair. If no certificate exists, the label has a value of 0 and the name of the generated key pair is displayed under the label value. After all key pairs are listed, the utility displays the message, Command successful: List keys.


Changing the Label of a Key Pair

Changing the Label of a Key Pair

Labels are assigned to key pair to make them easily identifiable and manageable. This procedure describes how to change an existing label assigned to a key pair, even an imported key pair.

To Change the Key Pair Label






4 At the Enter a choice prompt, enter 18 for Change Label of Key Pair, and then press Enter.

5 At the (-) Enter identity prompt, type the alphanumeric text string (alias name) used to identify the key pair.

For information about how to view the identity of a key pair, see “Listing Public–Private Key Pairs in the Key Database” on page 73.

6 At the (+) Enter identity prompt, type the alphanumeric text string (alias name) to which you want to change the label, and then press Enter.

If the label change is successful, sslcmd displays the message, Command successful: Change Label of Key Pair.


Deleting Private and Public Key Pairs and Certificates

Deleting Private and Public Key Pairs and Certificates

This procedure describes how to remove a key pair (private and public keys) from a key database. Removing the key pair also removes any certificates that are assigned to and thus encrypted\decrypted by that key pair.

To Remove a Key Pair and Certificate






4 At the Enter a choice prompt, enter 6 for Delete key, and then press Enter.

5 At the Enter identity prompt, enter the identity (alias) name of the key pair that you want to delete from the SSL key database, and then press Enter.

6 At the Confirm deletion of prompt, enter y for yes, and then press Enter.

Enter n if you do not want to delete.

sslcmd deletes the key pair and its associated certificates from the key database and displays the message, Command successful: Delete key.


Exporting Key Pairs and Assigned Certificates


Exporting key pairs from one key database and importing them into another is a means to distribute keys and certificates. The export process provides two forms of protection: key encryption and Message Authentication Code (MAC), commonly referred to as check sum. The encryption of the key pair allows you to transfer the pair to another computer by a insecure method. The check sum feature ensures that the encrypted key pair has not been altered or corrupted.

This procedure describes how to export a private–public key pair and its related certificates so that they can be easily transferred to another computer and imported into a second key database.

To Export a Key Pair






4 At the Enter a choice prompt, enter 17 for Export Key Pair, and then press Enter.

5 At the Export File Name prompt, type a filename, and press then Enter.

6 At the Enter identity prompt, type the identity of the key pair, and then press Enter.

7 At the Encryption password prompt, type a password, and press then Enter.

The password must be a minimum of eight printable characters and a maximum of 255, and should consist of printable characters.

8 At the Retype password prompt, re-enter the password, and then press Enter.

NOTE The encryption password is the key to the encryption algorithm that is used to encode the exported key. Because only the authorized recipient is supposed to know the password, only the authorized recipient will be able to decrypt the exported key.



9 At the MAC password, type a password, and then press Enter.

The password must be a minimum of 8 printable characters and a maximum of 255.

10 At the Retype password prompt, re-enter the password, and then press Enter.

sslcmd generates a PKCS#12 formatted file with the name that you supplied in step 5 and displays the message, Command successful: Export Key Pair.

NOTE Message Authentication Code (MAC) protection, also referred to as a check sum, is incorporated into the exported key file. During importation of the exported key, the MAC provides a means of verifying that the file containing the exported key was not altered in any way during transit. This check prevents an intruder from changing the imported key value from that which was exported.

Frequently, the encryption password and the MAC password are the same value.


Importing Key Pairs and Assigned Certificates


Importing key pairs and assigned certificates is an efficient way to distribute public–private keys throughout an enterprise. This procedure describes how to import a key pair and a certificate assigned to it that has been exported into a Public Key Cryptography Standard number 12 (PKCS#12) formatted file.

Before you begin

■ For importing, sslcmd expects a file containing a private key and its associated certificate in PKCS#12 format.

■ You must acquire the encryption password and the MAC password from the user that created the exported key pair file.

■ The root authority (CA) of the private key’s associated certificate must already be present in the key database. Otherwise, the database cannot authenticate the keys and certificate and will not import them into the database.

For information about how to add a CA certificate, see “Installing a CA Certificate in the Key Database” on page 85.

To Import a Key Pair and Certificate






4 At the Enter a choice prompt, enter 16 for Import Key Pair, and then press Enter.

5 At the Import File Name prompt, type a filename, and then press Enter.

6 At the Encryption password prompt, type the password, and then press Enter.

The user that exported this key pair assigned the encryption password to it. You must get the password from that user.



7 At the MAC password prompt, enter a password and press Enter.

The user that exported this key pair assigned the encryption password to it. You must get the password from that user.

sslcmd imports the key pair and certificate and displays the message, Command successful: Import Key Pair.


For information about how to view the key pair in the key database, see “Listing Public–Private Key Pairs in the Key Database” on page 73.


Management of User Credential (Labeled Password)

Management of User Credential (Labeled Password)

To protect user credentials (user passwords), PATROL applications store them in key databases. To be able to identify the passwords and extract them from the key database when needed, the PATROL applications assign a text string to them. This text string is called a label and passwords with an assigned label are referred to as Labeled Passwords.

This section describes the following labeled password tasks that you can perform using the sslcmd utility:

■ adding user credentials (labeled passwords) to a key database■ listing user credentials that are stored in a key database■ deleting user credentials from a key database

Purpose and Usage

The sslcmd utility provides a means to assign an identity or tag to a password in the same manner as a public–private key pair. The labeled password can then be stored securely in the key database, along with the rest of the private data belonging to the security system. Applications can retrieve the password from the key database, using the label to identify it.

Adding User Credentials (Labeled Passwords)

This procedure describes how to add a labeled password into the key database.

To Add User Credentials (Labeled) Password







Listing User Credentials (Labeled Passwords)

4 At the Enter a choice prompt, enter 13 for Add Labeled Password, and then press Enter.

5 At the Enter identity prompt, type a description text string for the password, and then press Enter.

6 At the Password (identity_name) prompt, type a password, and then press Enter.

7 At the Retype Password prompt, type the password, and then press Enter.

sslcmd displays the message Command successful: Add Labeled Password.

Listing User Credentials (Labeled Passwords)

This procedure describes how to list labeled password stored in a key database.

To List Labeled Passwords Stored in a Key Database






4 At the Enter a choice prompt, enter 14 for List Labeled Password, and then press Enter.

sslcmd lists all the labeled passwords in the key database and displays the message Command successful: List Labeled Password.

NOTE The key management utility list the labels but does not display the values of the passwords.


Deleting User Credentials (Labeled Passwords)

Deleting User Credentials (Labeled Passwords)

This procedure describes how to delete a labeled password from a key database.

To Delete a Labeled Password from a Key Database






4 At the Enter a choice prompt, enter 15 for Delete Labeled Password, and then press Enter.

5 At the Enter identity prompt, type the identity (also referred to as the label) of the password, and then press Enter.

6 At the Confirm deletion of identity_name (y/n) prompt, type y, and then press Enter.

sslcmd deletes the labeled password that you specified from the key database and displays the message, Command successful: Delete Labeled Password.


Management of Certificate Authority

Management of Certificate AuthorityThis section describes certificate tasks that you will perform using the sslcmd utility, including the configuration tasks listed in “Workflow for Configuring PKI-Based Security” on page 66 and the following tasks:

■ viewing field information for CA certificates■ deleting trusted root authority certificates

Establishing a CA Certificate

After you have generated a Certificate Signing Request (CSR) by using the sslcmd utility, you can submit the CSR to one of several public companies that serve as Certificate Authorities (CA) or your company can acquire the necessary software and credentials and become its own Certificate Authority. Examples of Certificate Authorities are

■ Certiposte Serveur■ Deutsche Telekom Root CA 1■ Entrust.net Secure Server Cerification Authority■ GTE Cyber Trust Root■ IPS SERVIDORES■ Microsoft Root Authority■ SecureNet■ VeriSign Trust Network

The CA certificate should be obtained from the Certificate Authority by a secure means. Using the sslcmd utility, this certificate can then be loaded into the security module’s key database. After the certificate is loaded, it can be presented to any peer. This certificate contains a genuine copy of the CA’s public key.

NOTE BMC Software does not make any recommendations for the companies listed as examples. These companies are listed only to demonstrate the prevalence and diversity of companies that provide Certificate Authority service.


Establishing a CA Certificate

Secure Manner

A certificate should be obtained in a secure manner from a trusted CA. Failure to do so undermines the endeavor to provide security. In this context, a secure manner is defined as a manner in which the certificate is transferred (physically or electronically) from the CA to a key database without being intercepted and altered by a third party.

Certificate Format

A certificate that you obtain must be an ASCII text file in version 3 of the X.509 PEM (Privacy-Enhanced Mail) Base64 format. The key management utility (sslcmd) uses the X.509 ASCII string format to import certificates. You can obtain CA certificates from your chosen Certificate Authority.

WARNING Obtaining a Certificate Authority certificate from the internet is not considered a secure manner.


Installing a CA Certificate in the Key Database

Installing a CA Certificate in the Key Database

This procedure describes how to install a CA certificate, also referred to as a trusted root authority certificate, into a key database.

Before you begin

You must have already obtained a CA certificate in the required format, as described in “Establishing a CA Certificate” on page 83.

To Install a Root Authority Certificate in the Key Database






4 At the Enter a choice prompt, enter 2 for Add CA, and then press Enter to add a CA’s certificate to the key database.

5 At the Enter CA certificate file name prompt, enter the path relative to the current directory and the file name of the CA certificate, and then press Enter.

The system installs the specified CA certificate in the SSL key database and displays a verification message.

NOTE The CA certificate that you are installing in this task differs from the public–private keypair certificate that you install in “Installing a User Certificate in the Key Database” on page 92.


Verifying Trusted Root Authority Certificates

Verifying Trusted Root Authority Certificates

This procedure describes how to list all the CA certificates, also referred to as the trusted root authority certificates, that have been installed in a key database.

To Verify Trusted Root Authority Certificates






4 Enter 8 for List CA, and then press Enter.

sslcmd displays a list of CA certificates in the key database. After the information is displayed, the utility displays the message, Command successful: List CA.


Viewing Field Information for CA Certificates

Viewing Field Information for CA Certificates

This procedure describes how to display the information stored within the certificate such as label name, country, and encryption method.

To View CA Certificate Information






4 At the Enter a choice prompt, enter 9 for View CA, and then press Enter.

5 At the Enter CA number to view prompt, enter the number for the CA certificate that you want to view.

sslcmd displays the information about the CA certificate in the key database is displayed. After the information is displayed, the utility displays the message, Command successful: View CA.


Deleting Trusted Root Authority Certificates

Deleting Trusted Root Authority Certificates

If you learn that a CA’s certificate has been compromised or you discontinue using the services of a particular CA, you should remove the CA’s certificate from your key database.

This procedure describes how to remove the certificate.

To Remove CA Certificate from a Key Database






4 At the Enter a choice prompt, enter 10 for Delete CA, and then press Enter.

5 At the Enter CA number prompt, enter the number of the CA certificate that you want to delete and press Enter.

For information about how to view a list of CA certificates, see “Verifying Trusted Root Authority Certificates” on page 86.

6 At the Confirm deletion of <number> (y/n) prompt, enter y.

sslcmd deletes the CA certificate and displays the message, Command successful: Delete CA.

TIP BMC Software recommends that you remove the Demo Certificate Authorities (CN = Demo Certificate Authority and CN = WWWQA Testing Certificate Authority) from the trustedroots.kdb.


Management of User Certificates

Management of User CertificatesThe difference between a Certificate Authority (CA) certificate and a user certificate is that a user certificate is associated through a label or identity with a private–public key pair stored in the key database. The CA certificate contains only the public key.

This section describes certificate tasks that you will perform using the sslcmd utility, including the configuration tasks listed in “Workflow for Configuring PKI-Based Security” on page 66 and the following tasks:

■ listing signed certificates in the key databases■ deleting certificates

Certificate Format

The certificates that you obtain must be an ASCII text file in version 3 of the X.509 PEM (Privacy-Enhanced Mail) Base64 format. The key database administrator utility (sslcmd) uses the X.509 ASCII string format to import certificates. You can obtain these certificates with Microsoft Certificate Server, Netscape Certificate Server, and OpenSSL.

Creating a Certificate Signing Request

This procedure describes how to create a certificate signing request that is associated with a key pair that your generated and that can then be submitted to your Certificate Authority.

Before you begin

You must generate a public and private cryptographic key pair (as described in “Generating Public and Private Keys” on page 72. Next, you generate a certificate signing request that is associated with the key pair that you generated.

To Create a Certificate Signing Request








4 At the Enter a choice prompt, enter 3 for Generate CSR, and then press Enter.

5 At the CSR output file name prompt, enter the file name for the generated CSR, and then press Enter.

Unless you provide a path relative to the executable’s working directory along with the file name, sslcmd creates the CSR output file in the directory in which the executable resides.

6 At the Enter alias name prompt, enter the alias (identity) name for the key pair that you generated, and then press Enter.

The alias is the alphanumeric string that identifies the public–private key pair. The alias is usually the same as the name of the key database file.

7 When prompted to supply the information of the distinguished name (DN) associated with your new certificate, see Table 20 to help you determine what information is needed for each prompt.

Table 20 Distinguished Name Prompts

Prompt Description of Requested Value

Country the 2-character country code of the certified’s resident address.

For a list of codes, see Appendix C, “Valid Country Codes.” For example, the country code for the United States is US.

State the 2-character abbreviation of the state of the certified resident’s address

For example, the state code for Texas is TX.

Locality the address of the certified resident

Name the organization to which the certified person belongs

Unit the body within an organization to which the certified person belongs

Common name the name of the entity that you are certifying

E-mail address the return e-mail address for the certified person

This value is used by the ESS connection profile ACL_Deny and ACL_Allow configuration variables, which are stored in the access file. At level 4 security, the e-mail address must match the value (literal string or expression with wildcards) set in the configuration variables.



After you respond to all of the prompts, a CSR is generated and is ready for you to submit to the trusted CA for signing. If the generation of the signing request is successful, the message Command successful: Generate CSR appears and the system writes the certificate signing request (CSR) to the file that you specified in step 5 on page 90.


Your next task is to present the certificate signing request (CSR) to your Certificate Authority (CA). Depending upon how your CA accepts CSRs, you will either have to use a text editor to extract the contents of the CSR and copy and paste it into a form or you can import the CSR file.

Your CA will respond by giving you a signed certificate that you can then install in your key database, as described in “Installing a User Certificate in the Key Database” on page 92.


Installing a User Certificate in the Key Database

Installing a User Certificate in the Key Database

Installing a user certificate in the key database makes the certificate available to the BMC Software security subsystem for use in secure product communications.

This procedure describes how to install the certificate that you received from your Certificate Authority into the key database from which you generated the Certificate Signing Request (CSR).

Before you begin

■ You must have installed the CA (trusted root authority) certificate from the vendor site to the database, as described in “Installing a CA Certificate in the Key Database” on page 85.

■ You must have generated a CSR and submitted it to the vendor site, as described in “Creating a Certificate Signing Request” on page 89.

■ You must have generated and downloaded the signed certificate from the vendor.

To Install a User Certificate in the Key Database






4 At the Enter a choice prompt, enter 4 for Add cert to add a digital certificate to the key database, and then press Enter.

5 At the Enter certificate file name prompt, enter the file name for the digital certificate that you downloaded from the vendor site, and then press Enter.

If the certificate is added, sslcmd displays the message: Command successful: Add Cert.

WARNING You must install the CA (trusted root authority) certificate in the key database before you install a user certificate in the database. If you do not, the key management utility fails to install the user certificate and returns a -45 error code.


Listing Certificates in the Key Database

Listing Certificates in the Key Database

This procedure describes how to view a list of signed certificates in a key database.

To List Certificates in a Key Database






4 At the Enter a choice prompt, enter 7 for List certs to list the digital certificates installed in the SSL key database, and then press Enter.

For each signed certificate, sslcmd displays the label assigned to the certificate and the information that was assigned using the distinguished name prompts (see Table 20 on page 90). After the certificates, the utility displays the message Command successful: List Cert.

Deleting a Certificate

Deleting a private–public key pair also removes from the key database all the certificates associated with that key pair. For information about how to delete keys, see “Deleting Private and Public Key Pairs and Certificates” on page 75.


Management of Certificate Revocation Lists

Management of Certificate Revocation ListsIf the private key is given to an unauthorized entity or otherwise compromised, use a Certificate Revocation List (CRL) to invalidate it.

The CRL is maintained by the Certificate Authority (CA). Similar to user certificates, CRLs are time stamped and signed by the issuing CA.

When the private key associated with the public key contained in the certificate is compromised, the owner of the compromised private key should immediately notify the CA that signed the certificate. The CA then publishes a CRL, which lists the certificate as having been revoked. Each user of a particular CA should obtain the CRL of that CA on a regular basis and install the CRL in the key database, so that if the revoked certificate is presented at a later date, the software will detect it as a revoked certificate and the chain of trust will be broken. The frequency with which you acquire updated CRLs should be determined by the sensitivity of the application.

Description of a Certificate Revocation List (CRL)

CRLs are signed by the CA that issues them. The key database will not accept a CRL that has not had the certificate of the CA previously installed; therefore, a chain of trust for a CRL is established in the same manner as one for a certificate that is to be installed. A CRL is obtained from the CA by e-mail or over the web.

CRL Format

In the PATROL environment, the CRL is stored in Base64 encoding, as shown Figure 6.

PATROL does not display the contents of the CRL.

Figure 6 Example of a CRL Stored in a Key Database

-----BEGIN CERTIFICATE REVOCATION LIST----- MIIBVDCBvjANBgkqhkiG9w0BAQQFADB5MQswCQYDVQQGEwJVUzEOMAwGA1UECBMFVGV4YXMxEDAO BgNVBAcTB0hvdXN0b24xEjAQBgNVBAoTCUNvcnBvcmF0ZTEVMBMGA1UECxMMQk1DIFNvZnR3YXJl MR0wGwYDVQQDExRCTUMgU29mdHdhcmUgQ0EgUm9vdBcNMDExMDA0MTkzNTQ3WhcNMDExMDA0MTk1 NTQ3WjAUMBICAQkXDTAxMDkxNzIxMDkzM1owDQYJKoZIhvcNAQEEBQADgYEACh2SCmVhnnYXz95G SHQ2WJbMBgjYkGvC4w/FF+c+4Q66ONbEZGmSFec3WfgW53Xb9C5RwKSDwU3ORPYkH2yVhaUSDZkF 7M2AQdShu3K9fh3gs4pO1EBF/fOW4Frrc39w9fYML/3Jqp+9IOspJw9Ymx3S0bub9Q+nnS6YofkM Up0=-----END CERTIFICATE REVOCATION LIST-----


Missing Certificate Revocation List Warning

Precedence of New CRLs

As new CRLs are issued by the CA, they are installed. New CRLs overwrite any previous ones pertaining to that CA. Once a CRL is installed in the key database, you cannot remove it independently of the CA certificate. CRLs can only be updated.

Missing Certificate Revocation List Warning

The PATROL warning message REVOCATION UNKNOWN indicates that a chain of trust for a certificate has been established, but no CRL can be found for the CA. That is, the certificate is validated, but there is no list present to see if it has been revoked.

PATROL does not accept a missing list as meaning no certificates have been revoked. Only a signed CRL that is empty can accomplish this.

Acquiring a Certificate Revocation List

Contact your Certificate Authority to see how you can obtain its CRLs on a regular and timely basis.

Installing a Certificate Revocation List

This procedure describes how to install a CRL.

To Install a CRL

1 Obtain the new CRL from the trusted CA.



WARNING PATROL does not regard REVOCATION UNKNOWN as a fatal error. When this error occurs, a PATROL component does not prevent another component from establishing a connection and communicating with it.

To ensure the security of your PATROL environment and to prevent this message from occurring, install a CRL (regardless of its contents) for the CA that signed the certificate.


Installing a Certificate Revocation List




5 At the Enter a choice prompt, enter 11 for Add CRL, and then press Enter.

6 At the Enter crl file name prompt, enter the file name of the CRL that you want to install in the key database, and then press Enter.

sslcmd installs the CRL into the key database and displays the message Command successful: Add CRL.


C h a p t e r 5
5 Security Policies
This chapter describes what security policies are, what part they play in PATROL Security, what kind of information they contain, and how that information is organized, formatted, and stored. This chapter provides both conceptual and practical information. It discusses the concepts of roles and explains how they are implemented by using files on Unix and registry entries on Windows. The tasks provide step-by-step instructions for how to create, configure, manage, test, and trouble-shoot these configurations. Finally, this chapter covers the automated migration process used to upgrade earlier versions of PATROL Security to the most current version.


Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Site Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Application Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Policy Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Policy Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Inheritance and Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106PATROL Configuration Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Format and Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Microsoft Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Utilities for Policy Testing and Password Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 111esstool Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111plc_password Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112bmcryptpw Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113signFile and verifyFile Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Policy and Role Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Creating a Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Viewing the Policies and Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Viewing Version Information for Security Modules . . . . . . . . . . . . . . . . . . . . . . . 117

Authentication and Encryption Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Specifying an Authentication Provider and Service . . . . . . . . . . . . . . . . . . . . . . . 119Testing Authentication Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Selecting an Encryption Algorithm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128


Listing the Encryption Algorithms Supported by the Encryption Module . . . . 130Testing Encryption Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Key Database and Password Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Designating a Key Database for an Application’s Role . . . . . . . . . . . . . . . . . . . . . 133Setting the Attended or Unattended Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Adding or Editing a Password Stored in a Policy. . . . . . . . . . . . . . . . . . . . . . . . . . 135Encrypting a Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Signer and Verifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Operation of Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Operation of Verifying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Testing Digital Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Testing the Verification of a Digital Signature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Client-Server Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Testing a Secure TCP/IP Channel for the Client and Server. . . . . . . . . . . . . . . . . 145

Policy Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151PATROL Security versus Extended Security System . . . . . . . . . . . . . . . . . . . . . . . 151ESS 3.0.00 and ESS 3.0.05. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Migration Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152Migrate or Overwrite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153Migration Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153


Introduction

IntroductionA collection of data that defines and controls how security is implemented is referred to as a security policy. Security policies contain set up and configuration information for implementation of PATROL Security, which addresses potential security violations. The policies associate the potential security violations and the capability to prevent them with the types of applications that interact within the PATROL environment. The functions of these applications are termed roles within PATROL Security. PATROL provides security roles that, when properly configured, can address any security problem posed by applications fulfilling these roles. Security roles for PATROL applications include

■ authenticator■ encryptor■ keystore■ client■ server■ signer■ verifier

In a PATROL environment, the security policies define each role by storing in a series of policy attributes the details of how much security is implemented for an application operating in that role. These attributes define such aspects of security as

■ the PATROL Security level■ which key database to use■ the encrypted password required to access a key database■ the amount of security information written to the security log and its location■ the mode setting, which determines whether a password must be manually

entered to start an application■ the location of security information such as key databases and key material files

used to generate unique keys

At startup, each PATROL component attempts to load two security policies to determine its security configuration: a general site policy and a specific application policy. In the Unix environment, policies are implemented as *.plc files. In Windows environments, policies are implemented as registry entries.


Site Policy

Site Policy

The default security policy is the site policy (site.plc on Unix; site registry entry on Windows). It is the only required security policy. The site policy defines the security configuration shared by PATROL services and provides the minimal amount of information that a PATROL component needs to load and run the Extended Security System (ESS) module.

The site policy contains the default attributes for all security roles. The site policy attributes can be overridden by optional application policy attributes.

Application Policy

Application policies define roles, which contain attributes used by specific applications, such as agents or consoles. Application policies can override and augment the basic security policy for all PATROL services.

As each application is initialized, the attributes specified for its role are loaded from the site policy. Selected attributes of the site policy are then modified by the application policy. Any attributes specified in the application policy take precedence over or override the attributes of the site policy.

For more information about how policies operate, see “Inheritance and Precedence” on page 106.

PATROL Applications and Their Policies

For PATROL applications, security policies are stored in different locations on Unix and Windows. Table 21 provides the location based upon the operating system.

TIP The application policy name used by a PATROL application is built into that application. You cannot change which application policy a PATROL application loads.

To change the policy information for a PATROL application, you must edit the policy that the PATROL application references. For information about which PATROL applications employ which policies, see Table 22 on page 101.

Table 21 Policy Installation Location

Operating System Type of Storage Location

Windows registry key HKEY_LOCAL_MACHINE\Software\BMC Software\Patrol\SecurityPolicy_v3.0

Unix directory/file /etc/patrol.d/security_policy_v3.0


Policy Roles

Table 22 shows the policy configuration files or Windows registry entries that correspond to each PATROL application. The site policy is not listed because it is the default policy of every PATROL application and is required.

Policy Roles

The roles specify security capabilities of the application process. An application process that acts as a client will adopt the security constraints defined by the security policy’s client role. A server application will adopt the server role.

Within the context of security, application processes can have multiple roles. Besides the communication roles, a process can also operate in an authentication role. An application can also operate in either a signer or verifier role by applying a signature to a file, by verifying a signature of a file, or by both signing and verifying signatures.

Table 22 PATROL Applications and Their Corresponding Application Policy Names

PATROL ApplicationApplication Policy Files (Unix)

Application Policy Registry Entry Keys (Windows)

PATROL 3.5 console console.plc console

PATROL Central – Microsoft Windows Edition 7.x

not applicable pcentral

PATROL Agent 3.5 or later agent.plc agent

PATROL Console Server cserver.plcclient.plc

cserverclient

PATROL Event Manager 3.5a,PATROL Console 3.4.11, PATROL Agent 3.4.11 and earlier, PATROL Command Line Interface,pconfig

a All applications that run in a PATROL 3 session or interact with PATROL using the PEM API will use the esi policy by default.

esi.plc esi

PATROL Configuration Managerb

b PATROL Configuration Manager employs this application policy for use with only its reporting function. The key database specified by the policy stores user names and passwords of PATROL Agents for which the manager generates reports.

pcm.plc pcm

SignFile utility(digital signature signing CLI utility)

signer.plc signer

VerifyFile utility(digital signature verification CLI utility)

verifier.plc verifier


Policy Roles

To define these roles for each application, policies consist of sections. Each section describes a role. In Unix, sections are designated by square brackets [ ] around a rolename: [role_name]. In Windows, sections are registry keys. Table 23 lists all the possible policy roles and describes each one’s purpose.

Table 23 Policy Roles (Part 1 of 2)

Roles Description

common specifies the shared configuration for all applications

This role consolidates into one section all the attributes essential to the implementation of security. The Common policy section of a site security policy provides default values for the following policy attributes:

bindir – 32-bit binaries’ locationbindir64 – 64-bit binaries’ locationlogdir – location of log fileslogfile – default log file nameloglevel – default log levelsecuritydir – location of private files such as key databases and key files

client specifies security configuration of a client application

At a minimum, the Client section should specify the security level, log level, and log file name and log file location. It supports the following attributes: keyfile, logdir, logfile, loglevel, password, and security_level.

server specifies security configuration of a server application

At a minimum, the Server section should specify the security level, log level, and log file name and location. It supports the following attributes: keyfile, logdir, logfile, loglevel, password, and security_level.

authenticator specifies security configuration of an authentication application

The Authentication section enables a user to specify an authentication provider and service parameters. It supports the following attributes: provider and service.

encryptor specifies security configuration of a bulk encryption module

The Encryptor security section specifies the encryption algorithm. It has one attribute, cipher_type.

keystore specifies the configuration of a keystore security application

A keystore application provides integrity and protection to confidential user data. It supports the following attributes:

keyfile – the path to the key database (*.kdb) for this policy’s applicationpassword – the password required to access the key database. This attribute is optional. Include it only if you want to run in unattended mode.


Policy Attributes

Policy Attributes

To define each role policies contain attributes, which are assigned to roles. Attributes define the contents of security policy by defining specific actions that an application can and cannot perform with regards to security. Attributes also define characteristics of the application (role) within the context of PATROL.

In the policies installed by PATROL Security, the default set of attributes assigned to each role is considered the optimal configuration. Table 24 lists all the possible policy attributes and describes each one’s purpose.

signer specifies which keystore (and thus user-created keys) that the application uses when signing data

The Signer section lists attributes provided in both the Common and Keystore sections such as keyfile, password, and log attributes. It supports the following attributes: identity, keyfile, logdir, logfile, loglevel, password, and security_level.

verifier specifies which keystore (and thus user-created keys) the application uses when verifying signed data

The Verifier section lists attributes provided in both the Common and Keystore sections such as keyfile, password, and log attributes. It supports the following attributes: identity, keyfile, logdir, logfile, loglevel, password, and security_level.

Table 24 Policy Attributes (Part 1 of 3)

Attribute Description

bindir a specifies the absolute path of the security 32-bits library

bindir64 a specifies the absolute path of the security 64-bits library

cipher_type specifies the encryption algorithm cipher type used by the encryption module

For a list of values, see “Table 35 on page 128“.

identity specifies the name or label under which the keypair is stored in the SSL keystore

keyfilea specifies the location of a SSL keystore database

logdira specifies the absolute path to a subdirectory where the log file will be written

logfilea specifies the log file path

When only a file name is provided, the log file is created in the current working directory.

Table 23 Policy Roles (Part 2 of 2)

Roles Description


Policy Attributes

loglevel ERROR, WARNING, INFO, TRACE specifies the log level desired.

Any comma-separated combination of these tokens can be used to generate error, warning, or diagnostics log messages. To generate security-level information in the log file, you must include the INFO token.

password specifies an unattended service encrypted password, key material, and optional lock mode required to retrieve the master password from the SSL key databases

The encrypted password can be generated offline using bmcryptpw.

The value consists of the following parameters separated by commas: encrypted_password, keymaterialfile location, [optional lock mode].

■ encrypted _password – specifies the encrypted password generated by the offline bmcryptpw or plc_password password encoding program

For more information, see “bmcryptpw Utility” on page 113 or “plc_password Utility” on page 112. The password encryption method is based on Triple DES PCBC cipher and CBC checksum.

■ keymaterialfile – is the user-supplied file used for 3 DES key computation

Any file can be used as a key material. You are responsible for administrative protection of the file. In operational environment, limit file exposure to the service startup only, and physically remove a file (for example, from a floppy disk drive) after the service is running. You are responsible for the protection and security risk taken due to the selection of such an unattended service startup.

For a discussion of the security risks inherent in unattended operation, see “Setting the Attended or Unattended Mode” on page 134.

■ lock_mode field - user or ip – specifies additional data, inserted during 3 DES key computation

When user lock mode is specified, only the user specified at the time when password was encrypted using bmcryptpw or plc_password (-u user option) can decode the password.

When ip lock mode is specified, the local host’s IP address is inserted during the key computation. The password can be decoded only on a computer with the same IP address as the one on which the password was encrypted.




Policy Attributes

provider specifies an authentication security mechanism and overrides the default mechanism that is provided by the operating system

A common provider for Unix systems is Pluggable Authentication Modules (PAM). A common provider for Microsoft Windows is LogonUser. The service attribute specifies to which application, such as rlogin or telnet on Unix and LOGON32_LOGON_ INTERACTIVE on Windows, the provider supplies security.

service specifies additional details of security mechanism listed in the provider attribute

securitydira specifies the directory where sensitive key information is stored (for example, SSL keystore or key material files)

security_level is a security grade (0-4) that specifies the methodology and security strengths of the application

0 is weakest; 4 is strongest.

If the security_level field is deleted or contains an empty string, the level of security defaults to 4. This differs from the PATROL installation process, which defaults to 0 (basic security level).

a Ensure that all file path conventions comply with operating system naming conventions.




Inheritance and Precedence

Inheritance and Precedence

PATROL applications load two policies: the site policy and an application specific policy. When starting up a PATROL application first loads the site policy. After loading the site policy, PATROL loads the application policy.

The resulting configuration

■ supplements the security established by the site policy with application policy attributes that the site policy does not contain

■ overwrites the site policy roles with corresponding application roles

■ inherits the site policy roles that the application policy does not contain

PATROL Configuration Files

In PATROL, security configuration and setup information are stored in PATROL configuration files (patrol.conf, config.default, dlls.conf, and access) and security policies. These files are discussed in Chapter 6, “Configuration Files.”

EXAMPLE The Console Server plays the role of server (using the server policy) when communicating with a PATROL Central console. At the same time, the Console Server plays the role of client (using the client policy) when communicating with a PATROL Agent.

Table 25 Order of Precedence

Order Action

1. Commona section of a site security policy is read in.

a To ensure backward compatibility with ESS2.0 policy, the common role section of the policy is optional.

2. Role section of a site security policy provides or overrides previously read parameters

3. Role section of an application security policy provides or overrides previously read parameters


Format and Implementation

Format and ImplementationDue to the differences in how the Windows and Unix operating systems manage and store sensitive information, the implementation of security differs. This section describes those differences in detail.

Unix

In Unix environments, a security policy is implemented as an ASCII text file. The format of the file is the standard .ini format.

Implementation of Roles

Roles are implemented as stanzas, which are indicated by the role name enclosed in square brackets ([ ]).

Attributes are implemented as attribute/value pairs, which are formatted as attribute_name1 = value1, value 2, value N and ended by a new-line character.

Location of Policy Files

Separate files store the individual policies. On Unix computers, .plc files store the policies. They are located in the following directory:

/etc/patrol.d/security_policy_v3.0

Example of Unix Policy File with Stanzas and Attributes

Figure 7 displays a typical site policy (site.plc) for a Unix operating system.

Figure 7 Sample Site Policy File (site.plc) for Unix (Part 1 of 2)

[common] bindir = /local/xyz/common/security/bin_v3.0/solaris-2-9-sparc bindir64 = /local/xyz/common/security/bin_v3.0/solaris-2-9-sparc-64 securitydir= /local/xyz/common/security/keys logdir = /local/xyz/common/security/log_v3.0 sksdir = /local/xyz/common/security/sks

[client] security_level=0 loglevel = ERROR,WARNING logfile = site_client.log


Unix

[server] security_level=0 loglevel = ERROR,WARNING logfile = site_server.log

[signer] security_level=0 password = 17fa9e37f011ec79ef0b32d00cbc98c4f4ca367272714f6b, /local/xyz/common/security/keys/sample.bin keyfile = /local/xyz/common/security/keys/signer.kdb identity = signer loglevel = ERROR logfile = site_signer.log

[verifier] security_level=0 password = 17fa9e37f011ec79ef0b32d00cbc98c4f4ca367272714f6b, /local/xyz/common/security/keys/sample.bin keyfile = /local/xyz/common/security/keys/trustedroots.kdb loglevel = ERROR logfile = site_verifier.log

[authenticator] loglevel = ERROR logfile = site_authenticator.log

[keystore] password = 17fa9e37f011ec79ef0b32d00cbc98c4f4ca367272714f6b, /local/xyz/common/security/keys/sample.bin loglevel = ERROR logfile = site_keystore.log

[encryptor] password = 17fa9e37f011ec79ef0b32d00cbc98c4f4ca367272714f6b, /local/xyz/common/security/keys/sample.bin loglevel = ERROR logfile = site_encryptor.log

Figure 7 Sample Site Policy File (site.plc) for Unix (Part 2 of 2)


Microsoft Windows

Microsoft Windows

In Windows environments, a security policy is defined by registry keys placed in the Windows registry.

Implementation of Roles

Roles are implemented as one or more registry keys.

Attributes are implemented as attribute/string values assigned to a registry key. Attribute/string values are entered in the Edit String dialog box, an example of which is displayed in Figure 8.

Figure 8 Edit String Dialog Box

Location of Policy Registry Keys

Separate registry keys store the individual policies. On Windows, a .reg file sets the registry entries. After being set, the policy information is stored in the following Registry location.

HKEY_LOCAL_MACHINE\Software\BMC Software\Patrol\SecurityPolicy_v3.0


Microsoft Windows

Example of Windows Policy with Registry Keys and String Values

Figure 9 displays a typical site policy implemented in the form of a registry key for a Windows operating system. Figure 10 demonstrates what a security policy looks like when viewed from the Windows Registry Editor.

Figure 10 Regedit View of Site Policy Registry Key for Windows

Figure 9 Sample Site Policy Registry Key for Windows

My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Bmc Software\PATROL\SecurityPolicy_v3.0\site


Utilities for Policy Testing and Password Encryption

Utilities for Policy Testing and Password Encryption

This section briefly describes the policy testing tool and the password encryption tools installed with PATROL Security.

esstool Utility

The esstool utility is a command-line, diagnostic tool that provides information about the security configuration.

Capabilities


■ discovering which policies and roles have been implemented■ testing authentication■ testing encryption methods (algorithm)■ testing client-server communication■ viewing utility version information

Location

Table 26 provides the installation path of the esstool utility based upon the operating system.

Table 26 esstool Installation Location


Windows %BMC_ROOT\..\common\security\bin_v3.0\<OS>

Unix $BMC_ROOT/../common/security/bin_v3.0/<OS>


Usage

Usage

The esstool is used to perform the following tasks:

■ “Viewing the Policies and Roles” on page 115■ “Viewing Version Information for Security Modules” on page 117■ “Testing Authentication Configuration” on page 126■ “Testing Encryption Algorithm” on page 131■ “Testing a Secure TCP/IP Channel for the Client and Server” on page 145

plc_password Utility

The plc_password utility is the key management utility with which you encrypt and manage (store) key database passwords in the security policies.

Capabilities


■ encrypt passwords using a user-specified file as a unique key■ assign an encrypted password to a role■ store encrypted password into a site or application policy■ change the password for a key database■ set the mode to attended or unattended■ restrict who or from what computer an encrypted password can be decrypted

Location

Table 27 provides the installation path of the plc_password utility based upon the operating system.

Table 27 plc_password Installation Location





Usage

Usage

The plc_password is used to perform the following tasks:

■ “Setting the Attended or Unattended Mode” on page 134■ “Adding or Editing a Password Stored in a Policy” on page 135

bmcryptpw Utility

The bmcryptpw utility is the command-line utility with which you can encrypt and verify passwords. The results can be used as a key database password and entered into a policy or as user credentials (labeled password) and entered into the key database of a PATROL application.

Capabilities


■ encrypt passwords using a user-specified file as a unique key■ verify that a text string is an encrypted password■ restrict who or from what computer an encrypted password can be decrypted

Location

Table 28 provides the installation path of the bmcryptpw utility based upon the operating system.

Usage

The bmcryptpw is used to perform the following task:

■ “Encrypting a Password” on page 138

Table 28 bmcryptpw Installation Location





signFile and verifyFile Utilities

signFile and verifyFile Utilities

The signFile and verifyFile utilities are the command-line utilities that can be used to test the process of digitally signing and verifying digital signatures.

Capabilities

These utilities enables you to perform the following tasks:

■ sign a file■ verify a file

Location

Table 29 provides the installation path of the signFile and verifyFile utility based upon the operating system.

Usage

The signFile and verifyFile utilities are used to perform the following tasks:

■ “Testing Digital Signing” on page 141■ “Testing the Verification of a Digital Signature” on page 143

Table 29 signFile and verifyFile Installation Location





Policy and Role Information

Policy and Role InformationPolicies establish the configuration of security. This section enables you to manage that configuration by describing

■ what aspects of security you can control through a policy■ how to exercise control through changes to policies■ how to test the effectiveness and success of those changes

Creating a Security Policy

Security policies are created and installed by the installation utility during the installation of PATROL components. During the installation process, the installation utility asks you questions about security. It uses those answers to configure your the security policies on that computer for the applications that you are installing.

Viewing the Policies and Roles

This procedure describes how to view what security an application will use when it starts up.

To Learn Which Policies Are Being Used and Which Roles Are Being Played

1 At a command-line prompt, change to the directory that contains the esstool utility. The path to the esstool utility is given in “Location” on page 111.

2 Enter esstool policy and desired options. Figure 11 and Figure 12 provide examples of how to enter the esstool policy command.

WARNING Creating a security policy is an automated process. BMC Software strongly recommends against your creating a customized policy or modifying a policy through means other than those provided by the installation utility.

Figure 11 esstool policy Example on Windows

esstool policy -r server -a -S PATROL\SecurityPolicy_v3.0\site-P PATROL\SecurityPolicy_v3.0\agent


Viewing the Policies and Roles

Table 30 lists the options and their arguments.

3 Press Enter.

esstool displays the information that you requested in the command. Figure 13 provides sample output for the esstool policy function on Windows. On Unix, the content of the output is the same but the format differs.

Figure 12 esstool policy Example on Unix

esstool policy -r server -a -S ../config_v3.0/patrol.plc-P ../config_v3.0/agent.plc

Table 30 esstool policy Options

Option Argument Description

-r role designates the role whose security policy information you want to view

Possible roles include client, server, signer, verifier, keystore, encryptor, and authenticator.

-a prints out all the security policy for the specified role

-b checks to see that the security module required for the current security level is present and loads it

-S path supplies the path of the site policy if it is stored in a location other than the default location

-P path supplies the path of the site policy if it is stored in a location other than the default location

-? (Optional) prints usage information and exits

Figure 13 esstool policy Example Output on Windows

security role: server security level: 2, SSL anonymous site policy: SOFTWARE\BMC\PATROL\SecurityPolicy_v3.0\site application policy: SOFTWARE\BMC\PATROL\SecurityPolicy_v3.0\agemt log level: ERROR,WARNING log file: esi_server.log keyfile: C:\Program Files\BMC\common\security\keys\server.kdb identity: server sksdir: C:\Program Files\BMC\common\security\sks securityDir: C:\Program Files\BMC\common\security\keys logdir: C:\Program Files\BMC\common\security\log_v3.0 bindir: C:\Program Files\BMC\common\security\bin_v3.0\Windows-x86 network security module: C:\Program Files\BMC\common\security\bin_v3.0\Windows-x86\bmcssl.dll BCA API version BCA Version 1.0|ess3.0.5.21|win32|Jan 26 2005|11:42:43 last error:


Viewing Version Information for Security Modules


PATROL Security supports the following security modules:

■ Spyrus Secure Socket Layer (SSL)■ Diffie-Hellman■ PATROL ESI

This procedure describes how to view the security module capabilities including version, build dates, identification information, and operating system.

To View the Supported Encryption Algorithms


2 Enter esstool query security_module. Figure 14 provides an example of how to enter the esstool query command.

Table 31 lists the security modules and their associated files for the supported platforms.

Figure 14 esstool query Example on Windows

esstool query bmcssl.dll

Table 31 Security Modules

Security Module Windows Unix

Spyrus Secure Socket Layer (SSL) bmcssl.dll bmcssl.so

Diffie-Hellman bmcdh.dll bmcdh.so

PATROL ESI bmcesi.dll bmcesi.so



3 Press Enter.

The esstool utility lists the security module capabilities. Figure 15 provides sample output for the esstool query function on Windows. On Unix, the content of the output is the same but the format differs.

Figure 15 esstool query Result Example on Windows

doing BMC_LoadModule bmcssl.dll Module bmcssl.dll loaded by userSecurity Module capabilities (bmcssl.dll)-----------------------------------------version: SSL Module, Version 1.0|ess3.0.5.21|win32|Jan 26 2005|11:43:21 (Domestic) authentication: MUTUAL ciphers v1: des_64_cbc_with_md5, des_192_ede3_cbc_with_md5, rc4_128_with_md5, rc2_128_cbc_with_md5, rc4_128_export40_with_md5, rc2_128_cbc_export40_with_md5 ciphers v2: rc4_128_with_md5, rsa_with_rc4_128_md5, rsa_with_rc4_128_sha, rsa_with_3des_ede_cbc_sha, dhe_rsa_with_3des_ede_cbc_sha, dhe_dss_with_3des_ede_cbc_sha, dhe_rsa_with_des_cbc_sha, dhe_dss_with_des_cbc_sha, des_192_ede3_cbc_with_md5, rc2_128_cbc_with_md5, rsa_with_des_cbc_sha, des_64_cbc_with_md5, dhe_dss_with_rc4_128_sha, rsa_with_rc4_40_md5, rsa_with_rc4_56_sha, rsa_with_des_64_sha, rsa_with_rc2_40_md5, rsa_with_des40_cbc_sha, rc4_128_export40_with_md5, dhe_dss_with_des_64_sha, dhe_dss_with_rc4_56_sha, dhe_dss_export_with_des40_cbc_sha, dhe_rsa_export_with_des40_cbc_sha, rc2_128_cbc_export40_with_md5 ciphers v3: rsa_with_rc4_128_md5, rsa_with_rc4_128_sha, rsa_with_3des_ede_cbc_sha, rsa_with_des_cbc_sha, dhe_rsa_with_3des_ede_cbc_sha, dhe_dss_with_3des_ede_cbc_sha, dhe_rsa_with_des_cbc_sha, dhe_dss_with_des_cbc_sha, dhe_dss_with_rc4_128_sha, rsa_with_rc4_40_md5, rsa_with_rc4_56_sha, rsa_with_des_64_sha, rsa_with_rc2_40_md5, rsa_with_des40_cbc_sha, dhe_dss_with_des_64_sha, dhe_dss_with_rc4_56_sha, dhe_rsa_export_with_des40_cbc_sha, dhe_dss_export_with_des40_cbc_sha authorization: SERVER_ACL


Authentication and Encryption Information

Authentication and Encryption InformationThis section describes how to override the default authentication method supplied by the operating system and select an encryption algorithm. It also discusses how to test these changes.

Specifying an Authentication Provider and Service

Operating systems support different authentication providers and services. Because this information is stored in the policy, the procedures for specifying an authentication provider and service are different for different the platforms.

This procedure is divided into two procedures:

■ how to specify an authentication provider and service in a Windows environment■ how to specify an authentication provider and service in a Unix environment

Microsoft Windows

The Microsoft Windows operating system provides a default authentication method, LogonUser, used by ESS3.0. Therefore, when specifying authentication, you can select which authentication service is used by the LogonUser function.

To Specify an Authentication Service

1 Access the Site policy.

2 Navigate to the Authenticator role. If this role does not exist in the site policy, add it.

NOTE Regardless of the platform, you can specify only one authentication provider and only one service per policy.



3 Edit the service attribute. If this attribute does not exist, add it. The supported service values are

LOGON32_LOGON_BATCH—is for batch servers, where processes can execute on behalf of a user without their direct intervention. This type is also for higher performance servers that process many plaintext authentication attempts at a time, such as mail or Web servers. For this logon type, the LogonUser function does not store credentials.

LOGON32_LOGON_INTERACTIVE—is for users who will be interactively using the computer, such as a user being logged on by a terminal server, remote shell, or similar process. This logon type has the additional expense of caching logon information for disconnected operations; therefore, it is inappropriate for some client/server applications, such as a mail server.

LOGON32_LOGON_SERVICE— is for a service-type logon. The service privilege must be enabled for the logon account.

LOGON32_LOGON_NETWORK—is for high performance servers to authenticate plaintext passwords. For this logon type, the LogonUser function does not store credentials.

4 Save the policy and exit the application that you used to edit the policy.



Unix

Some variants of the Unix operating system automatically use either shadow passwords or NIS account databases for authentication. The PATROL Security component enables you to configure it to use Pluggable Authentication Module (PAM) services. To do so, you must determine which PAM services your system uses. Then, in the site policy, you must specify the PAM service that you want to employ.

To Determine Which PAM Services Are in Use

On Unix, PAM Services are specified in a system file stored in the /etc directory. Table 32 lists the platforms on which PATROL Security supports PAM services and the name and location of the PAM configuration file on those platforms.

Navigate to the appropriate directory and perform a cat operation on the file, cat pam.conf. Figure 16 provides an example of the files contents. For details about PAM Services, see the documentation for your operating system.

Table 32 Location of the PAM Configuration File by Operating System

Platform Version Example of File Location/Type

AIXa

a AIX requires operating system patches and the manual installation of the Kerberos PAM module library. For instructions, see “AIX Kerberos Support” on page 123.

5.2 or later /etc/pam.conf

HP 11.0 or later /etc/pam.conf

Linux all /etc/pam.d

Solaris 5.6 or later /etc/pam.conf

Figure 16 pam.conf Example

##ident “@(#)pam.conf 1.16 01/01/24 SMI”## Copyright (c) 1996-2000 by Sun Microsystems, Inc.# All rights reserved.# # PAM configuration# # Authentication management# login auth required /usr/lib/security/$ISA/pam_unix.so.1login auth required /usr/lib/security/$ISA/pam_dial_auth.so.1#rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1...



To Set Up Authentication Provider and Service

1 Access the Site policy. The path to the policy is

cd /etc/patrol.d/security_policy_v3.0/site.plc

2 Navigate to the Authenticator role. If this role does not exist in the policy, add it.

3 Edit the provider attribute. If this attribute does not exist, add it.

The only supported authentication providers for Unix that you can specify for this attribute is pam, Pluggable Authentication Module (PAM)

4 Edit the service attribute.

For PAM, the supported service values are listed in /etc/pam.d/pam.conf file. Such services include login, ftp, telnet, passwd, pop, and many others. Figure 17 provides an example of the contents of a Site policy file on Unix.


NOTE On Unix, attribute values are case-sensitive. Enter the value as it appears within the operating systems. For example, if a file lists a service in mixed case such as TelNet, enter the attribute value in mixed case, TelNet.

Figure 17 Authenticator Role of Site Policy on Unix

[authenticator]provider = pamservice = login



AIX Kerberos Support

PATROL Security 3.0.05 supports Kerberos authentication on AIX 5.2 or later. However, you must ensure that certain IBM updates have been applied to the operating system. You will also need to configure some files.

Required IBM Updates (APAR)

To support Pluggable Authentication Module (PAM) on AIX 5.2 or later, you must install IBM updates (APARs). Table 33 lists the version and the required updates.

Configuring AIX to Support Kerberos

PATROL Security supports Pluggable Authentication Module (PAM) on AIX 5.2 or later. To configure PATROL Security, you must manually update the pam.conf file with the location of the pam_krb5.so file and update the krb5.conf. For more information about how to select this authentication provider, see “Specifying an Authentication Provider and Service“ in Chapter 5 “Security Policies” of the PATROL Security User Guide.

To Support AIX

1 Access /etc/patrol.conf. Copy or record the location of pam_krb5.so.

2 Navigate to the directory that contains pam_krb5.so.

3 Change the file permissions of pam_krb5.so to 755.

4 Access /etc/pam.conf.

Table 33 IBM Updates for AIX 5.2 or Later

Operating System APAR Run-Time Environment (RTE)

AIX 5.2 32–bit none none

AIX 5.2 64–bit IY66349 none

AIX 5.3 64–bit IY66349 bos.rte.libc 5.3.0.2bos.rte.security 5.3.0.2

AIX 5.3 32–bit none bos.rte.libc 5.3.0.2bos.rte.security 5.3.0.2

NOTE This procedure involves modifying files in the /etc directory. To perform this procedure, you must have root access.



5 Add the service and location information to pam.conf. Figure 18 provides an example of what the entry will look like. Your services and the path to pam_krb5 may differ from this example.

6 Save and exit the file.

7 Navigate to /etc.

8 Access krb5.conf. If it does not exist, create it.

9 Edit the realms stanza to reference the Kerberos Key Distribution Center (KDC) server and the Kerberos administration server.

Figure 19 provides an example of a krb5.conf in which the KDC server and the Kerberos administration server is installed on the server kdc.bmc.com.


Figure 18 Example of Reference to pam_krb5 in pam.conf

klogin auth required /auth/lib/security/bmc/pam_krb5klogin account required /auth/lib/security/bmc/pam_krb5klogin password required /auth/lib/security/bmc/pam_krb5klogin session required /auth/lib/security/bmc/pam_krb5

Figure 19 krb5.conf Example

[libdefaults]default_realm = BMC.COM

[realms]

BMC.COM = {kdc = kdc.bmc.comadmin_server = kdc.bmc.comdefault_domain = bmc.com

}

[domain_realm].bmc.com = BMC.COMbmc.com = BMC.COM

[logging]default=FILE:/var/log/krb5lib.log




To test the configuration of this authentication, see “Testing Authentication Configuration” on page 126.


Testing Authentication Configuration


This procedure describes how to verify a user name and password and test the authentication module. The password can be verified by checking the password file, checking the shadow password file, or using the password authentication module (PAM).

To Verify a User Name and Password Using Authentication


2 Enter esstool authenticator and desired options. Figure 20 provides an example how to enter the esstool command to test the PAM Login Service.

Table 34 list the options and their arguments.

Figure 20 esstool authenticator Example on Windows

esstool authenticator -d my.company.com -u Admin1 -p adminpwd-S Patrol\SecurityPolicy_v3.0\site-P Patrol\SecurityPolicy_v3.0\console

Table 34 esstool authenticator Options (Part 1 of 2)


-d domain lists the Windows domain authenticates against

If no domain is specified, the default is null.

-u user_name specifies the user name of the account to be verified

This option is required.

-p password specifies the password to be verified

This option is required.

-n number repeat the test the number of times specified by the argument

The default is 1.

-w checks the supplied password against the shadow password





3 Press Enter.

esstool displays the results of the authentication test. Figure 21 provides sample output for the esstool authentication function on Windows. On Unix, the content of the output is similar.

-r provider specifies the provider of authentication that is being tested

Use this option to test a provider other than the one specified in the authentication role.

-s service specifies the service whose authentication is being tested

Use this option to test a service other than the one specified in the authentication role.

-? prints usage information and exits

The help option is optional.

Figure 21 esstool authentication Results Example on Windows

Site policy = 'SOFTWARE\BMC\Patrol\SecurityPolicy_v3.0\site'Appl policy = 'SOFTWARE\BMC\Patrol\SecurityPolicy_v3.0\console' BAA Version:BAA Module, Version 1.0|ess3.0.5.21|win32|Jan 26 2005|11:44:24 caps: BAA Module, Version 1.0|ess3.0.5.21|win32|Jan 26 2005|11:44:24 caps: NTLM |LogonUser |LOGON32_PROVIDER_DEFAULT |LOGON32_LOGON_BATCH |LOGON32_LOGON_INTERACTIVE |LOGON32_LOGON_SERVICE |LOGON32_LOGON_NETWORK ** Authentication successful **

Table 34 esstool authenticator Options (Part 2 of 2)



Selecting an Encryption Algorithm


The default cipher used by ESS 3.0 encryptor is Data Encryption Standard (DES) cipher des-cbc. It is backwards compatible with the encryption method used by ESS2.0 release. You can overwrite the default cipher by using the cipher_type attribute in the Encryptor role of the Site policy. PATROL supports the following encryption algorithms operating in cbc, cfb, ecb, and ofb modes.

■ Blowfish■ CAST■ Data Encryption Standard (DES)■ Triple Data Encryption Standard (3DES)■ RC2■ RC4

This procedure describes how to specify which supported encryption algorithm, other than the default, PATROL uses.

To Select an Encryption Algorithm

1 Access the Site policy.

2 Navigate to the Encryptor role. If this role does not exist in the site policy, add it.

3 Edit the cipher_type attribute. If this attribute does not exist, add it.

Table 35 lists the supported encryption algorithms and their corresponding cipher types.

Table 35 Supported Encryption Algorithms and Their Cipher Values (Part 1 of 2)

Encryption Algorithm Cipher Type Values

Blowfish bf-cbcbfbf-cfbbf-ecbbf-ofb

CAST cast-cbccastcast5-cbccast5-cfbcast5-ecbcast5-ofb



To generate a complete list of supported ciphers types from the encryption module, see “Listing the Encryption Algorithms Supported by the Encryption Module” on page 130.


DES des-cbcdesdes-cfbdes-ofbdes-ecbdes-ede-cbcdes-ededes-ede-cfb

3DES des-ede-ofbdes-ede3-cbcdes-ede3des3des-ede3-cfbdes-ede3-ofbdesx

RC2 rc2-cbcrc2rc2-cfbrc2-ecbrc2-ofbrc2-64-cbcrc2-40-cbc

RC4 rc4rc4-40

Table 35 Supported Encryption Algorithms and Their Cipher Values (Part 2 of 2)

Encryption Algorithm Cipher Type Values


Listing the Encryption Algorithms Supported by the Encryption Module

Listing the Encryption Algorithms Supported by the Encryption Module

This procedure describes how to view the ciphers types supported by the encryption module.

To View The Supported Encryption Algorithms


2 Enter esstool query encryption_module, where the encryption module for Windows is bmcpwk.dll and the encryption module for Unix is libbmcpwk.so.

3 Press Enter.

The esstool utility displays the supported cipher types. Figure 22 provides sample output for the Windows encryption module, bmcpwk.dll.

Figure 22 Sample List of Cipher Types for bmcpwk.dll

Security Module capabilities (bmcpwk.dll)-----------------------------------------version: BPW Module, Version 1.0|ess3.0.5.12|win32|MMM dd CCYY|HH:MM:SS crypto: OpenSSL 0.9.7c 30 Sep 2003bf-cbc|bf|bf-cfb|bf-ecb|bf-ofb|cast-cbc|cast|cast5-cbc|cast5-cfb|cast5-ecb|cast5-ofb|des-cbc|des|des-cfb|des-ofb|des-ecb|des-ede-cbc|des-ede|des-ede-cfb|des-ede-ofb|des-ede3-cbc|des-ede3|des3|des-ede3-cfb|des-ede3-ofb|desx|rc2-cbc|rc2|rc2-cfb|rc2-ecb|rc2-ofb|rc2-64-cbc|rc2-40-cbc|rc4|rc4-40


Testing Encryption Algorithm


This procedure describes how to verify that the encryption algorithm and cipher type that you are using is functioning correctly.

To Verify an Encryption Algorithm


2 Enter esstool encryptor and desired options. Figure 23 provides an example of testing encryption.


Figure 23 esstool encryptor Example

esstool encryptor -c rc2-64-cbc -p mypassword -e test_string

Table 36 esstool encryptor Options (Part 1 of 2)




-c cipher name specifies the encryption algorithm.

The default is des-cbc. For a list of supported encryption algorithms and cipher types, see Table 35 on page 128.

-p password specifies a temporary password for the encryption\decryption test

-l lock_string lock string used to perturb password

-e string encrypt the string provided as argument

Either this option or -d is required.

-d string decrypt the string provided as argument

Either this option or -d is required.

-D string decrypt the results of the encryption option

This option requires the -e option.



3 Press Enter.

esstool displays the information that you requested in the command.

Figure 24 provides an example of testing encryption. Figure 25 provides an example of testing decryption.

The “Anticipated decryption error” in both the examples results from an internal esstool test that is not expected to succeed. Disregard it.

- n number repeat the test the number of times specified by the argument

The default is 1.



Figure 24 esstool encryptor Example of Encryption Command and Output

esstool encryptor -p mypassword -e test_string

Creating new policy ...Site policy='..\SecurityPolicy_v3.0\site'Appl policy='..\SecurityPolicy_v3.0\agent'ModuleName C:\..\security\bin_v3.0\Windows-x86\bmcpwk.dllBPW Module Version 1.0|ess3.0.5.13|win32|Nov 10 2004|11:33:36test_string->pGkxdmT3nGI+YoAzXk30l2EXIZX...Anticipated decryption error -1.

Figure 25 esstool encryptor Example of Decryption Command and Output

esstool encryptor -p mypassword -d pGkxdmT3nGI+YoAzXk30l2EXIZX

Creating new policy ...Site policy='..\SecurityPolicy_v3.0\site'Appl policy='..\SecurityPolicy_v3.0\agent'ModuleName C:\..\security\bin_v3.0\Windows-x86\bmcpwk.dllBPW Module Version 1.0|ess3.0.5.13|win32|Nov 10 2004|11:33:36pGkxdmT3nGI+YoAzXk30l2EXIZX->test_string...Anticipated decryption error -1.

Table 36 esstool encryptor Options (Part 2 of 2)



Key Database and Password Information

Key Database and Password InformationThis section describes how to designate a key database for different policy roles. It also explains how to encrypt passwords and insert them into policy roles. Finally, this section discusses how to test these changes.

Designating a Key Database for an Application’s Role

The key database that an application uses is specified in the role section of a security policy. For each role of the policy, a different key database can be specified.

This procedure describes how to designate in a site or application policy a key database for the role which an application plays.

To Designate a Key Database for an Application

1 Access the Site or an application policy for the application that runs on the current computer. For example, if you are running a PATROL Agent on this computer, you should access the server security policy.

2 Navigate to the role of the application for which you want to designate a key database. If the desired role does not exist in the policy, add it.

3 Edit the keyfile attribute by setting the value equal to the key database filename (*.kdb). If this attribute does not exist, add it.

4 Repeat step 2 and step 3 for the role of each application with which the application that owns this policy file interacts.



If you want the to interact in unattend mode, you must add a password for each keyfile attribute that you set. For information about how to add passwords to policies, see “Adding or Editing a Password Stored in a Policy” on page 135.

NOTE You can specify a key database in the role section for the application that runs on this computer. You can also specify a key database in the respective role section of each application with which this application interacts.


Setting the Attended or Unattended Mode

Setting the Attended or Unattended Mode

The mode determines whether a user must manual type in a password to start up an application. Setting the mode involves storing a password in a security policy or removing a password from one. Figure 26 provides an example of adding a password to an application policy and setting the mode to unattended using the plc_password utility.

For information about how to encrypt a password and save it to a security policy, see “Adding or Editing a Password Stored in a Policy” on page 135.

WARNING To guarantee the security of an application running in unattended mode, you must maintain physical security of the computer by placing it in an area with restricted access. You must also insure the operational security of its operating system by closely controlling those ports which are open to the outside and shutting down unnecessary services that can be exploited.

These precautions are necessary because the password is stored on the computer. Although the password is encrypted, no means of password encryption is indecipherable, and thus the computer is at risk of being compromised.

Figure 26 plc_password Example Setting Mode to Unattended

plc_password -r server -P \etc\Patrol.d\SecurityPolicy_v3.0\agent -m unattended -n Da$h4ca$h -f scramble.bin -k agent.kdb

NOTE The PATROL Agent on OpenVMS and PATROL Agent on iSeries (AS400) run in unattended mode only.


Adding or Editing a Password Stored in a Policy


Policy files can contain passwords for many different roles. The usage and storage of passwords determines the security and ease-of-use of a PATROL installation.

This procedure describes how to create an encrypted password using a secret key for a key database and then install the password and a reference to the secret key in the appropriate role section of a policy file.

To Add or Change a Password in a Policy

1 At a command-line prompt, change to the directory that contains the plc_password utility. The path to the plc_password is given in “Location” on page 112.

2 Type in the plc_password command string for your operating system with the desired options and arguments. Figure 27 provides an example of adding a password to a site policy and setting the mode to unattended.

Table 37 lists the available options and their arguments.

Figure 27 plc_password Example Setting Mode to Unattended

plc_password -r server -S \etc\Patrol.d\SecurityPolicy_v3.0\site -m unattended -n pa$$3word -f padlock.jpg -k agent.kdb

Table 37 plc_password Utility Options (Part 1 of 2)


-r role designates the role within the security policy whose password you want to edit

Policy sections (Roles) that support the password attribute are client, server, signer, verifier, and keystore.

-P policy the security policy whose password you want to edit

For the location of security polices, see “Location of Policy Files” on page 107.



-m mode specifies whether you want to force a user to enter a password when starting\restarting the component with the associated role specified by the role option

attended – removes policy password field; forcing users to enter a password every time a process that uses this policy must be restartedunattended – creates policy password field; allowing any processes that use this policy to start up without user intervention, in other words, a user entering a password through the keyboard

Unattended mode options

-f key_material_file – used as a secret key to encrypt the password; this file can be any format (*.jpg, *.txt, *.bin, and so forth) but should be larger than 1024 bytes and is required to decrypt the password-H hostname or ip_address – lock by IP address; creates a password that is readable (can be decrypted) only from the IP address-u username --- lock by user name; creates a password that is readable (can be decrypted) only by user-w – unchange key database password; if a role password and the key database password are the same, this option allows you to change the role password without changing the key database password-o old_key_database_password – the old password in plain text-n new_password – the new password, in plain text, to be encrypted-k key_database_file – the key database whose password you want to change

The mode option is optional.

-v prints the version of the utility and exits

The version option is optional.

-h prints usage information and exits

This help option is optional.

Table 37 plc_password Utility Options (Part 2 of 2)




3 Press Enter.

The utility performs the specified action and displays the message. Figure 28 displays a probable result from a command similar to the one in Figure 27.

Figure 28 plc_password Example of Policy File Contents on Unix

...[server]

keyfile = agent.kdbpassword = kljf;lji9u8yu39miu-u3, padlock.jpg

[signer]...


Encrypting a Password


Policy files can contain passwords for many different roles. The usage and storage of passwords determines the security and ease-of-use of a PATROL installation.

This procedure describes how to encrypt a password using the bmcryptpw utility. It also describes how to verify that a password in encrypted format is valid.

To Encrypt a Password

1 At a command-line prompt, change to the directory that contains the bmcryptpw utility. The path to the bmcryptpw is given in “Location” on page 113.

2 Type in the bmcryptpw command with the desired options and arguments. Figure 29 provides an example of encrypting a password.


Figure 29 bmcryptpw Example on Windows

bmcryptpw -m ..\..\keys\company_logo.jpg -e

Table 38 bmcryptpw Utility Options


-m key_material_file used as a secret key to encrypt the password; this file can be any format (*.jpg, *.txt, *.bin, and so forth) but should be larger than 1024 bytes and is required to decrypt the password

-V encrypted_pswd a password in encrypted format

-H hostname or ip_address

lock by IP address; creates a password that is readable (can be decrypted) only from the IP address

-u user_name lock by user name; creates a password that is readable (can be decrypted) only by user

-e prompt user for password to encrypt

-g generate key material

-v prints the version of the utility and exits

The version option is optional.





3 Press Enter.

bmcryptpw prompts you to enter the password.

4 Type the password that you want to encrypt and press Enter.

bmcryptpw encrypts the password and prints it out in encrypted form. Figure 30 displays a probable result from a command similar to the one in Figure 29.

To Verify that a Password in Encrypted Format is Valid

1 At a command-line prompt, change to the directory that contains the bmcryptpw utility. The path to the bmcryptpw is given in “Location” on page 113.

2 Type in the bmcryptpw command with the desired options and arguments. Figure 29 provides an example of verifying that an encrypted password is valid.


3 Press Enter.

bmcryptpw verifies that the string that you pass is a password that was encrypted using the key material file.

Figure 30 bmcryptpw Results Example on Windows

Enter password: ******** Encoded passwd: 4a2b5466c070e2b43bc4290eb66558b8d801dc3fbd513949

Figure 31 bmcryptpw Test Example on Windows

bmcryptpw -m ..\..\keys\company_logo.jpg -V 4a2b5466c070e2b43bc4290eb66558b8d801dc3fbd513949

Figure 32 bmcrypt Test Results Example on Window

password decoded: valid


Signer and Verifier

Signer and VerifierThis section discusses the need for digitally signing files and verify digital signatures. It also describes how to test the digital signing and digital verification of a signature using the command-line utilities signFile and verifyFile.

Purpose

When important data (file, BLOB, etc.) is stored in insecure locations or transported by insecure means, it is useful to have a method of verifying that the documents have not been changed in any way in the interim. Signing a file and then verifying it when it arrives at its destination is one such method.

Operation of Signing

Digitally signing a file involves generating a checksum, or hash, of the entire file from top to bottom. A properly designed hashing algorithm produces a checksum value of the document which has two properties.

■ If even a single bit of the document is changed, the checksum value is changed.■ It is very difficult to compose a separate document that produces the same hash

value. (Such documents exist. However, one cannot identify them all by working backwards starting with the hash value).

The checksum value of the document is then encrypted with the private key of a trusted entity creating a digital signature. The process of signing does not change the signed file but rather creates an additional file, called a signature file. The signature (*.sgn) file contains the following data:

■ a signature (the encrypted check sum)■ a certificate that corresponds to private key of the signer

The file and its signature file are kept together as a pair. The signer's certificate contained in the signature file is used during verification to procure the public key to the signature. To ensure that the public key is genuine, the user first establishes a chain of trust between the signer's certificate and the certificate of a trusted Certificate Authority.


Operation of Verifying

Operation of Verifying

The integrity of the document can be verified by the receiver of the signed file by

1. decrypting the checksum value with the public key of the trusted entity

2. generating a checksum value of the file

3. comparing the receiver’s checksum value to the decrypted checksum value that accompanied the file

The two checksum values should be equal. If they do not, the document has been altered in some way.

Verifying a file ensures that the content is unchanged and that the owner of the private key signed the content.

Testing Digital Signing

This procedure describes how to test digital signing using the command-line utility signFile. Files signed by this utility should have their signatures verified by the command-line utility verifyFile.

To Sign a File

1 At a command-line prompt, change to the directory that contains the signFile utility. The path to the signFile utility is given in “Location” on page 114.

2 Enter signFile and desired options. Figure 33 provides an example of digitally signing a file.


Figure 33 signFile Example

signfile ..\..\financial_strat\secretplan.txt -s ..\..\digisigs\ -V


Testing Digital Signing

3 Press Enter.

The utility creates the digital signature. Figure 34 displays the results from a command similar to the one in Figure 33.

Table 39 signFile Options


file file_name the name and location of the file that you want to digitally sign

-s path specifies the location where the utility creates the signature (*.sgn) file

If you do not specify the signature directory, the utility creates the signature file in the same directory as the file to be signed.


-P path supplies the path of the application\signer policy if it is stored in a location other than the default location

-a signs the file according to the PKCS#1 standards

The default signature format is a legacy, BMC Software proprietary format.

-v displays the version of the utility

- V prints out the options and arguments that it uses in the signing process



Figure 34 signFile Example of Results

Site policy :SOFTWARE\BMC Software\Patrol\SecurityPolicy_v3.0\site Apps policy :SOFTWARE\BMC Software\Patrol\SecurityPolicy_v3.0\signer Object to sign:..\..\financial_strat\secretplan.txt Signature path:..\..\digisigs\ Object signed.


Testing the Verification of a Digital Signature


When any digitally signed file is verified, the utility uses the certificate and its public key contained within the signature file to perform the verification.

This procedure describes how to test digital signature verification using the command-line utility verifyFile. Signatures verified by this utility should be generated by the command-line utility signFile.

To Verify a Digital Signature

1 At a command-line prompt, change to the directory that contains the verifyFile utility. The path to the verifyFile utility is given in “Location” on page 114.

2 Enter verifyFile and desired options. Figure 35 provides an example of digitally signed file being verified.


Figure 35 verifyFile Example

verifyfile ..\..\financial_strat\secretplan.txt -s ..\..\digisigs\ -V

Table 40 verifyFile Options (Part 1 of 2)


file file_name the name and location of the file whose digital signature that you want to verify

-s path specifies the location of the signature (*.sgn) file to be used for verification of the file

If you do not specify the signature directory, the utility looks in the same directory as the file to be verified.


-P path supplies the path of the application\verifier policy if it is stored in a location other than the default location

-a verifies signature files that were created according to the PKCS#1 standards only

Omitting this option permits the utility to verify signature files that conform to either PKCS#1 format or the legacy, BMC Software proprietary format. Omitting this option is recommended.

-v displays the version of the utility



3 Press Enter.

The utility checks the digital signature and displays the message, Verified OK. Figure 36 displays the results from a command similar to the one in Figure 35.

- V prints out the options and arguments that it uses in the verifying process



Figure 36 verifyFile Example of Results

Site policy :SOFTWARE\BMC Software\Patrol\SecurityPolicy_v3.0\site Apps policy :SOFTWARE\BMC Software\Patrol\SecurityPolicy_v3.0\verifier Object to verify:..\..\financial_strat\secretplan.txt Signature path:..\digisigs Verified OK

Table 40 verifyFile Options (Part 2 of 2)



Client-Server Communication

Client-Server CommunicationThis section describes how to test the SSL secure communication channel that is established for an application operating in client role to communicate with an application operating in a server role. The primary benefit of this test is to verify that the security policy is properly configured to be used by PATROL applications.

This test cannot be performed at security level 0 because that level does not employ secure channel communication.

Testing a Secure TCP/IP Channel for the Client and Server

This procedure tests the communication modules shipped with PATROL Security. They include

■ Spyrus Secure Socket Layer (SSL)■ Diffie-Hellman

This procedure describes how to start a client and server using the esstool and then send messages from the client to the server to demonstrate that the connection works.

To Start an esstool Server

1 Access a command-line prompt.

2 At the command-line prompt, change to the directory that contains the esstool utility. The path to the esstool utility is given in “Location” on page 111.

3 Enter esstool server and desired options. Figure 37 provides an example of starting a test server.


Figure 37 esstool server Example Command on Windows

esstool server -h Tron -L 2 -S Patrol\SecurityPolicy_v3.0\site -P Patrol\SecurityPolicy_v3.0\agent



If you specify level 3 or 4 and you have not set the server role to run in unattend mode, the esstool process prompts you for the password to its key database. Enter the password and click OK.

Table 41 esstool server Options


-h hostname specifies a computers host name if you are not starting an esstool server a computer other than the one from which you are issuing the command

-p portnumber specifies the port on which the server listens

The default is 4443.

-s service_name assigns a service name to the esstool server process other than the default, esstool

-L security_level specifies the security level at which to run the esstool server

The esstool server must run at a security level greater than 0.

-S path specifies the path to the site policy

-P path specifies the path to the application policy

-V version_number displays the version number of the esstool server module

-n sets communication to nonblocking input\output mode, which allows the computer to service other connections

This option is for developing testing and should not be employed.





Figure 38 displays startup messages.

Figure 38 esstool server Example Startup Messages

C:\Program Files\BMC Software\common\security\bin_v3.0\Windows-x86>esstool server -L 1host: localhost, port 4443, sprinc mysprinc Creating new policy ... Site policy = 'SOFTWARE\BMC Software\Patrol\SecurityPolicy_v3.0\site'Appl policy = 'SOFTWARE\BMC Software\Patrol\SecurityPolicy_v3.0\agent' ModuleName C:\Program Files\BMC Software\common\security\bin_v3.0\Windows-x86\bmcdh.dll client doing connect on 664 socket accepted new fd 656********************Starting Accept**********************************New session established sid: 512**************** session established , doing BCA_Read ---recv: 11, Message 1



To Start an esstool Client

1 Access a command-line prompt. It must be a separate command prompt/shell than the one used for the esstool server.

2 At the command-line prompt, change to the directory that contains the esstool utility. The path to the esstool utility is given in “Location” on page 111.

3 Enter esstool client and desired options. Figure 39 provides an example of starting a test client.


Figure 39 esstool client Example Command on Windows

esstool client -L 2 -S Patrol\SecurityPolicy_v3.0\site -s 2

Table 42 esstool client Options (Part 1 of 2)


-h hostname specifies a computers host name if you are not starting an esstool server a computer other than the one from which you are issuing the command

-p port_number specifies the port on which the server listens

The default is 4443.

-s time_in_seconds specifies the amount of time (in seconds) that the client waits before trying to connect to the server

-L security_level specifies the security level at which to run the esstool server

The esstool server must run at a security level greater than 0.

-S path specifies the path to the site policy

-P path specifies the path to the application policy

-V version displays the version number of the esstool server module

-r url performs an HTTP GET request

-u string assigns user-defined text string (also referred to as an identity) to the process

-k path specifies the path to the key file



4 If you specify level 3 or 4 and you have not set the client role to run in unattend mode, the esstool process prompts you for the password to its key database. Enter the password and click OK.

Figure 40 displays startup messages.

-n sets communication to nonblocking input\output mode, which allows the computer to service other connections

This option is for developing testing and should not be employed.



Figure 40 esstool client Example Startup Messages

C:\Program Files\BMC Software\common\security\bin_v3.0\Windows-x86>esstool server -L 1host: localhost, port 4443, sprinc mysprinc Creating new policy ... Site policy = 'SOFTWARE\BMC Software\Patrol\SecurityPolicy_v3.0\site'Appl policy = 'SOFTWARE\BMC Software\Patrol\SecurityPolicy_v3.0\agent' ModuleName C:\Program Files\BMC Software\common\security\bin_v3.0\Windows-x86\bmcdh.dll client doing connect on 664 socket accepted new fd 656********************Starting Accept**********************************New session established sid: 512****************

Table 42 esstool client Options (Part 2 of 2)




To Test Communication Between Client and Server

1 Access the command-line prompt where you started the esstool client.

2 Type a text string, such as Message 1, and press Enter.

3 Access the command-line prompt where you started the esstool server and observer the message. Figure 41 displays an example of what the esstool server would display.

To Stop the Client

1 Access the command-line prompt where you started the esstool client.

2 Press CTRL + C.

To Stop the Server

1 Access the command-line prompt where you started the esstool server.

2 Press CTRL + C.

Figure 41 esstool server Example of Message Received from esstool client

session established , doing BCA_Read---recv: 11, Message 1


Policy Migration

Policy MigrationThe goal of the migration process is to preserve the customizations that you have made to existing security content such as, key databases, acquired key pairs, unattended passwords, and other aspects.

PATROL Security 3.0.05 further extends the deployment of ESS3.0 by providing migration capability for PATROL Security 1.2.07, which contained ESS2.0 policy information. This fundamental policy migration requirement preserves existing security configuration and transfers certain configuration attributes into a new ESS3.0 policy.

The migration process copies ESS2.0 policy attributes into the ESS3.0 policy configuration.

PATROL Security versus Extended Security System

PATROL Security 3.0.05 contains the Extended Security System 3.0.05 (ESS3.0.05). PATROL Security 1.2.07 contains the Extended Security System 2.0 (ESS2.0). This section refers to the ESS version rather than the PATROL Security versions.

ESS 3.0.00 and ESS 3.0.05

ESS 3.0.05 release is an extension of the ESS 3.0 release and will be installed as 3.0 version. Due the common feature set of 3.0 and 3.0.05 ESS versions, these releases utilize the common ESS3.0 security policy version, designated by the suffix _v3.0. All ESS 3.0.x libraries and binaries are compatible and can be replaced by later versions of 3.0.x.


Migration Process

Migration Process

As part of the installation process, PATROL Security performs the following steps to migrate information from version 2.0 to 3.0.

1. Detects a ESS2.0 policy.

2. Scans ESS2.0 policy for the replicated parameters. The duplicate parameters are replaced by the parameters stored in a common role section of the site policy. The ESS3.0 policy template file will supply required ESS 3.0 configuration information.

3. ESS3.0 products will reside in versioned directories. The following policy attributes and their corresponding values are associated with ESS2.0 and are will not be migrated and are not referenced in ESS 3.0 policy.

bindirbindir64logdirlibconfig

To ensure independent operation of ESS2.0 and ESS3.0.x releases, the ESS3.0 product components use locations with versioned suffixes. The suffix for ESS3.0 is _v3.0.

bindir_v3.0bindir64_v3.0logdir_v3.0lib_v3.0config_v3.0

If the migration process detects the existence of the ESS2.0 pamservice attribute in either the client or server roles, the process will create an Authenticator role with a provider attribute and a service attribute and transfer the value from the pamservice attribute to the provider and service attributes as shown in Figure 42.

NOTE The migration process will run only in the absence of ESS3.0 policy. After an ESS3.0 policy has been created, the migration will not be initiated.

Figure 42 Result of the Migration of the pamservice Attribute

[authenticator]provider = pamservice = service_name


Migrate or Overwrite

Migrate or Overwrite

The installation process provides you with the ability to control whether it overwrites an earlier version of security. Through the use of the Overwrite checkbox, you can choose whether to

■ preserve and migrate the existing, customized security configuration

or

■ create new security configuration and overwrite any existing configuration

For more information about the installation process and the ability to overwrite or preserve security configuration, see “Installation Process” on page 48.

Migration Scenarios

The following scenarios describe some common conditions and the behavior of the migration process.

Choose Not to Overwrite Existing Security

During the installation process, if you choose not to overwrite the existing security, the migration process looks for the ESS2.0 policy information. If the 2.0 policy information exists and there is no 3.0 policy, then the process migrates the 2.0 policy information during the installation of ESS3.0.05 and the creation of 3.0 policy.

If the 3.0 policy information already exists, then the process does not attempt to migrate the 2.0 information.

Choose to Overwrite Existing Security

During the installation process, the 3.0 policy is created using the default information specified by the installation package.

WARNING Overwrite your existing PATROL Security content and configuration only if you want to start over with demo certificates. BMC Software does not recommend overwriting existing security.


Migration Scenarios

Common Scenarios

Table 43 describes some common installation/migration scenarios.

Table 43 Installation and Migration Scenarios

Scenario Overwrite Checkbox Results

Installing ESS3.0 on a new computer

checked ESS3.0 is installed with default settings

not checked ESS3.0 is installed with default settings

Installing ESS3.0 on a computer with ESS2.0 — for the 1st time

checked ESS3.0 is installed with default settings. Security customizations are discarded.

not checked ESS2.0 policy information is migrated to ESS3.0

Installing ESS3.0 on a computer with ESS2.0 — subsequent installations (not the 1st time)


not checked No change is made to the current settings.

Installing ESS3.0 on a computer with ESS3.0 — for the 1st time


not checked No change is made to the current settings.


C h a p t e r 6
6 Configuration Files
This chapter describes the PATROL configuration files that store additional security information not contained in the certificates, key databases or security policies.


PATROL Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156patrol.conf. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157config.default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Working with Configuration Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Configuring the SSL access File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Operating System and Application-Specific Configurations . . . . . . . . . . . . . . . . . . . 168Configuring the dlls.conf for PATROL for Unix. . . . . . . . . . . . . . . . . . . . . . . . . . . 168Using PATROL Event Manager Applications with PATROL Security. . . . . . . . 170


PATROL Configuration Files

PATROL Configuration FilesThe PATROL configuration files listed in Table 44 contain parameters that pertain to security implementation.

Table 44 PATROL Configuration Files That Contain Security Information

Filename Description

patrol.conf contains the Extended Security Interface (ESI) configuration stanzas

When you install security (and choose a security level), the installation process updates patrol.conf and backs up the original version of the file. For more information, see “patrol.conf” on page 157.

config.default is the default configuration file for the PATROL Agent

When you install security (and choose a security level), the installation process updates config.default and backs up the original version of the file. For more information, see “config.default” on page 161.

access is a file that stores SSL access control list information for applications operating in the server role and running at security level 4

For more information, see “Configuring the SSL access File” on page 166.

dlls.conf lists the .dll files necessary for KMs to work with the PATROL Agent

For more information, see “Configuring the dlls.conf for PATROL for Unix” on page 168.


patrol.conf

patrol.conf

The patrol.conf file contains the Extended Security Interface (ESI) configuration stanza. (For further information, see “Extended Security Interface (ESI)” on page 159.) When you install PATROL and choose a security level, the installation process updates patrol.conf and backs up the original file.

The security features controlled by patrol.conf include

■ prevent or permit the execution of PSL commands from SNMP monitor■ allow or deny commits from the PATROL Console 3.x running in developer mode■ allow or deny a PATROL Console 3.x running in developer mode to connect■ prevent or permit the system output window from executing operating system

commands

Location

Table 45 provides the location of the patrol.conf file for each operating system.

Table 45 Location of patrol.conf File


Windows %PATROL_HOME%\..\common\patrol.d

Unix /etc/patrol.d


patrol.conf

Security-Related Contents

Table 46 lists an example of configuration data and a description of each section of data in patrol.conf. (Please note the legend at the end of the table.) For more detail on the patrol.conf file, see the PATROL Agent Reference Manual.

Table 46 Security Configuration Data of patrol.conf File

Stanza and Parameter Name

Level 0 (Basic

Security)

Level 1 Level 2 Level 3 Level 4

DescriptionC A C A C A C A C A

[ESI] ESI stanza name

esi_lib I I I I I I I I I I ■ specifies the path to the PATROL ESI library for the console and agent

■ install location example is /home/seqqa/PATROL3.3/Solaris25-sun4/bin/bmcesi.so

[AGENT] agent stanza name

allowsnmpexecute T T T T T T F F F F permits or prevents the ability to run PSL commands from an SNMP network monitor

[CONSOLE] console stanza name

allowcommit T T T T T T F F F F permits or prevents the console from committing any KM changes to any connected agents (if you remove this right, PATROL disables menus that provide access to KM commit operations)

allowdeveloper T T T T T T F F F F permits or prevents a console from establishing a developer mode connection to an agent

allowsysoutputexec T T T T T T F F F F permits or prevents a user from entering operating system commands into the PATROL system output window

C = console A = agentI = installedT = true (value)F = false (value)


patrol.conf

Extended Security Interface (ESI)

The ESI pluggable security component specifies the PATROL Security plug-in used to ensure privacy of communications between PATROL components. The installation process installs the libraries and sets the appropriate variables in patrol.conf.

In the patrol.conf file, the esi_lib32 and esi_lib64 variables specify the ESI library location for 32-bit or 64-bit installed products, respectively. Table 47 describes these variables.

Values and Security Levels

At security level 0, the installation process sets all the ESI variables to none. At security levels 1-4, the installation process sets the ESI variables to the location of the libraries: bmcesi.so on Unix and bmcesi.dll on Windows, which is the secure channel provider for PATROL.

Unix

On Unix, the ESI variables appear in the patrol.conf file as shown in Figure 43.

Table 47 ESI Variables in patrol.conf File

Variables Valid Values Description

esi_lib the default path of the ESI library or none if no ESI library is being used

The default value for the esi_lib variable is none.

specifies an ESI library to use for authentication and encryption

esi_lib32 the path of the 32-bit ESI library or none if no ESI library is being used

The default value for the esi_lib32 variable is none.

specifies a 32-bit ESI library to use for authentication and encryption

esi_lib64 the path of the ESI library or none if no ESI library is being used

The default value for the esi_lib64 variable is none.

specifies a 64-bit ESI library to use for authentication and encryption

Figure 43 patrol.conf File Example of the ESI Section on Unix

#[ESI] esi_lib = $PATROL_HOME/common/security/bin/OS/bmcesi.soesi_lib32=$PATROL_HOME/common/security/bin/OS/bmcesi.soesi_lib64=$PATROL_HOME/common/security/bin/OS/bmcesi.so


patrol.conf

Windows

On Windows, the ESI variables appear in the patrol.conf file as shown in Figure 44.

For more information about using an ESI pluggable security component, see the PATROL API Reference Manual and the PATROL Agent Reference Manual.

Figure 44 patrol.conf Example of the ESI Section on Windows

#[ESI] esi_lib = %PATROL_HOME%\common\security\bin\<OS>\bmcesi.dllesi_lib32=%PATROL_HOME%\common\security\bin\<OS>\bmcesi.dllesi_lib64=%PATROL_HOME%\common\security\bin\<OS>\bmcesi.dll


config.default

config.default

The config.default file is the default configuration file for the PATROL Agent. When you install PATROL and choose a security level, the installation process updates config.default and backs up the original file.

The security features controlled by config.default include

■ sets the access control list■ determines the communication protocol■ enables the ESI library

Location

Table 48 provides the location of the config.default file for each operating system.

Table 48 Location of config.default File


Windows %PATROL_HOME%\lib

Unix $PATROL_HOME/lib


config.default


Table 49 describes security-related parameters in the config.default file.

Table 49 Agent and Console Features in config.default File (Part 1 of 2)

DescriptionBasic Security Level 1 Level 2 Level 3 Level 4

/AgentSetup/accessControlList

This variable lists which user names may be used by which consoles when connecting to an agent.

The format is a comma-separated list of entries, with each entry being of the form UserName/HostName/Mode.

■ UserName is the name of a local account that the connecting console may request to use. UserName may be either a single asterisk (*) (meaning that any user name is allowed, assuming the account exists), or the actual name of the account.

■ HostName is the console that is authorized to connect to the agent. HostName may be a single asterisk (*)(meaning that all hosts are allowed to connect), the actual name of a host (indicating that this entry is for that host only), or a wildcard specification, in which the first character is a single asterisk (*) with other characters following.

Mode is a list of zero or more of the characters C, D, O, P, and A (see legend). Mode indicates that the host is authorized to connect to the agent in a particular mode and log on as that user.

*/*/CDOPSR

*/*/CDOPSR

*/*/CDOPSR

*/*/COP */*/COP

/AgentSetup/PortConnectType

This variable allows you to select the communication protocols UDP, TCP, or both when binding to a port.

UDP/TCP

UDP/TCP

UDP/TCP

TCP TCP


config.default

/AgentSetup/BindToAddress

This variable allows you to bind the PatrolAgent to a specific network card on a machine with more than one network card.

blank a

/AgentSetup/security/ExtendedSecurityEnabled

This variable indicates when the ESI is enabled. If this variable is set to “yes,” but the ESI library could not be found or loaded, the agent will exit.

yes yes yes yes yes

PATROL Roles Used by ACLC = ConfigureD = DeveloperO = OperatorP = PATROL Event ManagerS = System OutputR = Operator OverwriteA = Anonymous

Communication ProtocolsTCP = Transmission Control ProtocolUDP = User Datagram Protocol

a The unfilled entries in config.default are empty strings.

Table 49 Agent and Console Features in config.default File (Part 2 of 2)

DescriptionBasic Security Level 1 Level 2 Level 3 Level 4


access

access

The SSL access file stores access control list (ACL) information for PATROL applications operating in the server role and running at security level 4. For security levels 3 or lower, it is not used. Within the file, users are identified by e-mail address.

Operation

The server application determines whether to grant or deny access by comparing the values in the allow and deny parameters of the access file with the Distinguished Name associated with the user’s certificate.

For more information about the Distinguished Name, see Table 20 on page 90.

Location

Table 50 provides the location of the access file for each operating system.

WARNING The purpose of this access control list is to determine which user can connect to the server by means of an SSL connection. When a user is denied access by this file, that user is completely locked out of that computer. The user cannot even establish a connection to the server.

Table 50 Location of access File


Windows %PATROL_HOME%\..\common\security\keys

Unix $PATROL_HOME/../common/security/keys


access


Table 51 describes security-related parameters in the access file.

Precedence

The DENY_ACL parameter takes precedence over the ALLOW_ACL parameter. If a user meets the criteria specified in both parameters, the user will be denied access.

Defaults

The installation process installs an access file in which the parameters are set to allow access to all users (ALLOW_ACL = *) and deny access to no one (DENY_ACL = ). This file overrides the default behavior of PATROL Security on a server at level 4, which is to deny access to all add allow access to no one.

Table 51 Configuration Data in access File

Stanza and Parameter Description

[SSL_SERVER] SSL server stanza name

ALLOW_ACL designates which users are allowed access

This parameter supports the wildcards asterisk (*) for many characters and question mark (?) for a single character.

DENY_ACL designates which users are denied access

This parameter supports the wildcards asterisk (*) for many characters and question mark (?) for a single character.

WARNING If the access file is deleted from a computer running a PATROL application in the server role such as the PATROL Agent, no other PATROL applications (PATROL Console, Console Server, PATROL Agent) will be able to connect to the application with the missing file.


Working with Configuration Files

Working with Configuration FilesThis section describes tasks that you may need to perform in the configuration files described in the previous sections.

Configuring the SSL access File

This procedure describes how to edit the access file for use by a PATROL application operating as a server and running at security level 4.

To Edit the SSL access File

1 At a command line prompt, change to the keys directory, which contains the access file.

The path to the file is given in “Location” on page 164.

2 Open the SSL access file in the text editor of your choice.

3 Navigate to the ALLOW_ACL parameter and enter the e-mail address or addresses of users to whom you want to grant access.

■ If you want to greatly restrict access, list only the users who require access to the server. Figure 45 provides an example.

■ If you want to provide access to a group or range of users with similar e-mail addresses, use patterns with wild cards: * and ?. Figure 46 provides an example.

■ If you want to allow everyone access, enter an asterisk *.

4 Navigate to the DENY_ACL parameter and enter the e-mail address or addresses of users to whom you want to explicitly deny access.

Otherwise, leave this field blank. Figure 46 provides an example.

Figure 45 access File Example Restricting Access to Two Users

[SSL_SERVER];ALLOW_ACL = [email protected], [email protected]_ACL =


Configuring the SSL access File


Figure 46 access File Example Allowing Access to a Group and Denying Access to an Individual User

[SSL_SERVER];ALLOW_ACL = *@company.com, *@subsidiary.comDENY_ACL = [email protected]


Operating System and Application-Specific Configurations

Operating System and Application-Specific Configurations

The different operating systems and certain applications require unique configuration changes. This sections describes how and in which configuration files you must make the necessary changes.

Configuring the dlls.conf for PATROL for Unix

The PATROL Knowledge Module for Unix requires a file called apidll.dll. In order to load the apidll.dll file to the PATROL Agent, the apidll.dll file must be authenticated in dlls.conf. The dlls.conf file lists the .dll files necessary for KMs to work with the PATROL Agent.

The dlls.conf file must be modified prior to loading the KM either by the PATROL Agent preload list or by a PATROL console. Modifying this file enables all functionality of the KM and makes it available to the agent. After installing PATROL Security components and before starting the agent, perform the following steps to modify the dlls.conf file.

To Modify the dlls.conf File

1 At the command line prompt, change to the directory that contains the dlls.conf file.

2 Create the following entries in the dlls.conf file:

or

Table 52 Location of the dlls.conf File


Windows %PATROL_HOME%\..\common\patrol.d

Unix /etc/patrol.d

DLLDIR = $PATROL_HOME/lib/psl/$TARGETDLL = apidll.dll

DLL = $PATROL_HOME/lib/psl/$TARGET/apidll.dll


Configuring the dlls.conf for PATROL for Unix

3 Specify any other dll files as needed:

or

4 Save and close the file.

DLLDIR = $OTHER_DIRDLL = otherdll.dll

DLL = $OTHER_DIR/otherdll.dll


Using PATROL Event Manager Applications with PATROL Security

Using PATROL Event Manager Applications with PATROL Security

When using PATROL Security at levels 1 through 4, the PATROL Event Manager (PEM) applications need to be recompiled with the PEM library only if with the applications are to be compatible with the 3.5 PEM APIs.

To Configure PATROL Security

1 Configure the following parameter in the config.default file as shown Figure 47.

2 Configure the following parameter in the patrol.conf file as shown Figure 48.

3 On Windows, set the registry HKEY_LOCAL_MACHINE\SOFTWARE\BMC Software\PATROL\ as shown Figure 47.

At security level 4, the PEM client application can be launched by a system user rather than a login user. In this case, a certificate with identity = system must exist in the client key database for the authentication with the server application (for example, the PATROL Agent). If the application is launched by a login user rather than a system, then use identity = user_name.

Using attended mode on Windows, in which the user is required to enter a password for the keyfile to get certificate information, the PEM service needs to be able to interact with Desktop. See “Setting the Attended or Unattended Mode” on page 134.

Figure 47 ESI Variable Configured for PATROL Event Manager Applications

"/AgentSetup/security/ExtendedSecurityEnabled" = { REPLACE="yes"}

Figure 48 ESI Library Location for PATROL Event Manager Applications

esi_lib = location_of_the_esi_library

Figure 49 Registry Keys for PATROL Agent and PATROL Security

PATROL Agent = esi_lib_pathPATROL Security = path_for_patrol.conf


A p p e n d i x A
A Changing the Security Level
This appendix describes how to change the security level of a computer after the installation process.

This appendix presents the following topics:

Changing the Security Level for the Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172


Changing the Security Level for the Enterprise

Changing the Security Level for the EnterpriseThe security level is set during the installation process. However, you can change the level security on an individual computer. PATROL Security provides a script that enables you to run the script locally and change the level of the PATROL applications installed on that computer. Those applications include

■ PATROL Agent 3.x■ PATROL Console 3.x■ Console Sever■ PATROL Central – Web Edition■ PATROL Central – Microsoft Windows■ Distribution Server: server, client, and command line interface

Before you begin

The p7_change_security_level script is a command line utility that enables you to change the security level and configuration of a PATROL application running on the local computer. To run this utility, on Unix, you need to log on as root. On Windows, you need Administrator privileges.

To Change the Security Level of All PATROL Applications on Computer

1 Access a command prompt.

2 Navigate to the config_v3.0 directory. Table 53 provides the installation path of the script based upon the operating system.

3 Type in the p7_change_security_level command string for your operating system with the desired options and arguments. Figure 50 provides an example of a script setting the security level to 2 for PATROL Central - Web Edition installed on Windows. Figure 51 provides an example of a script that sets the Distribution Server’s server to run at level 3 security on Unix.

NOTE If multiple PATROL applications are installed on the same computer (for example, a PATROL Agent and a Console Server), you must execute the script for each individual component to ensure that the security settings are consistent among applications.

Table 53 p7_change_security_level Script Location


Windows %BMC_ROOT\..\common\security\config_v3.0

Unix $BMC_ROOT/../common/security/config_v3.0



Table 54 lists the available options and their arguments. The order of the options is unimportant; however, a space must be inserted between an option and its argument.

Figure 50 p7_change_security_level Example on Windows

p7_change_security_level.cmd -c PCWEB -l 2 -d “Web Central”

Figure 51 p7_change_security_level Example on Unix

p7_change_security_level.sh -c DS_SERVER -l 3

Table 54 p7_change_security_level Script Options


-h displays the online help information.

-c component designates the PATROL application whose security level you want to change; components are

AGENT_CON – PATROL Agent and Console 3.xCSERVER – Console ServerDS_CLIENT – Distribution Server, clientDS_CLI – Distribution Server, command line interfaceDS_SERVER – Distribution Server, serverPCWEB – PATROL Central – Web EditionPCWIN – PATROL Central – Microsoft Windows Edition

-l security_level sets the new security level

Valid values range from 0 to 4. For information about PATROL Security levels, see “Levels of Security” on page 18.

-n protocol(s) determines which network communication protocols are supported.

Security Levels 0, 1 and 2 require both TCP and UDP protocols. Security Levels 3 and 4 permit one protocol or both.

TCP – supports the Transmission Control protocolUDP – supports the User Datagram ProtocolBOTH – supports TCP and UDP communication

This parameter applies to only PATROL Agent 3.x and PATROL Console 3.x.

-d Patrol3_subdir or “Patrol 3 subdir”a

provides the name of the Patrol3 subdirectory; no path is needed

This parameter applies to only PATROL Agent 3.x and PATROL Console 3.x.



The script attempts to change the security level. In the process, it updates the policy two configuration files: patrol.conf and config.default. For more information about these files, see Chapter 6, “Configuration Files”.

The script also writes its results to the command prompt. Figure 52 displays a selection form the results log.

-d PCWeb_subdir or “PC WEB subdir”a

provides the name of the PATROL Central Web subdirectory; no path is needed

This parameter applies to only PATROL Central - Web Edition.

-v version_number indicates the version of PATROL Security whose security level will be changed

– ESS version 2.0 (no flag)_v3.0 – ESS version 3.0

a Double quotes are required if the path\directory names contain spaces such as “\Program Files\BMC Software\PATROL Central”.

Table 54 p7_change_security_level Script Options




Figure 52 p7_change_security_level Script Sample Log on Windows

[LOG][LOG] p7_change_security_level.cmd execution begins...[LOG] Parameters passed in:[LOG] 1. Component: AGENT_CON[LOG] 2. BMC Installation Base: "C:\Program Files\BMC Software"[LOG] 3. Security Level: 1[LOG] 4. Version: Default to 2.0 - i.e. no _v3.0 extensions was specified.[LOG] 4. Protocol: BOTH[LOG] 5. Patrol 3 Directory: PATROL3[LOG] 1 file(s) copied.[LOG] Using config.default from "C:\Program Files\BMC Software"\PATROL3\lib[LOG] policy_install.cmd execution begins...

<< Log entries have been deleted from this example. >>

[LOG]config_install.cmd execution begins...[LOG]Parameters passed in:[LOG]1. Path of new config.default = "C:\Program Files\BMC Software"\common\patrol.d\config.default[LOG]2. Path of destination = "C:\Program Files\BMC Software"\PATROL3\lib\config.default[LOG]3. Path of bak destination = "C:\Program Files\BMC Software"\PATROL3\lib\ba[LOG]4. Overwrite flag = TRUE 1 file(s) copied.[LOG]Copied new file over existing file.[LOG]config_install.cmd completed successfully.




A p p e n d i x B
B Troubleshooting
This appendix briefly describes common problems that can occur.

This appendix presents the following topics:

Issues and Workarounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Character @ Interpreted as Kill Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179Attempt to Generate a Key Results in Extended Error Message . . . . . . . . . . . . . 179Defaults to Security Level 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Missing bindir Error Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180Missing securitydir Error Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Password Prompter Canceled Error Message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Password Attribute Requires 2 Fields Error Message . . . . . . . . . . . . . . . . . . . . . . 182Key File Cannot Be Reached Error Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182Decrypting Stored Password Error Message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Identity Missing from Key Database Error Message . . . . . . . . . . . . . . . . . . . . . . . 183Unexpected Password Prompt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184Installation Fails. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184Uninstallation Fails to Remove Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . 185Key Database Will Not Open With Correct Password . . . . . . . . . . . . . . . . . . . . . 185No Key for Negotiated Cipher Error Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Cannot Install a Certificate into a Key Database. . . . . . . . . . . . . . . . . . . . . . . . . . . 186Cannot Install a CRL into a Key Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186Windows CA Rejects a CSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Password Not Configured . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Password Prompt Does Not Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Typed Password Does Not Appear in Password Dialog Box. . . . . . . . . . . . . . . . 188Password Dialog Prompt Does Not Appear . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188PATROL KM for Microsoft Cluster Server Does Not Support Attended Mode at

Level 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Cannot Find Shared Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189Discovery Fails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Password for 64-bit Key Files Is Not Validated . . . . . . . . . . . . . . . . . . . . . . . . . . . 190Password Dialog Prompt Does Not Appear When Running at Level 4 . . . . . . . 191

Error Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Invalid Policy Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192


Invalid Policy Keyfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Incorrect Encrypted Password Used During Security Bootstrap . . . . . . . . . . . . . 193Invalid Policy Identity Field (Non-Existing Key) . . . . . . . . . . . . . . . . . . . . . . . . . . 193Mutual Authentication Nominal Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195Missing Key On Level 4 Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196Missing Trusted Root (client) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Missing Certificate (Server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200Expired Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201


Issues and Workarounds

Issues and WorkaroundsThis section identifies errors that you may encounter when working with PATROL Security components, identifies the corresponding causes, and provides diagnostic solutions, if applicable.

Character @ Interpreted as Kill Command

The stty terminal settings can affect the operation of the sslcmd command. For terminal setting stty -a, the following error might appear when you choose sslcmd command option 2 (Generate CSR):

The @ character in the e-mail address field may be read as a “kill” character, so that the e-mail address is truncated.

Cause

Terminal setting stty -a is not supported.

Solution

Enter an alternative terminal setting, such as stty killÛ.

Attempt to Generate a Key Results in Extended Error Message

On some platforms, extended error messages as shown in Figure 53 may appear when choosing sslcmd command option 1 (Generate Key).

After the error messages appear the key is generated successfully; therefore, no action is required.

Figure 53 Generate a Key Extended Error Message

HP-UX hppcoqs6 B.11.00 A 9000/785 2015255295 two-user license/local_home/patqa1/classicrc1/common/security/bin_v3.0/hpux-11-00-pa20-64 $ getconf KERNEL_BITS64


Defaults to Security Level 4

Cause

The code generates a stream of unpredictable bytes by performing a list of system calls to selected utilities, for example, ps, netstat, and vmstat. If a certain platform does not to support one or more of the utilities, an error message may appear.

Solution

Because the command successfully generates the key, no user action is required and the error message can be ignored.

Defaults to Security Level 4

The security policy level defaults to level 4 unexpectedly.

Cause

In the site policy file, if the security_level field is deleted or contains an empty string, the default level of security is set to 4. Note that this differs from the default 0 (basic security level) that is set during PATROL installation if no security level is specified.

Solution

Specify the desired security policy level in the security_level field.

Missing bindir Error Message

An error message appears in the command prompt stating that there is a missing bindir.

Cause

In the site file (site.plc on Unix, site.reg on Windows), the bindir field was deleted.

Solution

Include the bindir field in the file.


Missing securitydir Error Message

Missing securitydir Error Message

An error message appears in the log file stating that there is a missing securitydir.

Cause

In the site file (site.plc on Unix, site.reg on Windows), the securitydir field was deleted.

Solution

Include the securitydir field in the file.

Password Prompter Canceled Error Message

An error message appears in the log file stating that the password prompter was cancelled.

Cause

The user canceled the password dialog box.

Solution

Restart and enter the password for attended mode or set the mode to unattended by placing the password in the policy file for the product that you are starting.

Figure 54 Password Prompter Canceled Error Message

1:Mon Feb 7 14:46:57 2005:pid=11974:ERR:bmccfg_role.c:399:Password prompter canceled2:Mon Feb 7 14:46:57 2005:pid=11974:ERR:bmccfg.c:649:PolicyLoad failed -1


Password Attribute Requires 2 Fields Error Message

Password Attribute Requires 2 Fields Error Message

An error message appears in the log file stating that the password entry requires 2 fields (password and keymaterial) followed by an optional lock string.

Cause

In the site file (site.plc on Unix, site.reg on Windows), the password field requires an entry for both a password and key material file, which may have been deleted in order to run in attended mode.

Solution

Include a valid entry in the password field.

Key File Cannot Be Reached Error Message

An error message appears in the log file stating that the key file cannot be reached.

Cause

In the site file (site.plc on Unix, site.reg on Windows), the keyfile field may contain an invalid entry or may reference an invalid directory.

Solution

Include a valid entry in the keyfile field.

Figure 55 Password Attribute Requires 2 Fields Error Message

1:Mon Feb 7 14:53:40 2005:pid=11999:ERR:bmccfg.c:1966:invalid policy start up, 'password' entry requires 2 fields (password and keymaterial) followed by an optional lock string2:Mon Feb 7 14:53:48 2005:pid=11999:ERR:bmccfg_role.c:399:Password prompter canceled3:Mon Feb 7 14:53:48 2005:pid=11999:ERR:bmccfg.c:649:PolicyLoad failed -1"BUT PASSWORD PROMPTER WILL POP UP"


Decrypting Stored Password Error Message

Decrypting Stored Password Error Message

An error message appears in the log file stating that there was an error decrypting the stored password.

Cause

In the site file (site.plc on Unix, site.reg on Windows), the password field may contain an invalid password.

Solution

Include a valid entry in the password field.

Identity Missing from Key Database Error Message

An error message appears in the log file stating that the identity does not appear in the key database.

Cause

In the site file (site.plc on Unix, site.reg on Windows), the identity: field may contain an invalid entry.

Solution

Include a valid entry in the identity field.

Figure 56 Identity Missing from Key Database Error Message

1:Mon Feb 7 18:15:01 2005:pid=12507:ERR:bmccfg_role.c:316:Security policy entry server does not contain identity entry2:Mon Feb 7 18:15:01 2005:pid=12507:ERR:bmccfg.c:649:PolicyLoad failed -1


Unexpected Password Prompt

Unexpected Password Prompt

A password prompt unexpectedly appears.

Cause

In the site file (site.plc on Unix, site.reg on Windows), the password field have been deleted, or the keyfile or password entry in this field may have been deleted. This can occur when a user wishes to run in attended mode, and thus intentionally deletes the password field in order to enable the password prompt to appear.

Solution

To revert to unattended mode, include valid entries in the password field.

Installation Fails

Installation of PATROL Security fails.

Cause

Installation may fail due to lack of privilege. On Unix, you may lack the privilege for modifying the /etc directory; therefore you cannot create the /etc/patrol.d/security_policy or place the policy files in /etc/patrol.d.

On Windows, you may lack administrator privilege to modify registry entries; therefore you cannot create the necessary registry entries.

Solution

Obtain an account with the requisite privilege.


Uninstallation Fails to Remove Security Policies

Uninstallation Fails to Remove Security Policies

Uninstallation fails to remove the security registry entries (Windows) or policy files (Unix).

Cause

The uninstallation process is unable to remove policies.

Solution

Manually remove the security registry entries and/or policy files only if another PATROL application does not use them. Otherwise, leave them.

Key Database Will Not Open With Correct Password

The key database will not open although you entered the correct password.

Causes

■ A 32-bit platform cannot use a key database generated on a 64-bit platform.

■ In an international context, a key database generated in one locale cannot be opened in another locale.

Figure 57 Key Database Will Not Open With Correct Password Error Message

1:Mon Feb 7 17:14:38 2005:pid=12351:ERR:bmccfg_role.c:316:Security policy entry server does not contain keyfile entry2:Mon Feb 7 17:14:38 2005:pid=12351:ERR:bmccfg.c:649:PolicyLoad failed -1


No Key for Negotiated Cipher Error Message

No Key for Negotiated Cipher Error Message

An SSL server or client opens the key database, but refuses an SSL connection due to a “no key for negotiated cipher” error.

Cause

The key associated with the SSL Identity was found in the key database, but a certificate guaranteeing its authenticity was not found.

The SSLV2CipherSuite or the SSLV3CipherSuite attribute limits the list of possible cipher suites that can be used by the server or client. A common cipher suite supported by both cannot be found.

Cannot Install a Certificate into a Key Database

This certificate cannot be installed into the key database.

Causes

■ This certificate does not pertain to any key pair contained in the key database.

■ The CA certificate used to sign this certificate has not been previously installed in the key database.

■ A CA certificate has been installed in the key database, but it is not the CA certificate used to sign this certificate.

■ This certificate has (mistakenly) previously been installed in the key database as a CA certificate.

Cannot Install a CRL into a Key Database

A certificate revocation list (CRL) cannot be installed into the key database.

Cause

The CA certificate of the CA to which this CRL pertains has not been previously installed into the key database.


Windows CA Rejects a CSR

Windows CA Rejects a CSR

A Windows Certificate Authority rejects a certificate signing request (CSR) which contains the public key of a DSA key pair.

Cause

The Windows Certificate Authority will not generate a certificate for a DSA key pair.

Password Not Configured

The default ASCII Password Dialog prompts for the keyfile and password selection on operating systems s390/Linux and Siemens Sinix 5.43, or for systems where the X11 runtime environment is not configured.

Cause

Using the keyboard-based ASCII prompt is possible only by a foreground process.

Solution

For non-GUI configuration requiring an attended password entry, the PatrolAgent service must run directly from a user shell. The PatrolAgent script should not be used. Run PatrolAgent from the PATROL3/OS/bin directory.

Password Prompt Does Not Display

The password prompt fails to display when starting the agent or console for Unix.

Solution

Specify your computer as the hostname:

$ DISPLAY=hostname:0.0


Typed Password Does Not Appear in Password Dialog Box

Typed Password Does Not Appear in Password Dialog Box

When using the scripts file in PATROL3 to start the PATROL Console and Agent on Unix in attended mode (password required), the password dialog does not receive standard input.

Solution

Perform one of the following actions:

■ If you wish to run in attended mode, start the PATROL Console and Agent from the PATROL3/OS/bin directory. Be aware that starting the console and agent from the bin directory prevents the Perform Agent, dcm, and bgscollect services from running.

■ If you wish to run the Perform Agent, dcm, and bgscollect services, you can start the PATROL Console and Agent from the PATROL3 directory, but you must run in unattended mode.

Password Dialog Prompt Does Not Appear

When running PEM-based services, including the console, agent, and any other PEM-based applications, as a service under the domain account, the Password Dialog prompt does not appear.

Solution


■ If you wish to use attended mode, run the PEM-based service at the command line under the local system account or run it as a service using the system account and allowing the service to interact with the desktop.

■ If you wish to run the PEM-based service as a service under the domain account, use unattended mode.


PATROL KM for Microsoft Cluster Server Does Not Support Attended Mode at Level 4

PATROL KM for Microsoft Cluster Server Does Not Support Attended Mode at Level 4

The PATROL KM for Microsoft Cluster Server does not operate in attended mode with Level 4 security.

Solution

Attended mode does not support the use of services running under a domain account. Since the Cluster Service runs only under a domain account, you are unable to run this service in attended mode.

Cannot Find Shared Library

PATROL fails to discover the shared library API km.

Solution

For security levels 1 through 4, all dll files must have signature files (api.dll.sgn) in order to load. To create signature files, use the signFile utility located in $BMC_ROOT/common/security/bin_v3.0/target (Unix) or %BMC_ROOT%\common\security\bin_v3.0\target (Windows).

After you have created signature files for the dll files, perform either of the following actions:

■ In the patrol.conf file, in the 'agentrights' section under the [AGENT] stanza, change the allowalldlls attribute to allowalldlls=true.

■ In /etc/patrol.d/dlls.conf, list all DLL file(s) and directories that the agent is authorized to load. A template file for dlls.conf is loaded during installation and resides in /etc/patrol.d.


Discovery Fails

Discovery Fails

Discovery performs a UDP ping and fails.

Cause

Discovery using a UDP fails when during installation you select TCM network connection only.

Solution

In the config.default file, comment out the following line:

Password for 64-bit Key Files Is Not Validated

When entering a newly created .kdb file and password in the Password Dialog box, the system fails to validate the correct password for 64-bit key files and an “Incorrect password” message appears.

Cause

A key database created by a 64-bit sslcmd application cannot be opened by a 32-bit application. Similarly, a key database created by a 32-bit sslcmd application but opened and subsequently modified by a 64-bit sslcmd application can no longer be opened by the 32-bit application. In short, key databases are, in general, not transportable between 32-bit and 64-bit platforms.

"/AgentSetup/PortConnectType"= {REPLACE="TCP"}


Password Dialog Prompt Does Not Appear When Running at Level 4

Password Dialog Prompt Does Not Appear When Running at Level 4

When running PATROL Console Server (or any service which must run in attended mode at level 4) as a service under the domain account, the password prompt dialog box is not displayed.

Solution


■ If you want to use attended mode, run Console Server at the command line under the local system account or run it as a service using the system account and allowing the service to interact with the desktop.

■ If you want to run Console Server as a service under the domain account, use unattended mode.


Error Conditions

Error ConditionsIf you are experiencing a problem with PATROL Security, review the following error conditions. These conditions are the most frequently experienced problems.

Invalid Policy Password

Cause

The server encrypted password text was modified.

Invalid Policy Keyfile

Cause

The incorrect key database path and/or filename was entered in the keyfile attribute.

Figure 58 Invalid Policy Password Error Message

1:Wed Mar 6 11:14:15 2002:pid=27584:ERR:ess_policy.c:586:error decrypting stored password

Figure 59 Invalid Policy Keyfile Error Message

unable to bootstrap policy /etc/patrol.d/security_policy/agent.plc, unable to set /home/mpetkevi/bmc/ess2.0/cert/server1.kdb keystore: key store /home/mpetkevi/bmc/ess2.0/cert/server1.kdb cannot be reached


Incorrect Encrypted Password Used During Security Bootstrap

Incorrect Encrypted Password Used During Security Bootstrap

Cause

The server encrypted password differs from the actual key database password.

Invalid Policy Identity Field (Non-Existing Key)

Cause

The server identity field is set to an invalid value.

Client Log

Figure 60 Incorrect Encrypted Password Used During Security Bootstrap Error Message

1:Wed Mar 6 11:20:35 2002:pid=27733:INF:ess_policy.c:692:BCA Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:27:232:Wed Mar 6 11:20:36 2002:pid=27733:INF:ess_policy.c:694:SSL Module, Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:29:09 (Domestic)3:Wed Mar 6 11:20:37 2002:pid=27733:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmc/ess2.0/cert/server.kdb4:Wed Mar 6 11:20:37 2002:pid=27733:ERR:ssl_tsw.c:344:Cannot initiate with TSW_crypt_init, invalid password, key file /home/mpetkevi/bmc/ess2.0/cert/server.kdb, CORE: Wrong version5:Wed Mar 6 11:20:38 2002:pid=27733:ERR:../bcm/bcm_api.c:522:BCM_Option: unable to execute option

Figure 61 Invalid Policy Identity Field (Non-existing Key) Error Message, Client Log

1:Wed Mar 6 11:47:08 2002:pid=28431:INF:ess_policy.c:692:BCA Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:27:232:Wed Mar 6 11:47:09 2002:pid=28431:INF:ess_policy.c:694:SSL Module, Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:29:09 (Domestic)3:Wed Mar 6 11:47:09 2002:pid=28431:INF:ess_policy.c:770:client security system at level 2, application security at level 2, site policy /etc/patrol.d/security_policy/site.plc/client, application policy /etc/patrol.d/security_policy/console.plc/client4:Wed Mar 6 11:47:12 2002:pid=28431:ERR:ssl_tsw.c:1133:caught SSL alert from 127.0.0.1 , 40, Handshake failure, level 2, SSL: Caught alert5:Wed Mar 6 11:47:13 2002:pid=28431:ERR:../bcm/bcm_api.c:230:unable to connect secure sessionfor user: , service6:Wed Mar 6 11:47:14 2002:pid=28431:INF:bcm_profile.c:334:session 512 was shutdown7:Wed Mar 6 11:47:15 2002:pid=28431:ERR:../bcm/bcm_api.c:536:BCM_CleanUp: Unable to locate session8:Wed Mar 6 11:47:16 2002:pid=28431:ERR:../bcm/bcm_api.c:423:BCM_Terminate: Unable to locate session


Invalid Policy Identity Field (Non-Existing Key)

Server Log

Figure 62 Invalid Policy Identity Field (Non-existing Key) Error Message, Server Log

1:Wed Mar 6 11:47:04 2002:pid=28430:INF:ess_policy.c:692:BCA Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:27:232:Wed Mar 6 11:47:05 2002:pid=28430:INF:ess_policy.c:694:SSL Module, Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:29:09 (Domestic)3:Wed Mar 6 11:47:06 2002:pid=28430:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmc/ess2.0/cert/server.kdb4:Wed Mar 6 11:47:07 2002:pid=28430:INF:ess_policy.c:770:server security system at level 2, application security at level 2, site policy /etc/patrol.d/security_policy/site.plc/server, application policy /etc/patrol.d/security_policy/agent.plc/server5:Wed Mar 6 11:47:10 2002:pid=28430:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmc/ess2.0/cert/server.kdb6:Wed Mar 6 11:47:11 2002:pid=28430:TRC:bcm_sslsess.c:157:BCM_ModuleServer(): done7:Wed Mar 6 11:47:12 2002:pid=28430:ERR:key_hook.c:93:identity: server1 is not found in key database /home/mpetkevi/bmc/ess2.0/cert/server.kdb8:Wed Mar 6 11:47:12 2002:pid=28430:ERR:ssl_tsw.c:1149:Error initiating handshake as server with 127.0.0.1 , errno 0, SSL: Operation Cancelled9:Wed Mar 6 11:47:13 2002:pid=28430:ERR:../bcm/bcm_api.c:279:unable to establish session side, handle: 0007b0e8, service: mysprinc10:Wed Mar 6 11:47:14 2002:pid=28430:INF:bcm_profile.c:334:session 512 was shutdown11:Wed Mar 6 11:47:15 2002:pid=28430:ERR:../bcm/bcm_api.c:536:BCM_CleanUp: Unable to locate session12:Wed Mar 6 11:47:16 2002:pid=28430:ERR:../bcm/bcm_api.c:423:BCM_Terminate: Unable to locatesession


Mutual Authentication Nominal Case

Mutual Authentication Nominal Case

Cause

Nominal level 4.

Client Log

Server Log

Figure 63 Mutual Authentication Nominal Case Error Message, Client Log

1:Wed Mar 6 14:41:19 2002:pid=1962:INF:ess_policy.c:692:BCA Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:27:232:Wed Mar 6 14:41:20 2002:pid=1962:INF:ess_policy.c:694:SSL Module, Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:29:09 (Domestic)3:Wed Mar 6 14:41:20 2002:pid=1962:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmcuser.kdb4:Wed Mar 6 14:41:21 2002:pid=1962:INF:ess_policy.c:770:client security system at level 4, application security at level 4, site policy /etc/patrol.d/security_policy/site.plc/client, application policy /etc/patrol.d/security_policy/console.plc/client5:Wed Mar 6 14:41:22 2002:pid=1962:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmcuser.kdb6:Wed Mar 6 14:41:24 2002:pid=1962:INF:ssl_tsw.c:1039:creating cert list of 27:Wed Mar 6 14:41:25 2002:pid=1962:WRN:auth_hook2.c:226:REVOCATION UNKNOWN certificate discovered --> subject: CN=TrialServerPrincipal,OU=TestAndVerification,O=BMC Software,L=Houston,ST=TX,C=US,[email protected], serial: 07:6D:34:8F:00:00:05:138:Wed Mar 6 14:41:28 2002:pid=1962:INF:ssl_tsw.c:1112:connection with 127.0.0.1 established

Figure 64 Mutual Authentication Nominal Case Error Message, Server Log (part 1 of 2)

1:Wed Mar 6 14:41:07 2002:pid=1959:INF:ess_policy.c:692:BCA Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:27:232:Wed Mar 6 14:41:08 2002:pid=1959:INF:ess_policy.c:694:SSL Module, Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:29:09 (Domestic)3:Wed Mar 6 14:41:09 2002:pid=1959:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmc/ess2.0/cert/server.kdb4:Wed Mar 6 14:41:09 2002:pid=1959:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmc/ess2.0/cert/server.kdb5:Wed Mar 6 14:41:10 2002:pid=1959:INF:ess_policy.c:770:server security system at level 4, application security at level 4, site policy /etc/patrol.d/security_policy/site.plc/server, application policy /etc/patrol.d/security_policy/agent.plc/server6:Wed Mar 6 14:41:22 2002:pid=1959:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmc/ess2.0/cert/server.kdb7:Wed Mar 6 14:41:23 2002:pid=1959:TRC:bcm_sslsess.c:157:BCM_ModuleServer(): done8:Wed Mar 6 14:41:23 2002:pid=1959:INF:ssl_tsw.c:1098:Client authentication enabled


Missing Key On Level 4 Client


Cause

The bmcuser key was removed from bmcuser.kdb.

Client Log

9:Wed Mar 6 14:41:26 2002:pid=1959:INF:ssl_tsw.c:1039:creating cert list of 210:Wed Mar 6 14:41:26 2002:pid=1959:WRN:auth_hook2.c:226:REVOCATION UNKNOWN certificate discovered --> subject: CN=TrialUserPrincipal,OU=TestAndVerification,O=BMC Software,L=Houston,ST=TX,C=US,[email protected], serial: 09:AC:8F:E2:00:00:05:2211:Wed Mar 6 14:41:27 2002:pid=1959:INF:auth_hook2.c:260:access granted for client [email protected]:Wed Mar 6 14:41:28 2002:pid=1959:INF:ssl_tsw.c:1112:connection with 127.0.0.1 established13:Wed Mar 6 14:41:32 2002:pid=1959:INF:bcm_profile.c:334:session 512 was shutdown14:Wed Mar 6 14:41:33 2002:pid=1959:INF:../bcm/bcm_api.c:430:BCM_Terminate: session 512 terminated

Figure 65 Missing Key on Level 4 Client Error Message, Client Log (part 1 of 2)

1:Wed Mar 6 14:59:04 2002:pid=2198:INF:ess_policy.c:692:BCA Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:27:232:Wed Mar 6 14:59:04 2002:pid=2198:INF:ess_policy.c:694:SSL Module, Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:29:09 (Domestic)3:Wed Mar 6 14:59:05 2002:pid=2198:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmcuser.kdb4:Wed Mar 6 14:59:06 2002:pid=2198:INF:ess_policy.c:770:client security system at level 4, application security at level 4, site policy /etc/patrol.d/security_policy/site.plc/client, application policy /etc/patrol.d/security_policy/console.plc/client5:Wed Mar 6 14:59:06 2002:pid=2198:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmcuser.kdb6:Wed Mar 6 14:59:09 2002:pid=2198:INF:ssl_tsw.c:1039:creating cert list of 27:Wed Mar 6 14:59:09 2002:pid=2198:WRN:auth_hook2.c:226:REVOCATION UNKNOWN certificate discovered --> subject: CN=TrialServerPrincipal,OU=TestAndVerification,O=BMC Software,L=Houston,ST=TX,C=US,[email protected], serial: 07:6D:34:8F:00:00:05:138:Wed Mar 6 14:59:10 2002:pid=2198:ERR:ssl_tsw.c:1141: no key, while handshaking with 127.0.0.1 , SSL: No key available for negotiated cipher9:Wed Mar 6 14:59:11 2002:pid=2198:ERR:../bcm/bcm_api.c:230:unable to connect secure session for user: , service10:Wed Mar 6 14:59:11 2002:pid=2198:INF:bcm_profile.c:334:session 512 was shutdown

Figure 64 Mutual Authentication Nominal Case Error Message, Server Log (part 2 of 2)



Server Log

11:Wed Mar 6 14:59:13 2002:pid=2198:ERR:../bcm/bcm_api.c:536:BCM_CleanUp: Unable to locate session12:Wed Mar 6 14:59:14 2002:pid=2198:ERR:../bcm/bcm_api.c:423:BCM_Terminate: Unable to locate session

Figure 66 Missing Key on Level 4 Client Error Message, Server Log

1:Wed Mar 6 14:59:04 2002:pid=2198:INF:ess_policy.c:692:BCA Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:27:232:Wed Mar 6 14:59:04 2002:pid=2198:INF:ess_policy.c:694:SSL Module, Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:29:09 (Domestic)3:Wed Mar 6 14:59:05 2002:pid=2198:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmcuser.kdb4:Wed Mar 6 14:59:06 2002:pid=2198:INF:ess_policy.c:770:client security system at level 4, application security at level 4, site policy /etc/patrol.d/security_policy/site.plc/client, application policy /etc/patrol.d/security_policy/console.plc/client5:Wed Mar 6 14:59:06 2002:pid=2198:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmcuser.kdb6:Wed Mar 6 14:59:09 2002:pid=2198:INF:ssl_tsw.c:1039:creating cert list of 27:Wed Mar 6 14:59:09 2002:pid=2198:WRN:auth_hook2.c:226:REVOCATION UNKNOWN certificate discovered --> subject: CN=TrialServerPrincipal,OU=TestAndVerification,O=BMC Software,L=Houston,ST=TX,C=US,[email protected], serial: 07:6D:34:8F:00:00:05:138:Wed Mar 6 14:59:10 2002:pid=2198:ERR:ssl_tsw.c:1141: no key, while handshaking with 127.0.0.1 , SSL: No key available for negotiated cipher9:Wed Mar 6 14:59:11 2002:pid=2198:ERR:../bcm/bcm_api.c:230:unable to connect secure session for user: , service10:Wed Mar 6 14:59:11 2002:pid=2198:INF:bcm_profile.c:334:session 512 was shutdown11:Wed Mar 6 14:59:13 2002:pid=2198:ERR:../bcm/bcm_api.c:536:BCM_CleanUp: Unable to locate session12:Wed Mar 6 14:59:14 2002:pid=2198:ERR:../bcm/bcm_api.c:423:BCM_Terminate: Unable to locate session

Figure 65 Missing Key on Level 4 Client Error Message, Client Log (part 2 of 2)


Missing Trusted Root (client)


Cause

WWWQA trusted root removed from bmcuser.kdb

Client Log

Figure 67 Missing Trusted Root (client) Error Message, Client Log

1:Wed Mar 6 15:13:18 2002:pid=2470:INF:ess_policy.c:692:BCA Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:27:232:Wed Mar 6 15:13:19 2002:pid=2470:INF:ess_policy.c:694:SSL Module, Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:29:09 (Domestic)3:Wed Mar 6 15:13:19 2002:pid=2470:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmcuser.kdb4:Wed Mar 6 15:13:20 2002:pid=2470:INF:ess_policy.c:770:client security system at level 4, application security at level 4, site policy /etc/patrol.d/security_policy/site.plc/client, application policy /etc/patrol.d/security_policy/console.plc/client5:Wed Mar 6 15:13:21 2002:pid=2470:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmcuser.kdb6:Wed Mar 6 15:13:23 2002:pid=2470:WRN:verify.c:89:No trusted CA for the last certificate in the chain: Subject CN=WWWQA Testing Certificate Authority,OU=WEBDEV,O=BMC Software,L=Houston,ST=Texas,C=US Issuer CN=WWWQA Testing Certificate Authority,OU=WEBDEV,O=BMC Software,L=Houston,ST=Texas,C=US Certificate Serial=2cc4384b1000128f11d2e2e0a91681d4 Valid Begin:Thu Mar 25 12:44:14 1999 Valid End: Thu Mar 25 12:44:14 2004 Status: UNVERIFIED, verification required - certificate rejected7:Wed Mar 6 15:13:24 2002:pid=2470:WRN:verify.c:89:No trusted CA for the last certificate in the chain: Subject CN=TrialServerPrincipal,OU=TestAndVerification,O=BMC Software,L=Houston,ST=TX,C=US,[email protected] Issuer CN=WWWQA Testing Certificate Authority,OU=WEBDEV,O=BMC Software,L=Houston,ST=Texas,C=US Certificate Serial=076d348f00000513 Valid Begin:Thu Jul 1923:15:54 2001 Valid End: Sat Jul 19 23:15:54 2003 Status: UNVERIFIED, verification required - certificate rejected8:Wed Mar 6 15:13:25 2002:pid=2470:ERR:ssl_tsw.c:1149:Error initiating handshake as client with 127.0.0.1 , errno 2, SSL: Required certificate not provided9:Wed Mar 6 15:13:25 2002:pid=2470:ERR:../bcm/bcm_api.c:230:unable to connect secure session for user: , service10:Wed Mar 6 15:13:26 2002:pid=2470:INF:bcm_profile.c:334:session 512 was shutdown11:Wed Mar 6 15:13:27 2002:pid=2470:ERR:../bcm/bcm_api.c:536:BCM_CleanUp: Unable to locate session12:Wed Mar 6 15:13:27 2002:pid=2470:ERR:../bcm/bcm_api.c:423:BCM_Terminate: Unable to locate session



Server Log

Figure 68 Missing Trusted Root (client) Error Message, Server Log

1:Wed Mar 6 15:12:57 2002:pid=2459:INF:ess_policy.c:692:BCA Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:27:232:Wed Mar 6 15:12:58 2002:pid=2459:INF:ess_policy.c:694:SSL Module, Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:29:09 (Domestic)3:Wed Mar 6 15:12:59 2002:pid=2459:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmc/ess2.0/cert/server.kdb4:Wed Mar 6 15:12:59 2002:pid=2459:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmc/ess2.0/cert/server.kdb5:Wed Mar 6 15:13:00 2002:pid=2459:INF:ess_policy.c:770:server security system at level 4, application security at level 4, site policy /etc/patrol.d/security_policy/site.plc/server, application policy /etc/patrol.d/security_policy/agent.plc/server6:Wed Mar 6 15:13:21 2002:pid=2459:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmc/ess2.0/cert/server.kdb7:Wed Mar 6 15:13:22 2002:pid=2459:TRC:bcm_sslsess.c:157:BCM_ModuleServer(): done8:Wed Mar 6 15:13:23 2002:pid=2459:INF:ssl_tsw.c:1098:Client authentication enabled9:Wed Mar 6 15:13:28 2002:pid=2459:ERR:ssl_tsw.c:1149:Error initiating handshake as server with 127.0.0.1 , errno 0, SSL: IO error10:Wed Mar 6 15:13:28 2002:pid=2459:ERR:../bcm/bcm_api.c:279:unable to establish session side, handle: 0007b0e8, service: mysprinc11:Wed Mar 6 15:13:29 2002:pid=2459:INF:bcm_profile.c:334:session 512 was shutdown12:Wed Mar 6 15:13:30 2002:pid=2459:ERR:../bcm/bcm_api.c:536:BCM_CleanUp: Unable to locate session13:Wed Mar 6 15:13:30 2002:pid=2459:ERR:../bcm/bcm_api.c:423:BCM_Terminate: Unable to locate session


Missing Certificate (Server)

Missing Certificate (Server)

Cause

The server policy specifies a key with no certificate.

Client Log

Server Log

Figure 69 Missing Certificate, Client Log

1:Wed Mar 6 15:20:31 2002:pid=2629:INF:ess_policy.c:692:BCA Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:27:232:Wed Mar 6 15:20:32 2002:pid=2629:INF:ess_policy.c:694:SSL Module, Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:29:09 (Domestic)3:Wed Mar 6 15:20:32 2002:pid=2629:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmcuser.kdb4:Wed Mar 6 15:20:33 2002:pid=2629:INF:ess_policy.c:770:client security system at level 4, application security at level 4, site policy /etc/patrol.d/security_policy/site.plc/client, application policy /etc/patrol.d/security_policy/console.plc/client5:Wed Mar 6 15:20:33 2002:pid=2629:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmcuser.kdb6:Wed Mar 6 15:20:37 2002:pid=2629:ERR:ssl_tsw.c:1133:caught SSL alert from 127.0.0.1 , 40, Handshake failure, level 2, SSL: Caught alert7:Wed Mar 6 15:20:38 2002:pid=2629:ERR:../bcm/bcm_api.c:230:unable to connect secure session for user: , service8:Wed Mar 6 15:20:39 2002:pid=2629:INF:bcm_profile.c:334:session 512 was shutdown9:Wed Mar 6 15:20:39 2002:pid=2629:ERR:../bcm/bcm_api.c:536:BCM_CleanUp: Unable to locate session10:Wed Mar 6 15:20:40 2002:pid=2629:ERR:../bcm/bcm_api.c:423:BCM_Terminate: Unable to locate session

Figure 70 Missing Certificate, Server Log (part 1 of 2)

1:Wed Mar 6 15:20:10 2002:pid=2623:INF:ess_policy.c:692:BCA Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:27:232:Wed Mar 6 15:20:11 2002:pid=2623:INF:ess_policy.c:694:SSL Module, Version 1.0|ess2.0.d.5.7|sunos_5.5.1_sun4u|Mar 1 2002|14:29:09 (Domestic)3:Wed Mar 6 15:20:12 2002:pid=2623:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmc/ess2.0/cert/server.kdb4:Wed Mar 6 15:20:13 2002:pid=2623:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmc/ess2.0/cert/server.kdb5:Wed Mar 6 15:20:13 2002:pid=2623:INF:ess_policy.c:770:server security system at level 4, application security at level 4, site policy /etc/patrol.d/security_policy/site.plc/server, application policy /etc/patrol.d/security_policy/agent.plc/server6:Wed Mar 6 15:20:33 2002:pid=2623:INF:ssl_tsw.c:299:key file name is: /home/mpetkevi/bmc/ess2.0/cert/server.kdb7:Wed Mar 6 15:20:35 2002:pid=2623:TRC:bcm_sslsess.c:157:BCM_ModuleServer(): done


Expired Certificate

Expired Certificate

Cause

The key certificate has expired.

Client

8:Wed Mar 6 15:20:35 2002:pid=2623:INF:ssl_tsw.c:1098:Client authentication enabled9:Wed Mar 6 15:20:36 2002:pid=2623:ERR:key_hook.c:93:identity: mike is not found in key database /home/mpetkevi/bmc/ess2.0/cert/server.kdb10:Wed Mar 6 15:20:37 2002:pid=2623:ERR:ssl_tsw.c:1149:Error initiating handshake as server with 127.0.0.1 , errno 0, SSL: Operation Cancelled11:Wed Mar 6 15:20:38 2002:pid=2623:ERR:../bcm/bcm_api.c:279:unable to establish session side, handle: 0007b2f0, service: mysprinc12:Wed Mar 6 15:20:39 2002:pid=2623:INF:bcm_profile.c:334:session 512 was shutdown13:Wed Mar 6 15:20:39 2002:pid=2623:ERR:../bcm/bcm_api.c:536:BCM_CleanUp: Unable to locate session14:Wed Mar 6 15:20:40 2002:pid=2623:ERR:../bcm/bcm_api.c:423:BCM_Terminate: Unable to locate session

Figure 71 Expired Certificate, Client Log (part 1 of 2)

1:Sun Mar 07 15:01:06 2004:pid=4016:WRN:auth_hook2.c:226:EXPIRED certificate discovered --> subject: CN=TrialServerPrincipal,OU=TestAndVerification,O=BMC Software,L=Houston,ST=TX,C=US,[email protected], serial: 07:6D:34:8F:00:00:05:132:Sun Mar 07 15:01:06 2004:pid=4016:ERR:ssl_tsw.c:1149:Error initiating handshake as client with peer , errno 2, SSL: Permission denied by auth hook3:Sun Mar 07 15:01:06 2004:pid=4016:ERR:ssl_tsw.c:962:Unable to rehandshake4:Sun Mar 07 15:01:06 2004:pid=4016:ERR:..\bcm\bcm_api.c:437:esi_Read, unable to process BCA event for context 01E905B05:Sun Mar 07 15:01:06 2004:pid=4016:WRN:auth_hook2.c:226:EXPIRED certificate discovered --> subject: CN=TrialServerPrincipal,OU=TestAndVerification,O=BMC Software,L=Houston,ST=TX,C=US,[email protected], serial: 07:6D:34:8F:00:00:05:136:Sun Mar 07 15:01:06 2004:pid=4016:ERR:ssl_tsw.c:1149:Error initiating handshake as client with peer , errno 2, SSL: Permission denied by auth hook7:Sun Mar 07 15:01:06 2004:pid=4016:ERR:ssl_tsw.c:962:Unable to rehandshake8:Sun Mar 07 15:01:06 2004:pid=4016:ERR:..\bcm\bcm_api.c:437:esi_Read, unable to process BCA event for context 01E905309:Sun Mar 07 15:01:06 2004:pid=4016:ERR:ssl_tsw.c:1002:error on TSW_SSL_Read, status = -13, unknown, SSL: Internal error10:Sun Mar 07 15:01:06 2004:pid=4016:ERR:..\bcm\bcm_api.c:437:esi_Read, unable to process BCA event for context 01E905B0

Figure 70 Missing Certificate, Server Log (part 2 of 2)


Expired Certificate

Server Log

11:Sun Mar 07 15:01:06 2004:pid=4016:ERR:ssl_tsw.c:1002:error on TSW_SSL_Read, status = -13, unknown, SSL: Internal error12:Sun Mar 07 15:01:06 2004:pid=4016:ERR:..\bcm\bcm_api.c:437:esi_Read, unable to process BCA event for context 01E90530

Figure 72 Expired Certificate, Server Log

1:Sun Mar 07 15:09:43 2004:pid=2396:INF:ess_policy.c:692:BCA Version 1.0|ess2.0.d.5.7|win32|Feb 1 2002|12:42:152:Sun Mar 07 15:09:43 2004:pid=2396:INF:ess_policy.c:694:SSL Module, Version 1.0|ess2.0.d.5.7|win32|Feb 1 2002|12:44:33 (Domestic)3:Sun Mar 07 15:09:43 2004:pid=2396:INF:ssl_tsw.c:299:key file name is: D:\Program Files\BMC Software\common\security\keys\server.kdb4:Sun Mar 07 15:09:43 2004:pid=2396:INF:ssl_tsw.c:299:key file name is: D:\Program Files\BMC Software\common\security\keys\server.kdb5:Sun Mar 07 15:09:43 2004:pid=2396:INF:ess_policy.c:770:server security system at level 4, application security at level 4, site policy SOFTWARE\BMC Software\Patrol\SecurityPolicy\SITE\server, application policy SOFTWARE\BMC Software\Patrol\SecurityPolicy\AGENT\server6:Sun Mar 07 15:12:57 2004:pid=2396:TRC:..\bcm\bcm_api.c:437:esi_FreeCtx, deallocating module security context7:Sun Mar 07 15:12:57 2004:pid=2396:ERR:..\bcm\bcm_api.c:423:BCM_Terminate: Unable to locate session8:Sun Mar 07 15:12:57 2004:pid=2396:INF:..\bcm\bcm_api.c:437:esi security context deallocated for 015C05A0, session termination status is -79:Sun Mar 07 15:12:58 2004:pid=2396:TRC:..\bcm\bcm_api.c:437:Entering esi_Read with len 99, ctx 015C05A010:Sun Mar 07 15:12:58 2004:pid=2396:INF:ssl_tsw.c:299:key file name is: D:\Prog

Figure 71 Expired Certificate, Client Log (part 2 of 2)


A p p e n d i x C
C Valid Country Codes
Table 55 provides the valid two-letter ISO country codes for the Distinguished Name prompt “Country,” as used by the sslcmd utility. For more information, see “Creating a Certificate Signing Request” on page 89.

Table 55 Valid Country Codes (part 1 of 7)

Country Code

Afghanistan AF

Albania AL

Algeria DZ

American Samoa AS

Andorra AD

Angola AO

Anguilla AI

Antarctica AQ

Antigua And Barbuda AG

Argentina AR

Armenia AM

Aruba AW

Australia AU

Austria AT

Azerbaijan AZ

Bahamas BS

Bahrain BH

Bangladesh BD

Barbados BB

Belgium BE

Belize BZ

Benin BJ

Bermuda BM


Bhutan BT

Bolivia BO

Bosnia Hercegovina BA

Botswana BW

Bouvet Island BV

Brazil BR

British Indian Ocean Territory

IO

Brunei Darussalam BN

Bulgaria BG

Burkina Faso BF

Burundi BI

Belarus BY

Cambodia KH

Cameroon CM

Canada CA

Cape Verde CV

Cayman Islands KY

Central African Republic CF

Chad TD

Chile CL

China CN

Christmas Island CX

Cocos (Keeling) Islands CC

Colombia CO

Comoros KM

Congo CG

Cook Islands CK

Costa Rica CR

Cote D'ivoire CI

Croatia HR

Cuba CU

Cyprus CY

Czech Republic CZ

Czechoslovakia CS

Denmark DK

Djibouti DJ

Dominica DM


Country Code


Dominican Republic DO

East Timor TP

Ecuador EC

Egypt EG

El Salvador SV

Equatorial Guinea GQ

Estonia EE

Ethiopia ET

Falkland Islands (Malvinas) FK

Faroe Islands FO

Fiji FJ

Finland FI

France FR

French Guiana GF

French Polynesia PF

French Southern Territories TF

Gabon GA

Gambia GM

Georgia GE

Germany DE

Ghana GH

Gibraltar GI

Greece GR

Greenland GL

Grenada GD

Guadeloupe GP

Guam GU

Guatemala GT

Guinea GN

Guinea-bissau GW

Guyana GY

Haiti HT

Heard And Mc Donald Islands

HM

Honduras HN

Hong Kong HK

Hungary HU

Iceland IS


Country Code


India IN

Indonesia ID

Iran (Islamic Republic Of) IR

Iraq IQ

Ireland IE

Israel IL

Italy IT

Jamaica JM

Japan JP

Jordan JO

Kazakhstan KZ

Kenya KE

Kiribati KI

Korea, Democratic People's Republic Of

KP

Korea, Republic Of KR

Kuwait KW

Kyrgyzstan KG

Lao People's Democratic Republic

LA

Latvia LV

Lebanon LB

Lesotho LS

Liberia LR

Libyan Arab Jamahiriya LY

Liechtenstein LI

Lithuania LT

Luxembourg LU

Macau MO

Madagascar MG

Malawi MW

Malaysia MY

Maldives MV

Mali ML

Malta MT

Marshall Islands MH

Martinique MQ

Mauritania MR


Country Code


Mauritius MU

Mexico MX

Micronesia FM

Moldova, Republic Of MD

Monaco MC

Mongolia MN

Montserrat MS

Morocco MA

Mozambique MZ

Myanmar MM

Namibia NA

Nauru NR

Nepal NP

Netherlands NL

Netherlands Antilles AN

Neutral Zone NT

New Caledonia NC

New Zealand NZ

Nicaragua NI

Niger NE

Nigeria NG

Niue NU

Norfolk Island NF

Northern Mariana Islands MP

Norway NO

Oman OM

Pakistan PK

Palau PW

Panama PA

Papua New Guinea PG

Paraguay PY

Peru PE

Philippines PH

Pitcairn PN

Poland PL

Portugal PT

Puerto Rico PR

Qatar QA


Country Code


Reunion RE

Romania RO

Russian Federation RU

Rwanda RW

St. Helena SH

Saint Kitts And Nevis KN

Saint Lucia LC

St. Pierre And Miquelon PM

Saint Vincent And The Grenadines

VC

Samoa WS

San Marino SM

Sao Tome And Principe ST

Saudi Arabia SA

Senegal SN

Seychelles SC

Sierra Leone SL

Singapore SG

Slovakia SK

Slovenia SI

Solomon Islands SB

Somalia SO

South Africa ZA

Spain ES

Sri Lanka LK

Sudan SD

Suriname SR

Svalbard And Jan Mayen Islands

SJ

Swaziland SZ

Sweden SE

Switzerland CH

Syrian Arab Republic SY

Taiwan, Province Of China TW

Tajikistan TJ

Tanzania, United Republic Of TZ

Thailand TH

Togo TG


Country Code


Tokelau TK

Tonga TO

Trinidad And Tobago TT

Tunisia TN

Turkey TR

Turkmenistan TM

Turks And Caicos Islands TC

Tuvalu TV

Uganda UG

Ukraine UA

United Arab Emirates AE

United Kingdom GB

United States US

United States Minor Outlying Islands

UM

Uruguay UY

Ussr SU

Uzbekistan UZ

Vanuatu VU

Vatican City State (Holy See) VA

Venezuela VE

Viet Nam VN

Virgin Islands (British) VG

Virgin Islands (U.s.) VI

Wallis And Futuna Islands WF

Western Sahara EH

Yemen, Republic Of YE

Yugoslavia YU

Zaire ZR

Zambia ZM

Zimbabwe ZW


Country Code



A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Glossaryaccess control list

A list that is set up by using a PATROL Agent configuration variable and that restricts PATROL Console access to a PATROL Agent. A PATROL Console can be assigned access rights to perform console, agent configuration, or event manager activities. The console server uses access control lists to restrict access to objects in the COS namespace.

authentication A method of proving a person's identity.

certificateThis is a digital document containing a public key and a name used to authenticate the identity of the source of the data accompanying the certificate.

certificate authority (CA)This is an issuer of an x509 certificate used in Secure Socket Layer (SSL) connections. It is also referred to as a trusted root authority. See trusted root certificate authority.

certificate revocation list (CRL)The CRL is maintained by the Certificate Authority (CA). When the private key associated with the public key contained in the certificate is compromised, the owner of the compromised private key should immediately notify the CA that signed the certificate. The CA then publishes a CRL, which lists the certificate as having been revoked. Each user of a particular CA should obtain the CRL of that CA on a regular basis and install the CRL in the key database, so that if the revoked certificate is presented at a later date, the software will detect it as a revoked certificate and the chain of trust will be broken. If the certificate revocation list of a CA is missing from the key database, PATROL will issue the warning “REVOCATION UNKNOWN.”

chain of trustThis is a principle of security by which a software component verifies the identity of an unknown party by accepting the assurance of a third party whose identity it knows is genuine. It is possible that this party’s identity is trusted because of the assurance of yet another party. This series of verifications by a trusted party continues (in a chain) until it is traced back to a trusted root (also known as a Certificate Authority) that the software component knows is trustworthy because it is provided by its own company or an approved vendor.

console serverA server through which PATROL Central and PATROL Web Central communicate with managed systems. A console server handles requests, events, data, communications, views, customizations, and security.

Diffie-Hellman public key A public key algorithm that allows participants to generate public-private keys, exchange public and private keys, and commute a common session key.

Glossary 211


digital signature Digitally signed hash of a user data.

digital signingThis is the process of generating a hash value or check sum by applying an algorithm to a file. The check sum is then used by the recipient of the file to verify that the contents of the file have not been altered during transmission from the sender to the receiver. The check sum is protected by its being encrypted with the signer’s private key. The resulting value is called a signature.

digital verificationThis is the process of decrypting a signature with the public key of the signer. The signer’s public key resides in the signer’s certificate, which must be stored in the key database used by an application operating in the verifier role.

distinguished name (DN) The fully-qualified hierarchical names that uniquely identify a specific entity that is authenticated by a digital certificate.

DSAA type of public-key algorithm used to encrypt and decrypt a signature passed from a private key to a public key. It is also known as DSS, which is stands for the USA's federal Digital Signature Standard. For other key types, see RSA.

DSSSee DSA.

encryption key A key that is used by an encryption algorithm to encrypt a message or data.

keyA key is a number (large) or set of numbers that possess mathematical properties that support both

■ encryption with a private key and decryption with a public key ■ encryption with a public key and decryption with a private key

key databaseAlso referred to as a key file and designated by the extension *.kdb, this file contains all the information necessary to verify a certificate. The file is encrypted with 3DES-CBC encryption and protected by a password. Its contents include

■ public keys for the software application and for the trusted roots■ private keys for the software application■ user certificates and trusted roots■ Certificate Revocation Lists (CRL)



Depending upon the various roles of a computer, more than one key database can exist on a single computer. The key database can contain any number of CAs, private and public keys, and user certificates.

key fileSee key database.

key pair A set of two cryptographic keys, one public and freely shared, one private and kept secret, used to encrypt and decrypt data. Synonym: public/private key pair.

KMSee Knowledge Module (KM).

Knowledge Module (KM)A set of files from which a PATROL Agent receives information about resources running on a monitored computer. A KM file can contain the actual instructions for monitoring objects or simply a list of KMs to load. KMs are loaded by a PATROL Agent and a PATROL Console.

KMs provide information for the way monitored computers are represented in the PATROL interface, for the discovery of application instances and the way they are represented, for parameters that are run under those applications, and for the options available on object pop-up menus. A PATROL Console in the developer mode can change KM knowledge for its current session, save knowledge for all of its future sessions, and commit KM changes to specified PATROL Agent computers.

labelThis is a descriptive, alphanumeric text string that is assigned to a key pair or password in the key database to help an administrator identify and manage the key and/or password. In the sslcmd utility, a label is also referred to as identity.

labeled passwordSometimes the need arises for some means of securely storing the passwords to other systems in the key database. The sslcmd utility provides a means to assign to a password or other string of bytes a descriptive text string to help identify and manage the password.

PATROL AgentThe core component of PATROL architecture. The agent is used to monitor and manage host computers and can communicate with the PATROL Console, a stand-alone event manager (PEM), PATROL Integration products, and SNMP consoles. From the command line, the PATROL Agent is configured by the pconfig utility; from a graphical user interface, it is configured by the xpconfig utility for Unix or the wpconfig utility for Windows.

PATROL Command Line Interface (CLI)An interface program that you can access from the command line of a monitored computer and through which you can run some PATROL products and utilities. With the CLI, you can monitor the state of PATROL Agents remotely, execute PSL functions, and query and control

Glossary 213


events. The CLI is used in place of the PATROL Console when memory and performance constraints exist.

PATROL ConsoleThe graphical user interface from which you launch commands and manage the environment monitored by PATROL. The PATROL Console displays all of the monitored computer instances and application instances as icons. It also interacts with the PATROL Agent and runs commands and tasks on each monitored computer. The dialog is event-driven so that messages reach the PATROL Console only when a specific event causes a state change on the monitored computer.

A PATROL Console with developer functionality can monitor and manage computer instances, application instances, and parameters; customize, create, and delete locally loaded Knowledge Modules and commit these changes to selected PATROL Agent computers; add, modify, or delete event classes and commands in the Standard Event Catalog; and define expert advice. A PATROL Console with operator functionality can monitor and manage computer instances, application instances, and parameters and can view expert advice but not customize or create KMs, commands, and parameters.

PATROL rolesIn PATROL 3.x and earlier, a set of permissions that grant or remove the ability of a PATROL Console or PATROL Agent to perform certain functions. PATROL roles are defined in the PATROL User Roles file, which is read when the console starts.

PATROL Script Language (PSL)A scripting language (similar to Java) that is used for generic system management and that is compiled and executed on a virtual machine running inside the PATROL Agent. PSL is used for writing application discovery procedures, parameters, recovery actions, commands, and tasks for monitored computers within the PATROL environment.

Pluggable Authentication Mode (PAM)PAM is a library for authentication-related services. This library enables a system administrator to add new authentication methods by installing new PAM modules and to modify authentication policies by editing configuration files.

PSLSee PATROL Script Language (PSL).

PolicySee security policy.

public key infrastructure (PKI) This infrastructure provides the means for performing public and private key cryptography. PKI-based security includes Secure Socket Layer (SSL), digital signing, and verification.



Public-Key Cryptography Standard (PKCS)A set of specifications produced by RSA Laboratories and developers worldwide for the purpose of standardizing public-key cryptography.

RSAA type of public-key algorithm used to encrypt and decrypt a signature passed from a private key to a public key. RSA is an acronym for Rivest, Shamir, and Adelman. For other key types, see DSA.

secure socket layer (SSL) protocol A standard protocol created by Netscape for secure message transmission in a network. It provides a cryptographic protocol for both mutual authentication and data protection of Internet communications.

security policyA centralized location in which configuration data regarding security is stored. A security policy enables a user to easily manage and apply common administrative rules of protection to its computer environment. Security policy information is stored as registry entries on computers running Microsoft Windows operating systems and *.plc files on computers running supported variations of Unix.

self-signed certificateA self-signed certificate is a certificate issued directly by the certificate authority (CA). It is also referred to as a trusted root authority certificate.

setup commandA command that is initiated by the PATROL Console and run by the PATROL Agent when the PATROL Console connects or reconnects to the agent. For example, a setup command can initialize an application log file to prepare it for monitoring. PATROL provides some setup commands for computer classes. Only a PATROL Console with developer functionality can add or change setup commands.

signing The actions that a certificate authority (CA) takes to create a valid digital certificate by first hashing the certificate contents and then signing the hash with the CA's private key. This process is also referred to as digital signing.

sslcmdThis is the key management utility used to create, set up, and manage key databases and certificates.

startup commandSee setup command.

trusted root certificate authority The final certificate authority whose digital signature and certificate completes the validation of a digital certificate.

Glossary 215


user credentialsThis is the user name and password used by an application to verify the identity of a user. Some PATROL applications store user credentials in a key database. User credentials can be added to, viewed, or deleted from a key database using the sslcmd key management utility. User credentials are also referred to as labeled password.

user profile The PATROL Web Central specific information that is associated with a particular user. It corresponds directly to the user and is defined by the user back-end. The groups to which certain users belong are properties of that user.

user profile template What you use to create your profile. It contains the default information in your user profile, but does not map to the user group.



Index

Aaccess control lists (ACLs) 17access file

ALLOW_ACL 165DENY_ACL 165

anonymous communications 30apidll.dll 168application policy 100

locations 107, 109attended

setting mode 134attended mode 19, 25attributes 103authenticated communications 31authentication 17, 19, 32

BBMC Software, contacting 2bmckeycli 68bmcryptpw 113, 138, 139

Ccertificate

revoking 94certificate authority (CA) 31certificate authority (CA) certificate 83certificate revocation list (CRL) 95certificate revocation list warning 95certificate signing request (CSR) 83certificates 84, 92

deleting 88viewing field information 87

changinglabel of key pair 74password for key database 71

communications privacy 17compatibility

versions 49config.default 161configuration 21configuration files 156

PATROL 106connection type 56

creatingkey database 70

customer support 3

Ddefault certificates 34, 65default keys 34, 65default modes (attended, unattended) 28default password 65deleting private and public key pair 75, 93Diffie-Hellman key exchange 18, 31digital signing 17directory structure 56distinguished name (DN) 90dlls.conf 168DSA 72

Eerror messages 179, 180, 181, 183esi_lib32 159esi_lib64 159esstool 111Extended Security Interface (ESI) 157, 159

Ffiles

configuration 106install location 56

Ggenerating public and private Keys 72

Iidentity 32impersonation 18installation

Index 217


directories 56files 56migration 48over-the-top 48

installing a certificate in the SSL key database 92installing new certificate revocation lists 95issues and workarounds 179

KKerberos

supported by AIX 123key database 21, 31, 32, 70, 73, 85, 93

changing password for 71creating 70shipped with PATROL 69

key databasesmanagement of 69

key material file 21key pair 32, 72

changing label 74keys

management of 69

Llabel

changing of for key pair 74level of security

selecting 54listing

private-public keys 73listing signed certificates 93

Mmanaging

keys 69managing key databases 69message privacy 32mode

setting 134modes (attended, unattended) 25

Nnaming conventions 32network protocol

selecting 56

Ooverhead 22


overview of security 16overwriting

warning against 51

PPAM support 121password 25

changing for key database 71password privacy and configuration 17password prompt 184PATROL Event Manager (PEM) applications 170PATROL Knowledge Modules (KMs) 34patrol.conf 157, 159plc_password 112, 114, 135Pluggable Authentication Module

AIX 123Pluggable Authentication Module support 121policy

application 100site 100

policy attributes 103policy implementation

windows 109private-public keys

listing 73product support 3public and private key pair 72public and private keys 32, 72

Rregistry entries 184registry key 110revoking

user certificates 94root authority certificate

installing 85verifying 86

RSA 72

SSecure Socket Layer (SSL) protocol 19, 32security

selecting level of 54security contents

overwriting 51security levels 18

costs and benefits 22level 1 18

security overview 16security policies 106selecting

level of security 54


network protocol 56server.kdb 32setting

attended mode 134mode 134unattended mode 134

setting mode 134signFile 141site policy 100

locations 107sslcmd 67, 70, 71, 72, 73, 74, 75, 76, 78, 80, 81, 82, 84, 85, 86,

87, 88, 89, 92, 93, 95, 115, 117, 126, 130, 131, 145, 148support, customer 3

Ttechnical support 3transaction 30trusted root authority 19, 32trusted third party 31

Uunattended 134unattended mode 19, 25usability 21, 22user certificate

revoking 94user rights and privileges 17utility

bmckeycli 68

VverifyFile 143version

compatibility 49

WWindows registry 109

Index 219



Third-Party Product TermsThe following terms apply to third-party products that are included with or in a BMC Software product as described in the BMC Software, Inc., License

Agreement that is applicable to the product.

Frank Cusack LicenseCopyright (c) Frank Cusack, 1999-2000. [email protected] All rights reserved

1. Redistributions of source code must retain the above copyright notice, and the entire permission notice in its entirety, including the disclaimer of warranties.

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. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED `ÀS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIEDWARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BELIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITEDTO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSEDAND 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.

OpenSSL LicenseThis product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/).

Copyright (c) 1998-2003 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.


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 [email protected].

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 `ÀS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOTLIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENTSHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, ORCONSEQUENTIAL 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, STRICTLIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IFADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

====================================================================

This product includes cryptographic software written by Eric Young ([email protected]). This product includes software written by Tim Hudson([email protected]).

Original SSLeay LicenseCopyright (C) 1995-1998 Eric Young ([email protected]) All rights reserved.

This package is an SSL implementation written by Eric Young ([email protected]).

The implementation was written so as to conform with Netscapes SSL.

This library is free for commercial and non-commercial use as long as the following conditions are aheared to. The following conditions apply to all codefound 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 coveredby the same copyright terms except that the holder is Tim Hudson ([email protected]).

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 shouldbe 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 (onlineor 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.


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 ([email protected])" The word 'cryptographic' can be left out if the rouines 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 ([email protected])"

THIS SOFTWARE IS PROVIDED BY ERIC YOUNG `ÀS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THEIMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THEAUTHOR 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 BUSINESSINTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDINGNEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCHDAMAGE.

*53017**53017**53017**53017*

*53017*

Documents

Patrol Security User Guide