BMCBladeLogicAdministration

www.bmc.com

BMC BladeLogic Server Automation Administration Guide

Supporting

BMC BladeLogic Server Automation version 8.1

February 2011

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 2002-2011 BladeLogic, Inc.

BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their respective owners.

BladeLogic and the BladeLogic logo are the exclusive properties of BladeLogic, Inc. The BladeLogic trademark is registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other BladeLogic trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their respective owners.

AIX and IBM, are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Linux is the registered trademark of Linus Torvalds.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

UNIX is the registered trademark of The Open Group in the US and other countries.

The information included in this documentation is the proprietary and confidential information of BMC Software, Inc., its affiliates, or licensors. Your use of this information is subject to the terms and conditions of the applicable End User License agreement for the product and to the proprietary and restricted rights notices included in the product documentation.

Restricted rights legendU.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

Customer support

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

Support website

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

■ read overviews about support services and programs that BMC offers■ find the most current information about BMC products■ search a database for issues similar to yours and possible solutions■ order or download product documentation■ download products and maintenance■ report an issue or ask a question■ subscribe to receive proactive e-mail alerts when new product notices are released■ find worldwide BMC 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]. (In the subject line, enter SupID:<yourSupportContractID>, such as SupID:12345). Outside the United States and Canada, contact your local support center for assistance.

Before contacting BMC

Have the following information available so that Customer Support can begin working on your issue 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 issue

■ 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

3

http://www.bmc.com/support

mailto:[email protected]

License key and password information

If you have questions about your license key or password, use one of the following methods to get assistance:

■ Send an e-mail message to [email protected].

■ Use the Customer Support website at http://www.bmc.com/support.

4 BMC BladeLogic Server Automation Administration Guide

mailto:[email protected]

http://www.bmc.com/support

ContentsChapter 1 Introduction 11

Intended Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Network Shell Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Chapter 2 Overview of BMC BladeLogic Server Automation 13

System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Client tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Middle tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Server tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Default permissions and security configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Perl support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Tools for managing BMC BladeLogic data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Troubleshooting tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Generating data for support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Monitoring and diagnosing issues in the BMC BladeLogic environment . . . . . . 21

Chapter 3 Configuring the Application Server 29

Understanding the application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Application server processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Work item threads and the job execution thread . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Job distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Pooled database connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Authentication framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33The Application Server Launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Using the Post-Install Configuration wizard to configure the default application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Changing the configuration of an application server . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Using the application server configuration wizard to change configuration

settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Starting Application Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Starting all Application Servers on the host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Restarting Application Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Restarting all Application Servers on the host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Stopping Application Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Stopping all Application Servers on the host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Contents 5

Using the Application Server Administration console (blasadmin) to configure Application Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Starting the Application Server Administration console . . . . . . . . . . . . . . . . . . . . . 45The set Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47The show Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48The help Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Specifying multiple values for a parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Changing the default separator for multiple values. . . . . . . . . . . . . . . . . . . . . . . . . 50Deleting a configuration setting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Managing Application Server behavior with the Application Server Administration console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Configuring the Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Changing the heap size for BMC BladeLogic components . . . . . . . . . . . . . . . . . . . 71Enabling/disabling SOCKS proxy rule evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . 73Configuring the file server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Configuring a mail server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Configuring Perl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Configuring an SNMP server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Configuring a database server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Configuring the process spawner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Configuring expiration time for credentials of NSH Script Jobs . . . . . . . . . . . . . . 82Processing across mount points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Restricting the size of configuration and extended objects . . . . . . . . . . . . . . . . . . . 83Configuring user interface settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Setting SRP login requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Configuring the PXE Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89Configuring the Licensing Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Enabling asynchronous execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Enabling web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Configuring multiple Application Servers on the same host. . . . . . . . . . . . . . . . . . . . . 93About Application Server deployments and profiles. . . . . . . . . . . . . . . . . . . . . . . . 94Creating additional Application Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Viewing and editing an Application Server’s profile . . . . . . . . . . . . . . . . . . . . . . . 100Listing conflicting attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Getting information about Application Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106The Application Server Launchers node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Reporting Application Server information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Managing multiple Application Servers on the same host . . . . . . . . . . . . . . . . . . . . . 109Starting a specific Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Stopping a specific Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Redeploying a stopped Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Terminating a specific Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Restarting a specific Application Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Removing an Application Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Adding unmanaged deployments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Editing the list of roles with Application Server Launcher access . . . . . . . . . . . . 113

Resetting database passwords for the Application Server . . . . . . . . . . . . . . . . . . . . . . 114


Chapter 4 Administering security 115

Fundamentals of BMC BladeLogic security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Session layer security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Impersonation and privilege mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121SRP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122RSA SecurID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Active Directory/Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Domain Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Authentication profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Single sign-on session credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Keytab files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128RBAC role selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Security for different communication legs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130BMC BladeLogic Console to Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . 130BLCLI to Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Network Shell to Network Shell Proxy Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Reports client to reports server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Application Server to agent or repeater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Network Shell to agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Repeater to agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Implementing single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Configuring the Authentication Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Configuring the Application Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Configuring the Network Shell Proxy Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Setting override locations for client SSO files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Setting up certificate verification using OCSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Implementing LDAP authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Overview of LDAP configuration tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158High availability configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Certificate trust store. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Distinguished names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160Cross-registering users in the BMC BladeLogic database. . . . . . . . . . . . . . . . . . . 160Configuring LDAP authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Implementing RSA SecurID authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Configuring RSA Authentication Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Configuring SecurID authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Cross-registering users in the BMC BladeLogic database. . . . . . . . . . . . . . . . . . . 166

Implementing PKI authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Configuring PKI authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167Cross-registering users in the BMC BladeLogic database. . . . . . . . . . . . . . . . . . . 169

Implementing Domain Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Sample domain structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Configuring BMC BladeLogic for Domain Authentication . . . . . . . . . . . . . . . . . 171

Contents 7

Implementing Active Directory/Kerberos authentication. . . . . . . . . . . . . . . . . . . . . . 177Overview of AD/Kerberos configuration tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . 178Registering an Authentication Service in an Active Directory Domain . . . . . . . 180Configuring an Authentication Service for AD/Kerberos authentication . . . . . 184Configuring a BMC BladeLogic Client for AD/Kerberos authentication . . . . . . 194

Implementing security – Application Server to agents or repeaters. . . . . . . . . . . . . . 202TLS with client-side certs – Securing a Windows Application Server . . . . . . . . . 202TLS with client-side certs – Securing a UNIX-based Application Server . . . . . . 206TLS with client-side certs – Discontinuing use of client-side certificates . . . . . . 210

Implementing security – Network Shell to agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211No authentication – Using a default installation. . . . . . . . . . . . . . . . . . . . . . . . . . . 211TLS with client-side certs – Securing a Network Shell client . . . . . . . . . . . . . . . . 212

Implementing Security – Repeater to agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217Creating a self-signed client-side certificate on the repeater . . . . . . . . . . . . . . . . . 218Provisioning agents with an SHA1 fingerprint of the repeater’s self-signed

certificate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219Configuring agents to authenticate incoming requests with client-side certificates

221Discontinuing use of client-side certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

Using certificates to secure communication between clients and Application Servers . 223Generating a self-signed certificate for an Application Server . . . . . . . . . . . . . . . 223Securing communication with CA certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Using the blcred utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228Typical scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Generating a user information file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

Chapter 5 Setting up configuration files 233

Introduction to the configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233Configuration file functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235Subnet designations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

How BMC BladeLogic grants access to RSCD agents. . . . . . . . . . . . . . . . . . . . . . . . . . 237Exports file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240

Configuring the exports file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Options for exports file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241Restricting commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

Users and users.local files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247Configuring the users or users.local files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249Options for users and users.local files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Secure file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253Clients, servers, and the secure file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254Communication protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Configuring the secure file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255Options for secure file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Securecert file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262


Configuring the securecert file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263BMC BladeLogic log file reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

About logging configuration for BMC BladeLogic . . . . . . . . . . . . . . . . . . . . . . . . 264Overview of BMC BladeLogic log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264Application Server logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Agent logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271PXE Server logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271Additional log files of interest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271Collecting log data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271About the Log4crc.txt file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Chapter 6 Managing BMC BladeLogic data 287

Cleaning up the BMC BladeLogic database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288About the clean-up utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288Marking data for deletion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289Executing the database clean-up utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

Cleaning the Application Server cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293Cleaning up target servers (Agents) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293Cleaning up repeater servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294Cleaning up the file server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295Cleaning up historical data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296Scheduling the cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Scheduling the retention policy utility to mark data for deletion . . . . . . . . . . . . 297Scheduling the database cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298Scheduling the file server cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299Scheduling the Application Server cache cleanup . . . . . . . . . . . . . . . . . . . . . . . . . 299Scheduling the repeater server cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300Scheduling the target server (Agent) cleanup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

Chapter 7 Configuring Advanced File Servers and Advanced Repeaters 303

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303Key terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304What is the BMC BladeLogic Advanced Repeater? . . . . . . . . . . . . . . . . . . . . . . . . 305Best practice information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

Installing the BMC BladeLogic Server Automation Advanced Repeater . . . . . . . . . 307Installing using the installation program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307Performing an unattended (silent) installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

Configuring Advanced File Servers and Advanced Repeater servers. . . . . . . . . . . . 312Before you begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312Configuring Advanced File Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312Configuring Advanced Repeater servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316Changing the administrator user and password for Advanced Repeater Servers .

318Securing communication between Advanced File Servers and Advanced Repeater

servers (optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319Set up the Advanced File Server for secure communication . . . . . . . . . . . . . . . . 319Generate the SSL certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320Enable SSL on Advanced File Servers and Advanced Repeaters. . . . . . . . . . . . . 321

Contents 9

Configure the Advanced Repeater server for secure communication . . . . . . . . . 322Configure the Advanced File Server to use secure communication. . . . . . . . . . . 323Disabling SSL communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

Troubleshooting advanced file servers and advanced repeaters . . . . . . . . . . . . . . . . 324Configuring bandwidth throttling between Advanced File Servers and Advanced

Repeater servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324Location of log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325Location of configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326Starting and stopping the Advanced Repeater . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

Chapter 8 Integrating BMC BladeLogic and Change Management 329

Levels of integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329The BMC Continuous Compliance for Servers solution . . . . . . . . . . . . . . . . . . . . 330Requirements for integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

Enabling BMC Remedy ITSM integration for job approval . . . . . . . . . . . . . . . . . . . . . 333Configuring job approval for job types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333Assigning job approval permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334Setting up the connection to BMC Atrium Orchestrator . . . . . . . . . . . . . . . . . . . . 335Enabling HTTPS support for the BMC Atrium Orchestrator connection . . . . . . 336

Security Glossary 339

Index 345


C h a p t e r 1
1 Introduction
The BMC BladeLogic Server Automation Administration Guide describes all of the configuration and administration tasks you can perform to ensure the smooth functioning of BMC BladeLogic Server Automation (referred to in this guide as “BMC BladeLogic”). This document describes how to set up and maintain an Application Server, how to implement security restrictions, and how to define user permissions using the BMC BladeLogic configuration files.

Intended AudienceThis document is intended for system administrators who manage data centers and networks of remote servers.

TerminologyThroughout this document you will see discussions related to client and server machines. In the BMC BladeLogic context, a server is a machine where an RSCD agent is installed. Clients are machines running the BMC BladeLogic Console or Network Shell. Clients establish contact with servers by means of the RSCD agents installed on server machines. The configuration of the RSCD agent on those servers determines whether the client can establish a connection with the server and what permissions the client will have. If a connection is established, the configuration you define for both the client and the server determines how the client and server communicate with each other.

Chapter 1 Introduction 11

Documentation Conventions

In some contexts, a machine may be a BMC BladeLogic server, and in other contexts the same machine can be a client. This can happen because you can install client applications on the same hosts where you have installed an RSCD agent. Despite that possibility for confusion, this document always uses the term client to refer to a machine where someone is using the BMC BladeLogic Console or Network Shell to contact another machine. This document always calls the machine being contacted a server.

Documentation ConventionsIn this document, monospace, serif fonts depict text that a user might enter at the command line or text that a system generates in response to user input. Monospace fonts also depict file system paths. The following is an example of system text:

ERROR: You must be "root" for pkgadd to execute properly.

Bold fonts identify Network Shell commands and utilities, as well as the exports, users, users.local, and secure configuration files.

Within a procedure, bold text highlights actions that you should take. For example, a procedural step might read, “From the File menu, select Add.”

When describing paths, this guide uses UNIX-style path separators (forward slashes) except in situations where a Windows-style path separators (backslashes) are specifically required.

Network Shell DocumentationBMC BladeLogic provides descriptions of all Network Shell commands and utilities as man pages available on both Windows and UNIX-style systems. To display a man page while using Network Shell, enter man <command>, such as man nsh. In addition, the BMC BladeLogic Server Automation Network Shell Command Reference provides a full description of all Network Shell commands and utilities.


C h a p t e r 2
2 Overview of BMC BladeLogic Server Automation
This chapter provides an overview the system architecture for BMC BladeLogic Server Automation (BMC BladeLogic), as well as a discussion of other topics that apply to the BMC BladeLogic system as a whole.

System architectureA BMC BladeLogic system has a three-tier architecture that consists of client, server, and middle tiers. The following graphic illustrates the relationship between the major components of the three-tiered BMC BladeLogic system.


Client tier

Client tier

The BMC BladeLogic client tier includes the BMC BladeLogic console, a command line interface (BLCLI) that provides API-level access to the functionality available through the console, and Network Shell for ad hoc administration of one or more servers. It also includes a web interface to the BMC BladeLogic Decision Support for Server Automation server.

File Server

Agent

Network Shell Proxy Server

Application Server(s)

Client Tier

Middle Tier

Server Tier

PXE / TFTPServer

Remote Server

Remote Server

reports server

reporting data warehouse

BMC BladeLogic core database

Server

Agent

Server

Agent

Server

Agent

Server

Agent

Server

Agent

(optional)

Network Shell

reports client

(web browser)

BMC BladeLogic Console BLCLI


Middle tier

The BMC BladeLogic console is a graphical user interface that gives system administrators a host of sophisticated tools for managing and automating data center procedures. It also lets system administrators provision operating systems onto servers. Network Shell is a network scripting language that enables cross-platform access through a command line interface. All BMC BladeLogic client-tier applications let you manage Solaris®, Linux® (Red Hat and SUSE), AIX®, HP-UX, and Microsoft Windows 2000/2003/2008 servers.

Middle tier

The primary component of the middle tier is the Application Server, which controls how the BMC BladeLogic console communicates with remote servers. Not only does the Application Server manage communication between consoles and remote servers, it also controls interaction with the database and file servers. The Application Server is completely scalable, allowing administrators to adjust its performance to accommodate added users and increased database activity. If necessary, a BMC BladeLogic system can incorporate multiple Application Servers that cooperate by balancing job processing workloads.

The middle tier also includes several components used for provisioning servers, with the principal components being the PXE Server and the Application Server. The PXE Server delivers instructions to servers being provisioned so they can download a bootstrap program. The Application Server provides servers being provisioned with the instructions necessary to provision the machine.

If a site is running BMC Service Automation Reporting and Analytics, the middle tier includes an Apache Tomcat server. BMC Service Automation Reporting and Analytics uses the Application Server to authenticate users, and it reads data from the core BMC BladeLogic database as well as a reporting data warehouse. The reporting data warehouse is populated using information from the core BMC BladeLogic database.

Network Shell can optionally incorporate a middle tier component—an Application Server that is configured to run a Network Shell Proxy Server. Operating as an intermediary between Network Shell clients and the managed servers those clients target, the Network Shell Proxy Server authenticates Network Shell client users and ensures traffic is encrypted between clients and managed servers.

Server tier

The BMC BladeLogic server tier consists of RSCD agents on remote servers. The Application Server communicates with RSCD agents and initiates all communication to perform ad hoc and scheduled tasks. RSCD agents never initiate communication with an Application Server or any other BMC BladeLogic component.


Default permissions and security configuration

Default permissions and security configuration

In BMC BladeLogic, access control can be managed at multiple levels. Using the BMC BladeLogic Console, you can control user access through a combination of role-based and system object-based authorizations.

A role is a set of authorizations and other information that reflects the capabilities of an organizational entity, such as QA engineers or web administrators. When a user is assigned to a role, he or she is granted the authorizations defined for that role.

A system object is an object you can interact with in the BMC BladeLogic Console. The definition of a system object includes a set of authorizations specifying roles who can access the object and the actions those roles can perform.

For more information on managing access at the console level, see the BMC BladeLogic Server Automation User Guide.

BMC BladeLogic also lets you control access to servers at the agent level. Configuration files on the RSCD agent let you define who can access servers and how users communicate with those servers.

For many BMC BladeLogic installations, you do not have to modify the agent configuration files. The system’s default configuration provides sufficient functionality and appropriate user permissions. If your installation requires additional refinement, you should understand the default configuration of BMC BladeLogic.

When you install BMC BladeLogic on clients and servers, the following permissions and security configurations are set by default for each RSCD agent:

■ All clients are granted read/write access to all servers.

■ All clients and servers are set to communicate using protocol 5, a BMC BladeLogic protocol for secure communication based on Transport Layer Security (TLS), the successor to Secure Socket Layer (SSL). With protocol 5, TLS automatically negotiates the strongest form of encryption that clients and servers can support.


Perl support

■ Users are granted permissions on managed servers through two different processes:

— For Windows servers, users can be granted permissions through a process called Windows user mapping. This process allows a role to be mapped to a local or domain user who has permissions for a Windows server. For more information on Windows user mapping, see the BMC BladeLogic Server Automation User Guide.

— In all other situations, users can be granted permissions through a process of user impersonation (for all UNIX servers) or user privilege mapping (for Windows). For either of these approaches, when a user attempts to connect to an agent, the agent maps the user to an identity using the following steps:

■ First the agent determines whether the user has an equivalent identity on the server machine. If so, the connecting user is granted the permissions of that equivalent user. However, root users on UNIX are not automatically mapped to root, and members of the Administrator group in Windows are not automatically mapped to Administrator.

■ If a user does not have an equivalent local identity on the server, the agent maps the incoming user to a default user with downgraded permissions. On UNIX, users are mapped to user “nobody.” On Windows, users are mapped to user “Anonymous.” Incoming users can be granted the permissions of a specified user, but that requires modification of the configuration files.

For a complete discussion of how users are granted permissions on servers, see Chapter 5, “Setting up configuration files.”

By default when you add users to the BMC BladeLogic system, they are set up for SRP authentication when using BMC BladeLogic clients to communicate with Application Servers. Other forms of authentication are possible, but they require additional configuration. For more information on securing communication between all components of a BMC BladeLogic system, see Chapter 4, “Administering security.”

Perl supportBMC BladeLogic provides built-in support for Perl, the script programming language. The BMC BladeLogic Perl module integrates with libnc, the core library for BMC BladeLogic, which functions like a network-enabled version of libc. Because of this integration, you can use Perl scripts to perform functions on remote hosts (such as open, read, and write files) as long as those hosts are running RSCD agents.


Tools for managing BMC BladeLogic data

When you install Network Shell on a platform that can support a BMC BladeLogic Application Server, the Perl module is automatically installed. See the BMC BladeLogic Server Automation Installation Guide for a list of the platforms for which BMC BladeLogic provides Perl support. If you are using Perl in conjunction with the BMC BladeLogic Console, you must configure the Application Server so it knows the location of Perl, as described in “Configuring Perl” on page 77.

Tools for managing BMC BladeLogic dataBMC BladeLogic provides a suite of tools for managing data in the BMC BladeLogic system and controlling its growth where necessary. These tools let you delete unused data or data no longer needed for BMC BladeLogic operations.

These tools include:

■ A database clean-up utility (cleanupDatabase) to minimize the amount of space taken up by unused data in the BMC BladeLogic database. This utility deletes from the database objects users have deleted in the BMC BladeLogic Console, objects marked for deletion with the retention policy utility, and historical data such as old audit trail entries, audit results, snapshot results and compliance results.

■ A target server clean-up utility. You can use this utility to delete old files that accumulate on target servers (agents) from Deploy Jobs.

■ A repeater server clean-up utility. Data from Deploy Jobs can also accumulate in the staging directory on repeater servers. You can delete these files by using the repeater server clean-up utility.

■ An Application Server cache clean-up utility. You can use this utility to delete old temporary files in the Application Server cache (directory).

■ The BMC BladeLogic file server clean-up utility. You can use this utility to delete unused files from the file server.

For more information on these tools, see Chapter 6, “Managing BMC BladeLogic data.”


Troubleshooting tools

Troubleshooting toolsBMC BladeLogic provides several tools that you can use to collect data for diagnosing issues and working with Customer Support:

■ Generate Support Data — Generates data about Application Servers and other components of the BMC BladeLogic environment and packages that data into a zip file.

■ Application Server Diagnostics — Runs predefined tests that evaluate the status of the BMC BladeLogic environment while it is running and identifies problems.

■ Database Diagnostics — Run predefined tests from the command line that evaluate the status of the BMC BladeLogic database and identifies potential issues.

■ DEBUG_MODE_ENABLED job property - provides additional diagnostic information to the job log.

Generating data for support

The Generate Support Data tool generates data about the Application Servers and other components in the BMC BladeLogic environment and packages that data into a zip file. This data can be useful for diagnostic purposes when you contact Customer Support.

1 In the BMC BladeLogic Console, select Configuration => Generate Support Data.

2 In the Generate Support Data dialog, select the Application Servers from which you want to collect data. Accept the default selection (the Application Server to which you are connected) or click the Browse button (three dots) and select one or more Application Servers from the Select Application Servers dialog. (The Select Application Servers dialog lists only Application Servers configured to use the same database and file server and that are currently accessible.) To select multiple Application Servers, use Shift + Click or Ctrl + Click.

3 Select the data you want to include in the zip file. Click Select All or click the data types you want.

NOTE To use the Support Data Generation tool, your role must be granted the BL_Administration.Read authorization.


Generating data for support

This selection: Includes:

Application Server log The currently active Application Server log.

You can also include Application Server logs that have been rolled over.

A “rolled-over” log file is one that is generated after a preset size has been reached for the currently active log file. For example, suppose you set the size to 20 MB for the appserver.log file. When the log file reaches that size, a new log file is automatically created (appserver.log.1).

Console log The current console log, if any.

You can also include console logs that have been rolled over.

Application Server Deployment files

The entire deployment directory for the specified Application Servers.

Application Server status

A file containing all status information for the Application Server. (This information is the same as that generated by the Export Detail Report operation in the Infrastructure Management window.) The file’s name is StatusReport.txt.

System Properties table

A file containing the current contents of the SYSTEM_PROPERTY table in the database to which the Application Server is connected. The file’s name is System Properties.txt.

Agent log The log from one or more Agents.

Click Agent Log and use the Browse button (three dots) to select a server, group of servers, or a Smart Group of servers.

You can also include Agent logs that have been rolled over.

Agent Security Files The current security files from one or more Agents.

Click Agent Security Files and use the Browse button (three dots) to select a server, group of servers, or a Smart Group of servers.

Security files included are:

■ Secure■ Exports■ Users■ User.local■ home

Application Server Security Files

Security files from the Application Server. At a minimum, the Secure file is included. If an Agent resides on the Application Server, all security files are included.

Deploy Job Target Logs (Failed Targets Only)

All transaction logs for target servers that failed to execute the specified Deploy Job run.

Click Deploy Job Logs and use the Browse button (three dots) to select one or more jobs.


Monitoring and diagnosing issues in the BMC BladeLogic environment

4 Click Generate Data.

5 Specify a path to the location where you want to store the zip file.

6 In the Object Name field, type a name for the zip file.

7 Click Save.

For each Application Server you selected, BMC BladeLogic generates the data and creates a zip file.

If you selected multiple Application Servers, the zip file for each has a name based on the file name you specified plus the Application Server name. For example, suppose you selected configserver1 and appserver1 and specified data_10_08.zip as the file name. The zip files created would have the names: data_10_08-configserver1.zip and data_10_08-appserver1.zip.


Application Server Diagnostics

The Application Server Diagnostics tool provides tests that can be helpful for monitoring the status of your BMC BladeLogic environment and for working with Customer Support to identify and resolve issues. These predefined tests collect data on the status of the BMC BladeLogic environment while it is running, compare the data to expected behavior, and analyze it to determine test success or failure.

PXE Server Files Information about the PXE server and the services it runs. (This information is the same as that reported in the Infrastructure Management window.)

Network Information A file of information about network configuration and status for each Application Server. The file’s name is NetworkInformationReport.txt.

NOTE To use the Support Data Generation tool, your role must be granted the BL_Administration.Read authorization.

This selection: Includes:



1 In the BMC BladeLogic Console, select Configuration => Application Server Diagnostics View.

2 In the Application Server Diagnostics view, select the Application Servers from which you want to collect data. Accept the default selection (the Application Server to which you are connected) or click Browse and select one or more Application Servers. The Select Application Servers dialog lists Application Servers configured to use the same database and file server; however, they do not need to be running on the same host.

3 The Application Server Diagnostics area lists the tests to be run.

Accept the tests listed in the Application Server Diagnostics area or refine the list in one of the following ways:

■ Select one or more tests from the Application Server Diagnostics area. (Use Shift + click or Ctrl + click to select multiple tests.)

■ Select a group of tests from the Diagnostic Group drop-down menu.Tests are grouped by the type of evaluation they do. For example, selecting the Configuration test group runs both the AppServer Test and the Service Deployment Test, both of which test the Application Server configuration.

Selecting a test group lists those tests in the Application Server Diagnostics area. You can select one or more tests from the list.

Test Description

AppServer Test Tests the Application Server’s configuration connectivity with other Application Servers.

BlExec Job Diagnostic Test Tests the job execution framework, including parallel execution, using a job created for test purposes.

Database Diagnostic Test Tests the Application Server’s connectivity with the database and executes test queries.

Environment KeyStore Test Checks whether the bladelogic.keystore files are properly synchronized between the various deployments (each deployment has its own keystore file).

File Manager Diagnostic Test Tests the Application Server’s connectivity with the File Server.

Pseudo Job Diagnostic Test Tests the job framework, using a job created for test purposes.

Service Deployment Diagnostic Test Tests the Application Server’s deployment to determine if the Application Server has been properly configured



4 Click Run All Tests to run all tests listed in the Application Server Diagnostics area. Or click Run Selected Tests to run only the tests you selected in that area.

5 In the Application Server Diagnostics area, the Status column shows an icon that indicates the success or failure of each test. Select a test and click the View Results icon to show detailed test results.

6 On the Diagnostic Results dialog, select the Application Server for which you want to display test results. Then click the Test Output, Log, or Failure Advice tab.

7 When you are finished viewing test results, click Close.

Database Diagnostics

The Database Diagnostics tool provides tests that can be helpful for monitoring the status of the database and for working with Customer Support to identify and resolve issues. These predefined tests collect data on the configuration of the BMC BladeLogic database and provide feedback.

To run the Database Diagnostics tool

1 On the BMC BladeLogic Application Server, open a shell (in Linux) or a command prompt (in Microsoft Windows).

2 From the ...NSH/bin folder, execute either dbdiagnostic.exe or dbdiagnostic.sh with any of the parameters shown in Table 1.

For the diagId argument used by some of the parameters, run dbdiagnostics list to determine the ID for each specific diagnostic test.

NOTE The warning messages displayed for any of the DB diagnostics are in most cases an indication that the system needs to be tuned with the recommended values suggested for optimum performance of the product, which are listed in the BMC BladeLogic Server Automation Installation Guide.

Consult with your DBA to see whether these recommendations can be applied.

Table 1 Parameters for the DBdiagnostic command (part 1 of 2)

Parameter Description

help Displays the help for the command.

list Lists only the ID, name, and description for all diagnostics.

listFull Lists all diagnostics with full details (for example, the parameters and their children).



IDs for the diagnostics

Each diagnostic test has an associated ID. Note that these IDs are not fixed and can be different in different environments.

Table 2 on page 25 shows example IDs for each of the diagnostic tests available with the dbdiagnostics tool. To run a diagnostic test, first obtain the list of IDs by running dbdiagnostics list and then use the ID of the particular diagnostic that you want to run as input to the utility.

getDiag diagId=diagId

Displays information for a specific diagnostic, such as statistics on the last execution of the diagnostic, the status of the run, and the parameters used for that run.

getDiagParams diagId=diagId

Displays the parameters for a diagnostic.

getResAfterDate diagId=diagId afterDate=MM-dd-yy[yy]

(you can enter a two or four digit year)

Displays all of the results for diagnostics recorded on or after the specified date starting at 00:00:00 AM.

getResLastExec diagId=diagId

Displays the results for the last execution for a specific diagnostic.

delRes diagId=diagId

Delete the results for a specific diagnostic.

delAllRes Deletes all results for all diagnostics.

runDiag diagId=<diagId> optName1=val1 optName2=val2

Runs a specific diagnostic using optional parameters.

You can find the list of parameters for a diagnostic by running the diagnostic with the getDiagParams parameter followed by the diagId.

NOTE The Top_N_tables_chk and JRE_Row_Count_Chk diagnostic tests apply to both Oracle and SQL Server databases. The remaining tests apply to Oracle databases only.

Table 1 Parameters for the DBdiagnostic command (part 2 of 2)




Example syntax and output

The following example shows the command format you would use to run the ORACLE CHECK BLOCK SIZE diagnostic, while Figure 1 shows the output returned from the command.

Figure 1 output from the command

You can then view the results of the diagnostic by running the command with the getResLastExec parameter, which displays the results of the last execution for this diagnostic (shown in Figure 2).

Table 2 Diagnostic names and description

ID Diagnostic name and description

1000000 ORACLE CHECK BLOCK SIZE

Checks the Oracle block size and provides advice.

1000001 ORACLE CHECK NUMBER PROCESSES ALLOWED

Checks the number of Oracle processes and provides advice.

1000003 ORACLE OPTIMIZER SETTINGS CHK

Checks the Oracle optimizer settings.

1000004 TOP_N_TABLES_CHK

Checks the data volumes/sizes of the top N tables.

1000005 JRE_ROW_COUNT_CHK

Checks the job_run table and returns the record with the largest number of events.

1000006 DBMS_STATS_CHK

Checks to see if the Schema statistics are current (based on a user-supplied expiration), and recommends remediation if the statistics are not current.

For a description of how to use this diagnostic to verify that Schema statistics are current, see the “Before you install” chapter of the BMC BladeLogic Server Automation Installation Guide

dbdiagnostics runDiag diagId=1000000



Running a job in debug mode

If you are experiencing issues with job execution, you can use the DEBUG_MODE_ENABLED job property to provide additional diagnostic information to the job log.

The additional level of logging provides you or BMC Software Customer Support representatives with more detailed information when diagnosing issues with job execution.

To set the DEBUG_MODE_ENABLED job property

1 In the Jobs folder, select a job.

2 Do one of the following:

— Right-click the job and select Set Property. The Set Job Properties window is displayed. Select DEBUG_MODE_ENABLED from the Name drop-down list.

— In the Properties tab, select DEBUG_MODE_ENABLED from the Extended properties list.

3 Set the property value to TRUE.

The default value for the DEBUG_MODE_ENABLED property is FALSE.

4 Click OK.

dbdiagnostics getResLastExec diagId=1000000

Figure 2 Sample output for ORACLE CHECK BLOCK SIZE diagnostic

diagId=1000000execDiagId=2000002execStartTime=2010-03-22 12:47:02.0messageLevel=INFOmessage=ORACLE CHECK BLOCK SIZE: Block size on the Database is 8192, which is large enough.messageTime=2010-03-22 12:47:03.0

NOTE Be sure to set the DEBUG_MODE_ENABLED property back to FALSE when not diagnosing an issue, as running the job in debug mode does have a negative impact on performance.



To view the job log

1 Open the Jobs folder, navigate to a job or Execution Task, right-click the job or Execution Task and select Show Results to display its job runs.

2 Select a run of a job, right-click, and select Show Log. A window displays log messages generated by the job.

3 To filter messages so the job log only shows servers with specific job results, use the Run Details drop-down to select Errors, Warnings, Success, or All.

4 To display messages in a dialog that allows you to scroll through messages one by one, double-click on a message. The Log Item Details dialog opens. Click the Up arrow or the Down arrow to scroll through messages one by one. Click Close to close the dialog.

5 Click Close to close the log messages window.

You can also review the log file on the Application Server for the additional diagnostic information. By default, the Application Server log file is located in:

UNIX

Windows

If you are running a multiple Application Server environment, see “Considerations for troubleshooting jobs in a MAS environment” on page 57.

/opt/bmc/BladeLogic/8.0.00/NSH/br/appserver.log

installationDirectory\BladeLogic\8.0.00\NSH\br/appserver.log




C h a p t e r 3
3 Configuring the Application Server
The core of the three-tier architecture in BMC BladeLogic is the Application Server. Controlling communication between clients and servers as well as access to database, file, and mail servers, the Application Server can be adjusted to scale a system and to fine tune its performance.

There are two general configurations for Application Servers in the BMC BladeLogic environment:

■ Single (Default) Application Server on the Host

This configuration is the most common one and can be performed as a last step in the installation of an Application Server. During installation, you use the Post-Install Configuration wizard to perform the initial configuration of the Application Server. With this basic configuration, you can start the Application Server and then fine-tune it as needed. See “Using the Post-Install Configuration wizard to configure the default application server” on page 34.

■ Multiple Application Servers on the Same Host

This configuration lets you add multiple Application Servers to the host and configure them to perform one or more functions. See “Configuring multiple Application Servers on the same host” on page 93.

Use the following tools to make configuration changes:

■ To make changes to basic configuration settings at a later time, you can run the Application Server Configuration wizard. For information, see “Using the application server configuration wizard to change configuration settings” on page 39.

NOTE The Application Server and the RCP client (BMC BladeLogic console) must be located on the same Local Area Network (LAN). Remote users can use the console through either RDP or Citrix from a remote machine to the machine where the console resides.


Understanding the application server

■ BMC BladeLogic provides a utility called the Application Server Administration console, which is a command line utility that allows you to set all parameters used by the Application Server. The Application Server Administration console lets you set the same parameters as those available in the Post-Install Configuration wizard, and you can also use it to set other more complex configuration options. For information, see “Using the Application Server Administration console (blasadmin) to configure Application Servers” on page 44.

■ To manage multiple Application Servers on the host or change their configurations, use the Infrastructure Management window. For information, see “Managing multiple Application Servers on the same host” on page 109.

Understanding the application server

Application server processes

The BMC BladeLogic Application Server is designed to process connections from many clients simultaneously. Rather than dedicating a thread to each client connection, the Application Server maintains a pool of threads that can be used for processing client activity. BMC BladeLogic calls these worker threads. When a client requests any type of activity, the Application Server picks a worker thread from the pool to execute that task. When the request is complete, the worker thread is returned to the pool. Using this approach, the Application Server can handle many more client connections than it has worker threads. (The number of worker threads in the pool is configurable. So is the number of open client connections. See “Scaling the Application Server” on page 52 for more on configuration.)

Typically, the BMC BladeLogic Application Server runs as two distinct processes. One process runs the core functionality of the Application Server. The other process is a process spawner, which launches new processes external to the Application Server process. Spawning processes externally to the Application Server can be beneficial for memory management. Process spawning is primarily used for Network Shell Script Jobs and some types of extended objects. If you prefer, you can configure the Application Server so the process spawner does not run as an external process. See “Configuring the process spawner” on page 79 for more on configuration.


Work item threads and the job execution thread

Work item threads and the job execution thread

A single Application Server processes BMC BladeLogic jobs using one job execution thread and a configurable number of work item threads. The job execution thread constantly watches for scheduled jobs. (Note that a job set to run immediately is considered a scheduled job.) When a job comes due, the job execution thread loads the job and allocates work item threads, which perform all work required for that job. After initiating a job in this way, the job execution thread continues to watch for other scheduled jobs. (For a description of how multiple Application Servers can process jobs cooperatively, see “Job distribution” on page 32.)

The number of work item threads needed for any job varies by job type. All jobs require one work item thread for pre-execution and another for post-execution. In addition, one work item thread is required to execute each part of the job. For most job types, the number of job parts equals the number of target servers, but there are exceptions to this rule. For a description of how jobs are divided into job parts, see the BMC BladeLogic Server Automation User Guide. Deploy Jobs can optionally utilize a special pool of lightweight work item threads used only for processing Deploy Job phases that access target servers.

When allocating work item threads, the Application Server assigns equal preference to all pending jobs. When an Application Server is running multiple jobs, a sufficient number of work item threads may not be available for simultaneously processing all jobs. In this case, when a work item thread becomes available, it is assigned to the first job in the queue of pending jobs. When the next work item thread becomes available, it is assigned to the second job in the queue. The next work item thread goes to the third job in the queue, and so forth, until a work item thread has been assigned to all jobs in the queue. Then the cycle of allocating work item threads begins again, starting with the first job in the queue. With this system, all jobs can begin processing as soon as a work item thread becomes available. However, jobs with fewer job parts may complete sooner than jobs with many job parts.

For more information on specifying the number of available work item threads, see “Scaling the Application Server” on page 52.


Job distribution

Job distribution

If you have multiple Application Servers installed and they all access the same database, those Application Servers can cooperate by distributing jobs to balance their processing workloads. Using additional Application Servers increases the job execution capacity of the system and in most cases speeds overall job processing.

By default, Application Servers are configured to cooperate when executing jobs. This work item sharing capability is controlled by the MultiAppServerEnabled attribute (which is set to true, by default) in the Application Server’s profile. If this attribute is set to False, work items are not shared to or from that Application Server. Best Practice: Do not mix-and-match the value of the MultiAppServerEnabled attribute between Application Servers; all Application Servers should have this attribute set to True, or all Application Servers should have the attribute set to False.

When multiple Application Servers are configured to execute jobs, scheduled jobs are delegated to the first Application Server that requests a job, provided that the Application Server making the request is not already executing the maximum number of jobs that it can run simultaneously. (That maximum number can be configured.) For example, if a BMC BladeLogic installation consists of two Application Servers that are both configured to run the same maximum number of jobs, each Application Server will be given the same number of jobs to run (assuming there are an even number of jobs to execute).

Generally, the number of work items processed during a job run directly corresponds to the number of target servers for the job. During job execution, Application Servers make an effort to distribute work items to each other to increase the number of concurrently executing work items and shorten overall execution time. Typically, local work item threads on an Application Server will process all work items for a job before those work items can be distributed to other Application Servers. However, if all local work item threads are already processing work items, the Application Server will distribute work items to other Application Servers that have idle work item threads. Although work for an individual job can be spread among multiple Application Servers, only one Application Server manages each individual job.

For more information on configuring cooperation between Application Servers, see “Setting up job distribution between multiple Application Servers” on page 55.

NOTE You cannot enable or disable work item sharing at the job type level.


Pooled database connections

Pooled database connections

The BMC BladeLogic Application Server maintains two different pools of database connections—one is used for processing jobs running the BMC BladeLogic Console and the other is used for processing all other activity, such as client connections.

When a worker thread or a work item thread needs a database connection, it acquires one from the appropriate pool of database connections. When the database activity is complete, the database connection is returned to its pool. A thread watches the pool of database connections, ensuring that the number of connections stays within high and low boundaries. If the number of database connections reaches the high boundary, the thread attempts to trim the number of database connections back to the low boundary. You can configure the high and low boundaries to accommodate user needs. For more information, see “Setting the number of database connections” on page 64.

Authentication framework

A BMC BladeLogic Application Server employs a unified framework for processing all user authentication requests. That framework is based on three services:

■ Authentication Service—An entity dedicated to authenticating users by means of all supported authentication protocols.

■ Application Service—An entity that encapsulates the functionality of a BMC BladeLogic Application Server.

■ Network Shell Proxy Service—An entity that encapsulates the functionality of a Network Shell Proxy Server.

The Authentication Service and the Application Service are always located on the same host. A Network Shell Proxy Service can be located on the same host, or it can be set up on a stand-alone machine even though it is still associated with an Application Server.

When users on a BMC BladeLogic client application (except BMC BladeLogic Decision Support for Server Automation) want to authenticate, the client contacts the Authentication Service using any supported authentication protocol. Based on the authentication protocol, the Authentication Service uses the appropriate mechanism to authenticate that user. If authentication succeeds, the Authentication Service issues a session credential to the client application. The client application can then initiate a session by presenting the session credential to an Application Service or Network Shell Proxy Service.


The Application Server Launcher

For more information on authentication and other security features, including a description of how BMC BladeLogic Decision Support for Server Automation authenticates users, see Chapter 4, “Administering security.”

The Application Server Launcher

An Application Server Launcher is a mechanism for configuring and controlling multiple Application Servers on the same host. It is so called because it launches (starts) and controls these additional Application Servers.

The BMC BladeLogic environment supports one Application Server Launcher per host. Installing the Application Server on a host also installs the Application Server Launcher. Starting, stopping, and restarting the Application Server on the host also starts, stops, and restarts the Application Server Launcher.

The Application Server Launcher lets you configure and manage (start, stop, restart, terminate, remove and redeploy) each additional Application Server on the host. The Application Server Launcher must be running on the host in order for you to perform these operations. See “Configuring multiple Application Servers on the same host” on page 93.

Using the Post-Install Configuration wizard to configure the default application server

The BMC BladeLogic Post-Install Configuration wizard consolidates the minimum configuration steps that must be performed to set up an Application Server. Although the BMC BladeLogic Application Server Administration console provides command-line mechanisms for configuring all possible Application Server options, only a few must be set to make a BMC BladeLogic system functional. The Post-Install Configuration wizard presents those essential tasks in a graphical user interface and provides explanatory information for each step in the process.

Available for both Windows and UNIX-style installations, the configuration wizard allows you to set the following configuration options:

■ Database connection parameters—The BMC BladeLogic Console works in conjunction with an Oracle or SQL Server database server in its middle tier. Use the configuration wizard to configure your database connection.



■ File server—The BMC BladeLogic Console uses a file server to store large snapshots of files, Network Shell scripts, BLPackages, Windows installables, and other types of information that is not easily stored in a database. Use the configuration wizard to identify the file server and a directory within the file server.

■ Notification servers—The BMC BladeLogic Console optionally generates email and SNMP traps that send notifications when a job completes. Use the configuration wizard to identify an SMTP server, the address from which the notification emails originate, and the SNMP destination to which all SNMP traps are sent.

■ Super-user passwords—The BMC BladeLogic Console provides several predefined users. The RBACAdmin user has full permission to manage roles and users in the RBAC Manager workspace in the BMC BladeLogic Console, where you can assign permissions for all users. The BLAdmin user has Read access for all system objects within the BMC BladeLogic Console. Use the configuration wizard to provide SRP passwords for the RBACAdmin and BLAdmin users.

1 To start the Post-Install Configuration wizard, do one of the following:

■ Perform an installation that includes installation of the Application Server. The installation program gives you the option of launching the wizard at the end of the installation procedure.

■ From the Windows Start menu, select Programs => BMC Software => BladeLogic Server Automation Suite => Utilities => Application Server Configuration Wizard.

■ Start the wizard manually by running one of the following commands in the directory where BMC BladeLogic is installed.

— On a Windows system, enter the following:

NOTE Be aware of the following:

■ If your database is not set up or you do not currently have the information needed to establish a connection to that database, you cannot configure the Application Server. Click Cancel to close the wizard. Obtain the necessary connection information and run the Post-Install Configuration wizard again to complete your system configuration.

■ If you are running the Post-Install Configuration wizard on UNIX, the OS-specific x11 libraries must be installed.



— On a UNIX-style system, enter the following:

The configuration wizard opens.

2 Read the introductory page and click Next. The Database page displays.

3 Choose a Database Type—either Oracle or SQL Server.

4 If you are not using a custom connection string, provide the following database configuration information (and do not select the Advanced option):

Database Server—Server running the database.

Database Port—Port the database listens on. By default a BMC BladeLogic installation uses the following database ports:

Database Name—SQL Server database name. By default the database name is bladelogic. (This option is only available for SQL Server databases.)

SID—System ID of the Oracle database. (This option is only available for Oracle databases.)

User ID—User name that the database needs to authenticate your connection.

Password—Password assigned to the user ID.

or...

If you are using a custom connection string, provide the following database configuration information:

\bin\ blappconf.exe

./br/blappconf

NOTE If you invoke the wizard without passing the -install flag, the wizard will display configuration settings that have already been entered for the Application Server and allow you to change those settings.

Database Type Port Number

Oracle 1521

SQL Server 1433



User ID—User name that the database needs to authenticate your connection.

Password—Password assigned to the user ID.

Advanced—Select this option to indicate that you are providing a custom connection string.

Connection String—Type the custom connection string in the field below the Advanced checkbox.

5 Click Next. The File Server page displays.

6 Provide the following file server configuration information:

File Server Name—Name of the server where data is stored. By default, the file server is created on the same machine as the Application Server.

File Server Storage Location—Directory on the file server where data is stored. By default, the directory of the file server is appserverInstallDirectory/storage.

A file server should meet the following requirements:

■ An RSCD agent must be installed and licensed.

■ A file server must have, as a minimum, 72 GB of available, non-redundant, disk space. BMC BladeLogic recommends that the file server have 200 GB or more of available RAID 5 disk space.

■ A user name must be defined on the file server, and all users must be mapped to that user. Without this mapping a user may not be able to access a file that another user has stored on the file server. One way to accomplish the necessary mapping is to create an entry like the following in the exports file on the file server:

appServer rw,user=userName

where appServer is a comma-separated list of Application Server names or IP addresses and userName is the name to which all users are mapped.

■ The internal System:System role/user must be mapped to the user name defined on the file server. To accomplish the mapping, create an entry like the following in the users.local file on the file server:

NOTE Do not limit access to the file server by pushing agent ACLs to the agent on the file server. All users need to be mapped to the same user on the file server.



System:System rw,user=userName

where userName is the name to which all users are mapped, typically bladmin or administrator.

If the required directory structure does not already exist on the file server, the process will attempt to create it.

7 Click Next. The Notification Servers page displays.

8 Provide information identifying an email server by entering the following under SMTP Options:

SMTP Server—Name or IP address of the host managing email. (SMTP stands for simple mail transfer protocol.)

Email From—Email address from which BMC BladeLogic-generated email is sent. BMC BladeLogic jobs can generate email upon their completion.

9 If you are using SNMP trap notifications, provide information identifying the SNMP server by entering the following under SNMP Options:

SNMP Server—Name or IP address of the host to which SNMP traps should be sent.

SNMP Port—The port on the SNMP server that listens for SNMP traps. By default the port is set to the standard SNMP port of 162.

10 Click Next. The User Passwords page displays.

11 Under both RBACAdmin User and BLAdmin User, enter a password and then retype the password to confirm your entry. You will not be able to enter a password if a password has already been set.

Passwords are used to authenticate the RBACAdmin and BLAdmin users via the SRP authentication protocol.

The RBACAdmin user has full permission to manage roles and users in the RBAC Manager workspace in the BMC BladeLogic Console, where you can assign permissions for all BMC BladeLogic users. The BLAdmin user has Read access for all system objects within BMC BladeLogic. For more information on the RBACAdmin and BLAdmin users, see the BMC BladeLogic Server Automation User Guide.

12 Click Finish.


Changing the configuration of an application server

Changing the configuration of an application server

There are three tools you can use to change an Application Server’s configuration. Which tool you use depends on the settings you want to change.

Using the application server configuration wizard to change configuration settings

To change configuration settings on an Application Server, you can use the Application Server Configuration wizard (blappconf). This wizard presents the same information as the Post-Installation Configuration wizard, except that it is in a tabbed format and shows current settings in the text boxes.

NOTE BMC BladeLogic recommends that you synchronize the clock on the Application Server and all client machines. Clocks should be synchronized to the minute. For example, if an Application Server is in Boston, where the time is 7:04, the clock on client machines in San Francisco should be set to 4:04.

To change... You can use...

Initial (post-installation) configuration settings for the Application Server:

■ Database connection■ File server■ Notification servers

The Application Server Configuration wizard.

For information, see “Using the application server configuration wizard to change configuration settings” on page 39.

You can also use the Application Server Administration console (blasadmin) to change these settings.

Most configuration settings or to set additional configuration parameters on an Application Server

The Application Server Administration console (blasadmin).

See “Using the Application Server Administration console (blasadmin) to configure Application Servers” on page 44.

Attributes (configuration settings) specified in an Application Server’s profile (when there are multiple Application Servers on the same host)

The Infrastructure Management window. See “Viewing and editing an Application Server’s profile” on page 100.


Using the application server configuration wizard to change configuration settings

You can change the following settings:

■ Database connection parameters

■ File server name and storage location

■ Notification servers — SMTP server and email address from which notification emails originate and SNMP server and port to which SNMP traps are sent

1 Start the Application Server Configuration wizard:

■ To change the configuration of the default Application Server, use one of the following methods:

— From the Windows Start menu, select Programs => BMC Software => BladeLogic Server Automation Suite => Utilities => Application Server Configuration Wizard.

— From the directory where BMC BladeLogic is installed, enter the following:

\bin\blappconf

— On a UNIX-style system, from the directory where BMC BladeLogic is installed, enter the following:

./br/blappconf.exe

■ To change the configuration of a specific Application Server when there are multiple Application Servers on the same host, enter the following:

\bin\blappconf -s applicationServerName

Where applicationServerName is the name of the Application Server you want to change.

For example:

blappconf -s JobServer1

NOTE After super-user passwords are set in the Post-Installation Configuration wizard, you cannot use the Application Server Configuration wizard to change them. You must use the RBAC Administration tool.


Starting Application Servers

2 The Application Server Configuration wizard appears. Make changes you want.

3 Click OK.

4 Restart the Application Server.

Starting Application ServersThere are two methods for starting Application Servers. The method you use depends on the Application Servers you want to start:

■ To start all Application Servers on the host, whether a single (default) Application Server or multiple Application Servers, see “Starting all Application Servers on the host”.

■ To start a specific Application Server (when additional Application Servers are configured on the host), use the Infrastructure Management window. See “Starting a specific Application Server” on page 109.

Starting all Application Servers on the host

This operation starts all Application Servers on the host, whether a single (default) Application Server or multiple Application Servers.

To start all Application Servers on the host, do one of the following:

■ On Windows, from the Start menu, select Settings => Control Panel. Double-click Administrative Tools, and double-click Services. Right-click BladeLogic Application Server and select Start from the pop-up menu.

■ On a UNIX-style system, from the directory where BMC BladeLogic is installed, enter the following:

/etc/init.d/blappserv start

NOTE If you specify blappconf -s, changes affect the specified deployment.If you specify blappconf with no -s option, changes affect only the default deployment. Application Servers created on the host in the future will not have the changes. To have changes affect future Application Servers, use this command to configure the template deployment: blappconf -s _template


Restarting Application Servers

Restarting Application ServersThere are two methods for restarting Application Servers. The method you use depends on the Application Servers you want to restart:

■ To restart all Application Servers on the host, whether a single (default) Application Server or multiple Application Servers, see “Restarting all Application Servers on the host”.

■ To restart a specific Application Server (when additional Application Servers are configured on the host), use the Infrastructure Management window. See “Restarting a specific Application Server” on page 111. To use this restart operation, the default Application Server must already be started.

Restarting all Application Servers on the host

This operation restarts all Application Servers on the host, whether a single (default) Application Server or multiple Application Servers.

Do one of the following:

■ On Windows, from the Start menu, select Settings= > Control Panel. Double-click Administrative Tools, and double-click Services. Right-click BladeLogic Application Server and select Restart from the pop-up menu.

■ On a UNIX-style system, enter the following:

/etc/init.d/blappserv restart

Stopping Application ServersThere are two methods for stopping Application Servers. The method you use depends on the Application Servers you want to stop:

■ To stop all Application Servers on the host, whether a single (default) Application Server or multiple Application Servers, see “Stopping all Application Servers on the host” on page 43.

■ To stop a specific Application Server (when additional Application Servers are configured on the host), use the Infrastructure Management window. See “Stopping a specific Application Server” on page 109. To use this stop method, the default Application Server must already be started.


Stopping all Application Servers on the host

Stopping all Application Servers on the host

Performing this procedure immediately stops all Application Servers on the host, even though they may be currently processing jobs.

The BLCLI provides commands that allow you to shut down Application Servers more gracefully (see “Shutting down Application Servers gracefully”).

To stop all Application Servers on the host, do one of the following:

■ From the Windows command line window where the Application Server is running, enter Control-C.

■ From the Windows Start menu, select Settings => Control Panel. Double-click Administrative Tools, and double-click Services. Right-click BladeLogic Application Server and select Stop from the pop-up menu.


/etc/init.d/blappserv stop

Shutting down Application Servers gracefully

The BLCLI provides commands that allow you to shut down an Application Server after all jobs running on it have completed or after a specified period of time has elapsed. You can also use related commands to pause an Application Server while it processes all active jobs or resume service after you have paused the Application Server. You can use these commands to shut down, pause, or resume a specific Application Server or all Application Servers on the host.

These commands are available in the AppServerShutdown name space of the BLCLI. See the BLCLI Help for specific information on AppServerShutdown.

What happens when you pause, resume, or shut down an Application Server

When you pause an Application Server, the following occurs:

■ The job execution thread on the Application Server no longer processes newly scheduled jobs.

NOTE You can also use the Infrastructure Management window to gracefully shut down a specific Application Server (when multiple Application Servers are configured on the host). See “Stopping a specific Application Server” on page 109.


Using the Application Server Administration console (blasadmin) to configure Application Servers

■ The Application Server is temporarily set so other Application Servers cannot distribute jobs to it.

■ To expedite the processing of any currently active jobs, the Application Server continues to give out work item threads to other Application Servers, if requested.

■ The Application Server is temporarily set so it can no longer request work item threads from other Application Servers.

When you instruct a paused Application Server to resume work, you essentially undo the actions listed above. The job execution thread can again process scheduled jobs and the Application Server can request work item threads from other Application Servers.

When you use AppServerShutdown commands to shut down an Application Server, the Application Server’s job framework is paused, as described above. When all jobs and work items have completed or a specified period of time has elapsed, the shutdown sequence begins.

Using the Application Server Administration console (blasadmin) to configure Application Servers

The BMC BladeLogic Application Server Administration console (blasadmin) is a command line utility that lets you set parameters needed for an Application Server. These parameters define the location and behavior of the application, database, file, mail, and SNMP servers, the Authentication Service, and other components of an Application Server.

The blasadmin utility lets you configure all parameters, versus the subset you can configure with the Post-Install Configuration Wizard. This section provides procedures to control all aspects of the Application Server’s behavior.

NOTE When you pause an Application Server, it continues to process all of its current work items. If any of those work items take a long time to finish, the Application Server will not appear to be paused until all of those work items are complete.


Starting the Application Server Administration console

To configure Application Servers with the Application Server Administration Console (blasadmin):

1 Start the Application Server Administration Console. How you start this utility determines the Application Server configuration affected by the commands. See “Starting the Application Server Administration console”.

2 At the prompt, enter the commands. For information, see:

■ The set Command■ The show Command■ The help Command

3 Exit the blasadmin utility.

4 Restart the Application Server to have your configuration settings take effect.


To start the Application Server Administration console, run the blasadmin command. How you enter the command depends whether you want to configure the default Application Server or one of multiple Application Servers on the host.

Starting blasadmin to Configure the Default Application Server

To start the Application Server Administration console when there is a single Application Server on the host, do one of the following:

■ On Windows, do one of the following:

— From the Start menu, select Programs => BMC Software => BladeLogic Server Automation Suite => Utilities => Application Server Administration.


\bin\blasadmin.exe

TIP If you want to enter just one or two commands, you can both run the blasadmin utility and pass it a command at the same time. For example, you can change the location of a file server (on the default Application Server) by entering the following commandblasadmin set fileserver location /tmp/Storage.



Both options run the same command.


./br/blasadmin

This command starts the blasadmin utility and you can use blasadmin set and show commands.

Starting blasadmin when there are multiple Application Servers on the same host

If there are multiple Application Servers on the same host, you need to specify whether you want to use blasadmin to configure one specific Application Server or all Application Servers on the host. Do one of the following:

■ To start blasadmin and configure one specific Application Server, use:

blasadmin -s appServerName

Where:

-s appServerName is the Application Server’s name.

For example:

blasadmin -s OtherJobServer

This command starts the blasadmin utility and you can enter blasadmin commands. All commands you enter during the session (until you enter exit at the blasadmin prompt) affect only the Application Server you specified.

■ To start blasadmin and configure all Application Servers on the host, use:

blasadmin -a

NOTE All commands you enter during the session affect only the default Application Server. Application Servers created on the host in the future do not have the changes. To have changes affect future Application Servers, use this command to start blasadmin and configure the _template deployment: blasadmin -s _template

For information on the default and _template deployments, see “Editing the list of roles with Application Server Launcher access” on page 113


The set Command

This command starts the blasadmin utility and you can enter set and show commands. All commands you enter during the session affect:

— All additional Application Servers configured on the same host— The _template deployment— The default Application Server

For information on deployments, see “Editing the list of roles with Application Server Launcher access” on page 113.

The set Command

The set command sets the parameter to the specified value in the configuration. The setting takes effect when you restart the Application Server.The format for the set command is:

set component parameter value

Where:

■ component is the Application Server functionality you can configure■ parameter is an option that controls the Application Server behavior■ value is the value for the parameter

For example:

blasadmin> set fileserver name redhat1

This example sets the file server’s name to redhat1.

NOTE When configuring settings on the Application Server, you must restart the Application Server for a setting to take effect.

TIP When there is no ambiguity about the command you are typing, you can enter a shortened version of a command. For example, you can type set f n instead of typing set fileserver name.


The show Command

The show Command

The show command shows components, parameters, and current settings for an Application Server. The format is:

show [component] [component parameter] [all]

To Show At the bladmin> prompt, enter

Descriptions of all parameters for all components

show descriptions

For example:

bladmin> show descriptions[AccountConfig]AccountLockoutDuration - How long (in minutes) to keep the account lockedAccountLockoutThreshold - How many failed logins before the account is lockedMaxPasswordAge - How many days before a password needs to be changedMinPasswordLength - Minimum length of password required[AgentConfig]EnableAgentRpc - Enable or disable agent RPC communication [true, false]SecureFilePath - Path to the rsc “‘secure’ file.[AppServer]AppServerName - name of application serverAppSvcPort - listening port for Application service...

All components and parameters, plus settings for parameters that have them

show all

For example:

bladmin> show all[AccountConfig]AccountLockoutDuration:0AccountockoutThreshold:0MaxPasswordAge:0MinPasswordLength:0[AgentConfig]EnableAgentRpc:falseSecureFilePath:...


The show Command

A component’s parameters (with descriptions)

show component

For example:

bladmin> show fileserveravailable options: [all|location|name]all - display all configuration parameters for this optionlocation - the NSH style </c/temp> locationname - the name of the fileserver

A component’s parameters and settings

show component all

For example:

bladmin> show snmpconfig all[SnmpConfig]SnmpPort:162SnmpServer:

The current setting for a single parameter

show component parameter

For example:

bladmin> show database MaxGeneralConnectionsMaxGeneralConnections:100

To Show At the bladmin> prompt, enter


The help Command

The help Command

The help command provides help on the set and show commands.

Specifying multiple values for a parameter

Some Application Server parameters accept more than one value. To specify multiple values for a parameter, use a comma-separated list. For example:

blAdmin> set ManagementService EmailRecipients [email protected],[email protected]

Changing the default separator for multiple values

In the blasadmin utility, the comma is the default separator for specifying multiple parameter values. If the values you want to specify include commas, you can change the separator to a different character. To change the default separator, enter the blasadmin command with the -c option.

To get help on At the bladmin> prompt, enter

A list of components (with descriptions) you can specify with the command

help set | show

For example:

bladmin> help setAccountConfig - minimum password length configurationAuthServer - authorization configurationConfigManagerUI - configuration for UIDatabase - the database configuration parameters...

All of the parameters for a component

help set | show component

For example:

bladmin> help set Database

A description of a parameter

help set | show component parameter

For example:

bladmin> help show pxeserver listen_portthe server port the PXE server listens on


Deleting a configuration setting

blasadmin -c value_separator_character

For example, to change the value separator to a semicolon, you would enter:

blasadmin -c ;

The setting is in effect only for the blasadmin session (until you exit the blasadmin utility).

Deleting a configuration setting

You can delete a parameter value from an Application Server’s configuration. To delete the value, use the blasadmin set command and specify an empty value surrounded by quotation marks (““). For example:

blasadmin -s OtherConfigServer set AuthServer AppServiceURLs ““

This example removes the AppServiceURLs value for Application Server named OtherConfigServer.


Managing Application Server behavior with the Application Server Administration console

Managing Application Server behavior with the Application Server Administration console

Using the Application Server Administration console, (the blasadmin utility) you can perform a variety of tasks to manage all aspects of Application Server behavior. The following list describes the procedures you can perform to manage the Application Server. Many of these procedure include subordinate procedures.

■ Configuring the Application Server■ Configuring the file server■ Configuring a mail server■ Configuring Perl■ Configuring an SNMP server■ Configuring a database server■ Configuring the process spawner■ Processing across mount points■ Restricting the size of configuration and extended objects■ Configuring user interface settings■ Setting SRP login requirements■ Configuring the PXE Server■ Configuring the Licensing Module■ Enabling asynchronous execution■ Enabling web services

Configuring the Application Server

The Application Server is the core of the middle tier in a BMC BladeLogic installation. Not only does the Application Server control communication between clients and servers, it also regulates activity between the client and the database, file, and mail servers. The Application Server provides many adjustable parameters that allow you to scale a BMC BladeLogic system to virtually any size.

Scaling the Application Server

The Application Server provides several options that you can adjust to accommodate increased activity.

An Application Server should be configured so that even when all of its work item threads are busy, the Application Server still has additional resource capacity.



1 Start the Application Server Administration console, as described in “Starting the Application Server Administration console” on page 45.

2 To specify the maximum number of worker threads, enter the following:

set appserver maxworkerthreads #

where # is the maximum number of threads that can process requests from clients. For example, you might set this to 10, which means that only 10 client connections can be serviced at a time even though many more users might actually be connected to the Application Server. Worker threads should not be confused with work item threads, which process BMC BladeLogic Console jobs (see step 5).

3 To specify the maximum number of client connections that the Application Server can manage, enter the following:

set appserver MaxClientContexts #

where # is the maximum number of connections to clients.

4 To specify the maximum number of jobs, enter the following:

set appserver MaxJobs #

where # is the maximum number of jobs. By controlling the number of jobs that are processed simultaneously, you can avoid overtaxing Application Server resources.

5 To specify a maximum size for the pool of threads that can be used to process BMC BladeLogic Console jobs, enter the following:

set appserver MaxWorkItemThreads #

where # is a number of work item threads.

All BMC BladeLogic jobs let you specify how many targets to process in parallel. You can set a value from 1 to 10 or allow an unlimited number of targets to be processed in parallel.

The MaxWorkItemThreads and MaxLightweightWorkItemThreads (see step 6) also can control how many targets can be processed in parallel. If your system uses one Application Server, the maximum number of targets that can be processed is based on the Application Server’s available work item threads. If your system uses multiple Application Servers, the maximum number of targets that can be processed in parallel is based on the sum of all available work item threads on all Application Servers.



When processing Deploy Jobs, work item threads often sit idle while target servers process deployment tasks. To avoid this kind of inefficiency, the Application Server can use a pool of lightweight work item threads to process phases of a Deploy Job that access target servers.

For more on the role of work item threads, see “Work item threads and the job execution thread” on page 31.

6 To specify a maximum size for the pool of lightweight work item threads that can be used for Deploy Jobs, enter the following:

set appserver MaxLightweightWorkItemThreads #

where # is a number of lightweight work item threads. By default this value is set to 0.

An Application Server can optionally provide a secondary pool of lightweight work item threads. These threads are only used during the Simulate and Commit phases of a Deploy Job. Lightweight work item threads primarily perform tasks on target servers and consequently consume almost no memory on an Application Server. Using lightweight work item threads helps you run more Deploy Jobs in parallel more efficiently. Other than being limited to particular types of tasks, lightweight work item threads behave exactly like work item threads.




Setting up job distribution between multiple Application Servers

When Application Servers are configured to access the same database, they automatically attempt to cooperate by balancing their job processing workloads. They accomplish this by distributing the processing of entire jobs or work items for large individual jobs to other Application Servers.

For Application Servers to cooperate, they must know which Application Servers are in service. To accomplish this, each Application Server periodically updates its time stamp, which functions as its heartbeat. Application Servers that are cooperating monitor each other’s heartbeat to determine which Application Servers are in service.


2 To specify a time span that indicates a remote Application Server has timed out, enter the following:

set appserver RemoteServerTimeout #

where # is number of seconds between heartbeats before a remote Application Server is considered out of service. For example, if RemoteServerTimeout is set to 5, and 10 seconds elapse between heartbeats, the Application Server is considered out of service.

3 To specify an interval between heartbeats for an Application Server, enter the following:

set appserver ServerMonitorInterval #

where # is the frequency with which an Application Server updates its own time stamp (that is, its heartbeat). When an Application Server updates its heartbeat, it also checks for the heartbeat of any remote Application Servers.

NOTE For Application Servers to cooperate, the following prerequisites must be met:

■ Each Application Server must be configured to access the same database and have the same bladelogic.keystore file. For information on synchronizing bladelogic.keystore files, see “Synchronizing keystore files of multiple Application Servers” on page 58.

■ System clocks on all Application Servers must be synchronized to within a few seconds of each other.



4 To specify a time-out for connecting to a remote Application Server, enter the following:

set appserver SocketConnectTimeout #

where # is the maximum number of seconds for obtaining an initial socket connection to a remote Application Server. Once that maximum is exceeded, the connection times out.

5 To specify a time-out for responses from a remote Application Server, enter the following:

set appserver SocketTimeout #

where # is the maximum number of seconds to wait for a response from an Application Server after the initial connection has already been established. Once the maximum is exceeded, the connection times out.

6 To specify that a socket connection use SSL, enter the following:

set appserver UseSSLSockets true

where true indicates that connections to this Application Server must be encrypted using SSL.

7 To specify that remote Application Servers contacting the Application Server must authenticate, enter the following:

set appserver RequireClientAuthentication true

where true instructs the Application Server to require authentication from remote Application Servers. Generally, connections encrypted with SSL also require client authentication.

8 To specify a port used for communication between Application Servers, enter the following:

set appserver RegistryPort #

where # is a port number. By default the RegistryPort is set to 9836.




Considerations for troubleshooting jobs in a MAS environment

Each Application Server has a log file which contains information about what is being executed on that Application Server. When Application Servers are configured to access the same database, they automatically attempt to cooperate by balancing their job processing workloads, which means that the log information is also distributed.

For example, you may have two physical Application Servers (appserver1 and appserver2), with one job server running on each, and the Distribution Manager is dynamically allocating resource and running jobs on both Application Servers as needed.

In this example, the logging information for the job is actually distributed between the log files on both appserver1 and appserver2. Therefore you would need to review the log files on both Application Servers.

By default, the Application Server log file is located in:

UNIX

Windows

There are also individual log files for each Application Server deployment, which by default are located in:

UNIX

Windows

/opt/bmc/BladeLogic/8.1/NSH/br/appserver.log

installationDirectory\BladeLogic\8.1\NSH\br/appserver.log

/opt/bmc/BladeLogic/8.1/NSH/br/deploymentProfileName.log

installationDirectory\BladeLogic\8.1\NSH\br/deploymentProfileName.log



Job distribution and job priority in a MAS environment

You can use the PRIORITY* property to mark a job, or a class of jobs, with a relatively higher priority to ensure they are executed first in case of resource contention. You can assign one of any of the following priorities: Critical, High, Normal, Low, and Lowest. By default, all job types have a priority of Normal. Note that these priority levels are meaningful only in relation to each other.

For a list of the permissions and authorizations required to modify Job Priority, see “Authorizations for changing job priority” and “Setting job priority” in the BMC BladeLogic Server Automation User Guide.

If you have implemented a multiple Application Server environment, note the following considerations regarding job priority:

■ While queuing work items across all jobs, the Distribution Manager queues work items in respect to priority. For example, if two concurrent jobs are competing for resources, the individual work items of the higher priority job are queued to be processed before the work items of the lower priority job.

■ There is no guarantee about the order of completion of each job (which is dependent on various extraneous factors including the actions performed in each job, its target vector, the responsiveness of the target space, and so on).

■ The parallelism configuration of a job can significantly impact the appearance of the effectiveness of the job’s priority level, as it controls the maximum number of simultaneous work items that can be allocated for a given job. For example, consider the case of a job with a priority of Critical, but with a low maximum parallelism level. Such a job would appear to relinquish resources to a lower priority job with a high parallelism level, once the initial work item assignment quota for that Critical priority job is reached.

For more information on setting the job priority level, see BMC BladeLogic Server Automation User Guide.

Synchronizing keystore files of multiple Application Servers

Multiple Application Servers on different hosts can be set up to cooperate on processing jobs. (For information, see “Setting up job distribution between multiple Application Servers” on page 55.) For this cooperation to take place, all Application Servers must have the same bladelogic.keystore file.

To synchronize keystore files of cooperating Application Servers, do the following on each cooperating Application Server:



1 Stop the cooperating Application Server.

2 Copy the bladelogic.keystore file from the _template directory of the central Application Server to each deployment directory of the cooperating Application Server. The file location is:

installationDirectory/br/deployments/_template/bladelogic.keystore

3 Make sure that the passwords match for bladelogic.keystore files of all deployments of the cooperating Application Server. If the new bladelogic.keystore file you copied into a deployment has a different password from that of the old bladelogic.keystore file, change the keystore password for that deployment. (If keystore passwords match, you can skip this step.)

To change the password needed for the bladelogic.keystore file for all Application Server deployments:

A On the cooperating Application Server, start the Application Server Administration console for the deployment. At the command prompt, enter:

blasadmin -s deployment_name

For example:

blasadmin -s default

or

blasadmin -s _template

B At the blasadmin prompt, enter:

set appserver CertPasswd password

C Repeat these steps for each deployment whose keystore file has changed, including the PXE server, if it is in use.

D Change the keystore password for the _launcher deployment. At the command prompt, enter:

blasadmin -s _launcher

E At the blasadmin prompt, enter:

set appserverlauncher KeyStorePassword password

F If the process spawner is in use, change the keystore password for the _spawner deployment. At the command prompt, enter:



blasadmin -s _spawner

G At the blasadmin prompt, enter:

set ProcessSpawner KeyStorePassword password

4 Restart the cooperating Application Servers.

Specifying a maximum time for canceling a job part

You can specify a maximum period of time that can elapse for a job part to be canceled. If cancellation of a job part exceeds this maximum, the job part is classified as stuck and the job part is aborted. This prevents situations where cancellation of a job is not performing as expected and the act of canceling the job can potentially hang the job.


2 To set a maximum period for job cancellation, enter the following:

set appserver MaxTimeForCancelToFinish #

where # is the maximum amount of time in minutes that should elapse for job cancellation.


Setting limits for client connections

The Application Server lets you specify certain limits for connections to the Application Server, such as a prune time for idle connections or the maximum amount of time a client can perform read operations from the Application Server. If the client exceeds these maximums, the connection is closed.


2 To specify an idle prune time, enter the following:

set appserver IdleConnectionPruneTime #

where # is a value in minutes. When there is no traffic over the connection between a client and the Application Server for this period of time, the connection is considered expired.



When a new incoming connection is made, idle connections with non-zero IdleConnectionPruneTime values are checked, and the connections that have expired are pruned.

By default this value is set to 0, which means the connection never expired.

3 To specify a time-out for client socket read operations from the Application Server, enter the following:

set appserver SocketTimeout #

where # is the maximum number of seconds for client socket reads before the socket times out.


Setting time-out behavior for work item threads

The Application Server lets you specify time-out behavior for work item threads. By default, if you assign job part time-outs, a work item thread is canceled when it exceeds the time period you have defined in the JOB_PART_TIMEOUT property. In addition, all other work item threads acting on the same server are also canceled. This prevents situations where multiple work item threads time out serially on the same unresponsive server. If necessary, you can use this procedure to override the default behavior so that only one work item thread times out automatically.


2 To set time-out behavior, enter the following:

set appserver PropagateWorkItemTimeout true|false

Setting this value to true means all work item threads acting on the same server are canceled when one work item thread times out. Setting it to false means only the one work item thread is canceled.


Enabling automatic restart of provisioning jobs after Application Server restart

A restart of an Application Server cancels provisioning jobs that have been submitted but are waiting idle (for example, a job waiting for the PXE client to boot). To ensure that these jobs are automatically restarted when the Application Server restarts, use this procedure.




2 Enable automatic restart of provisioning jobs by entering the following:

set appserver restartIdleProvisionJobs true


Setting the outcome of Update Server Properties Jobs when target agents are unresponsive

By default, an Update Server Properties Job always ends successfully, even if the RSCD agents on the remote target servers are unresponsive, as the AGENT_STATUS property for the target servers is updated in any case. You can, however, set the Update Server Properties Job to end in failed status whenever agents do not respond.


2 Set the outcome of Update Server Properties Jobs by entering the following:

set JobFactory UspJobSucceedsWhenAgentDown true|false

The default value is true. Setting the value to false means that the Update Server Properties Job will be reported (in the log and in the display of job results) as having ended in failed status if the agent on the remote target is unreachable or not licensed.

Setting a maximum number of Compliance Results displayed

The Application Server lets you specify the maximum number of compliance results that are displayed for any failed condition in a compliance rule. A Compliance Job examines a component and compares its parts to conditions defined in compliance rules for a component template. Parts that do not comply are shown in Compliance Job results. If you are running a Compliance Job that examines many server objects that fail a compliance condition, you may tax your system resources, particularly disk space.

If results for a Compliance Job exceed the limits you set in this procedure, the job run is marked with a warning and the job log includes a message saying that job results have been truncated.




2 To set a maximum for compliance results displayed, enter the following:

set appserver ComplianceResultMaxNumberOfAssets #

where # is a the maximum number of server objects displayed per failed condition in a compliance rule.


Setting behavior for past due jobs

The Application Server lets you specify a period of time that a newly created job can remain in a queue while the Application Server is down or too busy to process the job. The period of time is measured from the scheduled occurrence of the job to the time the Application Server starts. Setting a value for this option specifies that:

■ If you restart the Application Server and the specified period has not elapsed, the scheduled occurrence of a one-time-only job does not execute but the scheduled occurrence of a recurring job does execute.

■ If you restart the Application Server and the specified period has elapsed, the scheduled occurrence of a job does not execute.


2 To set past due job execution behavior, enter the following:

set scheduler MaxJobTimeInSchedulerQ #

where # is a value in minutes. By default this value is set to 60. Setting this value to 0 means that all past due jobs execute when the Application Server starts.


NOTE This procedure only defines behavior for new jobs. No matter how you define this value, all existing jobs remain in the job queue for the default amount of time—60 minutes.



Setting the number of database connections

Use this procedure to set maximums and minimums for database connections. You can set the maximum and minimum number of database connections that jobs use. You can also set the maximum and minimum number of database connections used for general, non-job-related purposes, such as client connections to the database. By providing separate settings for job-related and non-job-related activity, you can help to prevent situations where client connections seem to hang because large jobs are using all available database connections.


2 To set a maximum and minimum number of job-related database connections, use either of the following commands:

set database MaxJobExecutionConnections #

set database MinJobExecutionConnections #

where # is a number of database connections.

3 To set a maximum and minimum number of non-job-related database connections, use either of the following commands:

set database MaxGeneralConnections #

set database MinGeneralConnections #

where # is a number of database connections.


NOTE The sum of the maximum numbers you define for MaxJobExecutionConnections and MaxGeneralConnections cannot exceed the connection limit specified by the database server.

NOTE Because each work item in an Audit Job requires a dedicated database connection, increasing the value for MaxJobExecutionConnections can sometimes increase the performance of large Audit Jobs.



Setting communication ports

The following sections list the port requirements for both the Application Server and the Application Server Launcher.

Application Server ports

By convention the Application Server listens to the ports listed in the following table:

Traffic Type

Port Number(By Convention) Description

AuthSvcPort 9840 Listening port for the Authentication Service associated with an Application Server. If this value is set to 0, the Application Server does not run an Authentication Service. By default the Authentication Service runs and listens on port 9840.

This port is used for BMC BladeLogic Console to Application Server communication, and is used in conjunction with the JMX Management Port 9838 (by default) to authenticate the client AppSvcPort (port 9841 by default).

AppSvcPort 9841 Listening port for the Application Service (that is, the service that accepts client connections). If this value is set to 0, the Application Server does not run an Application Service. By default the Application Service runs and listens on port 9841.

ProxySvcPort 9842 The listening port for a Network Shell Proxy Service. You must manually define a listening port for the default deployment of an Application Server. Typically, ProxySvcPort is set to 9842 for the default Application Server.

When you deploy a new Application Server with its type set to NSH_PROXY or ALL, the ProxySvcPort is automatically set to the Base Port plus 42. You can modify this value if necessary.

If this value is blank, the Application Server does not run a Network Shell Proxy Service.

RegistryPort 9836 Listening port for traffic between Application Servers that cooperate by distributing jobs to each other.

This port is used in a multiple Application Server configuration for Application Server to Application Server communication. It is used in conjunction with the RMI Execution Port 9850+ (which is obtained from the MaxPort/MinPort range when the Application Server starts).

This communication is used for various administration tasks, such as to pull Application Server statistics, coordinate job work item execution, update the remote heartbeat status, and so on.




2 To specify a listening port, enter the following:

set appServerComponent listeningport #

where appServerComponent is the option category you want to modify, such as AuthServer, listeningport is the type of listening port, such as AuthSvcPort, and # is the number of the port.


Ports used in a multiple application server deployment by the Application Server Launcher

By default, the following ports are used by the Application Server Launcher for BMC BladeLogic Console to AppServerLauncher communication:

Setting up HTTP proxy server support

This procedure describes how to set up a user name and password for authentication on an HTTP proxy server. The patch management component of BMC BladeLogic incorporates the ability to download files from the Internet. Many organizations provide Internet access through a proxy server. If the HTTP proxy server authenticates users, it requires a user name and password, which the Application Server can provide if you perform the following procedure.

Traffic TypePort Number(By default) Description

JMX 9700 Default Java Management Extensions (JMX) port used by the BMC BladeLogic Console to communicate with the Application Server Launcher.

Incoming messages

9701 Default communications port used for Application Server communication with the Application Server Launcher.

Each managed Application Server uses this port to notify the Application Server Launcher that the Application Server is up and in a ready state. This communication is all local traffic for this port

RMI execution 9702 In a firewall environment, use this port is used for BMC BladeLogic Console /Application Server Launcher communication.




2 To identify a proxy server, enter the following:

set appserver HTTPProxyName serverName

where serverName is the name of the HTTP proxy server.

3 To specify a listening port for the HTTP proxy server, enter the following:

set appserver HTTPProxyPort #

where # is the port used to contact the proxy server.

4 To specify a user name provided to the HTTP proxy server, enter the following:

set appserver HTTPProxyUser userName

where userName is the name of a valid user on the proxy server.

5 To specify a password, enter the following:

set appserver HTTPProxyPassword password

where password is the password assigned to the proxy user you identified in the previous step.


Binding the Application Server to an IP address

Use this procedure to specify an IP address to which an Application Server should listen. You can also instruct the Application Server to listen for connections on all of its IP addresses.

This procedure is primarily useful when an Application Server has more than one network interface and you want the Application Server to listen for connections on only one.


2 To specify an IP address to which the Application Server should listen, enter the following:

set appserver SocketsBindAddress IP_address|all



In the command shown above IP_address is the IP address or host name to which the Application Server should listen.

If you do not specify an IP address or host name, the Application Server listens on all of its IP addresses. Similarly, if you enter all in the command shown above, the Application Server listens on all IP addresses. If you have previously instructed an Application Server to listen for a specific IP address, you must use all in this command to change those instructions so the Application Server listens on all IP addresses.


Configuring ports for remote execution objects

Use this procedure to configure ports used to access remote execution objects, such as the management object used by JConsole.


2 To specify a port used to access the Application Server’s remote execution objects, enter the following:

set appserver RMIExecutionPort #

where # is the number of the port.

3 To specify a port used to access JConsole, enter the following:

set appserver JMXManagementPort #

4 To specify a port used to access the process spawner’s remote execution objects, enter the following:

set ProcessSpawner RMIExecutionPort #

For more on the process spawner, see “Configuring the process spawner” on page 79.


Enabling and disabling Network Shell proxy inspection

To ensure data integrity, BMC BladeLogic inspects data packets traveling between Network Shell clients and proxy servers. When this inspection reveals a problem, the packet is not delivered. You can use this procedure to turn off packet inspection.




2 Enable or disable packet inspection by entering the following:

set appserver EnableProxyInspection true | false

where false turns off proxy inspection and true turns it on. By default proxy inspection is turned on.


Ensuring version compatibility between Application Server and client

To ensure that a connection does not take place when an Application Server and client are at different versions, you can set up a version compatibility check. This check compares the version numbers of the client and the Application Server, at a level of detail you specify. If the version numbers are not the same, the Application Server refuses the connection.


2 Enter the following command:

set appserver VersionCompatibilityCheck major|minor|micro|build

(In the version number 7.5.0.125, 7 is the major part, 5 is the minor part, and so on.)

major — Sets the check to compare only the major part of the version numbers.

minor — Sets the check to compare the major and minor parts of the version numbers. This is the default.

micro — Sets the check to compare the major, minor, and micro parts of the version numbers.

build — Sets the check to compare all four parts of the version numbers.

For example, suppose the Application Server version is 7.5.0.125 and the client version is 7.5.0.123. If you specify:

set appserver VersionCompatibilityCheck micro

The check would find that the version numbers are the same and allow the connection.



If you specify:

set appserver VersionCompatibilityCheck build

The check would find that the version numbers differ and would refuse the connection.


Setting a maximum cache size for file system objects

The Application Server lets you specify the maximum number of file system objects that are stored in the cache. You can use this setting to improve database performance.

For example, if you take a snapshot of a directory structure contains multiple instances of the same, the Job does not have to write the same file to the database multiple times, as the file system object is stored in the cache and can be reused.


2 To set a maximum cache size for file system objects, enter the following:

set appserver FileSystemObjectCacheMaxSize #

where # is a the maximum number of file system objects that will be stored in the cache. The default value is 5000.



Changing the heap size for BMC BladeLogic components

Setting the maximum number of items per page

The Application Server lets you specify a maximum number of records retrieved from a managed server, per page. These records are used when working with groups, smart groups, folders, search groups, database assets, custom objects, and server objects in the Configuration Object Dictionary, for example.


2 To set a maximum page size, enter the following:

set appserver MaxPageSize #

where # is a the maximum number of items retrieved per page. The default value is 1000.



You can change the heap size for the Application Server, the Application Server Launcher, and other BMC BladeLogic components as described in the following sections.

Changing the heap size for the Application Server

You can the heap size for the Application Server from the BMC BladeLogic Console or using the blasadmin utility.

From the BMC BladeLogic Console

1 In the BMC BladeLogic Console, from the Configuration menu, select Infrastructure Management.

2 Expand the hierarchy of the Application Servers node.

TIP In the BMC BladeLogic Console, large numbers of objects are presented in groups of 50, by default. You can adjust this display number by selecting Window => Preferences. Expand BMC and Paging Options to change the default. You can then page through these groups to make working with large numbers of objects more manageable. You must choose File => Refresh after changing the default to have the change take effect.



3 Right-click the Application Server you want to edit and select Edit. The Edit Application Server Profile dialog opens.

4 In the Edit Application Server Profile dialog, change the values for the MaxHeapSize attribute.

Using the Application Server Administration console (blasadmin utility)

To change the heap size for the Application Server using the blasadmin utility, perform the following steps:



set AppServer MaxHeapSize heapSize

For example:

set AppServer MaxHeapSize 1024M

Changing the heap size for the Application Server Launcher

You can also change the heap size for the Application Server Launcher. In a multi-Application Server environment, Application Servers inherit the heap size value from the Application Server Launcher, by default.

To change the heap size for the Application Server Launcher, perform the following steps according to your environment.

■ On Windows platforms, update the registry key HKEY_LOCAL_MACHINE\SOFTWARE\BladeLogic\Operations Manager\Application Server\option1

TIP Assuming that the Application Server has the recommended configuration of 4GB or more of physical memory, the recommended Max Heap Size value for each platform is as follows:

■ Windows - 1024 MB ■ Linux - 1536 MB ■ Solaris - 2048 MB


Enabling/disabling SOCKS proxy rule evaluation

■ For UNIX and Linux platforms, modify the following line in the blappserv script, which is located in the .../usr/nsh/br directory:

where -Xmx512M specifies a max heap size of 512Mb. Changing the value to -Xmx1G, for example, specifies a max heap size of 1GB.

Changing the heap size for other BMC BladeLogic components

To change the heap size for other BMC BladeLogic components, you modify the configuration script or file for the component.

For example, to change the heap size for the blasadmin utility on Windows, you modify the blasadmin.cfg file. To change the heap size for the BMC BladeLogic Console on UNIX or Linux, you modify the blclient script.

■ For UNIX and Linux platforms, modify the following line in the corresponding script, which is located in the .../usr/nsh/br directory:

where -Xmx512M specifies a max heap size of 512Mb. Changing the value to -Xmx1G, for example, specifies a max heap size of 1GB.

■ For Windows platforms, modify the corresponding configuration (.cfg) file in the br directory. By default, the configuration files are located in C:\Program Files\BMC Software\Bladelogic\versionNumber\NSH\br. In the configuration file, the format for setting the max heap size is jvm.arg=-Xmx1024M.

Enabling/disabling SOCKS proxy rule evaluation

By default, the BMC BladeLogic system evaluates communication requests to remote servers against routing rules to determine if the communication needs to be routed through a SOCKS Proxy Server. If your system does not use SOCKS Proxy Servers to route to remote servers, you can disable routing rule evaluation.

$JAVA_HOME/bin/java -Xss2m -Xmx512M -Djava.io.tmpdir=$BLADELOGIC_HOME/tmp…….

$JAVA_HOME/bin/java -Xss2m -Xmx512M -Djava.io.tmpdir=$BLADELOGIC_HOME/tmp…….


Configuring the file server


2 To enable or disable routing rule evaluation, enter the following:

set RoutingConfig EvaluateSocksProxyRules true|false

Where:

true — Turns on routing rule evaluation. The system evaluates communication requests against routing rules. By default, routing rule evaluation is turned on.

false — Turns off routing rule evaluation; the system does not evaluate communication requests against routing rules.


For information on setting up communications to remote servers through SOCKS Proxy Servers, see the BMC BladeLogic Server Automation User Guide.


To configure a file server you must specify a host and directory where BMC BladeLogic stores content. Before you can start BMC BladeLogic for the first time after a fresh installation, you must perform this procedure.

BMC BladeLogic uses the file server to store the contents of files included in snapshots, Network Shell scripts, BLPackages, software packages, and other types of information that is not easily stored in the database. In addition, the file server stores registry, COM+, and metabase values longer than 255 characters.

A file server should meet the following requirements:

■ An RSCD agent should be installed and licensed.

■ The file server should have substantial disk space (see the BMC BladeLogic Server Automation Installation Guide for exact recommendations).

NOTE Do not limit access to the file server by pushing agent ACLs to the agent on the file server. All users need to be mapped to the same user on the file server.



■ A user name must be defined on the file server, and all BMC BladeLogic users must be mapped to that user. Without this mapping a user may not be able to access a file that another user has stored on the file server. One way to accomplish the necessary mapping is to create an entry like the following in the exports file on the file server:

applicationServer rw, user=userName

where applicationServer is a comma-separated list of Application Server names or IP addresses and userName is the name to which all users are mapped. For more information see “Exports file” on page 240.

Setting up the file server


2 To specify the name of the file server, enter the following:

set fileserver name hostname

where hostname is the name of the server where data is stored.

3 To specify the location of the file server directory, enter the following:

set fileserver location directory

where directory is the directory on the file server where data is stored. Use a Network Shell style path to a directory, such as /c/FileServer, as opposed to a Windows-style path, such as C:\FileServer.


Updating a file server

You can update the status or change the properties of a file server using the Infrastructure Management window.

1 Select Configuration => Infrastructure Management.

2 Right-click the file server and select choose from the following options:

Option Description

Update File Server Status Contacts the file server to determine current status


Configuring a mail server

Configuring a mail server

BMC BladeLogic jobs can generate email upon their completion. To enable this capability, you must configure a mail server. You do not have to configure a mail server if you are not using the system’s ability to generate email.


2 To specify the name or IP address of the SMTP server, enter the following:

set emailconfig smtpserver hostname

where hostname is the name or IP address of the host managing email. (SMTP stands for simple mail transfer protocol.)

3 To specify the email address from which system-generated email is sent, enter the following:

set emailconfig fromaddress address

where address is the address from which mail should be sent.

4 To display the email address for technical support, enter the following:

show emailconfig techsupport


Refresh Updates the status of the server

Properties Launches the properties dialog, where you can modify the host name or the file server root directory.

To modify the file server to an advanced file server, select the Enable Advanced File Server option. For more information, see “Configuring Advanced File Servers and Advanced Repeater servers” on page 312

NOTE The techsupport parameter is a read-only parameter.

Option Description


Configuring Perl

Configuring Perl

The BMC BladeLogic Console and Network Shell both support the Perl scripting language. If you are using Perl, you should configure the Application Server so it knows the location of the Perl executable.


2 Specify the path and name of the Perl executable by entering the following:

set perlconfig location pathToPerl

where pathToPerl is a Network Shell-style path, such as /c/perl/bin/perl.exe.


Configuring an SNMP server

When a BMC BladeLogic job completes, it can generate an SNMP trap. In addition, when an Audit Job detects consistent or inconsistent results, it too can generate an SNMP trap. To enable SNMP traps, you must configure an SNMP server.


2 To specify the name or IP address of the SNMP server, enter the following:

set snmpconfig snmpserver hostname

where hostname is the name or IP address of the host managing SNMP trap notifications.

3 To specify a listening port for the SNMP server, enter the following:

set snmpconfig snmpport #

where # is the port used to contact the SNMP server.



Configuring a database server

Configuring a database server

BMC BladeLogic works in conjunction with an Oracle® or SQL Server database server. The installation program can configure the Application Server to communicate with this database. However, you can manually configure the Application Server to communicate with the database, as described in this procedure.

1 Start the Application Server Administration console, as described in “Starting the Application Server Administration console”.

2 To specify a connection string for the database, enter the following:

set database connectionstring string

where string is a string that specifies the database type, the server running the database, the port the database listens on, and SQL Server database name or Oracle SID. The connection string can use one of the following formats:

■ jdbc:oracle:thin:@DBSERVER:PORT:SID

■ jdbc:sqlserver://DBSERVER:PORT;DatabaseName=DBNAME;SelectMethod=cursor

When using one of the formats shown above, do the following:

■ Replace DBServer with the name or IP address of the server running the database.

■ Replace DBNAME with the name of the database or replace SID with the Oracle SID.

■ Replace PORT with the port number the database is listening on. By default, a BMC BladeLogic installation uses the following database ports:

3 To specify the driver class for the database, enter the following:

set database driverclass class

where class is the Java® class used to communicate with the database. Depending on the type of database you are using, you can define the class with one of the following strings:

■ oracle.jdbc.driver.OracleDriver

Database Type Port Number

Oracle 1521

SQL Server 1433


Configuring the process spawner

■ com.microsoft.sqlserver.jdbc.SQLServerDriver

4 To specify the user ID and password for the database, enter the following two commands:

set database userid idset database password ******

where id is the user name that the database needs to authenticate your connection and ****** is the password assigned to that user ID.

5 To specify a commit size for an Oracle database, enter the following:

set database commitsize size

where size is the maximum number of rows that can be updated in an Oracle database before you either have to commit your updates or roll them back. Commit size is primarily used when taking snapshots or performing audits in BMC BladeLogic. A larger commit size means database processes execute more quickly, but at the same time you run the risk of losing more data should a database process fail.



An Application Server can be configured to spawn processes externally to the Application Server process itself. If you configure an Application Server in this way, a separate dedicated process (the process spawner) is used only for spawning processes. When the Application Server needs to spawn a process, it contacts the process spawner, which starts a new child process. The Application Server transfers the necessary information to the child process. Spawning processes externally can be beneficial for memory management.

Primarily, an Application Server spawns processes for Network Shell Script Jobs and some types of extended objects.

TIP Because Oracle databases can be highly tuned, you may want to consult your Oracle DBA to achieve best results when defining a commit size.



To configure the process spawner, do the following:

1 Configure the Application Server to use the process spawner. See “Configuring an Application Server to use the process spawner”.

2 Configure the process spawner itself. See “Configuring the process spawner” on page 81.

Configuring an Application Server to use the process spawner

1 Start the Application Server Administration console for the Application Server that you want to execute the NSH jobs. For example:

blasadmin -s JobServer1

For more information on methods for starting this console, see “Starting the Application Server Administration console” on page 45.

2 Specify that processes be spawned externally from the Application Server process. Enter the following:

set ProcessSpawner SpawnExternally true

Setting this value to false indicates the process spawner runs within the Application Server process. By default, this value is set to false.

3 Specify a port for communicating with the process spawner. Enter the following:

set ProcessSpawner RegistryPort #

where # is the number of a port. The default port is 1067 and is the port recommended by BMC BladeLogic.


NOTE If you set the ProcessSpawner SpawnExternally value to true, BMC Software recommends that you run the following command before starting the Application Server service (to avoid ‘connection refused’ failures for any scheduled jobs):

■ run /etc/init.d/blprocserv start (UNIX)

■ net start “BladeLogic Process Spawner” (Windows)




5 Start the Application Server Administration console for the process spawner deployment.

blasadmin -s _spawner

For more information on methods for starting this console, see “Starting the Application Server Administration console”.

6 Set the Registry Port for the process spawner to match the port specified to the when you configured the Application Server to use the process spawner. Enter the following:

set AppServer RegistryPort #

where # is the number of a port. The default port is 1067 and is the port recommended by BMC BladeLogic.

7 Restart the process spawner. Do one of the following:

■ On Windows, from the Start menu, select Settings > Control Panel. Double-click Administrative Tools, and double-click Services. Right-click BMC BladeLogic Process Spawner and select Restart from the pop-up menu.


/etc/init.d/blprocserv restart


Configuring expiration time for credentials of jobs

Configuring expiration time for credentials of jobs

Use this procedure to set a timeout value for the session credentials that are passed to jobs. Once the credentials expire, all active client connections are closed. The NshScriptJobCredentialTimeout setting is a global setting that applies to all jobs.


2 To set a timeout value for the job session credentials, enter the following:

set ProcessSpawner NshScriptJobCredentialTimeout #

where # is the number of hours (minimum of 24). The default setting is 96 hours.

For more on the process spawner, see “Configuring the process spawner” on page 81.


Processing across mount points

Use this procedure to configure the Application Server so snapshots, audits, and BLPackages in BMC BladeLogic can be processed across UNIX mount points and network mount points for remote file systems shared through NFS.

For example, if you want to cross mount points, you can perform a snapshot or audit of / and processing can traverse other volumes such as /home or /usr that may reside under /. Choosing not to cross mount points can substantially increase the speed of snapshots, audits, and packaging of BLPackages. By default, processing does not cross mount points.


2 To specify how UNIX mount points are processed, enter the following:

set mountconfig SnpAudPkgCrossMounts true|false

NOTE If a job exceeds the timeout value in the NshScriptJobCredentialTimeout setting, an error message is written to the Application Server log and the job log.


Restricting the size of configuration and extended objects

In the command shown above, false means that processing does not cross mount points (this is the default value); true means processing of audits, snapshots, and BLPackages crosses mount points.

3 To specify how network mount points are processed, enter the following:

set mountconfig SnpAudPkgNetworkMounts true|false

In the command shown above, false means that processing does not cross network mount points (this is the default value); true means processing of audits, snapshots, and BLPackages crosses network mount points.

To set SnpAudPkgNetworkMounts to true, the SnpAudPkgCrossMounts option must also be set to true (see step 2).


Restricting the size of configuration and extended objects

Use this procedure to limit the number of records that a server can provide to an Application Server for a single configuration object or extended object. Processing large numbers of records for a configuration object or extended object can consume large quantities of memory, particularly when the Application Server processes multiple configuration objects or extended objects on multiple servers simultaneously. Using this procedure can help prevent the Application Server from running out of memory.

Configuration objects and extended objects can be used in component templates, Audit, Snapshot, and Compliance Jobs, and in live browsing. If a job targets a server that returns more records for a configuration object or extended object than the limit set in this procedure, the job fails on that server with a parsing error.


2 To limit the number of records that an Application Server can process for a single configuration object or extended object, enter the following:

set AssetThresholds MaxConfigRecords #

where # is the maximum number of records to be processed. By default this value is set to 50,000. Setting this value to 0 means no records are processed.



Configuring user interface settings


The Application Server Administration console gives you several options for controlling the behavior of the BMC BladeLogic Console and the BLCLI. The following procedures describe the available options:

■ Displaying no access nodes in the BMC BladeLogic Console■ Deleting groups in the BMC BladeLogic Console■ Creating properties automatically in the BMC BladeLogic Console■ Limiting the number of results displayed when browsing■ Controlling the permissions of copied objects■ Enabling export and import of property dictionaries and classes■ Setting temporary group location for update

Displaying no access nodes in the BMC BladeLogic Console

In the BMC BladeLogic Console, users can potentially see system objects even when those users do not have appropriate permissions to interact with those objects. BMC BladeLogic calls these type of objects no access nodes.

This procedure lets you globally show or hide no access nodes. If you use this procedure to show no access nodes at the Application Server level, BMC BladeLogic users have the option of hiding or displaying no access nodes. If you use this procedure to hide no access nodes, users cannot display no access nodes.


2 To show or hide no access nodes, enter the following:

set ConfigManagerUI ShowNoAccessNodes true|false

In the command shown above, true indicates that no access nodes can be shown in the BMC BladeLogic Console; false indicates no access nodes are hidden.


Deleting groups in the BMC BladeLogic Console

Use this procedure to specify that users of the BMC BladeLogic Console cannot delete groups or folders unless they are empty. By default, users can delete groups and folders even when they contain system objects.

This setting has no effect on smart groups, which users can always delete.




2 To specify whether users can delete groups or folders, enter the following:

set ConfigManagerUI GroupsMustBeEmpty true|false

In the command shown above, true indicates that groups must be empty before they can be deleted; false indicates users can delete groups and folders even when they contain objects.


Creating properties automatically in the BMC BladeLogic Console

When you import objects into the BMC BladeLogic Console and those objects reference properties not defined on the destination system, BMC BladeLogic can automatically create properties so you can map them to the properties referenced by the imported object.

This procedure lets you specify whether properties should be created automatically during the import process. By default, properties are automatically created.


2 To turn the automatic creation of properties on or off, enter the following:

set ConfigManagerUI AutoCreate true|false

In the command shown above, true indicates that properties are automatically created; false indicates properties are not automatically created.


Limiting the number of results displayed when browsing

Use this procedure to limit the number of results displayed when a user is browsing in the BMC BladeLogic Console.

Selecting some nodes while browsing can potentially display large numbers of results, which can slow your system performance. This procedure lets you set an arbitrary limit to the number of results that can be displayed during live browse.



In the BMC BladeLogic Console, users can set a preference that also establishes a limit for results displayed while browsing. The limit set in the console cannot exceed the limit established with this procedure.


2 To limit the number of live browse results that can be displayed, enter the following:

set AssetThresholds MaxAllowedLiveBrowseResults #

where # is the maximum number of results that can be displayed for any node when browsing in the console. Setting this number to 0 indicates no results are displayed.

By default this option is set to 50,000.


Controlling the permissions of copied objects

Use this procedure to control the permissions that are assigned to objects during copy and paste operations in the BMC BladeLogic Console.

Normally, when users copy and paste an object, the newly created object has the same permissions as those assigned to the object that was copied. After you use blasadmin to perform this procedure, users can copy and paste an object, and the newly created object has the permissions that are specified for that type of object in the object permissions template defined for the user’s role. Also the user’s role is granted full permission to the object (that is, a * authorization).


2 To enable copying of objects so that the copied objects are assigned a default set of permissions, enter the following:

set ACLCopy UseDefaultAclOnObjectCopy true

In the command shown above, true means that when you copy and paste an object, the newly created object is granted a default set of permissions; false means that when you copy and paste an object, the newly created object has the same permissions that were defined for the object that was copied.

By default this option is set to false.




Enabling export and import of property dictionaries and classes

Use this procedure to enable or disable the export and import of the entire Property Dictionary or specific custom property classes. To enable import/export, this option must be set to true on both the exporting and the importing Application Server.


2 To enable or disable the import and export of the Property Dictionary or custom property classes, enter the following:

set ConfigManagerUI PropertySync true|false

In the command shown above, true indicates that you can export and import the Property Dictionary or custom property classes; false indicates import/export is disabled.

By default this option is set to false.


Setting temporary group location for update

When you run any of the BLCLI importAndUpdate commands in the Template or BlPackage name spaces, the import and update process creates a temporary group at the root of the relevant workspace and uses that group to store the imported object. This temporary group is deleted at the end of the update operation.

By default, the temporary group is /importAndUpdate. This procedure lets you change this group to another name or location.


2 To specify a new location for the temporary group, enter the following:

set ConfigManagerUI DefaultImportAndUpdateFolder /path/to/some/folder



Setting SRP login requirements

Setting SRP login requirements

Use this procedure to configure the Application Server so it forces users logging in via SRP to meet any of the following requirements:

■ Minimum password length—By setting a minimum password length, you can require users specifying passwords to provide a password of minimum length. By default, there is no minimum length for passwords.

■ Maximum password age—By setting a maximum password age, you can require users to change passwords at specified intervals.

■ Account lockout—By setting a threshold and duration for account lockouts, you can specify how many failed logins cause a user to be locked out and how long that lockout lasts.


2 Do any of the following:

■ To specify a minimum password length, enter the following:

set accountconfig MinPasswordLength #

where # is the minimum length for passwords. Entering a 0 indicates there is no minimum length for passwords.

■ To specify how long it takes for a password to expire, enter the following:

set accountconfig MaxPasswordAge #

where # is a period of time in days. Entering a 0 indicates passwords do not expire. In RBAC you can specify that passwords never expire no matter what expiration period you specify. For more information on RBAC see the BMC BladeLogic Server Automation User Guide.

■ To specify how many times a user can fail to log in before being locked out, enter the following:

set accountconfig AccountLockoutThreshold #

where # is the number of failed logins that trigger a lockout. Entering a 0 indicates that users cannot be locked out because of login failures.

■ To specify how long a user is locked out when he or she has surpassed the lockout threshold, enter the following:


Configuring the PXE Server

set accountconfig AccountLockoutDuration #

where # is the number of minutes the user is locked out. Entering a 0 indicates that users can only be unlocked by an administrator using RBAC.


When provisioning some types of servers, you must set up a PXE Server, which provides instructions for downloading the bootstrap program needed to begin the provisioning process. Use this procedure to provide various parameters needed to run a PXE Server.

1 Start the Application Server Administration console and specify the PXE Server deployment (_pxe). Enter the following:

blasadmin -s _pxe

2 Identify the type of Ethernet interface that the PXE server uses to listen by entering the following:

set pxeserver interface_to_bind interfaceName

where interfaceName is the type of Ethernet interface. For example, you might enter the name of a network interface card, such as eth0 or eth1.

3 Identify the address of the TFTP server by entering the following:

set pxeserver default_address TFTP_address

where TFTP_address is the IP address of the TFTP server. Servers being provisioned download bootstrap programs from a TFTP server.

4 Identify the IP address of the multicast group that the PXE server listens on by entering the following:

set pxeserver multicast_address address

where address is an IP address. By default, a BMC BladeLogic PXE Server listens on the multicast address of 224.0.1.2. Multicast addresses must fall in the range 224.0.0.0 to 239.255.255.255.

5 Identify the IP address of a multicast TFTP server by entering the following:

set pxeserver mtftp_address MTFTP_address

where MTFTP_address is the multicast address that the TFTP listens on.



6 Identify the multicast port that PXE clients should use to communicate with the TFTP server by entering the following:

set pxeserver mtftp_client_port port

where port is the multicast port that servers being provisioned should use to communicate with the TFTP server. By default BMC BladeLogic uses port 1758.

7 Identify the port that the TFTP server should use to listen for traffic from PXE clients by entering the following:

set pxeserver mtftp_server_port port

where port is the multicast port. By default BMC BladeLogic uses port 1759.

8 Identify the PXE Server’s listening port by entering the following:

set pxeserver listen_port port

where port is the port on which the PXE Server listens for connections from PXE clients.

9 Specify whether the PXE Server uses a multicast by entering the following:

set pxeserver is_use_multicast #

where # can be one of the following:

■ 0—The PXE Server cannot use a multicast.■ 1—The PXE Server can use a multicast.

10 Specify whether the PXE Server can use a broadcast by entering the following:

set pxeserver is_use_broadcast #

where # can be one of the following:

■ 0—The PXE Server cannot use a broadcast.■ 1—The PXE Server can use a broadcast.

11 Specify the amount of time the boot prompt displays before the boot process begins by entering the following:

set pxeserver prompt_timeout #

where # is the maximum amount of time the boot prompt can display. If you enter 0, the boot prompt does not display.


Configuring the Licensing Module

12 Identify the base directory on the TFTP server where operating system bootstrap programs are stored. Enter the following:

set pxeserver tftpd_base_dir directory

where directory is the base directory on the TFTP server for storing bootstrap programs.

13 Identify the PXE Server’s domain by entering the following:

set pxeserver domain domain_name

where domain_name is the name of the PXE Server’s domain.

14 Restart the PXE Server.

Configuring the Licensing Module

The Application Server communicates with the BMC Software Licensing Portal to register or deregister managed servers. Use the Licensing command to specify the information required to access the services of the Licensing Portal.

Connecting to the Licensing Portal

Use the following parameters for the Licensing command to specify the location of the portal and the credentials the Application Server uses to communicate with the Licensing Portal.

TIP To display the value of a parameter you have set previously, use the show parameter instead of the set parameter. For example, to display the user name the Application Server uses to connect to the Licensing Portal, enter:

show Licensing ServiceUsername

Task Command

Set the location of Licensing Portal for registering servers

set Licensing LicenseServiceURL http://www.bladelogic.com/services/LicensingWS

Set the location of Licensing Portal for deregistering servers

set Licensing DeregisterServiceURL https://webapps.bmc.com/ BMCBladelogicLicensingWS/services/BMCBladelogicLicenseService


Enabling asynchronous execution

Connecting to the Licensing Portal using a proxy

These optional parameters for the Licensing command specify the system and credentials for the proxy host through which the Application Server communicates with the Licensing Portal.

Enabling asynchronous execution

Asynchronous execution lets Deploy Jobs run without blocking work item threads for extended periods of time. This allow an Application Server to process a Deploy Job more efficiently and frees up valuable Application Server resources that can be used by other jobs.

Asynchronous execution can occur during the Simulate and Commit phases of a Deploy Job as well as during an undo. Turning asynchronous execution on or off does not affect the Staging phase of a Deploy Job.


2 To enable or disable asynchronous execution, enter the following:

Set the user name and password

set Licensing ServiceUsername userName

set Licensing ServicePassword password

Note: While the password is entered in clear text, it is stored in the database in encrypted form. When you use the show Licensing ServicePassword command, the password is displayed in encrypted form.

Task Command Notes

Set the proxy host name

set Licensing ProxyHost hostName

Enter the fully-qualified name of the host machine.

Set the proxy port set Licensing ProxyPort portNumber

Set the proxy user name and password

set Licensing ProxyUsername userName

While the ProxyPassword is entered in clear text, it is stored in the database in encrypted form. When you use the show Licensing ProxyPassword command, the password is displayed in encrypted form.

set Licensing ProxyPassword password

Task Command


Enabling web services

set appserver EnableAsyncExecution true | false

By default this value is set to true.


Enabling web services

To enable web services, enter the following:

set AppServer enableWebServices true

For information about additional web services settings, see the BMC BladeLogic Server Automation Web Services Developer Guide.

Configuring multiple Application Servers on the same host

BMC BladeLogic lets you run multiple Application Servers on a single host, in addition to the Application Server initially installed. You can configure each additional Application Server so it performs one or more distinct functions, such as a Configuration Server or a Job Server.

Using separate Application Servers in this way, the performance of one Application Server does not affect the behavior of another. Defining multiple Application Servers also lets you utilize more fixed memory on a host system because the JavaVM heap limit would otherwise restrict a single Application Server to a fixed amount of memory.

To configure multiple application servers on the same host, follow these steps:

1 If you have not done so already, install and configure the Application Server on the host machine.

All Application Servers on the same host must use the same database connection. The easiest way to achieve this result is to run the Post-Install configuration wizard as the last step of the Application Server installation. (For information, see “Using the Post-Install Configuration wizard to configure the default application server” on page 34.)


About Application Server deployments and profiles

2 Use the Infrastructure Management window or the Application Server Administration console (blasadmin) to create and configure additional Application Servers on the host. See “Creating additional Application Servers”. The creation process not only creates the additional Application Servers but also gives them an “out-of-the-box” configuration, based on their Application Server Type and other information you specify.

3 Optionally, use the Application Server Administration console (blasadmin) to further configure Application Servers.


The following sections provide an overview of Application Server deployment and the different types of Application Servers.

Application Server deployments

A deployment is a directory of services that an Application Server runs. The table describes each deployment and the effect of configuration changes on it.

NOTE When you start blasadmin, you must use options to specify the Application Server you are configuring or to specify configuration of all Application Servers on the host. See “Using the Application Server Administration console (blasadmin) to configure Application Servers” on page 44.



Deployment Name Description

_template The “master” from which other Application Server deployments are created. This deployment is created during BMC BladeLogic installation. This deployment contains default (“out-of-the-box”) settings and initial configuration settings made with the Post-Install Configuration wizard.

Changes to this deployment affect all new Application Servers created.

Configuration changes you make using blasadmin -a affect this deployment.

default The deployment for a single Application Server or the initial Application Server when there are multiple Application Servers on the same host.

This deployment is created when a single or initial Application Server is first started. The start-up process copies the _template deployment to create the default deployment.

The following configuration changes affect the default deployment:

■ Changes you make using the Application Server Administration console from the BMC BladeLogic menu or using blasadmin without the -a option or -s option. See “Starting blasadmin to Configure the Default Application Server” on page 45.

■ Changes you make using the Application Server Configuration Wizard or the blappconf command with no -s option. See “Using the application server configuration wizard to change configuration settings” on page 39.

AppServerName The deployment for each Application Server created on the same host (in addition to the default Application Server).

When there are multiple Application Servers configured on the same host, each Application Server’s profile determines the number and type of services in its deployment.

The following configuration changes affect the deployment:

■ Changes you make using blasadmin -s appServerName or blasadmin -a. See “Starting the Application Server Administration console” on page 45.

■ Changes you make using blappconf -s appServerName

For more information, see “Using the application server configuration wizard to change configuration settings” on page 39.



Application Server profiles

A profile is a definition of an Application Server’s identity: its name, type, and attributes. Each Application Server has a different profile. An Application Server’s profile is essentially a pre-packaged set of configuration options for an Application Server. BMC BladeLogic uses the profile to create and update an Application Server’s deployment (the services that the Application Server runs).

An Application Server profile can include attributes of one or more Application Server types. You specify the Application Server types when you create the Application Server. The attributes needed for each type are predefined in the profile for the type.

Application Server types

The Application Server Type defines the work that an Application Server performs and services that it runs.

The following table lists Application Server types and describes each.

_spawner The deployment for the process spawner. See “Configuring the process spawner” on page 81.

_pxe The deployment for the PXE Server. See “Configuring the PXE Server” on page 89.

_launcher The deployment for the Application Server Launcher. See “The Application Server Launcher” on page 34.

Application Server Type Functional Description

CONFIGURATION Handles all requests from the BMC BladeLogic Console and the BLCLI. While a CONFIGURATION server can create jobs and start the execution of jobs, only a JOB server can run the work items needed to process a job.

JOB Executes work items needed to process a job.

A JOB server responds to local connection requests from the BMC BladeLogic Console or the BLCLI, provided that one or more of the connection ports (for example, AppSvcPort) is open. A JOB server never responds to remote connection requests, regardless of settings for the connection ports.

Deployment Name Description


Creating additional Application Servers


You can create additional Application Servers from the BMC BladeLogic Console using the Infrastructure Management window or from the command line using the Application Server Administration console (blasadmin).

Creating additional Application Servers from the BMC BladeLogic Console

Use this procedure to create Application Servers in addition to the Application Server installed on a host.


2 Expand the Application Server Launchers node and right-click the Application Server Launcher that you want to control the new Application Server. Then select New Application Server.

If there are unmanaged deployments which match this new Application Server request, you are presented with the option of using the unmanaged deployment or creating a new one. Choose one of the following options:

■ Click No to return to the new Application Server dialog.

■ Click Yes to redeploy the unmanaged deployment with the base port and configuration type you specify. Note that you will not preserve the data that was in the previous unmanaged deployment.

3 In the New Application Server dialog, entering the following information for the new Application Server.

NSH_PROXY Manages traffic between Network Shell clients and remote servers. An NSH_PROXY server cannot service requests from the BMC BladeLogic Console or the BLCLI.

ALL Equivalent to (CONFIGURATION, JOB, NSH_PROXY)

An Application Server with its type set to ALL performs the functions of all Application Server types.

Application Server Type Functional Description



4 Click OK. The system creates a profile for the new Application Server.

5 A prompt appears, asking if you want to edit the new Application Server’s profile.

Field Description

Application Server Name

(Required) The name for the new Application Server. Used internally within the BMC BladeLogic environment, as well as for the Display Name in the interface.

Follow these guidelines:

■ Specify a name that is unique on the host. Do not use the same name as the default Application Server.

■ The name can be no more than 200 characters in length.

■ The name can include letters, digits, hyphens (-), and underscores (_).

■ Do not use the following reserved names: default, _install, _launcher, _old, _pxe, _spawner, _template, _util, _postmig

You cannot change the Application Server Name after configuration. However, you can change the Display Name. See “Viewing and editing an Application Server’s profile” on page 100.

Base Port (Required) The number that BMC BladeLogic uses to automatically generate default port numbers for the new Application Server.

Specify a number that makes the new Application Server’s default ports unique on the host. The number must be between 1000 and 65536.

To generate the numbers, BMC BladeLogic uses the base port with the last two digits of the default port. For example, if the default port numbers have a base of 9800 (9836 for Registry Port, 9829 for SRP Port, and so on), you could specify 9900 as the base port for the new Application Server. The creation process sets the Registry Port to 9936, the SRP Port to 9929, and so on.

Application Server Type(s)

(Required) Specifies the type of Application Server to create: CONFIGURATION, JOB, NSH_PROXY, or ALL (a combination of all three types). For information on each type, see “Application Server types” on page 96.

The Application Server Type determines the attributes included in its Application Server profile.

Accept the default (All Server Types) or uncheck All Server Types and select one or more types. (Use Shift + Click to select multiple contiguous types; use Ctrl-Click to select individual items).



■ To add or change attributes for the server, click Yes. The Edit Application Server Profile dialog appears. For information, see “Viewing and editing an Application Server’s profile” on page 100.

■ To accept the profile, click No. (You can always edit the profile later.)

BMC BladeLogic creates the Application Server. You can either start the Application Server or deploy it and start it later.

Creating additional Application Servers from the command line

You can also add a new Application Server deployment using the blasadmin Create command. This command provides the ability to set up an environment from the command line. You can create deployments while executing from a shell or while reading in a file.

To add a new deployment

1 Start blasadmin for the _template deployment by entering the following:


2 Create a new default deployment of a specific type by entering the following:

create deployment_name base_port profile_types

where

deployment_name is the name of the new deployment you are creating. For guidelines for creating the name, see the description of the Application Server Name field in “Creating additional Application Servers from the BMC BladeLogic Console” on page 97.

base_port is a number that is combined with offset values to determine Authentication and Application Server port numbers. For example, the offset for the authentication port is 40 by default. If the base_port is 9500, the authentication port would be 9540.

profile_type is a comma separated list of the type of Application Server to create: Configuration, Job, NSH_Proxy, or All (a combination of all three types). For information on each type, see “Viewing and editing an Application Server’s profile” on page 100.


Viewing and editing an Application Server’s profile

3 Start the Application Server on the machine where you are setting up the deployment. See “Starting Application Servers” on page 41.


An Application Server profile is a definition of an Application Server’s identity: its name, type, and attributes (configuration parameters). To view an Application Server’s profile or change attribute values, use the Edit Application Server Profile dialog.




4 In the Edit Application Server Profile dialog, add or change values for attributes.

The fields in this dialog are effectively overrides to default values or to previously- specified configuration parameters.

■ To add an attribute to the Application Server’s profile or to change a default value, type a value in the blank field.

■ To change an existing value, clear the field and type the value you want.

■ To remove an attribute from the profile, clear the field.

NOTE For instructions on using blasadmin to create a stand-alone NSH Proxy, see “Setting up a stand-alone Network Shell Proxy Server” on page 145.

NOTE Always use the Edit Application Server Profile dialog to add or change the attributes (configuration parameters) in an Application Server’s profile. Do not use the blasadmin utility.



Attributes listed depend on the Server Profile Type (Application Server Type). The following table describes all attributes that a profile can include.

Attribute Description

Application Server Name

The name for the Application Server, specified during configuration. You cannot edit this attribute.

Display Name The name that appears in all user interfaces, rather than the Application Server name.

You do not have to specify a name. If you leave this field blank, the Display Name is the same as the Application Server name.

If you specify a name, follow these guidelines:

■ Specify a name that is unique on the host. Do not use the same name as the default Application Server.

■ The name can include letters, digits, hyphens (-), and underscores (_).

■ Do not use the following reserved names: default, _install, _launcher, _old, _pxe, _spawner, _template, _util

Default Deployment Shows whether the Application Server uses the default deployment.

■ True — The Application Server uses the default deployment.■ False —The Application Server do not use the default deployment.

For information, see “Editing the list of roles with Application Server Launcher access” on page 113.

You cannot edit this attribute.

Server Profile Type(s) The Application Server’s type, as specified during configuration. The type can be one or more of the following: CONFIGURATION, JOB, NSH, or ALL. See “Application Server types” on page 96.

You cannot edit this attribute.

ServiceType Determines if the Application Server should be automatically started by the AppServerLauncher.

■ A ServiceType of Manual, which means that the Application Server can only be started using the Infrastructure Dialog.

■ A ServiceType of Automatic means that the Application Server will be started automatically by the AppServerLauncher.

By default, the ServiceType is Automatic.



AppServiceURLs The Application Service URLs distributed in the session credentials issued by the Authentication Service.

To include this attribute in the profile, specify one or more comma-separated values. For example: service:appsvc.bladelogic:blsess://localhost:9841,service:appsvc.bladelogic:blsess://10.10.10.10:9841

Typically, you do not need to specify a value for this attribute. However, if you want to run Network Shell Script Jobs that include BLCLI commands, you can direct these commands to run on a particular Application Server. BLCLI commands used for import or export must run on an Application Server with its type set to CONFIGURATION or ALL. By default BLCLI commands run on the Application Server processing the job. If that Application Server is a JOB type Application Server, it cannot process BLCLI commands used for import/export.

AppSvcPort The listening port for the Application Service (the service that accepts client connections).

When you create a new Application Server, BMC BladeLogic sets this value to the Base Port plus 41. This convention avoids conflicts when there are multiple Application Servers on the same host.

If you set this value to 0, the Application Server does not run an Application Service.

Note: When you create a job server (Application Server Type JOB), it runs a ClientConnectionService. However, that service accepts only connections from the local machine, unless the server is also a configuration server (Application Server Type JOB and CONFIGURATION).

AuthSvcPort The listening port for the Authentication Service (the service that authenticates user identities).


If you set this value to 0, the Application Server does not run an Authentication Service.

Note: When you create a job server (Application Server type JOB), this port defaults to 0, unless the server is also a configuration server (Application Server Type JOB and CONFIGURATION). In that case, the default is Base Port plus 40.

CLRProxyPort The listening port for Network Shell (NSH) communication.

If you set this value to 0, the port is disabled.




ConsoleLogfileName The name of the console log file for the Application Server. The console log file contains all information logged to the Application Server log, plus any information logged to the console.

When you create a new Application Server, BMC BladeLogic sets the console log file’s name to the Application Server name plus “_console”. This convention avoids conflicts when there are multiple Application Servers on the same host.

If you edit this attribute, specify a name that is unique on the host.

JMXManagementPort The port used to access the BMC BladeLogic JConsole.


JVMArgs Arguments to pass to Java Virtual Machine for this Application Server. Specify any argument that can be specified to the Java command line

If the MaxHeapSize attribute is set and you specify an -Xmx flag for JVMArgs, the value for JVMArgs is used instead of MaxHeapSize.

You do not need to specify a value for this attribute. If you specify a value, it is assumed to be valid and is used when the Application Server is started. If the value is not valid, the Application Server does not start.

LogfileName The name of the log file for the Application Server.

When you create a new Application Server, BMC BladeLogic sets the log file’s name to the Application Server name plus the .log extension. This convention avoids conflicts when there are multiple Application Servers on the same host.


MaxHeapSize You can specify a value for MaxHeapSize but you are not required to do so. If you do not specify a value, the Application Server uses the heap size set in the Application Server start-up script or service definition. This value is usually adequate. For information on recommended maximum Java heap size for Application Servers, see the hardware requirements for the Application Server in the BMC BladeLogic Server Automation Installation Guide.

To specify a value, use the standard Java notation, for example: 1G or 225M.

MaxJobs The maximum number of jobs the Application Server can execute simultaneously. The default is 20.

MaxPort The maximum dynamic port number. By default, this value is set to Base Port + 99.

MaxWorkItemThreads The maximum size of the pool of threads that can be used to process BMC BladeLogic Console jobs. Determines how many targets can be processed in parallel. The default is 50.

MinPort The minimum dynamic port number.

When you create a new Application Server, BMC BladeLogic sets this value to the Base Port + 50. This convention avoids conflicts when there are multiple Application Servers on the same host.




ProxyServiceURLs The Network Shell Proxy Service service URLs. If you leave this field blank, the system uses the default URLs.

To override the default URLs, type a comma-separated list in the field. For example:

service:proxysvc.bladelogic:blsess://host1.bladelogic.com:9842,service:proxysvc.bladelogic:blsess://host2.bladelogic.com:9842

ProxySvcPort The listening port for a Network Shell Proxy Service. You must manually define a listening port for the default deployment of an Application Server. Typically, ProxySvcPort is set to 9842 for the default Application Server.

When you deploy a new Application Server with its type set to NSH_PROXY or ALL, the ProxySvcPort is automatically set to the Base Port plus 42. You can modify this value if necessary.

If this value is blank, the Application Server does not run a Network Shell Proxy Service.

RegistryPort The listening port for traffic between Application Servers that cooperate by distributing jobs to each other.


SSLPort The listening port for SSL communication.


SqlFiles The list of SQL properties files used by the Database Service.

If you leave this field blank, the list is:

sql/sqlmap.propertiessql/streamable_sqlmap.propertiessql/blas-sqlmap.propertiessql/reports-sql.properties

In most cases, there is no need to change this list. However, you can override the default list by typing a comma-separated list of properties in the field.

TempDirectoryName The name of the directory that stores the Application Server’s tmp files. Usually, this name is the same as the Application Server Name and its location is:

installDirectory/tmp/temporaryDirectoryName

When you create a new Application Server, BMC BladeLogic sets the temporaryDirectoryName to the Application Server Name. This convention avoids conflicts when there are multiple Application Servers on the same host.




Listing conflicting attributes

5 When you are finished editing the profile, click OK.

6 Click OK on the warning that configuration changes do not take effect until you restart the Application Server.

7 Start or restart the Application Server to have changes take effect.

Rules for defining unique attributes

Several rules apply when assigning unique values to attributes:

■ Multiple Application Servers can share any port that is set to 0 if that setting of 0 disables the port.

■ Multiple Application Servers can have the same value for MaxJobs, MaxWorkItemThreads, or SqlFiles, regardless of what that value is.

■ All other attributes must be unique. Failure to make them unique results in conflicts that can cause a start or restart failure in one or more Application Servers. For information on identifying conflicts in Application Servers’ attributes, see “Listing conflicting attributes” on page 105.

Listing conflicting attributes

When there are Application Servers on the same host, each should have a unique profile. For the most part, attributes for these Application Servers cannot have the same values.

The Application Server Launcher automatically detects attribute conflicts among the Application Servers that it controls. Typically, a conflict occurs because the same port number has been assigned to more than one Application Server. These conflicts prevent an Application Server from starting or restarting if it has conflicts with one or more currently running Application Servers.

When an Application Server’s profile has a conflicting attributes, its Application Server details shows State = CONFLICT.

You can also use the List Conflicts operation to identify attributes on an Application Server that conflict with attributes on other Application Servers.


2 In the Infrastructure Management window, expand the hierarchy of the Application Servers node.


Getting information about Application Servers

3 Right-click an Application Server and select List Conflicts.

A Warning panel lists the attributes that conflict with those other Application Servers. For each attribute, the panel shows the attribute name and the name of Application Server that has the same attribute value specified.

4 Click OK.

Getting information about Application Servers

You can display information about an Application Server and the services that it runs. This information can be useful for diagnostic purposes.



NOTE To display information about the Application Server, your role must be granted the BL_Administration.Read authorization.

To display... Do the following:

A list of Application Servers on the host (using the same database).

Expand the Application Servers node.

The left pane lists each Application Server’s Display Name and Authorization Port.

General information about an Application Server

Click the Application Server’s name in the left pane.

The right pane shows:

■ Software version■ Number of jobs running■ Number of work item threads■ Database connections■ Host operating system■ JVM memory usage


The Application Server Launchers node

The Application Server Launchers node

The Application Server Launchers node lists a node for each Application Server Launcher that is configured to use the database and is available. (For information, see “The Application Server Launcher” on page 34.)

Status information from the Application Server Launcher.

(This information is displayed if your role has authorization to access the Application Server Launcher.)

Click the Application Server’s name in the left pane. In the right pane, scroll down. The right pane shows:

■ The Application Server Launcher that controls the Application Server

■ Name — The name for the Application Server, specified during configuration.

■ Display name— The name that appears in all BMC BladeLogic user interfaces.

■ Server Type— Application Server Type.

■ State — (VALID | CONFLICTS) Whether the Application Server’s profile has conflicts that can keep the Application Server from starting.

■ Status — (Ready | Stopped | Starting) Whether the Application Server is ready to perform tasks, stopped, or starting up.

■ Elapsed Time — The uptime of the Application Server.

■ Start Date — The date when the Application Server was started.

■ Needs Restart — (True | False) Whether the Application Server has been reconfigured and needs to be restarted.

■ ServiceType — (Manual | Automatic) Whether the Application Server is automatically started by the AppServerLauncher.

A list of the services that an Application Server provides

Expand the hierarchy of an Application Server. (The number and type of services vary according to the Application Server’s type.)

Status information about an Application Server service

Expand the hierarchy of the Application Server. Click the service name.

A menu of actions you can perform on the Application Server

Right-click the Application Server.

To display... Do the following:


Reporting Application Server information

The Application Server Launcher lists a node for each Application Server it controls.

Through the Application Server Launchers node, you can get the same information about Application Servers and perform the same operations as with the Application Servers node. However, it is only through the Application Server Launcher that you can:

■ Obtain port information for the Application Server Launcher.■ Create new Application Servers.■ Edit the list of roles allowed access to the Application Server Launcher.

Reporting Application Server information

You can generate a report containing information about all of the Application Servers on the host. The report includes:

■ General information for each Application Server configured on the host machine (and using the same database) and detailed status information about each Application Server’s services.

■ General information for each PXE server connected to the database and detailed status information about each PXE Servers services.

■ Information about the database to which the Application Server is connected.


2 In the Infrastructure Management window, click Export Detail Report .

3 On the Export AppServer Details Report dialog, from the pull-down menu, select a directory where the report should be stored. Optionally, select a subdirectory by double-clicking its name in the panel.

4 On the dialog, enter the information for the report file:

A For Object Name, type a file name for the report.

B For Object Type, select a file format.

C For File Encoding, select the type of character encoding that should be used for the exported data, such as UTF8 or Western (windows-1252).

5 Click Save.


Managing multiple Application Servers on the same host

Managing multiple Application Servers on the same host

When there are multiple Application Servers configured on the same host, you manage the additional Application Servers through the Infrastructure Management window.

You can perform any of the following management tasks:

■ Starting a specific Application Server■ Stopping a specific Application Server■ Redeploying a stopped Application Server■ Terminating a specific Application Server■ Restarting a specific Application Server■ Removing an Application Server■ Adding unmanaged deployments

Starting a specific Application Server

The start operation starts the Application Server and automatically deploys it, if it has not been deployed.


2 Expand the Application Servers node.

3 Right-click the Application Server and select Start.

Stopping a specific Application Server

The stop operation ends running jobs and stops the Application Server, providing a controlled shutdown. You can select options for handling the running jobs.

NOTE You cannot use the stop operation on an Application Server to which a BMC BladeLogic Console is connected.


Redeploying a stopped Application Server



3 Right-click the Application Server and select Stop.

4 On the Stop Application Server dialog, select the method for handling any running jobs:

■ Stop immediately without waiting for running jobs to finish.■ Stop when all running jobs finish.■ Stop when all running jobs finish OR after specified number of minutes,

whichever comes first.

5 Click OK.

Redeploying a stopped Application Server

You can select a stopped Application Server and then redeploy it with a different profile type.



3 Right-click the Application Server and select Redeploy.

4 On the Redeploy Application Server dialog, enter the following

■ Base port: enter a new base port. base_port is a number that is combined with offset values to determine Authentication and Application Server port numbers. For example, the offset for the authentication port is 40 by default. If the base_port is 9500, the authentication port would be 9540.

■ Application Server Type: select the profile type for this Application Server: CONFIGURATION, JOB, NSH_PROXY, or ALL (a combination of all three types). For information on each type, see “Application Server types” on page 96.

NOTE This action is only available for stopped Application Servers.


Terminating a specific Application Server

■ Preserve Existing Data: Check this box if you want to preserve deployment data from the existing deployment. You cannot enter a new Application Server name.

This option automatically migrates any customizations from the existing deployment to the new deployment. In the case where there are options in the customized deployment that do not exist in the new deployment type, those options are ignored.

5 Click OK to validate the information you entered and execute the action on the Application Server launcher.

Terminating a specific Application Server

The terminate operation terminates the Application Server process immediately. This selection is useful in cases where Stop does not work, for example, when the Application Server is hung.



3 Right-click the Application Server and select Terminate.

Restarting a specific Application Server

The Restart operation first stops the Application Server and then starts it again. Use this operation to have configuration changes take effect.

NOTE You cannot use the terminate operation on an Application Server to which BMC BladeLogic Console is connected.

NOTE You cannot use the restart operation on an Application Server to which BMC BladeLogic Console is connected.


Removing an Application Server



3 Right-click the Application Server and select Restart.

Removing an Application Server

The remove operation removes an Application Server from the Application Server Launcher so the Application Server does not automatically restart when the Application Server Launcher starts. This operation can be useful in situations where an Application Server is “missing” and no longer in use, such as when a system has been decommissioned or repurposed.



3 Right-click the Application Server and select Remove.

4 In the Remove Application Server dialog, specify options for handling the Application Server’s deployment directory and the database registration.

5 Click OK. The Application Server is removed from the Application Server Launcher.

Option Description

Preserve deployment Removes the Application Server but leaves its deployment directory unchanged. If you create a new Application Server with the same name, it uses this deployment directory.

Delete deployment Removes the Application Server and deletes its deployment directory.

Preserve server registration

Removes the Application Server but does not delete the database entry for the Application Server. This selection ensures that the Application Server can still be referenced from routing rules. In addition, the Application Server still appears under the Application Server Launchers node

Delete server registration

Removes the Application Server, deletes its database entry, and removes references to the Application Server from routing rules. In effect, this selection removes the Application Server from the BMC BladeLogic environment.


Adding unmanaged deployments

Adding unmanaged deployments

If you have Application Servers which have been removed from the system, but have had their deployments preserved (using the Preserve deployment option), you can add the deployment back into the system without having to restart the launcher.

1 Right-click an Application Server Launcher node and select Add Unmanaged Deployments.

2 On the Add Unmanaged Deployments dialog, select one or more unmanaged deployments you want to add to the Application Server Launcher.

3 Click OK.

The Application Server Launcher added the deployments you selected as managed Server Profiles, enabling you to manage these deployments as you would any other deployment in the system.

Editing the list of roles with Application Server Launcher access

At BMC BladeLogic installation time, only the BLAdmins role is granted authorization to access to the Application Server Launcher. Users with this role can use the Edit Application Server Launcher Roles dialog to grant or deny authorization to other roles.


2 Expand the Application Server Launchers node.

3 Right-click the Application Server Launcher and select Edit Role List.

4 Under Available Roles, select one or more roles you want to have access to the Application Server Launcher. Then click the right arrow to move the role to the Selected Roles list.

To remove roles from the selected list, under Selected Roles, select one or more roles. Then click the left arrow.

NOTE The option is displayed only if there are unmanaged deployments for this Application Server Launcher.


Resetting database passwords for the Application Server

5 When you have finished editing the list, click OK.

Resetting database passwords for the Application Server

In the event that the database user password has been changed, use this procedure to update the password on the Application Server.

1 Execute the following command to set the passwords to a blank value.

2 Run the application server configuration wizard and set the new password on the Database page of the wizard. See “Using the application server configuration wizard to change configuration settings” on page 39.

delete from system_property where name = 'tpasswd.conf_created_on'; update bluser set password = ''; commit;


C h a p t e r 4
4 Administering security
This chapter describes the approaches to security that are possible with BMC BladeLogic, including a discussion of some fundamental security concepts (see “Fundamentals of BMC BladeLogic security” on page 117).

In BMC BladeLogic, the approaches to security vary, depending on which system components are communicating. The following graphic illustrates the various communication legs possible within a BMC BladeLogic system.


See “Security for different communication legs” on page 130 for a discussion of the security approaches that are possible with each leg and references to any implementation procedures required.

A discussion of network security requires many technical terms. This chapter includes links to specialized terms that are defined in the Chapter 9, “Security Glossary”.


Fundamentals of BMC BladeLogic security

Fundamentals of BMC BladeLogic securityTo implement a secure data center automation system, BMC BladeLogic offers the following capabilities:

■ Authentication■ Session layer security■ Impersonation and privilege mapping■ Authorization

Authentication

Authentication is the process of verifying the identity claimed by a system entity. Often that entity is a user, but in some situations the entity is a service. For example, when a user starts the BMC BladeLogic Console, he or she must authenticate with the BMC BladeLogic Authentication Service (one of the services hosted by a BMC BladeLogic Application Server) prior to establishing a client/server session. On the other hand, when an Application Server establishes an authenticated connection with an agent, the identity to be verified is the server hosting the Application Service.

BMC BladeLogic uses different approaches for authentication, depending on the communication leg. For communication between most client tier applications (the BMC BladeLogic Console, Network Shell, or BLCLI) and middle tier applications (Application Server or Network Shell Proxy Server), BMC BladeLogic employs a two-step process. First, client users authenticate with the Authentication Service and acquire a BMC BladeLogic single sign-on (SSO) session credential. Then the client uses that session credential to establish an application session with middle tier services. Written into the session credential are service URLs, which are the identities and addresses of the Application Services and Network Shell Proxy Services that can be accessed using the session credential. For more information on single sign-on, see “Single sign-on” on page 121.

BMC BladeLogic client applications can cache SSO session credentials obtained from the Authentication Service, allowing client users to re-establish new application sessions without re-authenticating. In this way a user’s context can easily be passed between BMC BladeLogic client applications. For example, a user can launch the BMC BladeLogic Console and authenticate. If the user’s session credential is cached and the credential has not expired, the user can then exit the console and start a BLCLI session without authenticating again.

For any entity that communicates directly with agents—including Network Shell clients that access agents without going through a Network Shell Proxy Server—authentication relies on the TLS protocol’s support for client authentication via client-side X.509 certificates.


Session layer security

Session layer security

BMC BladeLogic uses TLS for session layer security across all communications legs. In all contexts (excluding BMC BladeLogic Decision Support for Server Automation), BMC BladeLogic system components employ TLS_RSA_WITH_AES_128_CBC_SHA for the TLS cipher suite, which includes the following capabilities:

■ RSA key negotiation

■ 128-bit AES block encryption algorithm

■ CBC (Cipher Block Chaining) block cipher mode

■ SHA1 HMAC construction for integrity protection.

The BMC BladeLogic Application Server and all client applications use FIPS 140-2 certified modules for cryptographic operations on all transported data.

Communication with middle tier

When a BMC BladeLogic client establishes a TLS connection with a middle tier entity (that is, the Authentication, Application, or Network Shell Proxy Services), the client must validate a certificate from that entity. At installation, middle tier entities are provisioned with self-signed X.509 certificates. (Optionally, you can provision middle tier entities with certificates issued by a CA. For more information, see “Securing communication with CA certificates” on page 224.) When a client first accesses a middle tier entity (by necessity, the Authentication Service) to authenticate and obtain an SSO credential, the client establishes a TLS connection with the Application Server hosting the Authentication Service. In the course of the TLS handshake, the client is presented with the Application Server’s self-signed X.509 certificate. The client cannot recognize the certificate as trusted so the client prompts the user to accept or reject the self-signed certificate. The client application displays the certificate’s content, as well as its SHA1 and SHA256 fingerprints. If the user chooses to trust the self-signed certificate, the certificate is added to the client’s list of trusted certificates and a secure session is established for the client. If the user chooses not to trust the self-signed certificate, the session is terminated.

NOTE Be aware of the following documentation conventions:

■ BMC BladeLogic supports both TLS and its predecessor, SSL. For the sake of simplicity, this document refers only to TLS.

■ When Network Shell connects to a Network Shell Proxy Server, this document refers to that state as Network Shell operating in proxy mode.


Impersonation and privilege mapping

All client services running on a BMC BladeLogic Application Server (Authentication Service, Application Service, and Network Shell Proxy Service) share the same certificate. If your installation employs multiple Application Servers or stand-alone Network Shell Proxy Servers, they too share the same certificate. Once a client application has added the Authentication Service’s certificate to its list of trusted certificates, the user is no longer prompted to trust that certificate when establishing future sessions with any of these other related entities.

A client’s list of trusted certificates are stored in a file written in the Privacy Enhanced Mail (PEM) format. This file is known as a keystore. The keystore resides in a default location, but you can modify that location, as described in “Setting override locations for client SSO files” on page 150. Client applications re-write the keystore file when a trusted X.509 certificate is added to or removed from the trusted certificate store.

Communication with server tier

Self-signed certificates are used to secure communication between entities that communicate directly with agents. These entities could be Application Servers, Network Shell Proxy Servers, repeaters, or Network Shell clients. By default, BMC BladeLogic generates self-signed certificates when an agent is installed on a server. The certificate is stored in a file called certificate.pem in the directory where the agent is installed. If this file is present, it is read every time an Application Server, Network Shell Proxy Server, repeater, or Network Shell client establishes a connection with the agent. If this file is not present, the agent creates one. Self-signed server-side certificates are used to secure the exchange of TLS session keys between agents and entities that communicate with agents.

By default, BMC BladeLogic does not use client-side certificates. However, you can choose to use self-signed client-side certificates for TLS sessions with RSCD agents. To accomplish this, you must provision agents with the SHA1 fingerprints of trusted clients’ self-signed certificates.

Impersonation and privilege mapping

Impersonation (on UNIX) and privilege mapping (on Windows) allow a user to assume an effective user identity and a set of user permissions on remote servers. When a client—that is an Application Server, Network Shell Proxy Server, or Network Shell client—contacts an RSCD agent on a remote server, settings in the exports, user, and users.local configuration files can specify the local user context under which the client’s commands should execute. (For details on this process, see “How BMC BladeLogic grants access to RSCD agents” on page 237.) If entries in the configuration files map the client user to a local user, the agent temporarily acquires the privileges that the managed server’s operating system grants to this local user. In this way BMC BladeLogic takes advantage of the access control mechanisms provided by the remote server’s operating system.


Authorization

If the managed server is a UNIX-style system, the agent fully impersonates a user through a call to the setuid command. If the managed server is a Windows machine, BMC BladeLogic uses a technique called user privilege mapping, which allows the agent to temporarily grant the local user’s group privileges to an unprivileged user account called BladeLogicRSCD. This privilege mapping mechanism allows the agent to acquire the mapped local user’s group privileges without having to access that user’s Windows credentials (user name and password).

If there is no user mapping defined in the exports, user, or users.local configuration files, the system attempts to match the user ID of the incoming user to a user ID defined on the managed server where the RSCD agent is installed. If there is a match, the user is assigned that user’s permissions in the same manner as if there was explicit mapping—that is, on UNIX systems the agent fully impersonates the user through setuid. On Windows systems the agent performs user privilege mapping. For example, if a user authenticates as “joe” and then begins to use Network Shell, the user will take on the privileges and permissions of the user “joe” on the target server. If user equivalency is not possible (that is, joe does not exist on the target server as a user), users are mapped to an underprivileged account (nobody on UNIX or Anonymous on Windows).

For more on impersonation and privilege mapping, see Chapter 5, “Setting up configuration files.”

Authorization

Authorization refers to the process of giving someone access to resources or permissions to perform certain actions. BMC BladeLogic supports authorization via a role-based access control (RBAC) model and a set of very granular access control lists (ACLs). Every system object that you manage with the BMC BladeLogic Console has ACLs defined for it, and those ACLs can grant a range of authorizations to users. You can also define authorizations for Network Shell users if they are configured to communicate through a Network Shell Proxy Server. (Network Shell users communicating directly with agents do not assume any particular role.)

For example, the BMC BladeLogic Console can allow users with an expert role to create component templates and other users with a junior admin role to check for compliance with these templates. Or, a Network Shell user with a junior admin role can be permitted to perform read-only Network Shell commands such as ls, grep, or ps on certain directories within a group of servers, but that same junior administrator cannot make any changes on those servers.

For more on RBAC and authorization in BMC BladeLogic, see the BMC BladeLogic Server Automation User Guide.


Single sign-on

Single sign-onBMC BladeLogic employs a two-stage procedure for authenticating client application users to their respective middle-tier servers. First, client users authenticate with a BMC BladeLogic Authentication Service (one of the services hosted by a BMC BladeLogic Application Server) and acquire an SSO session credential. Then, having acquired a credential, the client application establishes a TLS session with a middle tier service—either an Application Service or Network Shell Proxy Service. Once the TLS session is established, the client presents its SSO session credential to the service, which validates the credential and uses it to establish the identity of the client user. Readers familiar with HTTP cookies may view SSO session credentials as analogous to cookies used to communicate an authenticated identity to a BMC BladeLogic service.

SSO session credentials have a finite lifetime and can be cached in the file system of the client host. BMC BladeLogic Console users can choose whether to cache newly acquired session credentials in a cache file. The session credential cache file can only hold one session credential. This constraint will be relaxed in a future release.

If a client application's credential cache contains an unexpired session credential, that credential can be used to establish a new client/server session without requiring the user to re-authenticate. All BMC BladeLogic client applications except BMC BladeLogic Decision Support for Server Automation can share the same session credential.

The BMC BladeLogic Console has user authentication utilities built into it. The two client command line applications (BLCLI and Network Shell) do not. To connect to a middle tier server, the command line applications require access to a session credential that was acquired previously. BMC BladeLogic provides a command line-based user authentication utility called blcred. Users can authenticate with blcred and acquire session credential for the command line applications.

BMC BladeLogic Decision Support for Server Automation is a web-based application that uses BMC BladeLogic single sign-on functionality in a different manner than other BMC BladeLogic applications. A reports user logs in by providing the user credentials required for his or her authentication type. The reports server uses these credentials to authenticate to the BMC BladeLogic Authentication Service.

Single sign-on functionality supports the following authentication mechanisms:

SRPLDAPRSA SecurIDPKIActive Directory/Kerberos Domain Authentication


SRP

SRP

The secure remote password (SRP) protocol is a non-disclosing authentication protocol (also characterized as a zero-knowledge protocol). This type of protocol allows a client-tier user to prove to an Authentication Service that he or she has knowledge of a password without ever revealing that password to the middle-tier service. Non-disclosing authentication protocols protect against man-in-the-middle attacks, allowing password-based mutual authentication of a client and server.

For SRP, the BMC BladeLogic Authentication Service authenticates client-tier users against a registry of authorized users. In BMC BladeLogic, that registry is a user table in the central Application Server’s database. Information in the user table is derived from the RBAC utility in the BMC BladeLogic Console.

After successfully authenticating the SRP user, the Authentication Service issues the client a session credential. At that point a BMC BladeLogic client application can use the session credential to establish an authenticated secure session with the Application Service or Network Shell Proxy Service identified by the service URLs in the session credential.

LDAP

BMC BladeLogic authentication can be based on Lightweight Directory Access Protocol (LDAP), a protocol for querying and modifying directory entries that are arranged in a hierarchical, tree-like structure.

Client-tier users are correlated to identities maintained in directories on external LDAP servers. When a BMC BladeLogic client-tier user logs in and provides an LDAP “distinguished name” and password, the BMC BladeLogic Authentication Service connects to an LDAP server to authenticate the user. If the LDAP server successfully authenticates the user, the Authentication Service issues the client a session credential. At that point a BMC BladeLogic client application can use the session credential to establish a secure authenticated session with the Application Service or a Network Shell Proxy Service identified by the service URLs in the session credential.

To take advantage of automatic failover, users can set up a list of multiple LDAP servers that provide the same directories of user information. The Authentication Service authenticates users by contacting the first available LDAP server in the list.


RSA SecurID

RSA SecurID

BMC BladeLogic authentication can incorporate RSA’s Authentication Manager to utilize its two factor authentication mechanism. Client-tier users in BMC BladeLogic are correlated to identities maintained within RSA’s Authentication Manager rather than the central Application Server’s RBAC-based database.

SecurID users authenticate by providing a user name and a passcode. The passcode consists of a PIN and the current token code, which is obtained from an RSA SecurID token. If authentication is successful, the Authentication Service issues the client a session credential. At that point a BMC BladeLogic client application can use the session credential to establish a secure authenticated session with the Application Service or Network Shell Proxy Service identified by the service URLs in the session credential.

PKI

BMC BladeLogic authentication can be based public key infrastructure (PKI) for users who present a type of smart card known as a common access card (CAC). Through middleware, a BMC BladeLogic client can access the appropriate certificate and private key on the smart card to authenticate the user. The current status of a certificate can be verified by contacting an OCSP Responder.

While logging into a BMC BladeLogic client, the user must insert a smart card into a card reader and enter a PIN. If the information the user enters is valid and the OCSP Responder verifies the validity of the user’s certificate, the Authentication Service issues the client a session credential. At that point a BMC BladeLogic client application can use the session credential to establish a secure authenticated session with the Application Service or Network Shell Proxy Service identified by the service URLs in the session credential.

Active Directory/Kerberos

Active Directory/Kerberos (AD/Kerberos) authentication integrates BMC BladeLogic with a key distribution center (KDC) to utilize the Kerberos v5 protocol for authenticating client-tier users. AD/Kerberos authentication correlates client-tier users to identities maintained within an Active Directory domain controller rather than the central Application Server’s RBAC-based database.

When an Active Directory domain user chooses to authenticate using AD/Kerberos, Kerberos mediates an authentication exchange between the client (the BMC BladeLogic Console or the blcred utility) and the domain controller as well as between the client and the BMC BladeLogic Authentication Service. After successfully


Domain Authentication

authenticating the domain user, the Authentication Service issues the client a session credential. At that point, a BMC BladeLogic client application can use that session credential to establish an authenticated secure session with the Application Server or a Network Shell Proxy Service identified by the service URLs in the session credential.

AD/Kerberos takes advantage of the Windows single-sign on functionality. A user logging into the BMC BladeLogic Authentication Service authenticates with the same user credential he or she acquires when the logging into the Windows domain.

Although BMC BladeLogic Decision Support for Server Automation does not support AD/Kerberos authentication, it can authenticate AD/Kerberos users who provide a user name, domain, and password (see Domain Authentication).

Domain Authentication

The Domain Authentication solution integrates BMC BladeLogic with Active Directory without requiring users to obtain a Kerberos ticket—that is, a Windows user credential.

In Domain Authentication, BMC BladeLogic clients (the BMC BladeLogic Console or the blcred utility) accept a user’s name, domain, and password. This information is passed to the Authentication Service, which delegates user authentication to the Active Directory domain controller. If the domain controller successfully authenticates the user, the BMC BladeLogic Authentication Service issues the BMC BladeLogic client an SSO session credential. The BMC BladeLogic client application can then use the session credential to establish an authenticated secure session with the Application Server or a Network Shell Proxy Service identified by the service URLs in the session credential.

Domain Authentication provides greater flexibility than AD/Kerberos. A user logging into the BMC BladeLogic Application Server can authenticate with a different user name than the user name used to log into the Windows system hosting the BMC BladeLogic client application. For example, a user can log into Windows as [email protected] and then log into BMC BladeLogic as [email protected].

Authentication profiles

To facilitate single sign-on, BMC BladeLogic clients use authentication profiles, which are collections of information that a BMC BladeLogic client application needs to log into the BMC BladeLogic Authentication Service. An authentication profile identifies the following:


Authentication profiles

■ Application Server host name

■ Listening port for the Authentication Service hosted by the Application Server

■ Authentication protocol: SRP, LDAP, SecurID, PKI, AD/Kerberos, or Domain Authentication

■ Information specific to individual authentication protocols, such as the distinguished name template for LDAP.

A user can define multiple authentication profiles. For example, an organization might employ three instances of BMC BladeLogic—one for Operations, one for QA, and one for Development. If a user wants to connect to all three from the same client application, he or she would need three different authentication profiles, each pointing to a different instance of BMC BladeLogic. In another example, if a user plans to log into the Application Server using various authentication mechanisms, he or she would need an authentication profile for each mechanism.

For BMC BladeLogic Decision Support for Server Automation, users do not define authentication profiles. Instead, when logging on, users simply specify an authentication type. Each reports server always accesses the same Authentication Service, so a user does not have to specify an Application Server or listening port.

Using authentication profiles

When a user launches a BMC BladeLogic client application (except BMC BladeLogic Decision Support for Server Automation), he or she must specify an authentication profile. The client application looks in its cache of session credentials to determine if it holds a current credential that was acquired under the conditions defined by the authentication profile. Each authentication profile specifies an Application Server hosting an Authentication Service, the port used to access the Authentication Service, and an authentication mechanism. If a cached session credential includes information matching these specifications, the client application establishes a connection to the service listed in the session credential. If the client application does not possess an appropriate session credential, the BMC BladeLogic Console prompts the user to log into the Authentication Service identified by the specified authentication profile. In Network Shell or BLCLI, establishment of the client/server session is aborted if the session credential cache does not contain a session credential matching the requirements specified in the authentication profile. The BLCLI or Network Shell user can use the BMC BladeLogic Console or the blcred utility to obtain and cache the appropriate SSO session credential.


Single sign-on session credentials

The BMC BladeLogic Console provides a dialog that allows users to add or delete authentication profiles as well as select an authentication profile for the purpose of logging in. The blcred utility also can be used to add or delete authentication profiles. The BMC BladeLogic command line applications provide various options for identifying an authentication profile by name. The following table summarizes these options. Note that BMC BladeLogic Decision Support for Server Automation does not require authentication profiles so it is not listed in the table below.

For more information on setting up authentication profiles for the BMC BladeLogic Console, see the BMC BladeLogic Server Automation User Guide. For more information on using blcred, see “Using the blcred utility” on page 226. For more information on using environment variables, see “Environment variables” on page 129.

Authentication profiles are stored in a single XML file. Within that file each authentication profile must have a unique name. The XML file resides at a default location, but you can modify that location, as described in “Setting override locations for client SSO files” on page 150.


When an Authentication Service authenticates a user, it issues a session credential to the client application. The BMC BladeLogic Console lets users choose to cache session credentials. The blcred utility always caches any session credential it obtains from the Authentication Service.

BMC BladeLogic clients use session credentials to establish secure sessions with Application Servers and Network Shell Proxy Servers.

A session credential contains the following information:

■ BMC BladeLogic user name

ApplicationMechanisms to Identify Authentication Profile Precedence

BMC BladeLogic Console login dialog

Network Shell(in proxy mode)

environment variable:BL_AUTH_PROFILE_NAME

Takes precedence over secure file setting

secure file setting:auth_profile

BLCLI command line option:-v authenticationProfileName

Takes precedence over environment variable

environment variable:BL_AUTH_PROFILE_NAME



■ Protocol used to authenticate user: SRP, LDAP, SecurID, AD/Kerberos, or Domain Authentication

■ Service URL, which identifies the Authentication Service that issued the session credential, its host address, and its port.

■ Expiration time for session credential

■ Maximum lifetime for session credential

■ Client system’s IP address

■ Authorized roles for user

■ Service URLs of BMC BladeLogic services that the credential can be used to access, such as Application Services and Network Shell Proxy Services. Each of these URLs specifies the type of service, its host address, and its port.

Session credentials are digitally signed by the issuing Authentication Service. A BMC BladeLogic service, upon being presented with a session credential, verifies the digital signature to ensure the credential’s authenticity and integrity. SSO session credentials are cached in a file on the client host. BMC BladeLogic relies on system access controls to restrict access to the session credential cache. The session credential cache file resides at a default location, but you can modify that location, as described in “Setting override locations for client SSO files” on page 150.

On both Windows and UNIX, the credential cache can hold a maximum of one session credential at any time. This restriction will be relaxed in a future release. File system access controls only allow the user for whom the credential was issued to access the credential cache

Unlike other BMC BladeLogic system components, the reports server does not cache the session credential on the client’s system. Each time a user logs into the reports server from a browser, the user provides data required for authentication. The reports server relays this information to the Authentication Service and obtains a session credential for the user. The reports server can potentially hold the user’s session credential even after the user’s connection with the reports server terminates. This allows users to schedule recurring report jobs. BMC BladeLogic Decision Support for Server Automation can automatically renew the user’s session credential without requiring the user to re-authenticate.


Keytab files

Keytab files

If you are using SRP authentication, keytab files are useful when running unattended automation scripts that make use of Network Shell proxy services or make calls to the BLCLI. Keytab files provide the blcred utility with long-term user credentials that can be used to authenticate a user.

In this release, for single sign-on, BMC BladeLogic only supports a keytab file for SRP authentication. The SRP keytab file is called user_info.dat. For instructions on setting up user_info.dat, see “Generating a user information file” on page 230.

Note that BMC BladeLogic also employs a keytab file for its AD/Kerberos implementation. Procedures for the AD/Kerberos implementation explain the use of a keytab file in that context.

Because of their sensitive nature, access to keytab files should be tightly controlled.

RBAC role selection

When a session is established, a user must be assigned to an RBAC role. If a user is authorized for only one role, he or she is assigned to that role after logging into an application. If a user is authorized for multiple roles, the user can interactively select a role while logging into a BMC BladeLogic client application. When using Network Shell or BLCLI, the role may be specified through an environment variable. Network Shell also provides a command called chrole, which lets you change roles after a Network Shell session is established.

When a user is authorized for multiple roles, BMC BladeLogic command line applications can specify a role using a command line option or an environment variable. The following table summarizes the options available to specifying a role.

Application Mechanisms to Specify a Role Precedence

BMC BladeLogic Console GUI dialog, if multiple roles are defined

BLCLI interactive prompts from command line dialog

command line option:-r roleName


environment variable:BL_RBAC_ROLE

Network Shell(in proxy mode)

interactive prompts from command line dialog

environment variable:BL_RBAC_ROLE


Environment variables

Environment variables

BMC BladeLogic provides environment variables that can be used to pass configuration data to the command line client applications (BLCLI and Network Shell) and the blcred utility. BLCLI and blcred also provide command line options for providing the same data. The command line options take precedence over environment variable settings.

To set an environment variable, use a procedure like the following:

% BL_SSO_CRED_CACHE_FILE=userHomeDirectory\bladelogic_alt\bl_sesscc % export BL_SSO_CRED_CACHE_FILE

The following table details the environment variables that can be used with single sign-on functionality.

Environment Variable Description For More Information:

BL_SSO_TRUSTED_CERT_KEYSTORE_FILE

Specifies location of file storing trusted certificates

“Trusted keystore” on page 151

BL_RBAC_ROLE Specifies RBAC role “RBAC role selection” on page 128

BL_SSO_CRED_CACHE_FILE Specifies location of session credential cache file

“Session credential cache file” on page 151

BL_AUTH_PROFILES_FILE Provides location of file containing authentication profile definitions

“Authentication profile file” on page 151

BL_AUTH_PROFILE_NAME Identifies authentication profile to use when authenticating

“Using authentication profiles” on page 125


Security for different communication legs

Security for different communication legsAlthough some aspects of security—session layer security, privilege mapping, and authorization—are consistent throughout BMC BladeLogic, authentication can be configured differently for the various communication legs. The following sections describe security for the following communication legs in BMC BladeLogic:

■ BMC BladeLogic Console to Application Server■ BLCLI to Application Server■ Network Shell to Network Shell Proxy Server ■ Reports client to reports server■ Application Server to agent or repeater■ Network Shell to agent■ Repeater to agent

BMC BladeLogic Console to Application Server

For traffic between the BMC BladeLogic Console and an Application Server, BMC BladeLogic relies on TLS to secure communication between client and server and single sign-on credentials to authenticate client users.

Client users obtain single sign-on credentials by authenticating themselves to the BMC BladeLogic Authentication Service. The BMC BladeLogic Authentication Service supports many authentication mechanisms. SRP is the default user authentication mechanism.

Implementation

A default BMC BladeLogic installation sets up a single sign-on system using SRP authentication and TLS session layer security. Additional configuration is necessary if you want to customize the default behavior or use other authentication protocols. For implementation details, see “Implementing single sign-on” on page 135.

BLCLI to Application Server

For traffic between BLCLI and an Application Server, BMC BladeLogic relies on TLS to secure communication between client and server and single sign-on credentials to authenticate client users.


Network Shell to Network Shell Proxy Server

BLCLI users obtain single sign-on credentials by authenticating themselves to the BMC BladeLogic Authentication Service. The BMC BladeLogic Authentication Service supports many user authentication mechanisms. SRP is the default user authentication mechanism.

The BLCLI does not have a built-in authentication utility. Users can acquire and cache a SSO session credential through the BMC BladeLogic Console and the BLCLI can use that credential. Alternatively, BLCLI users can use a separate user authentication command line utility, blcred, to authenticate themselves to an Authentication Service and acquire a SSO session credential.

Implementation

■ A default BMC BladeLogic installation sets up a single sign-on system using SRP authentication and TLS session layer security. Additional configuration is necessary if you want to customize the default behavior or use other authentication protocols. For implementation details, see “Implementing single sign-on” on page 135.

■ For information on using the blcred utility to obtain session credentials, see “Using the blcred utility” on page 226.

Network Shell to Network Shell Proxy Server

For traffic between a Network Shell client and a Network Shell Proxy Server, BMC BladeLogic relies on TLS to secure communication between client and server and single sign-on credentials to authenticate client users.

Network Shell users obtain single sign-on credentials by authenticating themselves to the BMC BladeLogic Authentication Service. The BMC BladeLogic Authentication Service supports many user authentication mechanisms. SRP is the default user authentication mechanism.

Network Shell does not have a built-in authentication utility. Users can acquire and cache a SSO session credential through the BMC BladeLogic Console. Network Shell can use that credential. Alternatively, Network Shell users can use a separate user authentication command line utility, blcred, to authenticate themselves to an Authentication Service and acquire a SSO session credential.

Implementation

■ A default BMC BladeLogic installation sets up a single sign-on system using SRP authentication and TLS session layer security. Additional configuration is necessary to set up a Network Shell Proxy Service, implement any authentication mechanism other than SRP, or customize SSO behavior. For implementation details, see “Implementing single sign-on” on page 135.


Reports client to reports server

■ For information on using the blcred utility to obtain session credentials, see “Using the blcred utility” on page 226.

Reports client to reports server

A BMC BladeLogic Decision Support for Server Automation client is a web browser that connects to the reports server. Once a user on the reports client is authenticated, the reports server obtains data for reports from the reports data warehouse. BMC BladeLogic Decision Support for Server Automation data is packaged using Cognos Reports.

For traffic between the reports client and the reports server, BMC BladeLogic relies on the HTTPS protocol (HTTP over TLS) to secure communication between the browser and reports server. Users authenticate themselves to the reports server over the HTTPS session.

Server-side certificates

The TLS communication protocol automatically negotiates an encryption algorithm to secure data. Server-side certificates are used during the TLS handshake to establish session keys for encrypting traffic between the web browser and the reports server. By default the reports server uses a self-signed certificate, but you can replace it with a custom certificate. To generate a new certificate, you can use a tool such as OpenSSL.

Authentication

For BMC BladeLogic Decision Support for Server Automation, user authentication functions much like authentication for other BMC BladeLogic applications. After users are authenticated, they are granted session credentials.

BMC BladeLogic Decision Support for Server Automation supports all BMC BladeLogic authentication protocols except AD/Kerberos. Organizations that want Kerberos-based authentication for BMC BladeLogic Decision Support for Server Automation can use the Domain Authentication protocol, which can authenticate AD/Kerberos users when they provide their user name, domain, and password.

Implementation

A default installation of BMC BladeLogic Decision Support for Server Automation sets up a BMC BladeLogic Authentication Service called BMC SARA Authentication. The reports server accesses the BMC SARA Authentication Service to authenticate a user and acquire SSO credentials in the name of the authenticated user. By default


Application Server to agent or repeater

only SRP authentication is enabled on the BMC SARA Authentication Service. Additional configuration is necessary if you want to use an Authentication Server that is not located on the same machine as the reports server. For all implementation details, see the BMC BladeLogic Decision Support for Server Automation User Guide.

Application Server to agent or repeater

For traffic between an Application Server and an agent or repeater, BMC BladeLogic relies on TLS to secure communication and the following options for authenticating the Application Server host to the repeater or agent:

■ Self-signed certificates—Enables agents or repeaters to authenticate Application Servers. To accomplish this, agents and repeaters are provisioned with the SHA1 fingerprints of the Application Servers’ self-signed certificates.

Implementation

For implementation details, see “TLS with client-side certs – Securing a Windows Application Server” on page 202 or “TLS with client-side certs – Securing a UNIX-based Application Server” on page 206. If you want to set up self-signed certificates for a Network Shell Proxy Server, use these procedures as well. The procedure is identical.

■ IP address—Limits incoming traffic for an agent or repeater to IP addresses of specific Application Servers.

Implementation

To implement this approach, modify the exports file on each agent or repeater. For more information, see “Exports file” on page 240.

■ No authentication—By default, when an Application Server connects to an agent or repeater, no authentication occurs.

Implementation

A default installation of BMC BladeLogic provides no authentication for this communication leg.

Network Shell to agent

For traffic between a Network Shell client and an agent, BMC BladeLogic relies on TLS to secure communication and the following options for authenticating the Network Shell client to the agent:


Repeater to agent

■ Self-signed, client-side certs—Enables agents to authenticate Network Shell clients. To accomplish this, agents are provisioned with SHA1 fingerprints of Network Shell clients’ self-signed certificates.

Implementation

For implementation details, see “TLS with client-side certs – Securing a Network Shell client” on page 212.

■ IP address—Limits an agent’s incoming traffic to IP addresses of specific Network Shell clients. (If necessary, Application Servers can also be specified in the same way.)

Implementation

To implement this approach, modify the exports file on each agent. For more information, see “Exports file” on page 240.

■ No authentication—By default, when a Network Shell client connects to an agent, no authentication occurs other than the authentication provided by the underlying operating system of the host where Network Shell is running when a Network Shell user logs in.

Implementation

A default installation of BMC BladeLogic provides no authentication. Instead, this configuration relies on the host operating system of the Network Shell client to authenticate a user.

Repeater to agent

For traffic between a repeater and an agent, BMC BladeLogic relies on TLS to secure communication and the following options for authenticating the repeater host to the agent:

■ Self signed, client-side certs—Enables agents to authenticate repeaters. To accomplish this, agents are provisioned with SHA1 fingerprints of repeaters’ self-signed certificates.

Implementation

For implementation details, see “Implementing Security – Repeater to agent” on page 217.


Implementing single sign-on

■ IP address—Limits an agent’s incoming traffic to IP addresses of specific repeaters. (If necessary, Application Servers and specific clients can be specified in the same way.)

Implementation

To implement this approach, modify the exports file on each agent. For more information, see “Exports file” on page 240.

■ No authentication—By default, when a repeater connects to an agent, no authentication occurs.

Implementation

A default installation of BMC BladeLogic provides no authentication for this communication leg.

Implementing single sign-onTo implement the BMC BladeLogic single sign-on system, you need the following services:

■ Authentication Service—Used for authenticating user identities and issuing session credentials to authenticated users. The Authentication Service processes all user authentication requests—that is, all requests from the BMC BladeLogic Console or the blcred utility. All communication with the Authentication Service occurs over TLS. A standard installation of the Application Server includes an Authentication Service. A standard installation of BMC BladeLogic Decision Support for Server Automation sets up a stand-alone Authentication Server for reports users. SRP authentication is supported by default for all BMC BladeLogic applications.

■ Application Service—Used for accessing the functionality of the BMC BladeLogic Application Server. After a client user authenticates, the client application is issued a session credential. A client application (the BMC BladeLogic Console or the BLCLI) presents the session credential to the Application Service to establish a secure session with one of the targeted services listed within the session credential. All communication with the Application Service occurs over TLS. A standard installation of the Application Server sets up the Application Service.

■ Network Shell Proxy Service—Used for accessing the functionality of a Network Shell Proxy Server. After a client user authenticates, the client application is issued a session credential. A Network Shell client presents the session credential to the Network Shell Proxy Service to establish a secure session with the Network Shell Proxy Server. All communication with the Network Shell Proxy Service occurs over TLS. Some configuration is necessary to set up a Network Shell Proxy Service.


Implementing single sign-on

Use the following master procedure to implement the single sign-on system. Each of the steps in this procedure references a section that describes another procedure.

1 If you want to modify the default behavior of an Authentication Service, see “Configuring the Authentication Service” on page 137.

A default installation of a BMC BladeLogic Application Server sets up an Authentication Service to support single sign-on for BMC BladeLogic client applications.

2 If you want to modify the default behavior of the Application Service, see “Configuring the Application Service” on page 140.

A default installation of a BMC BladeLogic Application Server sets up an Application Service to support single sign-on.

3 If you want to use a Network Shell Proxy Server, see “Configuring the Network Shell Proxy Service” on page 142.

4 If you want to modify the location of any SSO files used by any BMC BladeLogic client application, see “Setting override locations for client SSO files” on page 150.

The files used by the SSO system reside at default locations. If necessary, you can instruct a client application to use different files.

5 If you want to set up OCSP verification of certificates, see “Setting up certificate verification using OCSP” on page 153.

Currently, OCSP verification is only enabled by default for PKI authentication. You can optionally use OCSP verification for Application Servers provisioned with custom certificates.

6 If you want the SSO system to support any authentication protocol other than SRP, see any of the following:

Implementing LDAP authenticationImplementing RSA SecurID authenticationImplementing PKI authenticationImplementing Active Directory/Kerberos authenticationImplementing Domain Authentication


Configuring the Authentication Service


A default installation of a BMC BladeLogic Application Server sets up an Authentication Service to support single sign-on and SRP authentication. Additional configuration is necessary to support other authentication protocols. The Authentication Service runs on the same machine as the Application Server.

There are various options for modifying the standard behavior of an Authentication Service. Use the following procedure to set any of those options.

1 Start the Application Server Administration console (that is, the blasadmin utility), as described in “Starting the Application Server Administration console” on page 45.

2 To specify a listening port other than 9840 for the Authentication Service, enter the following:

set AuthServer AuthSvcPort #

where # is the number of the port. Setting AuthSvcPort to 0 turns off the Authentication Service.

3 To specify the duration of session credentials that the Authentication Service issues, enter the following:

set AuthServer SessionCredentialLifetime #

where # is the lifetime, in minutes, of issued session credentials. By default, the session credential lifetime is 600 minutes (10 hours).

4 To specify the types of authentication mechanisms that are enabled, do any of the following:

■ To enable or disable SRP authentication, enter the following:

set AuthServer IsSRPAuthEnabled true|false

By default this value is set to true.

■ To enable or disable LDAP authentication, enter the following:

set AuthServer IsLdapAuthEnabled true|false

By default, this value is set to false.

■ To enable or disable SecurID authentication, enter the following:

set AuthServer IsSecurIdAuthEnabled true|false




■ To enable or disable PKI authentication, enter the following:

set PkiAuth IsEnabled true|false


■ To enable or disable AD/Kerberos authentication, enter the following:

set AuthServer IsADKAuthEnabled true|false


■ To enable or disable Domain Authentication, enter the following:

set AuthServer IsDomainAuthEnabled true|false


5 To write non-default destination service URLs into a session credential, do any of the following:

■ To override the default Application Service URL, enter the following:

set AuthServer AppServiceURLs serviceURL,...,serviceURL

where serviceURL,...,serviceURL is a list of alternative Application Service’s service URLs. For example:

set AuthServer AppServiceURLs service:appsvc.bladelogic:blsess://host1.bladelogic.com:9841,service:appsvc.bladelogic:blsess://host2.bladelogic.com:9841

Typically, you do not need to change the default Application Server URL. However, if you want to run Network Shell Script Jobs that include BLCLI commands, you can direct these commands to run on a particular Application Server. BLCLI commands used for import or export must run on an Application Server with its type set to CONFIGURATION or ALL. By default BLCLI commands run on the Application Server processing the job. If that Application Server is a JOB type Application Server, it cannot process BLCLI commands used for import/export.

■ To configure the Authentication Service so it does not write any Application Service service URLs into the session credential it issues, enter the following:

set AuthServer AppServiceURLs " "

Note the blank space between the quotation marks.



■ To configure the Authentication Service so it reverts to its default behavior of writing the service URL of the local Application Service into session credentials, enter the following:

set AuthServer AppServiceURLs ""

Note that there is no blank space between the quotation marks.

■ To override the default Network Shell Proxy Service service URL, enter the following:

set AuthServer ProxyServiceURLs serviceURL,serviceURL

where serviceURL,serviceURL is a list of alternative Network Shell Proxy Service’s service URLs. For example,

set AuthServer ProxyServiceURLs service:proxysvc.bladelogic:blsess://host1.bladelogic.com:9842,service:proxysvc.bladelogic:blsess://host2.bladelogic.com:9842

If you are setting up a stand-alone Network Shell Proxy Server, you must identify the URL for the stand-alone server’s Network Shell Proxy Service service URL. For more information on setting up a stand-alone Network Shell Proxy Server, see “Setting up a stand-alone Network Shell Proxy Server” on page 145.

■ To configure the Authentication Service so it does not write any Network Shell Proxy Service service URLs into the session credential it issues, enter the following:

set AuthServer ProxyServiceURLs ""

Note that there is no blank space between the quotation marks.

■ To configure the Authentication Service so it reverts to its default behavior of writing the service URL of the local Network Shell Proxy Service into session credentials (assuming the local proxy service is enabled), enter the following:

set AuthServer ProxyServiceURLs " "

Note the blank space between the quotation marks.

NOTE If you provide a value for ProxyServiceURLs on an Application Server that is defined as type ALL, then any Network Shell commands run by jobs on this Application Server are routed to the Network Shell Proxy Servers identified by ProxyServiceURLs.


Configuring the Application Service

Providing service URLs lets you specify alternative addresses (in the form of service URLs) for an Application Service or Network Shell Proxy Service. This is particularly useful when your installation has a network configuration (for example, a firewall) that requires address translations.

By default the Authentication Service creates a session credential that only includes the service URL for the local Application Service. If the local Network Shell Proxy Service is enabled, the Authentication Service will, by default, include its service URL in the session credential it issues.

Overriding the defaults and specifying empty service URLs results in session credentials with no destination service URLs. When a session credential has no destination service URL, a client cannot use it to access an Application Service or Network Shell Proxy Service.

6 To specify the maximum number of worker threads used for authentication, enter the following:

set AuthServer MaxAuthSvcThreads #

where # is the maximum number of threads that can process requests from clients. By default, the maximum is 5.

7 To specify a time-out for responses from Authentication Service worker threads, enter the following:

set AuthServer AuthSvcSocketTimeout #

where # is the maximum number of minutes to wait for a response from a worker thread. Once the maximum is exceeded, the connection times out. By default the maximum is 1.

8 Restart the Application Server (see “Restarting a specific Application Server” on page 111).


A default installation of BMC BladeLogic sets up an Application Service to support single sign-on. Typically, no additional configuration is necessary.

There are various options for modifying the standard behavior of an Application Service. Use the following procedure to set any of those options.




2 To specify a listening port other than 9841 for the Application Service, enter the following:

set appserver AppSvcPort #

where # is the number of the port. Setting AppSvcPort to 0 turns off the Application Service.

3 To specify whether the client’s IP address included in a session credential should be compared to the IP address of the client that is presenting the credential, enter the following:

set appserver ValidateClientIpAddress true|false

In the command shown above:

■ true means the IP address of the client must match the client’s IP address included in the session credential. If the IP addresses do not match, the client is denied access. By default, this option is set to true.

■ false means the IP address of the client does not have to match the client’s IP address included in the session credential.

Set this value to false only if you are using a network load balancer for your Application Servers or Network Shell Proxy Servers, you are not using a load balancer for the Authentication Service, and a client can access any one of many Application Servers when establishing a session connection.

4 To specify whether the service URL of the Application Service or Network Shell Proxy Service specified in a client’s service request should be compared to the actual service URL of that service, enter the following:

set appserver ValidateRequestURL true|false

In the command shown above:

■ true means the service URL of the Application Service or Network Shell Proxy Service handling the request must match the service URL to which the request was addressed. By default, this option is set to true.

■ false means the receiving service’s URL does not have to match the service URL to which the request is addressed.


Configuring the Network Shell Proxy Service

Always set this value to false if you are using a network load balancer for your Application Servers or Network Shell Proxy Servers, and a client can access any one of many Application Servers when establishing a session connection.



Use this procedure to set up a Network Shell Proxy Server that manages traffic from Network Shell clients. A default installation of a BMC BladeLogic Application Server does not set up a Network Shell Proxy Server.

When setting up a Network Shell Proxy Server, you have the following options:

■ Setting up an Application Server that performs many functions including that of Network Shell Proxy Server. See “Setting Up a Network Shell Proxy Server” on page 142.

■ Setting up an Application Server that functions exclusively as a Network Shell Proxy Server. See “Setting Up a Network Shell Proxy Server” on page 142.

■ Setting up an Application Server that serves as a stand-alone Network Shell Proxy Server, which means it only manages Network Shell traffic and performs no other Application Server functionality. A stand-alone Network Shell Proxy Server cannot access the BMC BladeLogic database. See “Setting up a stand-alone Network Shell Proxy Server” on page 145.

This section also includes a description of how to set up Network Shell Proxy Services for Application Servers that process jobs (see “Setting up Network Shell Proxy Services for Windows user mapping” on page 149). This procedure is only necessary if you want to use Windows user mapping to run jobs that act on Windows target servers.

Setting Up a Network Shell Proxy Server

Use this procedure to configure an Application Server so that it either functions as an Application Server that also manages traffic from Network Shell clients or it only manages Network Shell traffic. Using this configuration, a Network Shell Proxy Server can accommodate all authentication protocols that BMC BladeLogic supports.

If an Application Server experiences high traffic loads that include Network Shell activity, you may want to reduce overall traffic loads by setting up an Application Server that functions exclusively as a Network Shell Proxy Server. It can relieve the overall workload by processing all Network Shell traffic.



1 Start the Network Shell Proxy Server using an application server profile with its Type set so it includes one of the following:

■ ALL—The Application Server performs many functions including Network Shell Proxy Server.

■ NSH_PROXY—The Application Server functions exclusively as a Network Shell Proxy Server.

For more information on application server profiles, see “Configuring multiple Application Servers on the same host” on page 93.


3 If necessary, modify the listening port for the Network Shell Proxy Server by entering the following:

set appserver ProxySvcPort #

where # is the number of the port on the Application Server that listens for Network Shell traffic. By default the Network Shell Proxy Server listens for traffic on port equal to Base Port plus 42. If this value is acceptable, you do not have to set a value for ProxySvcPort.

If a value is not set for ProxySvcPort, the Application Server does not run a Network Shell proxy service.

4 To specify the maximum number of threads that are available to process Network Shell client connections, enter the following:

set appserver MaxNshProxyThreads #

where # is the maximum number of threads. By default this value is set to 5.

Each proxy thread can accommodate multiple Network Shell client connections by switching between connections when there is no traffic on a particular connection. Increasing the maximum number of proxy threads can improve performance for Network Shell users. However, using an excessive number of threads can potentially degrade the performance of a Network Shell Proxy Server.

5 To adjust the performance of proxy threads processing Network Shell client connections, specify a maximum idle time for thread processing. To accomplish this, enter the following:

set appserver NshProxyMaxThreadIdleTime #

where # can be any of the following:



0 – Provides the best thread switching performance. A thread is always available to serve another connection after traffic ends on the current connection.

-1 – Provides the fastest performance for a particular connection. Each thread is dedicated to a single connection so the thread never switches connections.

>0 – Provides a compromise between the two settings described above. A value greater than zero specifies a period, in milliseconds, that a thread should remain idle. While the thread is idle it continues to serve the current connection. When the specified period expires, the thread can switch to another connection. The longer you instruct a thread to be idle, the harder it is for that thread to process more than one connection.

By default NshProxyMaxThreadIdleTime is set to 500 ms.

6 To specify the maximum idle time for a connection with a Network Shell client, enter the following:

set appserver IdleNshProxyPruneTime #

where # is a value in minutes. When there is no traffic over the connection between a Network Shell client and its proxy for this period of time, the connection is automatically closed. By default this value is set to 0, which means the connection is never closed.

7 To specify the timeout settings for obtaining a NSH proxy socket connection to the Application Server, enter the following:

set appserver NshProxySocketConnectTimeout #

where # is a value in seconds.

This value specifies the number of seconds for obtaining a NSH proxy socket connection to the Application Server. By default this value is set to 60 seconds.

8 To specify the timeout settings for NSH proxy socket reads, enter the following:

set appserver NshProxySocketOperationTimeout #

where # is a value in seconds.

This value specifies the number of seconds for NSH proxy socket reads before the socket times out. By default this value is set to 7200 seconds.




10 Set up a client for Network Shell users. See “Setting up a Network Shell Client to run in proxy mode” on page 147. You must repeat this step for every Network Shell client that should communicate with the Network Shell Proxy Server.

11 Assign the NSH_PROXY.Connect authorization to any role that should be used to connect to a Network Shell Proxy Server.

Setting up a stand-alone Network Shell Proxy Server

Use this procedure to configure a stand-alone Network Shell Proxy Server. In this configuration, a deployment of an Application Server is configured to function only as a Network Shell Proxy Server. A stand-alone Network Shell Proxy Server can perform no other Application Server functionality. It cannot even access the BMC BladeLogic database.

To perform this procedure, you must create a Network Shell Proxy Server deployment using the blasadmin utility, and you must perform some configuration on the central Application Server.

1 Install an Application Server on the machine where you want to create a stand-alone Network Shell Proxy Server. When installing, provide the same password for the Application Server’s certificate that you entered when installing the central Application Server. Do not run the Post-Install Configuration wizard.

2 Copy the bladelogic.keystore file from the central Application Server. Using the copied bladelogic.keystore file, replace all occurrences of bladelogic.keystore on the Application Server where you are setting up a Network Shell Proxy Server.

On the central Application Server, you can find bladelogic.keystore at installDirectory/br/deployments/_template/bladelogic.keystore. On the Network Shell Proxy Server, search for all instances of bladelogic.keystore that may exist within installDirectory/br/deployments or any of its subdirectories, such as the _template and _launcher directories.

3 On the Network Shell Proxy Server, use the Application Server Administration console (that is, blasadmin) to create a new deployment of type NSH_PROXY and configure it as a stand-alone Network Shell Proxy Server. To accomplish this, perform the following steps:

A Start blasadmin for the _template deployment by entering the following:


NOTE You cannot use Windows user mapping to grant permissions to a user on a managed server when that user is running a Network Shell client to access a managed server through a stand-alone Network Shell Proxy Server.



B Create a new default deployment of a Network Shell Proxy Server by entering the following:

create new_proxy base_port NSH_PROXY

new_proxy is the name of the new Network Shell Proxy Server you are creating.

base_port is a number that is combined with offset values to determine Authentication and Application Server port numbers. For example, the offset for the authentication port is 40 by default. If the base_port is 9500, the authentication port would be 9540.

C Switch to the newly created deployment by entering the following:

switch new_proxy

D If necessary, modify the listening port for the Network Shell Proxy Server by entering the following:

set appserver ProxySvcPort #

where # is the number of the port on the Application Server that listens for Network Shell traffic. For new deployments of an Application Server, the Network Shell Proxy Server listens for traffic on a port equal to Base Port plus 42. If this value is acceptable, you do not have to set a value for ProxySvcPort.

If a value is not set for ProxySvcPort, the Application Server does not run a Network Shell Proxy Service.

E Indicate that the Network Shell Proxy Server should not contact the BMC BladeLogic database by entering the following command:

set appserver PwdStore file

4 Start the Application Server on the machine where you are setting up a stand-alone Network Shell Proxy Server. See “Starting Application Servers” on page 41.

5 Using the BMC BladeLogic Console, configure the central Application Server by doing the following:

A Select Configuration => Infrastructure Management.

B Expand Application Servers, select the central Application Server, right-click, and select Edit.

C On the Edit Application Server Profile, for ProxyServiceURLs, enter the following:



service:proxysvc.bladelogic:blsess://NSH_proxy_server_host:proxy_svc_port

In this entry NSH_proxy_server_host is the host where you have set up the Network Shell Proxy Server and proxy_svc_port is the port number you defined in step D above (under step 3).

6 Restart the central Application Server (see “Restarting a specific Application Server” on page 111).

7 Set up a client for Network Shell users. See “Setting up a Network Shell Client to run in proxy mode” on page 147. You must repeat this step for every Network Shell client that communicates with the Network Shell Proxy Server.


Setting up a Network Shell Client to run in proxy mode

Use this procedure to configure a Network Shell client so it can run in proxy mode—that is, so it can communicate with servers via a Network Shell Proxy Server. Primarily this procedure consists of some settings you must add to the secure file for a client installation.

Additionally, if you plan to run Network Shell and BLCLI scripts unattended on this client machine, this procedure includes steps to ensure that the scripts have access to valid SSO session credentials. You can use the blcred utility to authenticate a user and acquire a new session credential. For a complete description of blcred, see the blcred man page.

1 Start Network Shell for a client installation and use the secadmin utility to create an entry in the secure file that specifies the following:

■ auth_profile=authProfile, where authProfile is the name of the authentication profile that holds a description of the Authentication Service from which the required session credential should be issued and the authentication mechanism that was used to authenticate the user when the session credential was acquired.

Authentication profiles are defined in the authentication profiles file. The value used for authProfile must match the name of an authentication profile included in that file. Note that the BL_AUTH_PROFILE_NAME environment variable can override the value of this secure file setting.

NOTE To use the blcred utility, you must have the BMC BladeLogic Console installed.



■ auth_profiles_file=fileName, where fileName is the Network Shell-style path to the XML file containing authentication profile definitions, such as /c/Program Files/BMC Software/BladeLogic/version/NSH/br/authenticationProfiles.xml. To create the authenticationProfiles.xml file, you can use the BMC BladeLogic Console to generate authentication profiles on this client machine (see the BMC BladeLogic Server Automation User Guide for details), or you can copy authenticationProfiles.xml from a machine where the console is installed and authentication profiles have already been created. Note that the BL_AUTH_PROFILES_FILE environment variable can override the value of the auth_profiles_file setting in the secure file.

■ appserver_protocol=ssoproxy

For example, the following is a default entry in the secure file on a client machine running Network Shell:

To use the secadmin utility to generate the default entry shown above, enter the following from Network Shell:

secadmin -m default -p 5 -auth_profile QAProfile-auth_profiles_file "/c/Program Files/BMC Software/BladeLogic/version/NSH/br/authenticationProfiles.xml" -appserver_protocol ssoproxy -T encryption_only -e tls

For more information on the secure file, see “Secure file” on page 253. For more information on secadmin, see “Using the secadmin utility” on page 258.


3 To run Network Shell and BLCLI scripts unattended from this client machine, do the following:

A Provide an authentication profile name that can be used to generate an SSO session credential. You can provide an authentication profile name using a command line option for blcred or by defining the BL_AUTH_PROFILE_NAME environment variable.

You can create an authentication profile using blcred or you can create one beforehand using theBMC BladeLogic Console. See the BMC BladeLogic Server Automation User Guide for information on using the BMC BladeLogic Console to set up authentication profiles.

default:protocol=5:auth_profile=QAProfile:auth_profiles_file=/c/Program Files/BMC Software/BladeLogic/version/NSH/br/ authenticationProfiles.xml:appserver_protocol=ssoproxy:tls_mode=encryption_only:encryption=tls



B Provide user information required for the authentication mechanism specified in the authentication profile by doing any of the following:

— Enter command line options to blcred that provide a user name, password, and other information required for the authentication mechanism.

— Let the blcred utility prompt for a user name, password, and other information required for the authentication mechanism.

— For SRP authentication, set up a keytab file called user_info.dat, which stores a user name, password, and role. For information on setting up user_info.dat, see “Generating a user information file” on page 230.

C If the user is authorized for multiple roles, make a role selection by doing one of the following:

— Define the BL_RBAC_ROLE environment variable.

— Let the Network Shell client (operating in proxy mode) and the BLCLI prompt the user to make a role selection after establishing an SSO session.

— Provide a BLCLI command line option that specifies the user’s role.

Setting up Network Shell Proxy Services for Windows user mapping

If you are using automation principals to implement Windows user mapping, your Application Server environment must meet certain criteria. If Application Servers are not correctly configured, jobs acting on target servers may not use Windows user mapping and instead may operate using user privilege mapping, or the job may not run at all.

The following procedure configures an Application Server so that Network Shell traffic will be routed through a Network Shell Proxy Service for any Application Server that is processing jobs. This procedure also requires you to modify the secure file on the Application Server. This procedure is only necessary for Application Servers that handle jobs and are defined as type ALL or JOB.

1 Using the BMC BladeLogic Console, select Configuration => Infrastructure Management.

2 Expand the Application Servers node. Right-click the Application Server you want to modify and select Edit.

3 On the Edit Application Server Profile dialog, provide a value for ProxyServiceURLs.


Setting override locations for client SSO files

This value should identify a Network Shell Proxy Service running in the Application Server’s environment. The value you provide should have the format

service:proxysvc.bladelogic:blsess://nshProxyServerHost:portNumber

In the value shown above, nshProxyServerHost is the fully qualified name of the host where a Network Shell Proxy Server is running; portNumber is the value provided for ProxySvcPort on that Network Shell Proxy Server. By default, ProxySvcPort is set to Base Port plus 42.

4 If necessary, provide values for other Application Server attributes.

For more information, see “Viewing and editing an Application Server’s profile” on page 100.

5 Click OK.


7 Configure the secure file on the Application Server so the appserver_protocol option is set to ssoproxy.

For more information, see “Secure file” on page 253.


The BMC BladeLogic system of single sign-on stores SSO user information in the following files:

Authentication profile fileSession credential cache fileTrusted keystore

Each of these SSO files resides at a default location. If necessary, you can instruct a client application to use a file in a different location. The following procedures let you define override locations for SSO files for the different BMC BladeLogic client applications:

■ Setting SSO file locations for BLCLI■ Setting SSO file locations for Network Shell



Authentication profile file

Authentication profiles are collections of information that a BMC BladeLogic client application needs to log into the BMC BladeLogic Authentication Service. All authentication profiles are stored within a single XML file. Within that file each authentication profile must have a unique name. By default, that XML file resides at installDirectory/br/authenticationProfiles.xml.

To create the authenticationProfiles.xml file, you can use the BMC BladeLogic Console to generate authentication profiles in their default location (see the BMC BladeLogic Server Automation User Guide for details), or you can copy the authenticationProfiles.xml file from a client machine where the console is installed and authentication profiles have already been created.

BMC BladeLogic Decision Support for Server Automation does not need an authentication profile to authenticate users.

Session credential cache file

When an Authentication Service authenticates a user, it issues a session credential. BMC BladeLogic clients use session credentials to establish secure sessions with Application Servers and Network Shell Proxy Servers. BMC BladeLogic Console users can choose to cache session credentials. When authenticating with the blcred utility, session credentials are automatically cached.

A standard BMC BladeLogic installation uses a default location for caching session credentials, as described below.

Trusted keystore

When a BMC BladeLogic client first accesses a middle tier entity (by necessity, the Authentication Service) to authenticate and obtain an SSO credential, the client establishes a TLS connection with that entity. In the course of the TLS handshake, the client is presented with the Authentication Server’s self-signed X.509 certificate. The user is asked to trust the certificate. If the user does, the certificate is added to the client’s list of trusted certificates. This list, which is known as a keystore, resides in a default location, as described below:

Platform Default Location

SolarisLinuxAIXHP-UX

userHomeDirectory/.bladelogic/bl_sessccwhere userHomeDirectory is the home directory of the user running the client application

Windows C:\Documents and Settings\WindowsUserName\Application Data\BladeLogic\bl_sesscc



Setting SSO file locations for BLCLI

To specify alternative locations for SSO files used by the BLCLI, you can either provide command line arguments or define environment variables. A location provided in a command line option takes precedence over a location provided with an environment variable. The following table identifies SSO file locations you can specify for BLCLI and the mechanisms available to provide that information.

For more information on using command line options in BLCLI, see the BLCLI Help. For more information on setting environment variables, see “Environment variables” on page 129.

Setting SSO file locations for Network Shell

To specify alternative locations for SSO files used by Network Shell operating in proxy mode, you can define environment variables or make settings in the client’s secure file. A location provided in an environment variable takes precedence over a secure file setting. The following table identifies SSO file locations you can specify and the mechanisms available to provide that information.

Platform Default Location

SolarisLinuxAIX,HP-UX

userHomeDirectory/.bladelogic/client_keystore.pkcs12.pemwhere userHomeDirectory is the home directory of the user running the client application

Windows C:\Documents and Settings\WindowsUserName\Application Data\BladeLogic\client_keystore.pkcs12.pem

SSO FileMechanisms to Identify Location Precedence

SSO session credentials command line option: -f credentialCacheFileName


environment variable: BL_SSO_CRED_CACHE_FILE

Authentication profile definitions

command line option: -w authenticationProfilesFile


environment variable: BL_AUTH_PROFILES_FILE

Keystore for trusted X.509 certificates

command line option:-x certificateStore


environment variable: BL_SSO_TRUSTED_CERT_KEYSTORE_FILE


Setting up certificate verification using OCSP

For more information on defining settings in the secure file, see “Secure file” on page 253. For more information on setting environment variables, see “Environment variables” on page 129.


The Online Certificate Status Protocol (OCSP) is an Internet standard used to verify the revocation status of X.509 certificates. When a BMC BladeLogic Authentication Server uses this type of verification, it sends a message over HTTP to an OCSP Responder. In response, the OCSP Responder sends back a signed message indicating the certificate’s revocation status.

OCSP checking can be used to improve the security of the overall BMC BladeLogic system. Not only is OCSP checking enabled by default for PKI authentication, it can also be used to further secure communication between components of the BMC BladeLogic system. For example, OCSP can determine the revocation status of customer-provisioned certificates for Application Servers (see “Securing communication with CA certificates” on page 224).

Typically, an Authentication Server uses the information in a certificate to determine which OCSP Responder to access when verifying a certificate. If the certificate includes a valid URL for an OCSP Responder, BMC BladeLogic will contact that URL to verify the certificate. For almost all situations, this default approach is sufficient and users do not have to perform any additional configuration for OCSP checking. You will need to perform additional configuration for OCSP if any of the following conditions are true:

■ In the smart card certificate, there is no URL for the OCSP Responder.

■ You want to override the URL for the OCSP responder in the smart card certificate.

■ You want failover capability that tries a second OCSP Responder in situations when the first OCSP Responder fails.

SSO FileMechanisms to Identify Location Precedence

SSO session credentials environment variable:BL_SSO_CRED_CACHE_FILE

Authentication profile definitions

environment variable:BL_AUTH_PROFILES_FILE

Takes precedence over secure file setting

secure file setting: auth_profiles_file

Keystore for trusted X.509 certificates

environment variable:BL_SSO_TRUSTED_CERT_KEYSTORE_FILE



■ Your OCSP Responder signs OCSP responses with a private key that is unrelated to the Certificate Authority that issued your smart card certificates.

To enhance the security of communication with an OCSP Responder, you may want to enable the OCSP “PKCS” extension. For more information on this capability, see “Enabling or disabling nonce support” on page 154.

Designating another OCSP responder

In some circumstances an organization may want to designate an OSCP Responder, either because a certificate does not include a URL for an OSCP Responder or conditions prevent users from contacting that responder. In such a situation, an organization can use the BMC BladeLogic system to designate another OCSP Responder (see “Configuring an additional OCSP responder” on page 155).

When you use BMC BladeLogic to designate an OCSP Responder, you can set up a failover capability (see “Configuring failover to an OCSP responder” on page 155). The Authentication Server can first attempt to contact the OCSP Responder identified within a certificate. If that attempt fails, the Authentication Server can then contact a secondary responder, identified within the BMC BladeLogic system.

Trusting the response from an OCSP responder

If you have used the BMC BladeLogic system to designate an OCSP Responder, you may need to set up a trust store so the OCSP responses can be validated (see “Setting up a trust store for an OCSP trusted responder” on page 156). In a typical configuration, the Authentication Server contacts the OCSP Responder identified within a certificate. The response BMC BladeLogic receives is signed either by the CA that issued the certificate or a responder designated by the CA. No additional configuration is needed to validate responses sent by the OCSP Responder. However, in some situations, the Authentication Server may be contacting a trusted responder specified within the BMC BladeLogic system. The response from that trusted responder may be using a certificate that was not issued by the CA that originally signed the certificate being verified. In this situation, you must create a trust store used specifically for validating communication with the trusted responder.

Enabling or disabling nonce support

Use this procedure to enable or disable nonce support when contacting OCSP Responders. When nonce is enabled, the Authentication Server encloses a unique value in an OCSP request message. The Authentication Server expects that same value will be returned in the response message from the OCSP Responder. Using nonce helps to thwart replay attacks.



1 On the Authentication Server, start the Application Server Administration console (that is, the blasadmin utility).

2 To enable or disable nonce support, enter the following command:

set OCSP IsNonceEnabled true|false

By default nonce support is disabled.


Configuring an additional OCSP responder

Use this procedure to define an OCSP Responder other than the responder specified in a certificate. This procedure enables the Authentication Server to send the OCSP request to the specified URL.

Once you perform this procedure to define an OCSP Responder, the Authentication Server only contacts the responder identified in this procedure unless you have defined a failover capability (see “Configuring failover to an OCSP responder” on page 155).


2 Specify the additional responder by entering the following command:

set OCSP ResponderUrl responderURL

where responderURL is the URL of the additional responder.

If you set responderURL to an empty string (""), the only URL used to find an OCSP Responder is the URL obtained from the certificate. By default this value is set to an empty string.


Configuring failover to an OCSP responder

Use this procedure to set up failover capability between OCSP Responders. With failover, a second OCSP Responder can be contacted in the event that the first fails for any reason.


2 To enable failover between OCSP Responders, enter the following command:



set OCSP IsFailoverEnabled true

By default this value is set to false and failover is not enabled.

3 To specify which OCSP Responder the Authentication Server should contact first, enter the following command:

set OCSP UseCustomResponder true|false

In this command, true means the Authentication Server first contacts the additional responder you have defined using the BMC BladeLogic system (see “Configuring an additional OCSP responder” on page 155). Setting this value to false means the Authentication Server first contacts the OCSP Responder defined in the certificate.


Setting up a trust store for an OCSP trusted responder

Use this procedure to import a certificate and set up a trust store that is used to verify messages from an OCSP trusted responder.

To establish secure communication with an OCSP trusted responder, a trust store may be necessary in some unusual circumstances. Typically, when the Authentication Server contacts an OCSP Responder, the response is signed with the private key that was also used to sign the certificate being verified. No additional configuration is required. However, in some circumstances an OCSP trusted responder may sign its response with a key derived from some other entity. In this situation, you must set up a trust store used exclusively for validating communication with the OCSP trusted responder. The trust store must contain a certificate that allows the Authentication Server to trust messages from the OCSP Responder.

1 Obtain certificates for all OCSP trusted responders from a certificate authority.

The certificate to be added to the OCSP trust store must be the same certificate that the OCSP Responder inserted into OCSP response messages or the certificate used to issue the certificate that was inserted into OCSP response messages.

2 Import the certificates into a trust store file on the Authentication Server.

NOTE The Application Server only reads its certificate store when it starts up. If you change the certificate trust store, be sure to restart the Application Server.



There are many methods for importing a certificate. One approach is to use Java’s keytool utility, which is available on any machine where the Authentication Server is installed. For example, if you are importing certificates with the Authentication Server’s version of keytool, you might enter a command like the following:

installDirectory/jre/bin/keytool -import -keystore PkiOcspTruststore.jks -storepass ****** -file DODOcspCert.cer -alias ocspt

where -keystore identifies the trust store you are setting up, -file identifies the certificate you are importing, -storepass provides the password for accessing the trust store, and -alias is the name you are assigning to the certificate you are adding to the trust store.


4 Make the OCSP trust store available to the Authentication Server by entering the following command:

set OCSP TruststorePathname certificateStore

where certificateStore is the local path to the OCSP trust store.

5 Provide the password needed to decrypt the certificate by entering the following command:

set OCSP TruststorePassword ******

When you enter the password, it is displayed in clear text. If you attempt to view this password later using the show command, it displays in encoded text.

6 Specify the type of OCSP trust store by entering the following command:

set OCSP TruststoreType trustStoreType

In this command trustStoreType can be either of the following:

■ jks—Trust store uses the “JKS” format.

■ pkcs12—Trust store uses the PKCS12 format.


Enabling or disabling OCSP

Use this procedure to enable or disable OCSP support. Currently, OCSP verification is enabled by default for PKI authentication only.


Implementing LDAP authentication


2 To enable or disable OCSP support, enter the following command:

set OCSP IsEnabled true|false

By default OCSP is enabled.


Implementing LDAP authenticationThe BMC BladeLogic Authentication Service can authenticate users defined in an LDAP registry. To accomplish this, the Authentication Service uses the LDAP Service. When a user logs in and provides an LDAP distinguished name and password, the service uses that information to bind to an external LDAP server—that is, to connect to an LDAP server and authenticate a user. If the bind is successful, the Authentication Service issues a session credential with the user’s distinguished name.

Overview of LDAP configuration tasks

This section provides an overview of the concepts you should understand and the tasks you must perform to set up LDAP-based authentication. See “Configuring LDAP authentication” on page 161 for a step-by-step procedure describing how to set up LDAP authentication.

1 Specify the LDAP servers, including any servers used for high availability purposes.

For more information on high availability, see “High availability configurations” on page 159. For details on how to specify LDAP servers to the Authentication Server, see step 2 on page 161 in “Configuring LDAP authentication” on page 161.

2 Provision the Authentication Server with trusted certificates for all LDAP servers.

For more information, see “Certificate trust store” on page 159. For details on how to configure the Authentication Server to use a trust store for certificates, see step 3 on page 161 in “Configuring LDAP authentication” on page 161.

3 Define a distinguished name template.


High availability configurations

For more information, see “Distinguished names” on page 160. For details on how to set up a distinguished name template for the Authentication Server, see step 4 on page 162 in “Configuring LDAP authentication” on page 161.

4 On the BMC BladeLogic client:

A Set up a distinguished name template, if necessary.

For more information, see “Distinguished names” on page 160 and the BMC BladeLogic Server Automation User Guide.

B Set up an authentication profile for LDAP authentication.

For more information, see “Authentication profiles” on page 124 and the BMC BladeLogic Server Automation User Guide.

5 Cross-register LDAP users with the users in the RBAC user database.

For more information, see “Cross-registering users in the BMC BladeLogic database” on page 160.

High availability configurations

When the Authentication Service needs to authenticate a user by connecting to an LDAP server, you may want to provide a list of LDAP servers that it can potentially contact. Listing multiple servers helps to ensure high availability and failover capability. When a list of multiple LDAP servers is available, LDAP connects to the first functional LDAP server in the list.

Certificate trust store

The Authentication Service uses TLS to encrypt its connection to the LDAP Server.

The Authentication Service sends the user’s credential to the LDAP Server only if it can validate the LDAP server’s certificate. LDAP servers are authenticated via X.509 certificates that LDAP servers provide during the TLS handshake. When configuring LDAP, you must identify a file that contains trusted X.509 certificates. This file is the trust store. When provisioning X.509 certificates for the Authentication Server’s trust store, you can use one of the following approaches:

■ Install certificates for all LDAP servers. You must repeat this procedure each time an LDAP server’s certificate is updated.


Distinguished names

■ Install the certificate of the trusted Certificate Authority that issued certificates to the LDAP servers. Since all CA-issued certificates are trusted, all current and future LDAP certificates are automatically trusted. If the common names (CN) specified in the issued certificates are set to the directory server’s fully qualified domain names, be sure to also set IsHostValidationEnabled to True.

To add X.509 certificates to the Authentication Server’s trust store, use the blcred utility. For more information, see the blcred man page.

Distinguished names

LDAP users are uniquely identified by distinguished names (DN), such as CN=admin, ou=dev, o=bladelogic. To authenticate a user, the Authentication Service requires a full DN and a corresponding password. Rather than entering a full DN, however, users only have to enter the part of a DN that is unique to their accounts. The name the user provides is transformed to a full DN by the use of a distinguished name template. A DN template is a static string containing a {0} substring, which is replaced with the name the user provides when logging in. For example, with a DN template of CN={0}, ou=dev, o=bladelogic, the user only enters a string such as “qatest3”, which replaces the {0} substring. Consequently, the user’s DN becomes CN=qatest3, ou=dev, o=bladelogic.

DN templates can be defined in two places: the Authentication Service and LDAP authentication profiles (described in the BMC BladeLogic Server Automation User Guide). The two templates can be used together or by themselves. For example, the authentication profile DN template might be CN={0}, CN=Users, DC=sub1, and the Authentication Service DN template might be {0}, DC=bladelogic, DC=com. If the user enters “admin” as a user name when logging in, the profile template transforms the name to CN=admin, CN=Users, CN=sub1 before sending it to the Authentication Service. There it is transformed into CN=admin, CN=Users, DC=sub1, DC=bladelogic, DC=com before it is used to contact the LDAP server.

Cross-registering users in the BMC BladeLogic database

Users must be registered in both LDAP registries and BMC BladeLogic’s RBAC-based user database. Cross-registration allows users to be authorized for RBAC roles.

When cross-registering users, be sure to enter the users full distinguished name in both RBAC and the LDAP registry.

Only users authorized to use BMC BladeLogic should be entered into the BMC BladeLogic database. Use RBAC to add users to the BMC BladeLogic database. For information on adding users to RBAC, see the BMC BladeLogic Server Automation User Guide.


Configuring LDAP authentication


Use this procedure to configure the Authentication Service so it can perform LDAP authentication.


2 To identify LDAP servers, including any servers used for high availability configurations, do the following:

A To specify URLs of LDAP servers, enter the following:

set Ldap LdapServerURLs serverList

where serverList is a list of one or more URLs. URLs must point to LDAPv3 servers that support the StartTLS extension. Separate URLs with commas or other delimiters (see “Specifying multiple values for a parameter” on page 50).

B To specify the amount of time to wait for an LDAP server to respond before terminating the connection, enter the following:

set Ldap ConnectionTimeoutMs #

where # is the number of milliseconds to wait. In a high availability configuration, this is the amount of time the service waits for a response from one URL before trying the next URL in the list you provided in step A.

For more information on high availability configurations in LDAP, see “High availability configurations” on page 159.

3 To set up a trust store for X.509 certificates, do the following:

A Provision a trust store with X.509 certificates, either by adding certificates from individual LDAP servers or by importing a certificate from a PEM file. To provision a trust store, use the blcred utility.

B To identify the trust store containing trusted certificates, enter the following:

set Ldap TrustStore certificateStore

where certificateStore is the local path to a trust store.

C To check that the certificate’s common name matches the LDAP server’s fully qualified name, enter the following:

set Ldap IsHostValidationEnabled true



Setting this value to true causes the Authentication Server to reject X.509 certificates if the LDAP server’s fully qualified domain name (FQDN) is not contained in one of the alternative names or the common name (CN). See “Certificate trust store” on page 159 for more information on using this option.

For more information on X.509 certificates and setting up trust stores, see “Certificate trust store” on page 159.

4 To define an LDAP distinguished name template, enter the following:

set AuthServer LdapUserDnTemplate "text {0} text"

where text represents any distinguished name objects that should be included in the template. See “Distinguished names” on page 160 for more information on using a distinguished name template.

5 To enable LDAP authentication, enter the following:

set AuthServer IsLdapAuthEnabled true

By default LDAP authentication is not turned on.


7 Cross-register LDAP users with the users in the RBAC user database. See “Cross-registering users in the BMC BladeLogic database” on page 166.

8 Set up authentication profiles using LDAP authentication on the BMC BladeLogic client. See “Authentication profiles” on page 124 and the BMC BladeLogic Server Automation User Guide.


NOTE The blasadmin utility provides two additional commands for the Ldap component that are not documented here: DefaultUser and DefaultPassword. These commands are only used by BMC BladeLogic Decision Support for Server Automation.


Implementing RSA SecurID authentication

Implementing RSA SecurID authenticationThe BMC BladeLogic Application Server can authenticate users by means of RSA SecurID. If a user is registered in the RBAC system, that user can authenticate by providing his or her user name and passcode, which consists of a PIN and the current token code displayed on an RSA SecurID Token. In some situations the user may be prompted for a new PIN before authentication can occur. If the information the user enters is valid, the Authentication Service issues a session credential to the user.

Configuring a BMC BladeLogic system to support SecurID authentication requires configuration beyond the default setup. The following sections describe those requirements. In addition, you must configure a client to use an authentication profile set up for SecurID authentication. See “Authentication profiles” on page 124 and the BMC BladeLogic Server Automation User Guide for more information on authentication profiles.

Configuring RSA Authentication Manager

BMC BladeLogic assumes you have installed RSA Authentication Manager and are familiar with its functionality. BMC BladeLogic’s integration with SecurID requires the presence of a host configuration file called sdconf.rec. This file provides the address of the RSA Authentication Manager Server and other parameters needed to contact it.

RSA Authentication Agents are used to protect computers and other resources. BMC BladeLogic does not require one to be installed on the Application Server. Users might choose to install an RSA Authentication Agent to help troubleshoot SecurID. If an RSA Authentication Agent is installed, the BMC BladeLogic Authentication Service can share that agent’s configuration file. In that situation you do not have to perform the following procedure.

1 Log in to RSA Authentication Manager and define an Authentication Agent Host using the Application Server’s name or IP address. Then generate a configuration file (sdconf.rec) for the newly created agent.

2 Copy the sdconf.rec file to the BMC BladeLogic Authentication Server.

Configuring SecurID authentication

Use this procedure to configure the Authentication Server so it can perform SecurID authentication.



When you perform this procedure, you do not have to restart the Authentication Server if you are making changes to SecurID configuration. However, if you change the SecurID configuration, you must wait the amount of time specified by ReadConfigInterval (described below) until the new configuration values are read.


2 To enable SecurID authentication, enter the following:

set AuthServer IsSecurIDAuthEnabled true

By default SecurID authentication is not turned on. When set to false, all SecurID login attempts are rejected.

3 Restart the Authentication Server.

4 Provide the path to the RSA Authentication Manager’s configuration file (sdconf.rec) by entering the following:

set SecurID ConfigFilePath filePath

where filePath provides a local path to the sdconf.rec file.

5 Do any of the following to set additional configuration options for SecurID:

■ To instruct the RSA Authentication Agent which IP address to use if the Authentication Server has multiple IP addresses, enter the following:

set SecurID AgentHost iPAddress

■ To specify the interval at which SecurID settings are read, enter the following:

set SecurID ReadConfigInterval interval

where interval is the interval in seconds for reloading the configuration file. The valid range is 0-86400 (24 hours). The default is 600 seconds.

■ To specify the path to the RSA Authentication Manager’s server status file, enter the following:

set SecurID StatusFilePath filePath

where filePath is a local path to that file. If you do not provide a path, a new file is created in BMC BladeLogic’s /br directory. The default file name is JAStatus.1.

■ To specify the path to the RSA Authentication Manager’s optional configuration file (sdopts.rec), enter the following:



set SecurID OptionsFilePath filePath>

where filePath is a local path to that file. This configuration file is used to configure a manual authentication load balancing policy.

■ To specify the path to the RSA Authentication Manager’s node secret file, enter the following:

set SecurID NodeSecretFilePath filePath

where filePath is a local path to that file. This file is created automatically the first time the Authentication Service successfully connects to the RSA Authentication Manager. The default file name is securid. If you do not define a path, the file is automatically created in BMC BladeLogic’s /br directory. If multiple Application Servers are running on the same host, they should all use the same node secret file.

If you are running other applications that also use RSA authentication, they may need to share the same node secret file that the Application Server is using. When multiple applications share a node secret file, you must ensure that the Application Server can access the node secret file by granting the appropriate operating system-level permissions to the file. On UNIX, you must grant permission to the bladmin user; on Windows you must grant permission to SYSTEM. Other applications may have similar access requirements.

■ To specify the path to the SecurID log file, enter the following:

set SecurID LogFilePath filePath

where filePathis local path to the log file.

■ To turn on logging, enter the following:

set SecurID LogToFile true | false

If set to true, the RSA SecurID module creates log entries in the file specified by the LogFilePath option. By default this option is set to false.

■ To set the logging level, enter the following:

set SecurID LogLevel OFF | DEBUG | INFO | WARN | ERROR | FATAL

By default this option is set to OFF.



6 Cross-register users in both the SecurID user registry and the RBAC user data base. See “Cross-registering users in the BMC BladeLogic database” on page 166.

7 Set up authentication profiles using SecurID authentication on the BMC BladeLogic client. See “Authentication profiles” on page 124 and the BMC BladeLogic Server Automation User Guide.


Users must be registered in both the SecurID user registry and the BMC BladeLogic RBAC-based user database. Cross-registration allows users to be authorized for RBAC roles.

Only users authorized to use BMC BladeLogic should be entered into the BMC BladeLogic database. Use RBAC to add users to the database. For information on adding users to RBAC, see the BMC BladeLogic Server Automation User Guide.

BMC BladeLogic documentation assumes you know how to add users to the SecurID user registry.

Implementing PKI authenticationThe BMC BladeLogic Authentication Server can use public key infrastructure (PKI) to authenticate users who present a type of smart card known as a common access card (CAC). Through ActiveClient middleware, a BMC BladeLogic client can access the appropriate certificate and private key on the smart card to authenticate the user.

To verify whether a certificate is currently valid, the Authentication Server can access an OCSP Responder. By default, OCSP verification is enabled for PKI authentication. For more information on setting up OCSP, see “Setting up certificate verification using OCSP” on page 153.

While logging into a BMC BladeLogic client, the user must insert a smart card into a card reader and enter a PIN. If the information the user enters is valid and the OCSP Responder verifies the validity of the user’s certificate, the Authentication Service issues the client a session credential.

NOTE SecurID configuration settings are stored in installDirectory/br/deployments/deploymentName/options/securid-options.properties. You can manually edit this file to specify additional debug options, such as RSA_ENABLE_DEBUG=YES. Refer to RSA’s product documentation for a more complete description of supported settings.


Configuring PKI authentication

BMC BladeLogic does not provide a default set of trusted CA certificates for use with PKI authentication. If you are implementing PKI, you must obtain certificates yourself from a CA.


Use this procedure to configure the Authentication Server so it can perform PKI-based authentication. Note that many steps in this procedure reference a sub-section that describes another procedure.


2 To enable PKI authentication, enter the following:

set PkiAuth IsEnabled true

By default PKI authentication is not turned on. When set to false, all PKI-based login attempts are rejected.

3 To register users by the common name portion of the subject name within a user’s certificate, enter the following:

set PkiAuth useCommonName true

By default cross-registration by common name is not turned on; users must be cross-registered according their full distinguished name (DN).

If you choose to cross-register users by their common name, you cannot also cross-register users by their distinguished name. You must choose between the common name or the distinguished name approach.

For more information on registering users, see “Cross-registering users in the BMC BladeLogic database” on page 166.

4 Set up a trust store for a PKI certificate. See “Setting up a trust store for PKI authentication”.

NOTE In this release, PKI authentication is not supported for Windows 64-bit platforms.



5 To configure certificate verification using an OCSP Responder, see “Setting up certificate verification using OCSP” on page 153. In most situations, OCSP verification is enabled for PKI authentication and no additional configuration is necessary.

6 Cross-register users in both the user registry maintained for smart card holders and the RBAC user data base. See “Cross-registering users in the BMC BladeLogic database” on page 169.

7 Set up authentication profiles using PKI authentication on the BMC BladeLogic client. See “Authentication profiles” on page 124 and the BMC BladeLogic Server Automation User Guide.

Setting up a trust store for PKI authentication

Use this procedure to import a certificate into a trust store and then make that trust store available to the Authentication Server.

1 If you haven’t already done so, obtain the certificate for the certificate authority that issued the certificates on the smart card.

2 Import the certificate into a trust store file on the Authentication Server.

There are many methods for importing a certificate. One approach is to use Java’s keytool utility, which is available on any machine where the Authentication Server is installed. For example, if you are importing a certificate with the Authentication Server’s version of keytool, you might enter a command like the following:

installDirectory/jre/bin/keytool -import -keystore PkiTruststore.jks -storepass ****** -file DODJITCCA_19.cer

where -keystore identifies the trust store you are setting up, -storepass provides the password for accessing the trust store (needed later in step 5), and -file identifies the certificate you are importing.


4 Make the trust store available to the Authentication Server by entering the following command:

set PkiAuth TruststorePathname certificateStore




where certificateStore is the local path to the trust store.

5 Provide the password needed to decrypt the certificate by entering the following command:

set PkiAuth TruststorePassword ******

Enter the password using clear text. The Application Server Administration console encodes the password that is displayed.

6 Specify the type of trust store by entering the following command:

set PkiAuth TruststoreType trustStoreType

In this command trustStoreType can be either of the following:

■ jks—Trust store uses the “JKS” format.

■ pkcs12—Trust store uses the PKCS12 format.



Users must be registered in both the registry maintained for smart card holders and the BMC BladeLogic RBAC-based user database. Cross-registration allows users to be authorized for RBAC roles.

By default, users are registered by their full distinguished name. Optionally, users can be registered by just the common name portion of the subject name within their certificate. For details on this option, see “Configuring PKI authentication” on page 167.

Only users authorized to use BMC BladeLogic should be entered into the BMC BladeLogic database. Use RBAC to add users to the database. For information on adding users to RBAC, see the BMC BladeLogic Server Automation User Guide.

BMC BladeLogic documentation assumes you know how to add users to the registry of smart card holders.


Implementing Domain Authentication

Implementing Domain AuthenticationThe BMC BladeLogic Authentication Service can authenticate users via Windows Active Directory user credentials. Users provide a user name, domain, and password. The Authentication Service uses that information to authenticate the user to the Active Directory KDC, which relies on the Active Directory registry to store the names and passwords of registered users within its Kerberos realm. In Windows, a Kerberos realm is an Active Directory domain.

Configuring a BMC BladeLogic system to support Domain Authentication requires configuration beyond the default setup. For details on this process, see “Configuring BMC BladeLogic for Domain Authentication” on page 171.

After you configure BMC BladeLogic for Domain Authentication, you must configure a client to use an authentication profile set up for Domain Authentication. See “Authentication profiles” on page 124 and the BMC BladeLogic Server Automation User Guide for more information on authentication profiles.

The following sections provide instructions for setting up Domain Authentication at installations where AD/Kerberos authentication is not already being used for BMC BladeLogic. If you have already set up AD/Kerberos authentication for BMC BladeLogic, use your existing Kerberos configuration files and modify as necessary based on the descriptions in this section.


Sample domain structure

Sample domain structure

The following diagram shows a sample domain structure containing a parent domain and two child sub-domains. This is an example. Your domain structure may be simpler or more complex. The sample names shown in this example are used in many procedures that relate to the Domain Authentication and AD/Kerberos solutions.

Configuring BMC BladeLogic for Domain Authentication

Use this procedure to configure BMC BladeLogic so users can authenticate to the Authentication Service by providing an AD/Kerberos user name, domain, and password.

The following is a master procedure. Each of the steps in this procedure references a sub-section that describes another procedure.

NOTE When you specify a domain name in any of the following steps, you must use UPPER CASE LETTERS. You may want to review the diagram in “Sample domain structure” on page 171 for an overview of the domain names and host names used in the examples in this section.



1 Obtain the host names for Active Directory KDCs. See “Locating Active Directory KDCs”.

2 Create the blappserv_krb5.conf file, which defines Active Directory domains and servers. See “Creating the blappserv_krb5.conf file” on page 173.

3 Create the blappserv_login.conf file, which provides necessary authentication information. See “Creating the blappserv_login.conf file” on page 174.

4 Configure the Authentication Service to support Domain Authentication. See “Defining Authentication Service settings for Domain Authentication” on page 175.

5 Add user names based on Kerberos naming conventions to the RBAC user database. See “Cross-registering users in the BMC BladeLogic database” on page 176.

6 Add users to built-in roles. See “Logging on using default users and roles” on page 177.

7 Set up authentication profiles using Domain Authentication on the BMC BladeLogic client. See “Authentication profiles” on page 124 and the BMC BladeLogic Server Automation User Guide.

Locating Active Directory KDCs

Use this procedure to obtain the host names for Active Directory KDCs. Later in the configuration process, you will need these host names.

From a command line, enter the following:

nslookup -type=srv _kerberos._tcp.REALM

where REALM is a Windows domain name.

Look up the KDCs for each realm against which users authenticate. If multiple realms are used, such as SUB1.DEV.MYCOMPANY.COM and SUB2.DEV.MYCOMPANY.COM, also look up the KDC for the parent realm (DEV.MYCOMPANY.COM). For example:

nslookup -type=srv _kerberos._tcp.SUB1.DEV.MYCOMPANY.COMnslookup -type=srv _kerberos._tcp.SUB2.DEV.MYCOMPANY.COMnslookup -type=srv _kerberos._tcp.DEV.MYCOMPANY.COM

The Active Directory KDC’s host name is reported as the value of service (UNIX) or svr hostname (Windows). For example:

service = 0 100 88 kdc.sub2.dev.mycompany.com



Ignore the numbers before the host name.

Creating the blappserv_krb5.conf file

Use this procedure to create a blappserv_krb5.conf file. This file configures Kerberos so it can communicate with the Active Directory server or servers.

When you create a blappserv_krb5.conf file, you must define a default realm. When Domain Authentication users log in and they do not provide a fully qualified user name, they are authenticated as members of the default realm.

1 Create a text file and add the following content to it:

USERS_REALM is the realm where users are defined. USERS_REALM_KDC is the host name for the KDC servicing that realm. If multiple KDCs are running, list all of those KDCs. If users are defined in multiple realms, create a separate stanza for each realm.

In the “domain_realm” section, USERS_DOMAIN provides DNS names. A period before a DNS name indicates you are mapping every system with a DNS name ending with that value to a corresponding Kerberos realm. For example:

To obtain host names for any of the KDCs listed in this file, use the nslookup command, as described in “Locating Active Directory KDCs” on page 172.

NOTE When identifying servers in the blappserv_krb5.conf, do not use IP addresses. The Application Server must be able to resolve DNS names of Active Directory servers.

[libdefaults]ticket_lifetime = 6000default_realm = USERS_REALM

[realms]USERS_REALM = {kdc = USERS_REALM_KDC:88}[domain_realm].USERS_DOMAIN = USERS_REALM

.sub1.dev.mycompany.com = SUB1.DEV.MYCOMPANY.COM


.dev.mycompany.com = DEV.MYCOMPANY.COM




■ On a UNIX-style system, save the file to the InstallDirectory/NSH/br directory with the name:

blappserv_krb5.conf

For example, if BMC BladeLogic is installed in the default location, the file should be located as follows:

/opt/bmc/BladeLogic/version/NSH/br/blappserv_krb5.conf

■ On Windows, save the file to the InstallDirectory\NSH\br directory with the name:

blappserv_krb5.conf


C:\Program Files\BMC Software\BladeLogic\version\NSH\br\blappserv_krb5.conf

Creating the blappserv_login.conf file

You must create a blappserv_login.conf file. This files provides necessary Kerberos authentication information.

1 Create a text file and add the text shown below to this file.


■ On a UNIX-style system, save the file to the InstallDirectory/NSH/br directory with the name blappserv_login.conf. For example, if the Authentication Server is installed in the default location, the file should be located as follows:

/opt/bmc/BladeLogic/version/NSH/br/blappserv_login.conf

■ On Windows, save the file to the InstallDirectory\NSH\br directory with the name blappserv_login.conf. For example, if the Authentication Server is installed in the default location, the file should be located as follows:

com.bladelogic.auth.service.ADKerberosPasswordLogin {com.sun.security.auth.module.Krb5LoginModule requireddoNotPrompt=falseuseTicketCache=falsedebug=false;};



C:\Program Files\BMC Software\BladeLogic\version\NSH\br\blappserv_login.conf

Defining Authentication Service settings for Domain Authentication

Use this procedure to define settings for the BMC BladeLogic Authentication Service so it can use the Kerberos configurations you set up in previous procedures. To perform this procedure, you must use the Application Server Administration console.

1 Start the Application Server Administration console by doing one of the following:


./bin/blasadmin




\bin\blasadmin.bat


2 To allow users to log in using Domain Authentication, enter the following:

set AuthServer isDomainAuthEnabled true

By default this value is set to false.

3 To enable the blappserv_krb5.conf file, enter the following:

set AuthServer AuthSvcKrb5Config fileName

where fileName is the name of the blappserv_krb5.conf file. This file is essential for supporting Kerberos.

By default AuthSvcKrb5Config is set to a value of blappserv_krb5.conf. You can skip this step unless you choose to use a different file name.

4 To enable the blappserv_login.conf file, enter the following:

set AuthServer AuthSvcKrb5LoginConfig fileName



where fileName is the name of the blappserv_login.conf file. This file is essential for supporting Kerberos.

By default AuthSvcKrb5LoginConfig is set to a value of blappserv_login.conf. You can skip this step unless you choose to use a different file name.



Users must be registered in both Active Directory and BMC BladeLogic’s RBAC-based user database. Cross-registration allows users to be authorized for RBAC roles.


BMC BladeLogic documentation assumes you know how to add users to Active Directory.

Requirements for User Names

When using AD/Kerberos to authenticate end users, you must ensure that domain user names stored in RBAC are fully qualified and that those names match the user names stored in the Active Directory.

Each BMC BladeLogic user name must be in the form:

USER@DOMAIN

where DOMAIN is the domain the user is registered in.

For example, if you are using RBAC or the bladduser utility to add a new BMC BladeLogic user, you would fill in the name field with a value such as:

[email protected]

rather than filling in the name field with a value such as:

mary

Note that the user name [email protected] is a different user name than than mary or [email protected].

The user’s BMC BladeLogic user name must match the user’s fully qualified Active Directory user name.


Implementing Active Directory/Kerberos authentication

BMC BladeLogic provides a BLCLI command, RBACRole:syncUsers, that you can use to synchronize group information in Active Directory with role information in RBAC. For more information on this command, see the BLCLI help.

Logging on using default users and roles

The BMC BladeLogic user database comes pre-provisioned with two default SRP users: RBACAdmin and BLAdmin. These default users are assigned to the default roles RBACAdmins and BLAdmins, respectively. If the BMC BladeLogic administrator intends to support AD/Kerberos authentication exclusively and disable SRP user authentication, then, prior to disabling SRP, the administrator should log in as a user authorized for the RBACAdmins role and ensure that each of the four built-in roles—RBACAdmins, BLAdmins, GlobalReportViewers, and GlobalReportAdmins—has at least one registered domain user assigned to that role. Otherwise, when SRP authentication is disabled, no user will be able to access the built-in roles.

In a default installation, the RBACAdmins role has the authorizations necessary to manage users and roles. If you are using that default setup, you can simply assign a fully qualified domain user name (for example, [email protected]) to the RBACAdmins role. In this example, the user would also have to be registered in the Active Directory user registry for the domain SUB2.DEV.MYCOMPANY.COM.

The same issue applies to the BLAdmins role, which has built-in authorizations to change permissions for all system objects in BMC BladeLogic, the GlobalReportAdmins role, which has built-in authorizations to see data for all BMC Service Automation Reporting and Analytics sites, and the GlobalReportViewers role, which has read access to all reports at all sites in a BMC BladeLogic installation. To allow a user to log into the BLAdmins role, you must use RBAC to add a fully qualified user name to the BLAdmins role. To allow a user to log into the GlobalReportAdmins role, you must use RBAC to add a fully qualified user name to the GlobalReportAdmins role. To allow a user to log into the GlobalReportViewers role, you must use RBAC to add a fully qualified name to the GlobalReportViewers role.

Implementing Active Directory/Kerberos authentication

The BMC BladeLogic Authentication Service can authenticate users via Windows Active Directory single sign-on credentials or, equivalently, a Kerberos user’s ticket granting ticket (TGT). Windows single sign-on is based on the Kerberos authentication protocol. Windows Server 2003/2008 implements a Kerberos Key


Overview of AD/Kerberos configuration tasks

Distribution Center (KDC) as one of its default domain services. This Windows Server KDC, referred to as the Active Directory KDC, relies on the Active Directory registry to store the names and passwords of registered users within its Kerberos realm. In Windows single sign-on, a Kerberos realm is an Active Directory domain.

When a registered domain user logs into a client platform (Windows or UNIX), the login client sends a request to the Active Directory KDC for a Kerberos Ticket Granting Ticket (TGT). The request carries encrypted material that allows the KDC to authenticate the request. The keying material used to generate and verify the request is derived from the user’s password. After validating the request, the Active Directory KDC responds by sending the client a limited-lifetime (typically 10 hours) user credential, which the client stores in a local credential cache. This credential consists of a service ticket to the ticket granting service (the Ticket Granting Ticket) and an associated ticket granting service session key. In the context of Active Directory, the Kerberos TGT is also referred to as the domain user credential.

BMC BladeLogic end users can use their AD/Kerberos credentials to authenticate themselves to the BMC BladeLogic Authentication Service. When a BMC BladeLogic authentication user interface (either the authentication user interface built into the BMC BladeLogic Console or the blcred utility) selects an AD/Kerberos authentication profile, it employs the end user's AD/Kerberos credentials to conduct a Kerberos protocol exchange with the Authentication Service. In this exchange, the Active Directory domain controller or Kerberos KDC mediates the authentication of the end user to the BMC BladeLogic Authentication Service. Upon successful Kerberos authentication of the end user, the Authentication Service issues the authentication user interface a single sign-on credential, which BMC BladeLogic clients can use to establish secure sessions with the BMC BladeLogic Application Service or Network Shell Proxy Service.

Configuring BMC BladeLogic authentication user interfaces and the Authentication Service to support AD/Kerberos authentication requires additional configuration beyond the default configuration of clients and servers. The following sections describe those configuration tasks.


This section provides a quick overview of the tasks you must perform to set up a BMC BladeLogic environment that supports user authentication via AD/Kerberos user credentials:

1 On the Active Directory KDC:

A Create a user account for the BMC BladeLogic Authentication Service.

B Export the blauthsvc.keytab file. Give this file and the SPN to the administrator of the Application Server hosting the BMC BladeLogic Authentication Service.



These tasks are described in detail in “Registering an Authentication Service in an Active Directory Domain” on page 180.

2 On the BMC BladeLogic Application Server:

A Put the blauthsvc.keytab file in the correct directory.

B Locate the Active Directory KDC for the service principal’s realm.

C Create the blappserv_krb5.conf file.

D Create the blappserv_login.conf file.

E Define Authentication Service settings to support AD/Kerberos.

F Add users to the BMC BladeLogic RBAC user database, making sure each user name includes the user’s Active Directory domain ([email protected]).

G If you are using Network Shell to communicate directly with agents, set up a Network Shell Proxy Server.

These tasks are described in detail in “Configuring an Authentication Service for AD/Kerberos authentication” on page 184.

3 On the BMC BladeLogic client:

A Windows only: Update the Kerberos Registry Settings.

B Create the blclient_login.conf file.

C Locate the Active Directory KDC for the client’s realm.

D Create a blclient_krb5.conf file.

E Update the config.properties file.

F UNIX only: Obtain a ticket granting ticket (TGT) for the client.

G Create an authentication profile using AD/Kerberos authentication.

These tasks are described in detail in “Configuring a BMC BladeLogic Client for AD/Kerberos authentication” on page 194.


Registering an Authentication Service in an Active Directory Domain


This section provides procedures that an administrator of an Active Directory KDC can use to register the Authentication Service associated with a BMC BladeLogic Application Server in an Active Directory domain. Refer to this section only if you want to employ AD/Kerberos user credentials to authenticate BMC BladeLogic end users to the BMC BladeLogic Authentication Service.


1 Review the required utilities that must be installed on the Active Directory server. For more information, see “Requirements for the Active Directory server” on page 180.

2 Create an Active Directory user account for the Authentication Service associated with an Application Server. For more information, see “Creating a user account in the domain of the Application Server” on page 181.

3 Export the user account and SPN information into a keytab file. After you create the keytab file, you must give this file and the SPN to the administrator of the Application Server. For more information, see “Exporting the keytab file” on page 181.

Requirements for the Active Directory server

The following utilities must be installed on the Active Directory server:

■ ktpass.exe (BMC BladeLogic recommends using version 5.2.3790.2732)■ setspn.exe

For Windows 2003, both of these utilities are provided as part of the Support Tools Service Pack 1. For Windows 2008 these utilities are provided as part of the core operating system.




Creating a user account in the domain of the Application Server

Use this procedure to create a user account for the Authentication Service in the domain (that is, the Kerberos realm) where the BMC BladeLogic Application Server is running.

1 On a Windows 2003 or 2008 Server, from the Start menu, select Programs => Administrative Tools => Active Directory Users and Computers. The Active Directory Users and Computers window displays.

2 In the left column, expand the domain name for the BMC BladeLogic Application Server so that it displays the Users folder.

3 Right click the Users folder and select New => User. The New Object – User wizard displays.

4 For First name, enter a name, such as blauthsvc. For User logon name, enter the name again. In this example, you would enter blauthsvc again.

5 Click Next. The second screen of the wizard displays, requesting password information.

6 For Password, set the password to whatever you want. Be sure to use a password that conforms to the Active Directory password policy. Then check Password never expires.

7 Click Next. The final summary page of the wizard displays.

8 Click Finish to dismiss the wizard.

Exporting the keytab file

Use this procedure to export a keytab file from the Active Directory server. You must give the keytab file to the administrator of the BMC BladeLogic Application Server.

The Application Server needs a keytab file because it holds keying material used for decrypting and validating the service ticket that the domain controller (that is, the KDC) issues to the client. When requesting a service ticket from the KDC, the client identifies the targeted server (that is, the Application Server) by the SPN. Because Kerberos employs mediated authentication for the mutual authentication of both the client and server, both the client and server must be registered with the KDC. The user is registered under a domain user name. The server is registered under an SPN.



The procedure varies depending on what version of Windows and what service pack you are using. If you are using a Windows 2008 without Service Pack 2, you must work around a Microsoft defect by using a different setup. This defect is corrected in Service Pack 2 for Windows 2008, and it does not affect Windows 2003.

Windows 2003 and Windows 2008 with Service Pack 2

1 Use the ktpass command-line utility to export the keytab file using the command shown below. Run this utility in a directory suitable for writing a file with sensitive data.

ktpass -out blauthsvc.keytab -princ blauthsvc/instance@DOMAIN -mapuser blauthsvc@DOMAIN +rndPass -minPass 33

In this command, instance is the instance of this Application Server (typically a host name) and DOMAIN is the realm where the Application Server is running. (This is the realm/domain that appeared next to the User logon name when you created the blauthsvc user.)

For example, if you used the example names shown in “Sample domain structure” on page 171, you would enter:

ktpass -out blauthsvc.keytab -princ blauthsvc/[email protected] -mapuser [email protected] +rndPass -minPass 33

2 Give the following to the administrator of the Application Server:

■ The newly created blauthsvc.keytab file. The blauthsvc.keytab file contains key material, so transfer it between systems with care. The Authentication Service needs this keytab to allow users to authenticate.

■ The service principal name used in the keytab file. For example:

blauthsvc/app4

■ The name of the domain (that is, the Kerberos realm) for the Application Server. For example:

SUB2.DEV.MYCOMPANY.COM



Windows 2008 without Service Pack 2

1 On the command line, use the setspn utility to create a service principal name for the BMC BladeLogic Authentication Service by entering the following command:

setspn -A blauthsvc/instance blauthsvc

In this command, instance is the instance of this Application Server (typically a host name). For example, you can enter the following command:

setspn -A blauthsvc/app4 blauthsvc

2 Use the ktpass command-line utility to export the keytab file using the command shown below. Run this utility in a directory suitable for writing a file with sensitive data.

ktpass -out blauthsvc.keytab -princ blauthsvc@DOMAIN -mapuser blauthsvc@DOMAIN +rndPass -minPass 33

For example, if you used the example names shown in “Sample domain structure” on page 171, you would enter:

ktpass -out blauthsvc.keytab -princ [email protected] -mapuser [email protected] +rndPass -minPass 33

Note that the -princ parameter identifies a user principal (blauthsvc) rather than a service principal name.

3 Give the following to the administrator of the Application Server:

■ The newly created blauthsvc.keytab file. The blauthsvc.keytab file contains key material, so transfer it between systems with care. The Authentication Service needs this keytab to allow users to authenticate.

■ The user principal name used in the keytab file. For example:

blauthsvc

NOTE The remainder of this guide assumes you are using a service principal name when setting up AD/Kerberos authentication. When this guide provides examples of a service principal name, it uses blauthsvc/app4. However, if you are using Windows 2008 without Service Pack 2, you must work around the Microsoft defect by using a user principal name instead of a service principal name. In that case, you should use blauthsvc instead of blauthsvc/app4.


Configuring an Authentication Service for AD/Kerberos authentication

■ The name of the domain (that is, the Kerberos realm) for the Application Server. For example:



Use this procedure to configure a BMC BladeLogic Authentication Service so BMC BladeLogic users can authenticate using the AD/Kerberos user credentials.


1 If you have not done so already, perform the following prerequisite procedure: “Registering an Authentication Service in an Active Directory Domain” on page 180.

2 Review the information that is needed to perform subsequent steps. See “Required information” on page 185.

3 Copy the keytab file to the Application Server. See “Copying the keytab file” on page 185.

4 Obtain the host name of an Active Directory KDC for the service principal’s realm. See “Locating the Active Directory KDC for the service principal’s domain” on page 186.

5 Create the blappserv_krb5.conf file, which provides essential configuration information. See “Creating the blappserv_krb5.conf file” on page 186.

6 Create the blappserv_login.conf file, which provides the location of the keytab file. See “Creating the blappserv_login.conf file” on page 188.

7 Configure the Authentication Service to support Kerberos. See “Defining Authentication Service settings for AD/Kerberos” on page 191.




8 Add user names based on Kerberos naming conventions to the RBAC user database. See “Cross-registering users in the BMC BladeLogic database” on page 192.

9 If you are using Network Shell to communicate directly with agents, set up a Network Shell Proxy Server to manage that traffic. See “Setting up a Network Shell Proxy Server” on page 193.

10 Add users to built-in roles. See “Logging on using default users and roles” on page 194.

Required information

Before you start configuring an Authentication Service, you must obtain the following from the administrator of the Active Directory KDC:

■ The blauthsvc.keytab file.

■ The service principal name used for the keytab file. For example:

blauthsvc/app4

■ The name of the service principal’s domain (Kerberos realm). For example:


For information about creating a user account, service principal name, and keytab file on the Active Directory KDC, see “Registering an Authentication Service in an Active Directory Domain” on page 180.

Copying the keytab file

Use this procedure to copy the blauthsvc.keytab file you obtained from the Active Directory administrator to the correct location on the Application Server hosting the Authentication Service.

For the Authentication Service to authenticate users through the AD/Kerberos user credentials, the Authentication Service must be able to accept KDC service tickets. To accept service tickets, the Authentication Service needs the service key in the blauthsvc.keytab file.

1 Locate the blauthsvc.keytab file that was exported from the Active Directory KDC.


■ On a UNIX-style system, copy the file to the /NSH/br directory.



For example, if BMC BladeLogic is installed in the default location, the file should be located here:

/opt/bmc/BladeLogic/version/NSH/br/blauthsvc.keytab

■ On Windows, copy the file to the \NSH\br directory.

For example, if BMC BladeLogic is installed in the default location, the file should be located here:

C:\Program Files\BMC Software\BladeLogic\version\NSH\br\blauthsvc.keytab

Locating the Active Directory KDC for the service principal’s domain

Use this procedure to obtain the host name for the Active Directory KDC that is running in the realm where the keytab file for the service principal was created. Later in the configuration process, you will need this host name.


nslookup -type=srv _kerberos._tcp.SERVICE_PRINCIPAL_DOMAIN

In this command, SERVICE_PRINCIPAL_DOMAIN is the domain of the service principal. For example:

nslookup -type=srv _kerberos._tcp.SUB2.DEV.MYCOMPANY.COM

The Active Directory KDC’s host name is reported as the value of service (UNIX) or svr hostname (Windows). For example:



Creating the blappserv_krb5.conf file

Use this procedure to create a blappserv_krb5.conf file. This file provides necessary Kerberos configuration information.

NOTE When identifying servers in the blappserv_krb5.conf file, do not use IP addresses. The Application Server must be able to resolve DNS names of Active Directory servers.



1 Create a text file like the following:

In this text file:

SERVICE_PRINCIPAL_REALM is the realm where the keytab file was created. For example:


SERVICE_PRINCIPAL_REALM_KDC is the host name for the Active Directory KDC for the realm where the keytab file was created. For example:

kdc.SUB2.DEV.MYCOMPANY.COM

This is the value you got when you ran the nslookup command, as described in “Locating the Active Directory KDC for the service principal’s domain” on page 186.

In the “domain_realm” section, SERVICE_PRINCIPAL_DOMAIN provides DNS names. A period before a DNS name indicates you are mapping every system with a DNS name ending with that value to a corresponding Kerberos realm. For example:


■ On a UNIX-style system, save the file to the /NSH/br directory with the name:

blappserv_krb5.conf

[libdefaults]

ticket_lifetime = 6000 default_realm = SERVICE_PRINCIPAL_REALM

[realms]

SERVICE_PRINCIPAL_REALM = {

kdc = SERVICE_PRINCIPAL_REALM_KDC:88

}

[domain_realm] .SERVICE_PRINCIPAL_DOMAIN = SERVICE_PRINCIPAL_REALM







/opt/bmc/BladeLogic/version/NSH/br/blappserv_krb5.conf

■ On Windows, save the file to the \NSH\br directory with the name:

blappserv_krb5.conf


C:\Program Files\BMC Software\BladeLogic\version\NSH\br\blappserv_krb5.conf

Creating the blappserv_login.conf file

You must create a blappserv_login.conf file. The Application Server looks in the blappserv_login.conf file to find the location of the keytab file.


In this text file, keyTab is the location of the blauthsvc.keytab file on your system.

■ On a UNIX-style system, assuming BMC BladeLogic is installed in the default location, the keyTab line would look like this:

■ On Windows, assuming BMC BladeLogic is installed in the default location, the keyTab line would look like this:

Be sure to use the double backslash syntax shown above.

com.sun.security.jgss.accept {

com.sun.security.auth.module.Krb5LoginModule required

useKeyTab=true keyTab="keytabFileLocation" storeKey=true principal="blauthsvc/instance@DOMAIN" doNotPrompt=true debug=false;

};

keyTab="/opt/bmc/BladeLogic/version/NSH/br/blauthsvc.keytab"

keyTab="C:\\Program Files\\BMC Software\\BladeLogic\\version\\NSH\\br\\blauthsvc.keytab"



In the text file, principal is the service principal name for the Authentication Service, followed by the @ sign, followed by the Application Server’s domain. You obtained the service principal name from the Active Directory administrator. For example:

If you are using Windows 2008 without Service Pack 2, you should enter a user principal name rather than a service principal name. In other words, use blauthsvc instead of blauthsvc/app4. For example:

If you do not have the service principal name and the Application Server’s realm, you can use the klist utility to display them. See “Using klist to read the keytab file” on page 189.



blappserv_login.conf.


/opt/bmc/BladeLogic/version/NSH/br/blappserv_login.conf

■ On Windows, save the file to the \NSH\br directory with the name

blappserv_login.conf.


C:\Program Files\BMC Software\BladeLogic\version\NSH\br\blappserv_login.conf

Using klist to read the keytab file

You can use the klist utility to read the keytab file and display the name and realm of the service principal.



principal="blauthsvc/[email protected]"

principal="[email protected]"



utilityPath/klist -t -k /opt/bmc/BladeLogic/version/NSH/br/blauthsvc.keytab

In this command, utilityPath provides the path to the klist utility. If you do not have klist installed on a UNIX system, you must first obtain it. There are many online sources for Kerberos utilities such as klist.

■ On Windows, assuming that BMC BladeLogic is installed in the default location, enter the following:

"C:\Program Files\BMC Software\BladeLogic\version\NSH\jre\bin\klist" -t -k "C:\\Program Files\BMC Software\BladeLogic\version\NSH\br\blauthsvc.keytab"

2 The klist utility displays output similar to the following:

The service principal name is blauthsvc/[email protected].

Verifying a keytab file

Use this procedure to verify that the keytab file you have generated can be used to authenticate. This procedure is not essential, but BMC BladeLogic recommends performing this step to confirm that you have successfully set up authentication based on AD/Kerberos.

1 Copy the blappserv_krb5.conf file you set up for the Authentication Server to one of the following locations:

■ Windows: %WINDIR%\krb5.ini

■ Solaris: /etc/krb5/krb5.conf

■ All UNIX platforms except Solaris: /etc/krb5.conf

For more information on the blappserv_krb5.conf file, see “Creating the blappserv_krb5.conf file” on page 186.

2 Identify the service account name from the keytab file by entering one of the following:

■ Windows: installDirectory\jre\bin\klist -k -t keytabFile

■ UNIX: utilityPath/klist -k -t keytabFile

Service principal: blauthsvc/[email protected]



In this command, utilityPath provides the path to the klist utility. If you do not have klist installed on a UNIX system, you must first obtain it. There are many online sources for Kerberos utilities such as klist.

The variable keytabFile identifies the location of the keytab file you are generating. Typically, keytabFile is set to installDirectory/br. For example, if BMC BladeLogic is installed in the default location, the keytab file for Windows would be

C:\Program Files\BMC Software\BladeLogic\version\NSH\br\blauthsvc.keytab

Running the klist command generates output that identifies the service principal. For example, if you used the example names shown in “Sample domain structure” on page 171, this command might identify a service principal called blauthsvc/[email protected].

3 Using the results of the previous step, authenticate to Active Directory by entering one of the following:

■ Windows: installDirectory\jre\bin\kinit -k -t keytabFile servicePrincipal

■ UNIX: utilityPath/kinit -k -t keytabFile servicePrincipal

In this command, utilityPath provides the path to the kinit utility. If you do not have kinit installed on a UNIX system, you must first obtain it.

The variable keytabFile identifies the location of the keytab file and servicePrincipal is the entity identified in the previous step.

If this command runs successfully, you should be able to authenticate with AD/Kerberos. If the command does not succeed, verify that the default_realm you have set up in blappserv_krb5.conf is correct.

Defining Authentication Service settings for AD/Kerberos

Use this procedure to define settings for the BMC BladeLogic Authentication Service so it can use the Kerberos configurations you set up in previous procedures. To perform this procedure, you must use the Application Server Administration console.

1 Start the Application Server Administration console by doing one of the following:


./bin/blasadmin






\bin\blasadmin.exe


2 To enable Active Directory/Kerberos authentication, enter the following:

set AuthServer IsADKAuthEnabled true

By default Active Directory/Kerberos authentication is not turned on.

3 To enable the blappserv_krb5.conf file, enter the following:

set AuthServer AuthSvcKrb5Config fileName

where fileName is the name of the blappserv_krb5.conf file. This file is essential for supporting Kerberos.

By default AuthSvcKrb5Config is set to a value of blappserv_krb5.conf. You can skip this step unless you choose to use a different file name.

4 To enable the blappserv_login.conf file, enter the following:

set AuthServer AuthSvcKrb5LoginConfig fileName

where fileName is the name of the blappserv_login.conf file. This file is essential for supporting Kerberos.

By default AuthSvcKrb5LoginConfig is set to a value of blappserv_login.conf. You can skip this step unless you choose to use a different file name.



Users must be registered in both Active Directory and BMC BladeLogic’s RBAC-based user database. Cross-registration allows users to be authorized for RBAC roles.




BMC BladeLogic documentation assumes you know how to add users to Active Directory.

Requirements for User Names

When using AD/Kerberos to authenticate end users, you must ensure that domain user names stored in RBAC are fully qualified and that those names match the user names stored in the Active Directory.

Each BMC BladeLogic user name must be in the form:

USER@DOMAIN

where DOMAIN is the domain the user is registered in.

For example, if you are using RBAC or the bladduser utility to add a new BMC BladeLogic user, you would fill in the name field with a value such as:

[email protected]

rather than filling in the name field with a value such as:

mary

Note that the user name [email protected] is a different user name than than mary or [email protected].

The user’s BMC BladeLogic user name must match the user’s fully qualified Active Directory user name.

BMC BladeLogic provides a BLCLI command, RBACRole:syncUsers, that you can use to synchronize group information in Active Directory with role information in RBAC. For more information on this command, see the BLCLI help.

Setting up a Network Shell Proxy Server

If you cross-register users in Active Directory and RBAC and then you run an ACL Push Job on a server, Network Shell users may not be able to communicate directly with the agent on that server because the agent will expect user names to include domain information (such as [email protected]). Network Shell user names do not include domain information.


Configuring a BMC BladeLogic Client for AD/Kerberos authentication

To avoid this problem and maintain communication with agents via Network Shell, set up a Network Shell Proxy Server. For more information, see “Configuring the Network Shell Proxy Service” on page 142.

Logging on using default users and roles

The BMC BladeLogic user database comes pre-provisioned with two default SRP users: RBACAdmin and BLAdmin. These default users are assigned to the default roles RBACAdmins and BLAdmins, respectively. If the BMC BladeLogic administrator intends to support AD/Kerberos authentication exclusively and disable SRP user authentication, then, prior to disabling SRP, the administrator should log in as a user authorized for the RBACAdmins role and ensure that each of the four built-in roles—RBACAdmins, BLAdmins, GlobalReportViewers, and GlobalReportAdmins—has at least one registered domain user assigned to that role. Otherwise, when SRP authentication is disabled, no user will be able to access the built-in roles.

In a default installation, the RBACAdmins role has the authorizations necessary to manage users and roles. If you are using that default setup, you can simply assign a fully qualified domain user name (for example, [email protected]) to the RBACAdmins role. In this example, the user would also have to be registered in the Active Directory user registry for the domain SUB2.DEV.MYCOMPANY.COM.

The same issue applies to the BLAdmins role, which has built-in authorizations to change permissions for all system objects in BMC BladeLogic, the GlobalReportAdmins role, which has built-in authorizations to see data for all BMC Service Automation Reporting and Analytics sites, and the GlobalReportViewers role, which has read access to all reports at all sites in a BMC BladeLogic installation. To allow a user to log into the BLAdmins role, you must use RBAC to add a fully qualified user name to the BLAdmins role. To allow a user to log into the GlobalReportAdmins role, you must use RBAC to add a fully qualified user name to the GlobalReportAdmins role. To allow a user to log into the GlobalReportViewers role, you must use RBAC to add a fully qualified name to the GlobalReportViewers role.


This section describes how to configure a BMC BladeLogic client (the BMC BladeLogic Console or the blcred utility) to authenticate with a BMC BladeLogic Authentication Service using AD/Kerberos user credentials.



In addition to the procedures described here, a user must also define an authentication profile that calls for AD/Kerberos authentication. For more information on defining authentication profiles, see the BMC BladeLogic Server Automation User Guide.


1 If you have not done so already, perform the following prerequisite procedures:

■ “Registering an Authentication Service in an Active Directory Domain” on page 180

■ “Configuring an Authentication Service for AD/Kerberos authentication” on page 184

2 For Windows clients, update registry settings and perform other configuration tasks. See “Performing Windows-only client configuration tasks” on page 196. For UNIX environments, skip this step.

3 Create the blclient_login.conf file, which provides essential configuration data. See “Creating the blclient_login.conf file” on page 196.

4 Locate the Active Directory KDC for the client’s realm. This step provides information that is needed for subsequent steps in this procedure. See “Locating the Active Directory KDC for the client’s domain” on page 197.

5 Create a blclient_krb5.conf file, which provides essential Kerberos configuration information. See “Creating the blclient_krb5.conf file” on page 198.

6 Update the BMC BladeLogic config.properties file. See “Updating the config.properties file” on page 200.

7 For UNIX clients, each user must manually perform a kinit to obtain a ticket-granting ticket (TGT). See “Obtaining a TGT for a BMC BladeLogic client (UNIX only)” on page 201. When a Windows user logs into the Active Directory, the equivalent of a “kinit” is performed automatically.

8 Set up authentication profiles using AD/Kerberos authentication on the BMC BladeLogic client. See “Authentication profiles” on page 124 and the BMC BladeLogic Server Automation User Guide.




Performing Windows-only client configuration tasks

Use this procedure to modify registry settings and perform other configuration tasks on Windows client machines. This procedure is only necessary in Windows environments. If you are configuring a UNIX-style system, skip this section.


Creating the blclient_login.conf file

Use this procedure to create the blclient_login.conf file. This file provides necessary configuration information.

Platform Actions

Windows 2003 and 2008

1. Open the Windows Registry Editor.

2. Navigate to \HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters.

3. Create a new registry value of type REG_DWORD. It should be named allowtgtsessionkey and it should have a value of 1.

4. Reboot the workstation.

Windows XP 1. Open the Windows Registry Editor.

2. Navigate to \HKLM\System\CurrentControlSet\Control\Lsa\Kerberos.


Windows Vista 1. Disable User Account Control (UAC).

2. Open the Windows Registry Editor.

3. Navigate to \HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters.


5. Reboot the server.






blclient_login.conf.


/opt/bmc/BladeLogic/version/NSH/br/blclient_login.conf

■ On Windows, save the file to the \NSH\br directory with the name:

blclient_login.conf.


C:\Program Files\BMC Software\BladeLogic\version\NSH\br\blclient_login.conf

Locating the Active Directory KDC for the client’s domain

Use this procedure to obtain the host name for the Active Directory KDC that is running in the domain that includes the client machine. You will need this host name later in the configuration process.


nslookup -type=srv _kerberos._tcp.CLIENT_DOMAIN

where CLIENT_DOMAIN is the domain containing the user’s workstation where the client is running. For example:

nslookup -type=srv _kerberos._tcp.SUB1.DEV.MYCOMPANY.COM

com.sun.security.jgss.initiate {

com.sun.security.auth.module.Krb5LoginModule required

doNotPrompt=true Debug=false

useTicketCache=true;

};



The Active Directory KDC’s host name is reported as the value of svr host name (Windows) or service (UNIX). For example:



Creating the blclient_krb5.conf file

Use this procedure to create the blclient_krb5.conf file. This file provides necessary Kerberos configuration information.

1 Create a text file like the following:

In this text file:

CLIENT_DOMAIN is the realm containing the user’s workstation, where the BMC BladeLogic client is running. For example:


CLIENT_DOMAIN_KDC is the host name where the Active Directory server is running in your client’s realm. For example:


[libdefaults]

ticket_lifetime = 6000 default_realm = CLIENT_DOMAIN [realms]

CLIENT_DOMAIN = {

kdc = CLIENT_DOMAIN_KDC:88

}

SERVICE_PRINCIPAL_DOMAIN = {

kdc = SERVICE_PRINCIPAL_DOMAIN_KDC:88

}

PARENT_DOMAIN = {

kdc = PARENT_DOMAIN_KDC:88

}

[domain_realm] .CLIENT_DOMAIN = CLIENT_REALM .SERVICE_PRINCIPAL_DOMAIN = SERVICE_PRINCIPAL_REALM .PARENT_DOMAIN = PARENT_REALM



This is the value you obtained when you ran the nslookup command, as described in “Locating the Active Directory KDC for the client’s domain” on page 197.

SERVICE_PRINCIPAL_DOMAIN is the realm where the keytab file was created. For example:


SERVICE_PRINCIPAL_DOMAIN_KDC is the host name where the Active Directory server is running in the realm where the keytab file was created. For example:


This is the value you obtained when you ran the nslookup command, as described in “Locating the Active Directory KDC for the service principal’s domain” on page 186.

In the “domain_realm” section, SERVICE_PRINCIPAL_DOMAIN provides DNS names. A period before a DNS name indicates you are mapping every system with a DNS name ending with that value to a corresponding Kerberos realm. For example:



blclient_krb5.conf.


/opt/bmc/BladeLogic/version/NSH/br/blclient_krb5.conf

■ On Windows, save the file to the \NSH\br directory with the name blclient_krb5.conf.


C:\Program Files\BMC Software\BladeLogic\version\NSH\br\blclient_krb5.conf






Updating the config.properties file

Use this procedure to modify the config.properties file on the BMC BladeLogic client.

1 Open the config.properties file. By default, this file is initially stored in the following location:

■ UNIX-style systems:

/opt/bmc/BladeLogic/version/NSH/br/config.properties

■ Windows systems:

C:\Program Files\BMC Software\BladeLogic\version\NSH\br\config.properties

When a user runs the console for the first time, a copy of config.properties is placed in the following user-specific location:

■ UNIX-style systems:

userHomeDirectory /.bladelogic/config.properties

NOTE If there is no direct trust between the two child domains, you must add additional DOMAINS to the [realms] section of the blclient_krb5.conf file. These additional DOMAINS specify the explicit path you need to traverse from the first child domain, up the tree to the root domain and back down to the other child domain.

For example, using the examples in “Sample domain structure” on page 171, assume that there is no direct trust between the child domains SUB1.DEV.MYCOMPANY.COM and SUB2.DEV.MYCOMPANY.COM. In this case, the [realms] section would look something like this:

[realms]

SUB1.DEV.MYCOMPANY.COM = {kdc = kdc.SUB1.DEV.MYCOMPANY.COM:88}DEV.MYCOMPANY.COM = {kdc = kdc.DEV.MYCOMPANY.COM:88}SUB2.DEV.MYCOMPANY.COM = {kdc = kdc.SUB2.DEV.MYCOMPANY.COM:88}



■ Windows systems:

userHomeDirectory\Application Data\BladeLogic\config.properties

If you are setting up an AD/Kerberos environment that many users are sharing (for example, a terminal server) and you have already run the BMC BladeLogic Console, you should modify config.properties in both locations—its initial location and in your own user-specific location.

2 Set the following entries to the values shown below. If an entry does not already exist in the config.properties file, add it at the end of the file.

Obtaining a TGT for a BMC BladeLogic client (UNIX only)

Users of the BMC BladeLogic Console and the blcred utility running on a UNIX-style host must manually run a kinit to obtain a ticket-gathering ticket (TGT).

The TGT is the AD/Kerberos user credential that domain users need to authenticate with the BMC BladeLogic Authentication Service. This procedure must be performed every time a user needs a TGT on a UNIX client. If a user already has a valid TGT, this procedure is not necessary. Although the life span of a TGT is configurable, typically a TGT is valid for 10 hours.

Entry Value

java.security.auth.login.config= path/blclient_login.confIn this entry, path is the full path to the blclient_login.conf file. For Windows paths, use forward slashes as path delimiters (such as, C\:\\Program Files/BMC Software/BladeLogic/version/NSH/br/blclient_login.conf). Alternatively, you can use a backslash as a path separator but you must escape it with another backslash (such as, C\:\\Program Files\\BMC Software\\BladeLogic\\version\\NSH\\br\\blclient_login.conf). Note that in either case you must use a backslash to escape the colon and backslash after the drive letter.

java.security.krb5.conf= path/blclient_krb5.confIn this entry, path is the full path to the blclient_krb5.conf file. For Windows paths, use forward slashes as path delimiters (such as, C\:\\Program Files/BMC Software/BladeLogic/version/NSH/br/blclient_krb5.conf). Alternatively, you can use a backslash as a path separator but you must escape it with another backslash (such as, C\:\\Program Files\\BMC Software\\BladeLogic\\version\\NSH\\br\\blclient_krb5.conf). Note that in either case you must use a backslash to escape the colon and backslash after the drive letter.

javax.security.auth.useSubjectCredsOnly= false


Implementing security – Application Server to agents or repeaters

This procedure is only necessary in UNIX-style environments. If you are using a Windows client, skip this procedure.

1 Copy blclient_krb5.conf to /etc/krb5.conf.

If you are not already using krb5.conf, you can replace the existing version of krb5.conf by renaming the copy of blclient_krb5.conf. If you already use krb5.conf, then you must integrate the contents of blclient_krb5.conf with the contents of krb5.conf.

2 To obtain a TGT, run the following command:

utilityPath/kinit userName

In this command, utilityPath provides the path to the kinit utility. If you do not have kinit installed, you must first obtain it. There are many online sources for Kerberos utilities such as kinit.

The user name you provide for the kinit command does not have to be fully qualified. The name you provide is associated with the client’s realm, identified when you created the client’s blclient_krb5.conf file.

Implementing security – Application Server to agents or repeaters

This section provides the following procedures to secure access between the BMC BladeLogic Application Server and RSCD agents or repeaters by employing TLS client authentication:

■ TLS with client-side certs – Securing a Windows Application Server■ TLS with client-side certs – Securing a UNIX-based Application Server

TLS with client-side certs – Securing a Windows Application Server

Use this procedure to generate a self-signed, client-side certificate for a Windows Application Server, provision all targeted agents or repeaters with an SHA1 fingerprint of the Application Server’s self-signed certificate, and configure those agents or repeaters to authenticate incoming requests using client-side certificates. If your environment includes multiple Application Servers, you should repeat this procedure for each Application Server.



Note that in the context of this section, a “client” refers to an Application Server that is attempting to establish contact with the server hosting an agent. Generally, in BMC BladeLogic documentation a “client” refers to a host running the BMC BladeLogic Console or Network Shell.

If you want to stop using self-signed, client-side certificates, see “TLS with client-side certs – Discontinuing use of client-side certificates” on page 210.

You can use this procedure to use TLS with client-side certificates to secure communication between a Windows-based Network Shell Proxy Server and agents or repeaters. The procedure for a Network Shell Proxy Server is identical to the procedure for an Application Server.


1 Create a self-signed, client-side certificate on the Windows Application Server. Then add the passphrase for that certificate to the securecert file. See “Creating a self-signed client-side certificate on the Application Server” on page 203.

2 Provision all targeted agents or repeaters with an SHA1 fingerprint of the Application Server’s self-signed certificate. See “Provisioning agents and repeaters with a SHA1 fingerprint of the Application Server’s self-signed certificate” on page 204.

3 Configure all targeted agents or repeaters to authenticate incoming requests using client-side certificates. See “Configuring agents or repeaters to authenticate incoming requests with client-side certificates” on page 206.

Creating a self-signed client-side certificate on the Application Server

Use this procedure to create a file called id.pem, which contains the self-signed certificate for the Application Server and the private key associated with the certificate. Then add the passphrase used to encrypt the private key to the securecert file on the Application Server.

1 Log into a Windows Application Server as Administrator.

2 Create a directory called C:\WINDIR\rsc\certs\SYSTEM.

In the path shown above, WINDIR is typically winnt (on a Windows 2000 server) or windows.

3 Using a command line, generate a self-signed Application Server certificate by entering the following:



bl_gen_ssl -appcert

After you enter the command, you are prompted to provide and then confirm a passphrase. This passphrase is used to encrypt the private key in the id.pem file. The id.pem file is created in the C:\WINDIR\rsc\certs\SYSTEM directory.

4 Update the securecert file to include an encoded copy of the passphrase. To accomplish this, use the command line to enter the following:

secadmin -m default -cu SYSTEM -cp passPhrase

After issuing this command, the contents of the securecert file are updated to something like the following. The encoded passphrase will vary.

For the initial installation of BMC BladeLogic, you can find the securecert file in the C:\WINDIR\rsc directory. If additional instances of BMC BladeLogic are installed, you can find securecert in installDirectoryN\version\NSH\conf\securecert. For example, the default location for the second instance of BMC BladeLogic would be C:\Program Files\BMC Software\BladeLogic2\version\NSH.

Provisioning agents and repeaters with a SHA1 fingerprint of the Application Server’s self-signed certificate

Use this procedure to create, or update, on each managed server and repeater a file named SYSTEM. This file contains the SHA1 fingerprint of the Application Server’s self-signed certificate. An agent or repeater uses this fingerprint to validate the self-signed certificate received from the Application Server in the course of the TLS handshake.

1 Ensure that the secure file on all managed servers is configured so that tls_mode=encryption_only. If necessary, generate this setting by running the following secadmin command on each agent:

secadmin -m rscd -p 5 -T encryption_only -e tls

Before you can provision a managed server with the fingerprint of the Application Server’s certificate, you must ensure that the secure file on the agent or repeater is configured correctly. If you prematurely set the rscd entry in a secure file so that tls_mode=encrytion_and_auth, the agent or repeater will refuse the incoming connection because it will not have the SHA1 fingerprint of the Application Server’s self-signed cert. The secure file (located in the C:\WINDIR\rsc directory on a Windows server and in /usr/lib/rsc on a UNIX-style server) must have the rscd entry set to the following when deploying the certificate fingerprint:

[default]

SYSTEM=FCUVOMLNGLVRZNOO



rscd:port=4750:protocol=5:tls_mode=encryption_only:encryption=tls

This is the default setting after a fresh installation of an agent, so in most situations there is no need to perform this step.

2 Set up root or Administrator privileges on each managed server hosting an agent.

To provision an agent or repeater with the SHA1 fingerprint of an Application Server’s certificate, you must have root or Administrator privileges on the server hosting the agent. To grant this privilege, update the exports file on a Windows server by creating the following entry:

* rw,user=Administrator

On a UNIX server, update the exports file by creating the following entry:

* rw,user=root

To be safe, you should replace the host wildcard (“*”) with a more restrictive setting, such as the IP address or host name of the Application Server.

3 Using a command line on the Application Server, cd to C:\WINDIR\rsc\certs\SYSTEM, the directory containing the id.pem file.

4 Push the SHA1 fingerprint to managed servers by entering the following command:

putcert SYSTEM id.pem agent1...agentN

where agent1...agentN is a space-delimited list of the host names or IP addresses of the managed servers hosting agents or repeaters.

This command creates or updates a fingerprint file on each targeted agent or repeater. On a Windows machine, the fingerprint file for a Window Application Server is C:\Program Files\BMC Software\BladeLogic\version\RSCD\certs\SYSTEM; on a UNIX machine, the fingerprint file for a Windows Application Server is /opt/bmc/BladeLogic/version/NSH/certs/SYSTEM.

In environments where multiple Application Servers communicate with agents, you should provision each Application Server with its own self-signed certificate. Performing this procedure for each of those Application Servers generates multiple fingerprints in the SYSTEM file.

5 Revert the setting in the exports file on managed servers back to a more restrictive user mapping. Otherwise, all users accessing those agents will be mapped to root or Administrator.


TLS with client-side certs – Securing a UNIX-based Application Server

Configuring agents or repeaters to authenticate incoming requests with client-side certificates

Use this procedure to update the rscd entry in each agent's secure file so it reads as follows:

rscd:port=4750:protocol=5:tls_mode=encryption_and_auth:encryption=tls

After agents are provisioned with the SHA1 fingerprint of an Application Server’s self-signed certificate, the secure files on those agents must be updated so tls_mode=encryption_and_auth. This setting requires client authentication via client-side certificates.

To modify the rscd entry in the secure file on each targeted agent, use Network Shell to enter the following secadmin command:

secadmin -m rscd -p 5 -T encryption_and_auth -e tls

This procedure is also necessary if you are configuring a repeater to authenticate incoming requests from an Application Server.


Use this procedure to generate a self-signed, client-side certificate for a UNIX-based Application Server, provision all targeted agents or repeaters with an SHA1 fingerprint of the Application Server’s self-signed certificate, and configure those agents or repeaters to authenticate incoming requests using client-side certificates. This section is intended for administrators of BMC BladeLogic Application Servers.

Note that in the context of this section, a “client” refers to an Application Server that is attempting to establish contact with the server hosting an agent. Generally, in BMC BladeLogic documentation a “client” refers to a host running the BMC BladeLogic Console or Network Shell.

If you want to stop using self-signed, client-side certificates, see “TLS with client-side certs – Discontinuing use of client-side certificates” on page 210.

You can use this procedure to use TLS with client-side certificates to secure communication between a UNIX-based Network Shell Proxy Server and agents or repeaters. The procedure for a Network Shell Proxy Server is identical to the procedure for an Application Server.




1 Create a self-signed client-side certificate on the UNIX Application Server. Then add the passphrase for that certificate to the securecert file. See “Creating a self-signed client-side certificate on the Application Server” on page 207.

2 Provision all targeted agents or repeaters with an SHA1 fingerprint of the Application Server’s self-signed certificate. See “Provisioning agents and repeaters with a SHA1 fingerprint of the Application Server’s self-signed certificate” on page 208.

3 Configure all targeted agents or repeaters to authenticate incoming requests using client-side certificates. See “Configuring agents or repeaters to authenticate incoming requests with client-side certificates” on page 209.

Creating a self-signed client-side certificate on the Application Server

Use this procedure to create a file called id.pem, which contains the self-signed certificate for the Application Server and the private key associated with the certificate. Then add the passphrase used to encrypt the private key to the securecert file on the Application Server.

BMC BladeLogic will not load the certificate if group or world permissions are set for the id.pem file or the .bladelogic directory, where the id.pem file is generated.

1 Log into the UNIX system on the Application Server as root, and then enter the following command:

su - bladmin

This command logs you in as the bladmin user.


/opt/bmc/BladeLogic/version/NSH/bin/bl_gen_ssl

After entering the command, you are prompted to provide and then confirm a passphrase. This passphrase is used to encrypt the private key in the id.pem file. The id.pem file is created in the bladminUserHome/.bladelogic directory. In UNIX the Application Server runs as the bladmin user.

3 Enter exit to revert back to the root user.

4 Update the securecert file (contained in the /usr/lib/rsc directory) to contain an encoded copy of the passphrase. To accomplish this, use Network Shell to enter the following:

secadmin -m default -cu bladmin -cp passPhrase



After issuing this command, the contents of the securecert file are updated to something like the following. The encoded passphrase will vary.

5 Ensure that access is restricted to the id.pem file and the .bladelogic directory by running the following commands:

chmod 700 /opt/bmc/BladeLogic/version/NSH/br/.bladelogicchmod 600 /opt/bmc/BladeLogic/version/NSH/br/.bladelogic/id.pem

Provisioning agents and repeaters with a SHA1 fingerprint of the Application Server’s self-signed certificate

Use this procedure to create, or update, on each managed server or repeater a file named bladmin. This file contains the SHA1 fingerprint of the Application Server’s self-signed certificate. An agent or repeater uses this fingerprint to validate the self-signed certificate received from the Application Server in the course of the TLS handshake.



Before you can provision a managed server with the fingerprint of the Application Server’s certificate, you must ensure that the secure file on the agent or repeater is configured correctly. If you prematurely set the rscd entry in a secure file so that tls_mode=encrytion_and_auth, the agent or repeater will refuse the incoming connection because it will not have the SHA1 fingerprint of the Application Server’s self-signed cert. The secure file (located in the C:\WINDIR\rsc directory on a Windows server and in /usr/lib/rsc on a UNIX-style server) must have the rscd entry set to the following when deploying the certificate fingerprint:




[default]

bladmin=FCUVOMLNGLVRZNOO



To provision an agent or repeater with the SHA1 fingerprint of an Application Server’s certificate, you must have root or Administrator privileges on the server hosting the agent. To grant this privilege, update the exports file on a Windows server by creating the following entry:



* rw,user=root

To be safe, you should replace the host wildcard (“*”) with a more restrictive setting, such as the IP address or host name of the Application Server.

3 Using a command line on the Application Server, cd to /opt/bmc/BladeLogic/version/NSH/br/.bladelogic, the directory containing the id.pem file.

4 Push the SHA1 fingerprint to managed servers by entering the following command:

/opt/bmc/BladeLogic/version/NSH/sbin/putcert bladmin id.pem agent1...agentN

where agent1...agentN is a space-separated list of the host names or IP addresses of the managed servers hosting agents or repeaters.

This command creates or updates a fingerprint file on each targeted agent or repeater. On a Windows machine, the fingerprint file for a Window Application Server is C:\Program Files\BMC Software\BladeLogic\version\RSCD\certs\bladmin; on a UNIX machine, the fingerprint file for a Windows Application Server is /opt/bmc/BladeLogic/version/NSH/certs/bladmin.

In environments where multiple Application Servers communicate with agents, you should provision each Application Server with its own self-signed certificate. Performing this procedure for each of those Application Servers generates multiple fingerprints in the bladmin file.


Configuring agents or repeaters to authenticate incoming requests with client-side certificates




TLS with client-side certs – Discontinuing use of client-side certificates




This procedure is also necessary if you are configuring a repeater to authenticate incoming requests from an Application Server.

TLS with client-side certs – Discontinuing use of client-side certificates

Use this procedure to stop using client-side certificates that secure access between Application Servers and agents or repeaters.

1 Set up root or Administrator privileges on each managed server hosting an agent or repeater.

To perform this procedure, you must have root or Administrator privileges on any servers hosting agents or repeaters where you want to discontinue use of client-side certificates. To grant this privilege, update the exports file on a Windows server by creating the following entry:



* rw,user=root

To be safe, you may want to replace the host wildcard (“*”) with the IP address or host name of the Network Shell client.

2 Remove the SHA1 fingerprint of the Application Server’s self-signed certificate from managed servers by entering the following command:

nukecert SYSTEM|bladmin agent1...agentN

where SYSTEM|bladmin is SYSTEM for a Windows Application Server or bladmin for a UNIX Application Server and agent1...agentN is a space-delimited list of the names or IP addresses of the servers where you want to stop using the Application Server’s self-signed certificate.


Implementing security – Network Shell to agent

3 Configure the secure file on all agents or repeaters where you want to stop using certificates by using Network Shell to run the following secadmin command:


Running this command generates an rscd entry in the secure file like the following:


5 Remove certificates from Application Servers by deleting the SYSTEM directory for Windows Application Servers or the .bladelogic directory for UNIX Application Servers.

For Windows Application Servers, the SYSTEM directory can be found at C:\WINDIR\rsc\certs\SYSTEM.

For UNIX Application Servers, the bladmin directory can be found at /opt/bmc/BladeLogic/version/NSH/br/.bladelogic.

Implementing security – Network Shell to agent

This section provides procedures to secure access between Network Shell clients and servers hosting RSCD agents. The following options are available:

■ No authentication – Using a default installation■ TLS with client-side certs – Securing a Network Shell client

No authentication – Using a default installation

A standard installation of BMC BladeLogic requires no user authentication between Network Shell clients and servers hosting agents. Typically administrators use the exports file to limit Network Shell client access to agents by restricting access to certain client IP addresses. For more information on using the exports file, see “Exports file” on page 240.



TLS with client-side certs – Securing a Network Shell client


Use this procedure to generate a self-signed, client-side certificate for a Windows Network Shell client, provision all targeted agents with an SHA1 fingerprint of the self-signed certificate, and configure those agents to authenticate incoming requests using client-side certificates.

This procedure creates a file on the client called id.pem. That file contains the client’s digital certificate and the corresponding private key, which is encrypted using a password supplied when the self-signed certificate is created. Then this procedure calculates the SHA1 fingerprint of the client certificate and pushes it to targeted agents using the putcert utility. The SHA1 fingerprint is written into fingerprint files on the agents. During the TLS handshake, the client uses the contents of the id.pem file (certificate and corresponding private key) and the agents uses the SHA1 fingerprint.

On UNIX machines running Network Shell clients, BMC BladeLogic will not load the certificate if group or world permissions are set for the id.pem file or the .bladelogic directory, where the id.pem file is generated.

If you want to stop using self-signed, client-side certificates, see “Discontinuing use of client-side certificates” on page 216.

1 Ensure that the secure file is configured correctly on all agents where you want to set up secure access. At this point in the procedure the rscd entry in the secure file should be set to tls_mode=encryption_only. If necessary, generate this setting by running the following secadmin command on each agent:


This is the default setting after a fresh installation of an agent, so in many situations there is no need to perform this step. Later in this procedure you will change the tls_mode setting.


NOTE The machine where you are creating a certificate must have the capability to generate random numbers. The BMC BladeLogic installation program for the Application Server tests whether a machine has the capability to generate random numbers. The installation program also allows you to install a daemon or create a random number seed that BMC BladeLogic uses for generating random numbers. For more information, see the BMC BladeLogic Server Automation User Guide.



To provision an agent with the SHA1 fingerprint of a client’s certificate, you must have root or Administrator privileges on the server hosting the agent. To grant this privilege, update the exports file on a Windows server by creating the following entry:



* rw,user=root

To be safe, you should replace the host wildcard (“*”) with the IP address or host name of the Network Shell client.

3 Using a command line on the Network Shell client, generate a self-signed certificate by entering the following:

bl_gen_ssl

4 Enter a passphrase. Then confirm the passphrase by entering it again.

BMC BladeLogic generates a self-signed certificate in a file named id.pem. The passphrase is used to encrypt the private key in the id.pem file.

In UNIX, id.pem is stored in /userHomeDirectory /.bladelogic, where userHomeDirectory is the user’s home directory, such as /home/userName.

In Windows, id.pem is stored in /userProfileDirectory/Application Data/BladeLogic, where userProfileDirectory specifies a path such as /Documents and Settings/userName.

5 Cd to the directory where id.pem is stored.

6 For UNIX machines running Network Shell clients, ensure that access is restricted to the id.pem file and the .bladelogic directory by running the following commands:

chmod 700 /home/userName/.bladelogicchmod 600 /home/userName/.bladelogic/id.pem

7 Push the SHA1 fingerprint of the self-signed certificate to managed servers by entering the following command:

putcert userName id.pem agent1 ... agentN

where userName is the name of the user who created the certificate and agent1 ... agentN is a space-delimited list of the names or IP addresses of the servers to which you want to push the certificate.



This command creates or updates a fingerprint file on each targeted agent. On a Windows agent, C:\Program Files\BMC Software\BladeLogic\version\RSCD\certs\userName is the fingerprint file. On a UNIX agent, /opt/bmc/BladeLogic/version/NSH/certs/userName is the fingerprint file.

8 Modify the rscd entry in the secure file on each targeted agent by entering the following secadmin command:



10 If you plan to use Network Shell to run non-interactive tools such as the BLCLI, you should cache your private key for your client-side certificate. For more information, see “Caching private keys” on page 214.

Caching private keys

A client certificate and its associated private key (that is, the contents of the id.pem file) constitute a user credential that the holder of the credential can use to assume the identity of the user named within the credential. If the private key in the id.pem file is not password-protected, anyone gaining access to the file can assume the identity of the user named in the certificate. To keep private keys safe, BMC BladeLogic provides a password mechanism.

When an id.pem file is generated, the private key is encrypted using the password you provide when you run the bl_gen_ssl utility. When you start Network Shell, the system prompts you for your private key password. Once you provide the password, Network Shell decrypts and caches your private key, making it available to any command running under the shell.

Because each Network Shell session requires knowledge of the private key password, BMC BladeLogic provides a private key cache so users do not have to retype their passwords every time they start a new Network Shell session. The procedure for activating the private key cache varies for Windows and UNIX-style systems.

NOTE Performing this step could have implications for Application Servers or Network Shell Proxy Servers when they communicate with the same targeted agents. This step sets tls_mode=encryption_and_auth on the targeted agents, which means these agents will require Application Servers or Network Shell Proxy Servers to also use client-side certificates. For information on setting up client-side certificates on these entities, see “TLS with client-side certs – Securing a Windows Application Server” on page 202 or “TLS with client-side certs – Securing a UNIX-based Application Server” on page 206. You can also use these procedures to set up client-side certificates on Network Shell Proxy Servers. The procedure is the same as the procedure for Application Servers.



Activating the private key cache in Windows

1 From a Windows command line, enter the following command:

bltray -blkey

A dialog prompts for your private key password.

2 Enter the password and click OK.

The BMC BladeLogic icon displays in the system tray on the task bar, indicating the private key password is shared.

3 To stop sharing the password, right-click the BMC BladeLogic icon in the system tray and select Exit from the pop-up menu.

Activating the private key cache in UNIX

1 On the Network Shell client, enter the following command.

bl_ssl_agent --background

The system prompts for your private key password.

2 Enter the password.

The system generates a message like the following:

set BL_X509_KEY to xy to reuse this private key

where xy is the hexadecimal value of the location of the shared memory segment.

TIP If you are already running Network Shell and you create a certificate, Network Shell prompts you for a password every time you issue a command during that session. To avoid this, create the certificate, exit Network Shell, and then start Network Shell again. Network Shell only prompts for the password when you start the new session.

NOTE This command must be run in the foreground because it prompts for a password. The command will spawn a new process that will remain in the background to cache the password in a shared memory segment.



After entering your password, bl_ssl_agent runs in the background with the password cached in a shared memory segment. This shared memory segment is only usable by the person who ran bl_ssl_agent.

3 To reuse this shared memory segment with Network Shell, set the BL_X509_KEY environment variable by entering the following command:

BL_X509_KEY=xy

4 Export the BL_X509_KEY environment variable by issuing the following command:

export BL_X509_KEY

The bl_ssl_agent program remains in the background holding the private key password cached in a shared memory segment until you kill it.

Discontinuing use of client-side certificates

Use this procedure to stop using client-side certificates that secure access between Network Shell clients and agents.


To perform this procedure, you must have root or Administrator privileges on any servers hosting agents where you want to discontinue use of client-side certificates. To grant this privilege, update the exports file on a Windows server by creating the following entry:



* rw,user=root

To be safe, you may want to replace the host wildcard (“*”) with the IP address or host name of the Network Shell client.

2 Remove the SHA1 fingerprint of a client-side, self-signed certificate from managed servers by entering the following command:

nukecert userName agent1...agentN

where userName is the name of the user who created the certificate and agent1...agentN is a space-delimited list of the names or IP addresses of the servers where you want to stop using certificates.

3 Configure the secure file on all agents where you want to stop using certificates by using Network Shell to run the following secadmin command:


Implementing Security – Repeater to agent




5 Remove certificates from clients by deleting the id.pem file.

In UNIX, id.pem is stored in /userHomeDirectory /.bladelogic, where userHomeDirectory> is the user’s home directory, such as /home/userName.

In Windows, id.pem is stored in /userProfileDirectory/Application Data/BladeLogic, where userProfileDirectory specifies a path such as /Documents and Settings/userName.

Implementing Security – Repeater to agentUse this procedure to generate a self-signed, client-side certificate for a repeater, provision all targeted agents with an SHA1 fingerprint of the repeater’s self-signed certificate, and configure those agents to authenticate incoming requests using client-side certificates.

On UNIX repeaters, you must perform this procedure for every user to whom connecting users are mapped. Typically, users are mapped to root but mapping to other user names is possible. On Windows, you must perform this procedure for the BladeLogicRSCD user.

If you want to stop using self-signed, client-side certificates, see “Discontinuing use of client-side certificates” on page 222.



NOTE Performing this step could have implications for Application Servers or Network Shell Proxy Servers when they communicate with the same targeted agents. This step sets tls_mode=encryption_only on the targeted agents, which means these agents will not require Application Servers or Network Shell Proxy Servers to also use client-side certificates.


Creating a self-signed client-side certificate on the repeater

1 Create a self-signed, client-side certificate on the repeater, and then add the passphrase for that certificate to the securecert file. See “Creating a self-signed client-side certificate on the repeater” on page 218.

2 Provision all targeted agents with an SHA1 fingerprint of the repeater’s self-signed certificate. See “Provisioning agents with an SHA1 fingerprint of the repeater’s self-signed certificate” on page 219.

3 Configure all targeted agents to authenticate incoming requests using client-side certificates. See “Configuring agents to authenticate incoming requests with client-side certificates” on page 221.

Creating a self-signed client-side certificate on the repeater

Use this procedure to create a self-signed certificate for the repeater and then add the passphrase for that certificate to the securecert file on the repeater.

On UNIX repeaters, BMC BladeLogic will not load the certificate if group or world permissions are set for the id.pem file or the .bladelogic directory, where the id.pem file is generated.

4 Using a command line, generate a self-signed certificate by doing one of the following:

■ On UNIX-style systems, log into the repeater as a user to whom connecting users are mapped (typically root). Then, issue the following command for generating a certificate:

bl_gen_ssl

■ On Windows, do the following:

A. Log into the Application Server as Administrator.

B. Create a directory called C:\WINDIR\rsc\certs\BladeLogicRSCD.

In the path shown above, WINDIR is typically winnt (on a Windows 2000 server) or windows.

C. Enter the following command for generating a certificate:

bl_gen_ssl -repeatcert

5 Enter a passphrase for the private key to the certificate. Then confirm the passphrase by entering it again.


Provisioning agents with an SHA1 fingerprint of the repeater’s self-signed certificate

BMC BladeLogic generates a certificate in a file named id.pem.

On UNIX, the file is created in userHomeDirectory /.bladelogic., where userHomeDirectory is the user’s home directory. For example, if you are logged in as root, id.pem is created in /root/.bladelogic/id.pem.

On Windows, the file is created in WINDIR\rsc\certs\BladeLogicRSCD, where WINDIR is typically windows or winnt.

6 Update the securecert file to contain an encoded copy of the passphrase. Using Network Shell, enter the following:

secadmin -m default -cu user -cp password

where user is BladeLogicRSCD for Windows repeaters and the user who created the certificate (such as root) for UNIX-style repeaters.

Enter the password in clear text. The secadmin utility encrypts the password.

After issuing this command, the contents of the securecert file are updated to include an entry for your current user name, such as root or BladeLogicRSCD. For example, this command might create an entry like the following. (The encoded passphrase will vary.)

7 For UNIX repeaters, ensure that access is restricted to the id.pem file and the .bladelogic directory by running the following commands:

chmod 700 /opt/bmc/BladeLogic/version/NSH/br/.bladelogicchmod 600 /opt/bmc/BladeLogic/version/NSH/br/.bladelogic/id.pem


Use this procedure to provision managed servers with the SHA1 fingerprint of the repeater’s self-signed certificate. An agent uses this fingerprint to validate the self-signed certificate received from the repeater in the course of the TLS handshake.

[default]

BladeLogicRSCD=FCUVOMLNGLVRZNOO





Before you can provision an agent with the fingerprint of the repeater’s certificate, you must ensure the secure file on the agent is configured correctly. If you prematurely set the rscd entry in an agent's secure file so that tls_mode=encrytion_and_auth, the agent will refuse the incoming connection because it will not have the SHA1 fingerprint of the repeater’s self-signed cert. The secure file (located in the C:\WINDIR\rsc directory on a Windows server and in /usr/lib/rsc on a UNIX-style server) must have the rscd entry set to the following when deploying the certificate fingerprint:




To provision an agent with the SHA1 fingerprint of an Application Server’s certificate, you must have root or Administrator privileges on the server hosting the agent. To grant this privilege, update the exports file on a Windows server by creating the following entry:



* rw,user=root

To be safe, you may want to replace the host wildcard (“*”) with the IP address or host name of the Application Server.

3 Cd to the directory on the repeater where id.pem is stored.

On UNIX-style servers, id.pem resides in userHomeDirectory/.bladelogic., where userHomeDirectory is the user’s home directory. For example, if you are logged in as root, id.pem is created at /root/.bladelogic/id.pem.

On Windows, id.pem resides in WINDIR\rsc\certs\BladeLogicRSCD, where WINDIR is typically windows or winnt.


Configuring agents to authenticate incoming requests with client-side certificates

4 Push the SHA1 fingerprint for the repeater’s certificate to managed servers that communicate with the repeater. To accomplish this, use Network Shell to enter the following:

putcert user id.pem agent1...agentN

where,

user is either the name of the UNIX user you were logged in as when you created the certificate or BladeLogicRSCD if the repeater is on a Windows platform.

agent1...agentN is a space-separated list of the host names or IP addresses of the managed servers hosting agents.

When you issue the putcert command, BMC BladeLogic places the SHA1 fingerprint of the id.pem file for root in a file called root. It places the SHA1 fingerprint of the id.pem file for BladeLogicRSCD in a file called BladeLogicRSCD. The file resides in the /nsh/certs directory on UNIX-style servers and in \rsc\certs on Windows.


Configuring agents to authenticate incoming requests with client-side certificates









Use this procedure to stop using client-side certificates that secure access between repeaters and agents.


To perform this procedure, you must have root or Administrator privileges on any servers hosting agents where you want to discontinue use of client-side certificates. To grant this privilege, update the exports file on a Windows server by creating the following entry:



* rw,user=root

To be safe, you should replace the host wildcard (“*”) with a more restrictive setting, such as the IP address or host name of the Network Shell client.

2 Remove the SHA1 fingerprint of the repeater’s self-signed certificate from managed servers. To accomplish this, use Network Shell to enter the following:

nukecert user agent1...agentN

where user is BladeLogicRSCD for a Windows repeater and typically root for a UNIX repeater. If other UNIX users have fingerprints on the agent, you must remove those user names as well. In the command shown above agent1...agentN is a space-delimited list of the names or IP addresses of the servers where you want to stop using the repeater’s self-signed certificate.

3 Configure the secure file on all agents where you want to stop using certificates by using Network Shell to run the following secadmin command:




NOTE Performing this step could have implications for Application Servers or Network Shell Proxy Servers when they communicate with the same targeted agents. This step sets tls_mode=encryption_only on the targeted agents, which means these agents will not require Application Servers or Network Shell Proxy Servers to also use client-side certificates.


Using certificates to secure communication between clients and Application Servers


5 Remove certificates from repeaters by deleting the id.pem file storing the certificate.

On UNIX-style servers, the id.pem file resides in userHomeDirectory/.bladelogic., where userHomeDirectory is the user’s home directory. For example, if you are logged in as root, id.pem resides in /root/.bladelogic/id.pem.

On Windows, the id.pem file resides in WINDIR\rsc\certs\BladeLogicRSCD, where WINDIR is typically windows or winnt.

Using certificates to secure communication between clients and Application Servers

Typically BMC BladeLogic uses self-signed certificates to secure communication between clients and Application Servers. However, you may choose to provision Application Servers with a CA-issued certificate or certificate chain. For more information on that procedure, see “Securing communication with CA certificates” on page 224.

In some situations, you may need to manually generate a self signed certificate for an Application Server. For more information on that procedure, see “Generating a self-signed certificate for an Application Server” on page 223.

Generating a self-signed certificate for an Application Server

Performing this procedure generates a 2048-bit RSA key and a self-signed certificate for an Application Server. The certificate will be valid for three years, and it will be stored under the “blade” alias.

1 From installDirectory/bin, enter the following command:

blmkcert CN=hostname jksFileName password

The command shown above has the following parameters:

■ hostname—Typically set to the host name where you are generating the certificate.


Securing communication with CA certificates

■ jksFileName—The path to the keystore you are generating. This file should be stored in the /deployments directory for the Application Server that is being updated, such as installDirectory/br/deployments/_template.

■ password—A password used to encrypt the generated keystore file.

For example, if you are generating a self-signed certificate on a Windows server called winappserver1, you might enter a command like the following:

blmkcert CN=winappserver1 "C:\Program Files\BMC Software\BladeLogic\version\NSH\br\deployments\_template\bladelogic.keystore" ********

2 If you are using a multi-Application Server environment, copy the JKS file you generated in step 1 from this Application Server to all cooperating Application Servers. If a new password is needed, update the password for each cooperating Application Server. For information on this process, see “Synchronizing keystore files of multiple Application Servers” on page 58.


When you install an Application Server, the installation procedure provisions the Application Server with a self-signed certificate. However, some organizations may choose to use a CA-issued certificate or certificate chain rather than the default self-signed certificate.

When you perform this procedure, you set up a keystore that takes the place of the bladelogic.keystore created automatically when you install the Application Server. (A keystore contains certificates and a private key. A trust store only contains certificates.)

If the certificate you are importing includes a URL for an OCSP Responder, the client will attempt to verify the revocation status of the Application Server’s certificate. If you do not want clients to verify a certificate’s revocation status, do not provision the Application Server with a certificate that includes an OCSP URL.

After you provision Application Servers with CA-issued certificates, you should import those certificates into client trust stores. For more information on that procedure, see “Importing CA-issued certificates into clients” on page 226.

1 Obtain a certificate chain from a certificate authority.

2 Import the certificate and its corresponding private key into a keystore file on the Application Server.



Ideally, your certificate authority should create a certificates and private keys and output them using the JKS format. If your CA cannot create a JKS file and instead provides you with a PKCS12 file, you must convert your certificates and private keys into JKS. There are various tools for performing this type of conversion. For example, you can use Java’s keytool utility, which is available on any machine where the Authentication Server is installed. If you are importing a certificate with the Authentication Server’s version of keytool, you might enter a command like the following:

installDirectory/jre/bin/keytool -importkeystore -srckeystore bladelogic.p12 -destkeystore bladelogic.keystore -srcstoretype pkcs12 -deststoretype jks -srcalias pkcs12Alias -destalias blade

In this command bladelogic.p12 is the file being imported.

bladelogic.keystore is the name of the keystore file you are creating. This file should be stored in the /deployments directory for the Application Server that is being updated, such as installDirectory/br/deployments/_template.

pkcs12Alias is the alias under which the certificate and private key are stored.

When you enter the command shown above, you are prompted for a destination keystore password. This is the password used to encrypt the keystore. When you use the blasadmin utility to set up keystores for cooperating Application Servers (described in the next step) you must provide this password. The command shown above also prompts you for the source keystore password, which is the password originally used to create the PCKS12 file.

3 If you are using a multi-Application Server environment, copy the JKS file you generated in step 2 from this Application Server to all cooperating Application Servers. If a new password is needed, update the password for each cooperating Application Server. For information on this process, see “Synchronizing keystore files of multiple Application Servers” on page 58.

NOTE No matter what method you use to import the certificate, the alias you use to identify the certificate must be blade and the format of the keystore must be jks.


Using the blcred utility

Importing CA-issued certificates into clients

If you have provisioned an Application Server to use a certificate or certificate chain obtained from a Certificate Authority (see “Securing communication with CA certificates” on page 224), you should import a related certificate into the client’s trust store. The related certificate should be the issuing certificate for the Application Server’s certificate. If the Application Server is provisioned with a certificate chain, the certificate that you import into the client’s trust store should be the issuing certificate for the top of the certificate chain.

This procedure is not essential, but performing it configures the client so it communicates more securely with the Application Server. If you do not perform this procedure, when you establish a connection to the Application Server, you are prompted to trust the certificate. This functionality is equivalent to the default approach for BMC BladeLogic, which uses self-signed certificates.

Use the blcred utility to import the certificate into the client trust store by entering the following command:

blcred cert -import certificateFile

In this command certificateFile provides the path to the certificate you are adding to the trust store. This file must use the PEM or DER format. This file could be the Application Server’s certificate file, or it could be a CA’s certificate that can be used to verify the validity of the Application Server’s certificate. OCSP verification on the client side will only happen if the CA certificate was imported and the Application Server’s certificate contains an OCSP URL.

On Windows, this command imports the certificate to C:\Documents and Settings\user\Application Data\BladeLogic\client_keystore.pkcs12.PEM.

On UNIX, this command imports the certificate to userHomeDirectory/.bladelogic/client_keystore.pkcs12.PEM.

Using the blcred utilityThe blcred utility manages authentication profiles, session credentials, and trusted certificates. To use blcred, you must install the BMC BladeLogic Console.

To log into a BMC BladeLogic system, a user must provide an authentication profile, user name, and password. The authentication profile specifies a BMC BladeLogic Authentication Service and the mechanism that should be employed to authenticate the user. Once the Authentication Service validates a user, the Authentication Service issues a session credential. This session credential can be stored in a credential cache file.


Using the blcred utility

BMC BladeLogic client applications use session credentials to establish secure sessions with a middle tier service—either the Application Service or the Network Shell Proxy Service. BMC BladeLogic client applications can use a cached session credential when the owner of the credential cache file invokes the client application.

Session credentials have a finite lifetime. After a session credential has expired, it cannot be used to establish a client/server session. However, an established client/server session can continue even though the session credential used to establish that session has expired.

BMC BladeLogic users can log on and acquire session credentials using the BMC BladeLogic Console or blcred command line utility. When operating in a command line environment, the blcred utility lets you:

■ Create an authentication profile

■ Acquire a session credential by providing an authentication profile and the appropriate user credentials for each authentication protocol, as described below:

— SRP—user name and password.

— LDAP—distinguished name and password.

— SecurID—user name and passcode (PIN plus token code).

— AD/Kerberos—The blcred utility retrieves the AD/Kerberos user credential from the host system's AD/Kerberos credential store; users do not explicitly use the command line interface to provide AD/Kerberos credentials.

— Domain Authentication—User name (in the form [email protected]) and password.

— PKI—Insert a smart card into a smart card reader and provide the appropriate PIN for that smart card. You must insert the smart card before you can use blcred to run the acquire command to obtain a session credential.

■ Test whether a valid session credential already exists and determine the lifetime remaining for that credential.

■ Review, add, and delete authentication profiles.

■ Review, add, import, and delete trusted X.509 certificates. On clients, X.509 certificates are used when establishing a TLS connection to an Authentication Service, Application Server, or Network Shell Proxy Server. On Application Servers, X.509 certificates are used when establishing a TLS connection to an LDAP server.


Options

Options

For a complete description of all available command line options, refer to the man page for blcred.

Typical scenarios

The following sections describe some typical scenarios for using blcred.

Testing for valid session credentials

If you are using a command line (BLCLI or Network Shell in proxy mode) and you want to determine whether you have a valid session credential, run the following command:

blcred cred -test -profile MyProfile

where MyProfile is the name of the authentication profile for which a session credential has been issued. If this command is successful, it generates a return code of 0, which means a valid session credential does exist for MyProfile.

To determine whether a credential's remaining lifetime exceeds a specified number of minutes, enter a command like the following:

blcred cred -test -profile MyProfile -time 500

where 500 is a remaining lifetime in minutes. If this command is successful, it generates a return code of 0, which means the MyProfile session credential is valid for at least 500 minutes.

Interactively obtaining a session credential

If you are interactively running Network Shell (in proxy mode) or the BLCLI and you need to obtain a session credential but cannot use the console, run the following command:

blcred cred -acquire


Typical scenarios

The blcred utility will prompt for an authentication profile name, user name and password if the named profile specifies SRP authentication. The example below shows an authentication session that prompts the user for credential information. Alternatively, you can specify the profile name, user name and password as command line options.

If you are using AD/Kerberos authentication, you can enter the same command, but when prompted for an authentication profile name, you must enter a profile name that calls for AD/Kerberos authentication. (Alternatively, you can specify the profile name as a command line option.) When employing AD/Kerberos authentication, blcred does not prompt the user for a name or password. Instead, it retrieves the user’s Kerberos credential from the host operating system’s AD/Kerberos credential cache. Note that UNIX users must first manually run a kinit before attempting to authenticate, as described in “Obtaining a TGT for a BMC BladeLogic client (UNIX only)” on page 201.

Obtaining a session credential by referencing a keytab file

If you are running Network Shell or the BLCLI in batch mode and you need to obtain a session credential non-interactively, you can direct blcred to retrieve an SRP user name and password from an SRP keytab file, using a command like the following

blcred cred -acquire -profile srpProfile -i /home/user/user_info.dat

Obtaining a session credential using SRP authentication profile

If you are running Network Shell or the BLCLI in batch mode, you need to obtain a session credential non-interactively, and you are using SRP authentication, you can direct blcred to obtain a session credential.

blcred cred -acquire -profile srpProfile -username BLAdmin -password ******

$ blcred cred -acquire profile name: srpProfile username: BLAdmin password ******Authentication succeeded: acquired session credential

$ blcred cred -acquireprofile name: adkProfileAuthentication succeeded: acquired session credential


Generating a user information file

Obtaining a session credential using an LDAP authentication profile

If you are running Network Shell or the BLCLI in batch mode, you need to obtain a session credential non-interactively, and you are using LDAP authentication, you can direct blcred to obtain a session credential. If you are using a distinguished name template, you only have to provide a partial distinguished name (in this case admin) and an LDAP password.

blcred cred -acquire -profile ldapProfile -username admin -password ******

If you are not using distinguished name templates, you must provide a full distinguished name and a password.

Displaying the contents of a session credential

Using a blcred command like the following, you can display the contents of your current session credential.

Generating a user information fileUse this procedure to generate a user information file, which caches your user ID, password, and role.

1 From installDirectory/bin, do one of the following:

■ On Windows, run the command bl_gen_blcli_user_info.exe.

■ On UNIX, run the command bl_gen_blcli_user_info.

The utility prompts you to create a file name.

2 Name the file user_info.dat.

Username: RBACAdminAuthentication: SRPIssuing Service: service:authsvc.bladelogic:blauth://localhost:9840Expiration Time: Fri Aug 17 20:57:29 EDT 2007Maximum Lifetime: Sat Aug 18 06:57:29 EDT 2007Client address: 127.0.0.1Authorized Roles: RBACAdmins

Destination URLs: service:appsvc.bladelogic:blsess://localhost:9841 service:proxysvc.bladelogic:blsess://localhost:9842



3 When prompted, enter your user name, password, and role.

4 Move the file created in step 2 to one of the locations shown below:

■ Windows: userHomeDirectory\Application Data\BladeLogic \user\user_info.dat

■ UNIX: userHomeDirectory/.bladelogic/.user/user_info.dat

5 Make sure that only you have permission to access the directory where you have stored the user_info.dat file.

NOTE When running a Network Shell Script Job based on a Network Shell script that contains CLI commands, the user_info.dat file must be saved in the userHomeDirectory for the LocalSystem account on Windows or the bladmin user on UNIX.

To determine the userHomeDirectory for LocalSystem, run Network Shell on the Application Server and enter the following command:

echo $USERPROFILE

To determine the userHomeDirectory for bladmin, run the following command as root or a user with root privileges:

sudo -u bladmin echo $HOME




C h a p t e r 5
5 Setting up configuration files
This chapter describes how to modify BMC BladeLogic configuration files. The configuration files control how communication occurs between RSCD agents and their clients, which clients and users have access to RSCD agents.

The chapter also provides an overview of logging in BMC BladeLogic, and discusses how logging is performed.

Introduction to the configuration files BMC BladeLogic provides the following configuration files:

exportsusersusers.localsecuresecurecertlog4crc.txt.

The exports, users, users.local, secure, securecert, and log4crc.txt files reside on each server (that is, each machine where an RSCD agent is installed). The secure, securecert, and log4crc.txt files are also installed for each client installation, even if there are multiple client installations on the same machine. The secure files on both the client and server configure how clients communicate with servers.

When a client connects to a server, the client user can be granted permissions on the server using two approaches: through configuration files on the agent (a process called user privilege mapping) or through Windows user mapping.


Introduction to the configuration files

In BMC BladeLogic, the standard approach to granting user permission on managed servers is user privilege mapping. It uses a combination of the exports, users, and users.local configuration files. Together, these files define what permissions apply during the connection. This approach should always be used in the following situations:

■ When a user is accessing any UNIX server.■ When a user is accessing a Windows server and the user’s role is not mapped to a

Windows user through an automation principal.■ When a user runs a Network Shell client to connect directly to a server.■ When a user is using a Network Shell client to connect to servers via a stand-alone

Network Shell Proxy Server.■ When a user is running a Network Shell script defined to use the first and second

script types and the appserver_protocol setting in the secure file is not set to ssoproxy. For more information on configuring clients to use a Network Shell Proxy Server, see “Setting up a Network Shell Client to run in proxy mode” on page 147.

The alternative approach to user privilege mapping is to implement Windows user mapping. Using this technique, you can grant permissions to roles that are mapped to local or domain users who are authorized for a Windows server. For information on implementing Windows user mapping, see the BMC BladeLogic Server Automation User Guide.

When you are using Windows user mapping to grant permissions to roles, you must still create entries for the users, users.local, or exports files. The information in these entries defines whether users can access a server. Any user mapping information in these entries is ignored for roles that employ Windows user mapping through automation principals. Consequently, even if you are using Windows user mapping, you should still push agent ACLs to servers when you add or modify user or role information in the BMC BladeLogic Console.

Disabling user privilege mapping

BMC BladeLogic provides a mechanism for disabling user privilege mapping on Windows servers. For more information, see the man page for the chapw command.

NOTE Only Windows servers running BMC BladeLogic 8.0 or later can recognize automation principals.


Configuration file functions

Configuration file functions

The configuration files function as follows:

■ exports—Sets access permissions for client machines that communicate with a server. With the exports file you can also establish global user permissions.

■ users and users.local—Set access permissions for individual users that communicate with a server. Typically, the values specified in the users file are automatically generated to implement decisions made in RBAC. (For more information on RBAC, see the BMC BladeLogic Server Automation User Guide.) You can use the users.local file to override any permissions defined in the users file. Permissions set in either the users and users.local files override any global user permissions defined in the exports file.

■ secure—Sets communication parameters that define how client and server machines communicate. RSCD agents, Application Servers, and client installations each have their own secure file. (On Windows, a single machine can have multiple client installations.) A client’s secure file specifies how the client communicates with agents. A server’s secure file specifies how an agent communicates with clients. An Application Server’s secure file specifies how the Application Server communicates with agents and how the file server (typically created on the same host as the Application Server) communicates with clients. The secure file also determines whether a Network Shell client communicates with servers via a Network Shell Proxy Server. A utility called secadmin allows you to configure the secure file on a particular machine. Although you can edit the secure file by hand, BMC BladeLogic recommends that you always use secadmin.

■ securecert—Stores passphrases used to encrypt the private keys for X.509 certificates. Strong security for communication requires X.509 certificates. Storing passphrases lets BMC BladeLogic access private keys without any need for user interaction.

■ log4crc.txt—Controls logging in BMC BladeLogic so that all events are logged using consistent formats. With log4crc.txt, you can also control the rolling of log files, so that a single log file cannot get excessively large.


Subnet designations

The following graphic illustrates how the secure, exports, and users configuration files work together to control access to a server.

Subnet designations

When designating a host in the configuration files, you can use a resolvable host name, an IP address, or a subnet. A subnet represents a range of IP addresses. In the configuration files, a subnet designation uses the following format:

@<IP address or hostname>/mask

The @ symbol indicates that a subnet is being defined. After the IP address or host name, provide the number of bits in the mask. For example, a subnet with a subnet mask of 255.255.255.0 might look like the following:

@192.168.10.0/24

The following are sample subnet mask definitions:

255.255.255.000 @192.168.100.0/24


How BMC BladeLogic grants access to RSCD agents

255.255.255.128 @192.168.100.129/25

255.255.255.192 @192.168.100.193/26

255.255.255.224 @192.168.100.225/27

255.255.255.240 @192.168.100.241/28

255.255.255.248 @192.168.100.249/29


When a client contacts an RSCD agent, BMC BladeLogic uses the following algorithm to determine whether a user has permissions for accessing the agent:

1 Every client installation (on Windows there can be multiple clients) and the RSCD agent each have their own secure file. First, the client reads its secure file to determine whether it includes an entry for a particular server. If an entry for that server exists, the client uses the information in the entry to establish a connection with the server. Then, the RSCD agent on the server reads its secure file to determine if it has an entry for the incoming client. If there is no entry for that client in the secure file of the server, access to the agent is denied. If there is an entry and the communication parameters in the secure file on the server match those in the secure file on the client, a connection is established.

Depending on the type of authentication and encryption specified in the secure file, additional measures may be required before a connection can be successfully established between clients and servers. For a complete description of how to set up communication security for a BMC BladeLogic system, see Chapter 4, “Administering security.” For more information on using on the secure file, see “Secure file” on page 253.



2 Assuming the conditions described below are satisfied, if you are using Windows user mapping, the incoming role is granted the permissions of a local or domain user on the server and the process if complete. If any of the following conditions are not satisfied, the algorithm continues to step 3

■ The agent being contacted must be running on a Windows server.■ The agent being contacted must be running on a server that has already been

added to the BMC BladeLogic system.■ The agent must be running BMC BladeLogic 8.0.00 or later.■ A Network Shell client must be communicating through a Network Shell Proxy

Server. To take advantage of Windows user mapping, Network Shell cannot contact an agent directly or communicate through a stand-alone Network Shell Proxy Server.

■ Any job acting on a target server must be running in an Application Server environment that meets the following criteria:— The Application Server must also be running a Network Shell Proxy Service

or the ProxyServiceURLs value in the Application Server profile must point to a valid Network Shell Proxy Server.

— The secure file on the Application Server must be defined so the appserver_protocol option is set to ssoproxy.

3 Once a connection is established between the client and server, the system checks the exports configuration file, where the user= field can map users connecting from specified machines to a particular user on the server. For example, with the user= field, you can map users to root on UNIX-style systems or Administrator on Windows.

Note that on Windows, incoming users can only be mapped to local users. On Windows domain controllers, however, all users are domain users. On domain controllers, you can map a user to a domain user.

If a role is mapped to a Windows user through an automation principal, the exports file produces no user mapping.

For more on the exports file, see “Exports file” on page 240.

4 The system checks the users.local and users configuration files to determine if these files include any map= entries that supersede definitions set in the exports file. Using the map= field, you can map a user on a client to a user on a server. Typically, the users file is used to implement the permissions that are defined and granted to users on a system-wide basis through RBAC Management. The users.local file is used for granting user permissions on a per-agent basis rather than granting system-wide user privileges. If the same users have entries in both users.local and users, entries in the users.local file take precedence.

If a role is mapped to a Windows user through an automation principal, the users.local and users files produce no user mapping.



For more on the users and users.local files, see “Users and users.local files” on page247.

5 If there is no user mapping defined in the exports, users.local, or users files, the system attempts to match the user ID of the incoming user to a user ID defined on the server where the RSCD agent is installed. If there is a match, the user is assigned that user’s permissions.

Note that, by default, user “root” on a UNIX-style client is not allowed to map to its equivalent user “root” on a UNIX-style server. Similarly, on Windows, any client user found to be a member of the Administrators group cannot be mapped by default to an equivalent user on the server.

6 If none of the previous steps succeed, the system maps the incoming user to a default user. On UNIX-style systems, users are granted the permissions of user “nobody.” On Windows systems, if the role is not mapped to an automation principal, users are granted the permissions of user “Anonymous.”

Note that on UNIX, users coming in as root are, by default, mapped to nobody unless a corresponding entry for the root= field is found. If a root= field is found, then root equivalence is allowed. Similarly, on Windows, if an incoming user is not mapped to an automation principal and that user is a member of the Administrators group, then that user is, by default, mapped to Anonymous unless a corresponding entry for the root= field is found.

In UNIX-style systems, you can use the anon= field to specify how to deal with anonymous users, including rejecting them with anon=-1. The anon= field is not supported for Windows. Also, on Windows, be aware that the validusers= option is treated the same as the allowed= option.

On Windows, if you are not using Windows user mapping, a mapping exists in the exports or users file, and the user that is being mapped to does not exist, access to the agent is denied. For example, if an entry in the users file says

betty map=WindowsUser

then any user named betty that tries to make a connection to this machine is mapped to the local user named WindowsUser. If there is no user named WindowsUser, access is denied.


Exports file

Exports file The exports file determines which BMC BladeLogic clients have access to a server. With the exports file you can set permissions on a per-client basis and, when necessary, use the users or users.local files to override those permissions for particular users. Often the exports file is used to set global permission that apply to users on all client machines. For example, you can use the exports file to limit all clients to read-only permission on the server. Then you can use the users or users.local files to specify individual users who are granted read/write permission on that server.

Access permissions are defined for each individual RSCD agent and must be configured separately on each host where the RSCD agent is running. Updating the exports file on the host where you are running Network Shell or other BMC BladeLogic applications does not set access permissions for managed servers.

When an rscd daemon starts on a server, it automatically reads the exports file. When changes are made to the exports file, the daemon automatically re-reads it. All subsequent client connections have the access permissions defined in the modified version of the exports file. Existing client connections are not affected by the changes. You do not have to restart the agent or otherwise instruct it to read the new exports file.

If the exports file does not exist or it does not contain any configuration information, you cannot establish a connection with an agent.

The exports file resides in different locations in Windows and UNIX-style systems, as described in the following table.

The exports file does not grant permissions on Windows servers to roles that are set up for Windows user mapping. For information on Windows user mapping, see the BMC BladeLogic Server Automation User Guide. If you are using Windows user mapping to grant permissions to roles, the exports file may still include entries that apply to Windows servers. Only the user mapping information in the exports file is ignored.

Platform Location

Solaris, Linux, AIX, HP-UX /usr/lib/rsc/exports

Windows WINDIR\rsc\exports

(For example, WINDIR can be \windows or \winnt.)


Configuring the exports file

Configuring the exports file

The exports file consists of multiple entries, with each entry identifying client hosts and the access permissions granted to those hosts.

To configure the exports file, create entries that correlate the host names of clients with the permissions that should be granted to those clients. Use the following format for each entry:

hostNnames option1...optionN

hostNnames is a list of comma-separated IP addresses, resolvable host names, or subnet designations. Subnet designations are used to define a range of addresses (see “Subnet designations” on page 236). Using an asterisk (*) instead of a list of host names defines default options that apply to any host not specifically named in the exports file.

option1...optionN is a list of comma-separated fields. Each option defines a type of access permission that applies to the hosts you have named in that entry. For a complete list of available options, see “Options for exports file” on page 241. If a single option sets multiple values, separate each value with a colon, as in the following:

validusers=user1:user2

Lines in the exports file that begin with # are considered to be comments.

Options for exports file

For each of the entries in the exports file, you can apply any of the options listed below. When defining multiple options, enter options in a comma-separated list.

Option Description

allowed=username[:username] This option can be used to restrict access to specific users who do not have a local account. The user names entered here should be the login names of the users on the client machines.

This option is similar to the validusers option except that the users named here are not required to have an account on the local system. The allowed= option is read before the validusers= option. If possible, use the validusers option instead of the allowed= option.



anon=uid (UNIX only.) This option specifies how unknown users should be treated. If a request comes from an unknown user, the user is treated as an anonymous user and the effective user ID is uid. Root users (uid 0) are always considered “unknown” by the RSCD agent unless they are included in the root= option, described below. The default value for anon= is the UID of the user nobody. If the user nobody does not exist, the value 65534 is used. Setting anon=-1 disables anonymous access.

The value entered can be numeric or a user name. If a user name is entered, the corresponding UID and GID are determined and set accordingly. If a UID is entered, a corresponding GID is searched for. If the GID is not found, the GID is set to the GID for the user nobody.

commands=cmd1[:cmd2] By default, BMC BladeLogic clients are allowed to execute any command against an agent. The commands= option allows you to limit the commands a client can execute against an agent. See “Restricting commands” on page 244 for more details on how to use this option.

nomknod (UNIX only.) By default, clients are allowed to create special files (character special and block special). Specifying the nomknod option instructs the RSCD agent to prevent the client from making a mknod(2) call generating an EACCES (Permission denied) error.

nosuid (UNIX only.) By default, clients are allowed to create files with the setuid or setgid bits enabled and to set setuid and setgid permission via chown(2). If you specify the nosuid option, the RSCD agent silently ignores any attempt to enable the setuid or setgid bits when creating a file or changing a file’s permissions.

ro All clients have read-only access except those listed in the rw= option.

The ro option takes precedence over the rw option if both are defined.

rw All clients have read-write access except those listed in the ro= option.

The ro option takes precedence over the rw option if both are defined.

rw=hostname[:hostname] Hosts listed in this option are granted read/write permissions. Hosts not specified have read-only permissions if ro is defined or they are listed in the ro= option. If ro is not set or the host is not listed in the ro= option, the client is denied access.

If both the ro= and rw= options are defined, the ro and rw options are ignored.

ro=hostname[:hostname] Hosts listed in this option are granted read-only permissions. Hosts not specified have read/write permissions if rw is defined or they are listed in the rw= option. If rw is not set or the host is not listed in the rw= option, the client is denied access.

If both the ro= and rw= options are defined, the ro and rw options are ignored.

root=hostname[:hostname] This option gives root access to root users from specified hosts. The default is for no hosts to be granted root access.

Option Description



rootdir=dirname By default, the rscd server allows the client to “see” the complete directory tree from / on down. By specifying the rootdir= option, the rscd server sets the “root” directory to dirname by making a call to or emulating chroot(2). Clients can only see files and directories from dirname on down. When setting rootdir= on Windows systems, you can use the native file naming convention rather than a Network Shell-style path.

rsu=user[:user] The client command rsu allows a client to get alternate remote permissions on the agent. By default the client is challenged for the user’s password, but with the -p option no password is requested. The rsu= entry defines which users the client is allowed to rsu without challenging them for a password. If the client tries to use the rsu command with the -p option (that is, no password challenge) and then tries to switch to a user not in the list, access is denied.

user=username This option forces all incoming client connections to run with the permissions of username. For Windows systems, you can enter Windows user account SIDs rather than user names. This option takes precedence over the root= and anon= options if they exist.

The single entry you provide for username can be a user name or a numeric UID (UNIX only). On UNIX, if a user name is entered, the UID and GID for the user are determined and set accordingly. If the user name entered is not known, default user mapping applies. (For more details on user privilege mapping, see “How BMC BladeLogic grants access to RSCD agents” on page 237.) If a numeric UID is entered, then the corresponding UID on the server is used even if no known user account is associated with that UID. If an account is associated with a UID, then its corresponding GID is also set.

On Windows, if a user name or user account SID is entered, it is validated against a list of local users on the machine. If the user name that is entered is not known, access to the machine is denied. Note that on Windows domain controllers, you can map a user to a domain user. The user name you enter is validated against the domain users on the domain controller. See “How BMC BladeLogic grants access to RSCD agents” on page 237 for more details.

validgroups=groupname[:groupname] This option allows you to specify user groups that are allowed access. Enter user groups in a colon (:) separated list. For each group name and/or GID entered, the RSCD agent looks at the effective GID of the calling user (as reported by the calling host) and only allows it access if the GID is in the specified list. If the GID is not in the list, the connection is refused.

Group information can be provided in the form of group names or numeric GIDs. The comparison is done as a numeric equivalency and as such group names must be known on the local system to determine their corresponding GID. Numeric GIDs do not have to correspond to a local group name. Use /etc/groups to define group names.

Option Description


Restricting commands


The RSCD agent reads entries in the exports file to determine what access permissions a calling client should have. Access can be limited by host or subnet, by user name, and by the commands a user can run. BMC BladeLogic clients can run two types of commands. The first are Network Shell utilities, such as nsh, ls, and midair, which each have distributed capabilities. For example,

hostname $ mkdir //athens/tmp/foo //rome/tmp/bar

Besides launching external applications, the nsh utility provides access to many internal commands, including cd, pwd, true, false, set, echo, kill, and more. Given that these commands are internal to nsh, you cannot use the commands= option to explicitly restrict their use. Once you use the commands= option to authorize the nsh command to run against a server, you also inherently authorize the use of all nsh internal commands against the server.

The other type of command that a client can run is called a remote command (remote, that is, from the client’s perspective). These commands do not have distributed capabilities and run remotely on the server host. (The process is conceptually similar to doing an rsh.) For example, remote commands include ps, df, and netstat.

To prevent individuals from renaming executables to trick the RSCD agent, each distributed utility contains an encrypted string that is used to hard code the name of the utility into the executable. Remote commands do not include this safeguard.

In some circumstances you may want to restrict the commands a user can execute. This can be done using the commands= option in the exports or users files. The order in which commands are entered and the format of the commands= field affect the way permissions are determined. A distinction exists between distributed commands and remote commands. You must first define the allowable distributed commands and then define the allowable remote commands. To allow remote commands, you must

validusers=username[:username] This option allows you to specify users who are allowed access. Enter users in a colon (:) separated list. For each user name and/or UID that is entered, the RSCD agent looks up the corresponding UID and user name to create a user name/UID combination. The RSCD agent then matches the user name/UID combination to each attempted client connection. If the user name and UID of the client connection does not exactly match one of the user name/UID combinations generated by the daemon, the connection is refused.

The user information you provide for validusers= can be in the form of user names or numeric UIDs. User names and UIDs must correspond to a locally known user account. If no corresponding user account can be found, the entry is ignored.

Option Description



also allow the distributed command nexec. Once the nexec entry is found, all subsequent commands in the list are assumed to be remote commands. In other words, first you define the distributed commands, the last of which should be the nexec command. Then you define the remote commands. For example,

commands=nsh:mkdir:rmdir

allows users to execute Network Shell’s internal commands as well as to create and remove directories. No remote commands such as ps or df are allowed. The entry

commands=ls:nexec:ps:df

allows a user to execute the remote commands ps and df but does not allow a user to cd to the host because cd is not a remote command and the nsh command has not been authorized. This command does allow the user to do things like:

rome $ ls //athens/foo/

If you only want to limit the remote commands that can be executed, you can leave out the list of distributed commands. For example,

commands=nexec:df:ps:netstat

allows the user to execute all distributed commands but only allows the user to execute three remote commands on this host.

The decision to allow or disallow execution of a remote command is based on comparison of the effective (basename) of the command. In order to ensure that only the desired remote commands are executed, you can specify the full pathname of the remote executable. This prevents users from trying to execute a different executable than the intended one. For example, if you enter

commands=nsh:nexec:/bin/ps

the following commands work as expected (executing from /bin/ps):

rome $ nexec athens ps -ef

rome $ cd //rome/etc

athens $ ps -ef


Examples

Examples

The following example allows customers access to software updates from servers. The asterisk means permissions apply to all clients unless there are other entries that define different permissions for specific hosts. This example grants read-only access to all clients and maps all incoming connections so that users have “guest” privileges. The root directory for these users is set to /pubs.

* ro,rootdir=/pubs,user=guest

The following example grants read/write access to all users but turns off the setting of setuid/setgid bits and denies unknown users access.

* rw,nosuid,anon=-1

The following example maps incoming connections from machines called admin1 and admin2 to the local user called Administrator. A configuration like this is typically necessary if you are deploying BLPackages to Windows machines because you need Administrator privileges to deploy packages.

admin1,admin2 rw,user=Administrator

The following example allows both read/write and read-only access for selected hosts, granting them root access from only one host and changing the root directory to /reports:

host1,host2,host3 rw,rootdir=/reports,root=host1

host4,host5 ro,rootdir=/reports

The following example is a configuration that could be assigned when administrators, who typically work on Windows clients, need to manage remote UNIX servers. It grants two users (sysadmin1 and sysadmin2) read/write permission for all servers, and it also maps their user privileges to root. This entry would be added to the exports file on every remote server being managed by the two administrators. Because Windows machines have no inherent concept of root, a configuration entry something like this example is important if administrators working on Windows clients want to modify the configuration of UNIX servers.

* rw,allowed=sysadmin1:sysadmin2,user=root

NOTE On Windows, the user name entered is validated against a list of local users on the machine. However, on Windows Domain Controllers, all users are domain users. When using the exports file to set up user privilege mapping on Domain Controllers, map users to Administrator or the administrator account for the domain.


Users and users.local files

The following example demonstrates subnets. If you want to have different access (ro/rw) permissions for various hosts within a subnet, you should first define the exception hosts and then define the default value for the remaining subnet. In the example below the host host1.foo.com has read/write privileges while everybody else in the subnet (subnet mask 255.255.255.192) has read-only privileges.

host1.foo.com rw,root=host1.foo.com

@host1.foo.com/26 ro

The following is an example where an address range of 192.168.10.1-255 is split up so that the range from 1-127 has read/write privileges while the range 128-255 has read-only privileges.

@192.168.10.1/24 [email protected]/25,[email protected]/25

Users and users.local files The users and user.local files grant access permissions to specific users connecting to a server. The permissions granted in the users and user.local files override any permissions defined on a per-client basis in the exports file. The permissions in the users and user.local files are defined on a per-user basis.

The users file is primarily used to implement user permissions that are defined through RBAC. (For more on RBAC, see the BMC BladeLogic Server Automation User Guide.) With RBAC you define the characteristics of a role and assign users to that role. You can apply RBAC decisions to a server by running an ACL Push Job in the BMC BladeLogic Console. Running an ACL Push Job automatically converts your role definitions and role assignments into entries in the users file on that server. Together these entries are called an access control list (ACL).

Typically the users.local file is used for granting permissions on a per-server basis rather than granting system-wide user privileges. Administrators may want to modify the users.local file to override RBAC policy on a particular server. Both the users and users.local files have the same format, but the users.local file is scanned before the users file. If the same users have entries in both users.local and users, entries in the users.local file take precedence.

The agent on a server enforces user permissions defined in an ACL by mapping incoming users to users defined on the server. The agent accomplishes this by doing the following:

■ Incoming users are matched to a user name on the server. In other words, when user betty attempts to connect to a server, she must operate with the privileges already assigned to user betty on that server. In this scenario, a user cannot connect to a server unless a matching user name has been defined on a server.


Users and users.local files

■ Incoming users are mapped to a specified user name. For example, all users connecting to a UNIX system can be mapped to root, while users connecting to a Windows system can be mapped to Administrator.

■ If neither of the two previous techniques are possible, incoming users are automatically mapped to a user with downgraded permissions. UNIX users are mapped to user nobody and Windows users are mapped to Anonymous.

An ACL Push Job generates users file entries that grant a variety of permissions, including permissions for commands. The job uses the following algorithm to create users file entries relating to command authorizations:

■ If no command authorizations are specified on the server in the BMC BladeLogic Console and no command authorizations are specified for a role, no command authorizations for that role are pushed to the agent. This means the role has full authorization to use any Network Shell and nexec commands on that server.

■ If no command authorizations are specified on the server in BMC BladeLogic Console but command authorizations are specified for a role, those command authorizations are pushed to the agent. This means the role is authorized to perform those commands on the agent.

■ If command authorizations are specified on the server in BMC BladeLogic Console but no command authorizations are specified for a role, no command authorizations for that role are pushed to the agent. This means the role has full authorization to use any Network Shell and nexec commands on that server.

■ If command authorizations are specified on the server in BMC BladeLogic Console and command authorizations are specified for the role, the command authorizations common to both are pushed to the agent. This means the role is authorized to perform only those commands on the agent.

When you make changes to the users or users.local files, the RSCD agent automatically detects your new settings and uses them for all subsequent client connections. You do not have to restart the agent or otherwise instruct it to read the new users or users.local files.

The users and users.local files reside in different locations in Windows and UNIX-style systems, as described in the following table.

Platform Location

Solaris, Linux, AIX, HP-UX /usr/lib/rsc/users/usr/lib/rsc/users.local

Windows WINDIR\rsc\usersWINDIR\rsc\users.local

(For example, WINDIR can be \windows or \winnt.)


Configuring the users or users.local files

The users and users.local files do not grant permissions on Windows servers to roles that are set up for Windows user mapping. For information on Windows user mapping, see the BMC BladeLogic Server Automation User Guide. However, the users or users.local files should still include an entry for each role so that role can be granted access to a Windows server. Only the user mapping information in the users and users.local files is ignored for roles that employ Windows user mapping through automation principals. All other settings still apply. Consequently, even if you are using Windows user mapping, you should still push agent ACLs to servers when you add or modify user or role information in the BMC BladeLogic Console.


Both the users and users.local files are a list of entries. Each entry grants permissions to a user. The format of each entry consists of two fields. The first field provides a role and a user name, separated by a colon, such as BLAdmins:BLAdmin. The second field is a comma-separated list of permissions that apply to the user defined in the first field. For a complete list of available permissions, see “Options for users and users.local files” on page 251. If an option sets multiple values, separate each value with a colon. For example, hosts=host1:host2.

For Network Shell users that are not communicating with servers through a Network Shell Proxy Server, the first field in a users file entry provides only a user name. No role is necessary because Network Shell does not recognize roles. The name of a Network Shell user should match the name of the user on the client host who is attempting to make a connection to this server. The second field is a comma-separated list of permissions that apply to the user defined in the first field. For a complete list of available permissions, see “Options for users and users.local files” on page 251. If an option sets multiple values, separate each value with a colon. For example, hosts=host1:host2.



Below is a sample users file with entries for DBAdmins:george and DBAdmins:betty. In this example, DBAdmins is the role and george and betty are users. Below these entries, two more entries grant george and betty access to this server using Network Shell. In these entries george and betty are not paired with any role

If george and betty communicate with the server by means of a Network Shell Proxy Server, the Network Shell entries shown above would not be necessary. The entries for DBAdmins:george and DBAdmins:betty would grant george and betty access to this server.

The users file can also include a nouser entry. Including this entry instructs a server to allow a connection from a user only when that user has been explicitly defined in the users configuration file. When you use an ACL Push Job to push a users file to a server, BMC BladeLogic places a nouser entry in the users file if that server has a property called PUSH_ACL_NO_USERS_FLAG set to true.

Lines in the users and user.local files that begin with # are considered to be comments.

Using wild cards in the users.local file

The users.local file allows you to use a wild card in place of user names when defining role:user combinations. This capability is unique to the users.local file.

For example, you could create a users file entry such as:

SecOps:* rw,map=root

An entry like this grants read/write access to all users who have assumed the role of SecOpcs. All users in the role are mapped to root.

entries for DBAdmins role

entries for Network Shell users

# DBAdmins ACLs

DBAdmins:george rw,map=root

DBAdmins:betty rw,map=root

# NSH-only ACLs

george rw,map=root

betty rw,map=root

nouser


Options for users and users.local files

Identifying users with a wild card provides some benefits. By performing a modification like this, you can temporarily allow all users in a role to access a server without first running an ACL Push Job to change the users file on that server. In some organizations, running an ACL Push Job may first require a lengthy change control process.

Using a wild card like this also lets you authorize all members of a role to perform certain types of actions. You do not have to update entries in the users.local file when users are added to or removed from a group.

Using wild cards for user names in the users.local file is a capability that should be used sparingly. Entries in the users.local file override entries in the users file. Thus an entry like the one shown above overrides any more restrictive settings defined for the role using RBAC.

Options for users and users.local files

The users and users.local files provide the following options that you can use to assign access permissions to users:

TIP BMC BladeLogic recommends adding an entry for RBACAdmins:RBACAdmin and BLAdmins:BLAdmin to the users.local file for every server. Because these roles cannot be deleted, they provide a way to access a server in case you accidentally revoke everyone else’s permissions for that server. If you choose to rename the RBACAdmins or BLAdmins roles, the entries you make in the users.local file should reflect those naming decisions.

Option Description

commands=cmd1[:cmd2 ...] This is a list of colon (:) separated commands that the user is allowed to execute on the local host. If no commands= option is given, the corresponding entry in the exports file determines what commands the user can run. See “Restricting commands” on page 244 for more details on the use of this field.

exists (Unix only.) This entry tells the RSCD agent that an account with the same user name must exist on this host.

hosts=hosts1[:host2 ...] This entry tells the RSCD agent that permissions should only apply if the user named in the first field is connecting from one of the hosts in this list of colon (:) separated host names and/or addresses. If no hosts field is provided, the entry applies to the user named in the first field regardless of what host that user is connecting from.


Examples

Examples

In the following example, the first and second entries in the users file grant read/write access to user1 and user2, who are associated with the role of SrAdmin. Both users are mapped to Administrator on this server. Because no hosts field is provided, user1 and user2 can access this server from any other server. The third and fourth entries, which are for user1 and user2, do not associate those users with a role but do

map=username This entry forces incoming client connections to run with the permissions of username. For more information, see “How BMC BladeLogic grants access to RSCD agents” on page 237. For Windows systems, you can enter a Windows user account SID rather than a user name.

nomknod (Unix only.) By default, clients are allowed to create special files (character special and block special). Specifying the nomknod option instructs the RSCD agent to prevent the client from making an mknod(2) call, generating an EACCES (Permission denied) error.

nosuid (Unix only.) By default, clients are allowed to create files with the setuid or setgid bits enabled and to set setuid and setgid permission via chown(2). If you specify the nosuid option, the RSCD agent silently ignores any attempt to enable the setuid or setgid bits when creating a file or changing a file’s permissions.

nouser This is a special user name that denies user access to the server unless the user has an entry specifically configured in the users or users.local files. When the nouser name is included in the users or users.local file, server access is limited to users specifically included in the users or users.local files.

ro The named user has read-only access.

rootdir=dirname By default, the RSCD agent allows the client to “see” the complete directory tree from / on down. By specifying the rootdir entry, the RSCD agent sets the “root” directory to dirname by making a call to, or emulating, chroot(2). Clients can then see files and directories from dirname on down.

rsu=user1[:user2 ...] The client command rsu allows a client to get alternate remote permissions on the agent. By default the client is challenged for the respective user’s password but with the -p option no password is requested. The rsu= entry defines which users the client is allowed to rsu without challenging them for a password. If the client tries to use the rsu command with the -p option (that is, no password challenge) and then tries to switch to a user not in the list, access is denied.

rw The named user has read/write access.

validuser This entry tells the daemon that the user name/UID/GID combination of the remote (incoming) user must match a user name/UID/GID combination on the local host.

Option Description


Secure file

map them to user Administrator. These entries are used for granting permissions to Network Shell users. The fifth entry grants read-only access to user3, who is associated with the role of JrAdmin and is mapped to Anonymous on this server. The last entry forbids access to all users who are not specified in the users file.

SrAdmin:user1 rw,map=AdministratorSrAdmin:user2 rw,map=Administratoruser1 rw,map=Administratoruser2 rw,map=AdministratorJrAdmin:user3 ro,map=Anonymousnouser

The following example in the users.local file grants read/write access to user1 and user2 if they are connecting from either host1 or host2 and they have a local account with the same user name and user ID as they do on the host from which they are connecting. If user1 is not connecting from host1 or host2, then user1 is only given access to the /data directory and granted the permissions of user3. If user2 is not connecting from host1 or host2, user2 is granted read-only permission.

user1 hosts=host1:host2,rw,validuseruser2 hosts=host1:host2,rw,validuseruser1 rw,rootdir=/data,map=user3user2 ro

The following example in the users.local file grants read/write access to user1 and user2 and forbids access to all other users.

user1 rwuser2 rwnouser

Secure file The secure file defines how BMC BladeLogic applications for a client installation and the RSCD agent on a server communicate with each other. In this discussion, a client application can be a Network Shell client, BMC BladeLogic Application Server, or Network Shell Proxy Server that communicates directly with an RSCD agent or repeater.

The secure file for a client application defines parameters that BMC BladeLogic applications use to communicate with the RSCD agent on a server. The secure file on the server defines parameters that the RSCD agent uses to communicate with BMC BladeLogic applications on clients. The exports, users, and users.local files control user access to servers (see “Exports file” on page 240 and “Users and users.local files” on page 247).


Clients, servers, and the secure file

By default, client and server processes communicate via TCP/IP port 4750 with the server process listening on all configured NIC (Network Interface Card) addresses. The port number can be set with an entry in the Internet services databases (for example, /etc/services).

For simpler security installations, you need only modify the secure file to establish how data is communicated between clients and servers. Stronger security requires additional modifications to a system. See Chapter 4, “Administering security” for a full description of all the procedures needed to implement security in a BMC BladeLogic system.

Always use the secadmin utility to modify the secure file. Using the secadmin utility ensures that the secure file is formatted correctly. For more information, see “Using the secadmin utility” on page 258.

The secure file resides in different locations in Windows and UNIX-style systems, as described in the following table. On Windows, you can have multiple instances of BMC BladeLogic client applications, each with their own secure file. The following table shows how the location of the secure file on Windows varies between the first instance and all subsequent instances.

Clients, servers, and the secure file

When a BMC BladeLogic application on a client attempts to connect to an RSCD daemon on a server, the application first checks the secure file for a client to see how the connection should be established. If an entry for the target server exists in the secure file, the application checks the secure file to see if and how the connection should be redirected and whether data should be encoded, encrypted, or sent as clear text. If an entry for the remote host is not found, the application searches for an entry

Platform

Name and location of secure file for first instance of BMC BladeLogic

Name and location of secure file for additional instances


/usr/lib/rsc/secure Not applicable

Windows WINDIR\rsc\secure

For example, WINDIR can be \windows or \winnt.

installDirectoryN\version\NSH\conf\secure

For example, the default location for the second instance of BMC BladeLogic would be C:\Program Files\BMC Software\ BladeLogic2\version\NSH.


Communication protocol

called default to determine how the connection to the remote host should be made. (For more on configuring entries in the secure file, see “Configuring the secure file” on page 255.) If the secure file does not include an entry for the remote host or a default entry, the attempt to establish a connection is aborted.

TCP is a bi-directional virtual circuit protocol. As such, when a client establishes a connection to an RSCD daemon on a server, that connection is used to both send and receive data.

To determine where to listen for connection requests, the RSCD daemon consults the secure file on the server. It looks for an entry for a host named rscd. If an entry is not found, the daemon listens by default to port 4750 (or as otherwise defined in the Internet services databases). If an rscd entry is found, the software treats it as a special entry used by the RSCD daemon. The rscd entry can specify which port and address to listen to for connection requests and it can specify default communication parameters. (For more on configuring the rscd entry, see “Configuring the secure file” on page 255.) The RSCD daemon can listen on a specified port on all available NICs or a particular NIC (specified using the host= field, as described in “Options for secure file” on page 258). The RSCD daemon cannot listen to a port on a list of specified NICs. In other words, it can only listen on one NIC or all NICs.

When a client establishes a connection, the RSCD daemon again refers to the secure file to determine what data encoding/encryption it should expect from the client host. The RSCD first checks for an entry for the connecting host. If such an entry exists, the agent uses the connection parameters defined in that entry. If no entry for the connecting host is found, the daemon uses the default values from the rscd entry.

Communication protocol

Protocol 5, the BMC BladeLogic default communication protocol, establishes rules for communication between BMC BladeLogic clients and Application Servers and the RSCD agent. By default, protocol 5 uses Transport Layer Security (TLS), the successor to SSL, which automatically negotiates the strongest form of encryption that clients and servers can support. BMC BladeLogic clients and RSCD agents use the TLS_RSA_WITH_AES_256_CBC_SHA cipher suite. For a more detailed description of the capabilities of this suite, see “Session layer security” on page 118.

Configuring the secure file

When configuring the secure file, you can make three types of entries:

■ default

■ rscd



■ host

Always use the secadmin utility to configure the secure file. The secadmin utility encrypts any keys needed for data encryption and guarantees that the secure file is formatted correctly. For more information, see “Using the secadmin utility” on page258.

Default entry

The secure file allows for a special host name called default. It defines connection parameters for servers that otherwise do not have an entry in the secure file. Creating a default entry is an easy way to define the same communication parameters for multiple servers without having to configure entries for each of those servers.

A default entry in the secure file uses the following format:

default:option1:option2:option3...

where optionN is a list of colon-separated fields. Each option in the list defines a parameter for communicating with all servers that do not have a host entry specifically defined for them. For a complete list of available options, see “Options for secure file” on page 258.

When you initially install Network Shell, the BMC BladeLogic consoles, or the RSCD agent, a default entry is automatically created in the secure file. The default entry specifies that the client use protocol 5 and instructs clients and servers to communicate using the TLS protocol for secure communication. The default entry also designates the default port as 4750. The default entry that is automatically generated in a client’s secure file reads as follows:

default:port=4750:protocol=5:tls_mode=encryption_only:encryption=tls

rscd entry

The secure file allows for another special host name called rscd. It defines standard connection parameters that are used for an RSCD agent on a server communicating with clients when those clients are not included in the list of host entries on the server’s secure file. Creating an rscd entry is an easy way to define the same communication parameters for all of the servers in your system that are not otherwise configured in the secure file.

An rscd entry in the secure file uses the following format:

rscd:option1:option2:option3...



where optionN is a list of colon-separated fields. Each option in the list defines a parameter for communicating with all agents that do not have a host entry specifically defined for them. For a complete list of available options, see “Options for secure file” on page 258.

When you initially install an RSCD agent on a server, an rscd entry is automatically created in the secure file. The rscd entry specifies that the RSCD agent use protocol 5 and instructs clients and servers to communicate using the TLS protocol for secure communication. The rscd entry also designates the default port as 4750. The rscd entry that is automatically generated in the secure file on a server reads as follows:


Host entries

Host entries in the secure file on a server set connection parameters that define how that server communicates with individual clients. Host entries in the secure file on a client set connection parameters that define how that client communicates with individual servers. You must make corresponding entries in the secure file on both the client and server to establish a connection between client and server.

To configure host entries in the secure file, create entries that define parameters for a connection with a particular host. Use the following format for each entry:

hostName:option1:option2:option3...

where,

hostName is the host with which the client or server is communicating. hostName can be a resolvable host name, IP address, or subnet designation. Subnet designations are used to define a range of addresses (see “Subnet designations” on page 236).

optionN is a list of colon-separated fields. Each option defines a parameter for communicating with the host (or subnet) named in hostName. For a complete list of available options, see “Options for secure file” on page 258.

NOTE If you change the RSCD agent port number in the secure file, you must restart both the Application Server as well as the RSCD agent on the system(s) where you changed the secure file for the change to take effect.


Options for secure file

Using the secadmin utility

With the secadmin utility, you can create, modify, or delete entries in a secure file. You can also create, modify, or delete default or rscd entries in the secure file. Additionally, the secadmin utility lets you modify entries in the securecert file.

Example

If you are using protocol 5 and you want to specify TLS-style encryption between a client called host1 and three servers called host2, host3, and host4, you would use secadmin to make the following additions to the secure file on host1:

secadmin -a host2 -p 5 -T encryption_only -e tls



Next, you must use secadmin to modify the secure file on host2, host3, and host4 by entering the following command on each of those servers:

secadmin -m host1 -p 5 -T encryption_only -e tls

If you are using secadmin on a server where Network Shell is not installed, you must include the full path to the secadmin utility when running a secadmin command. By default, you can find secadmin in the following locations:

■ UNIX: /opt/bmc/BladeLogic/version/NSH/secadmin

■ Windows: C:\Program Files\BMC Software\BladeLogic\version\RSCD\secadmin

For a complete description of the secadmin utility, see the man page for secadmin.


An entry in the secure file can include the following fields:



Option Description

appserver_protocol=protocol This field specifies the authentication protocol used when communicating with a Network Shell Proxy Server. For more on Network Shell Proxy Servers, see “Configuring the Network Shell Proxy Service” on page 142.

You can set protocol to the following:

ssoproxy Use the single sign-on functionality when communicating with the Network Shell Proxy Server. This is the default value for appserver_protocol.

compression=value This field sets a data compression level. By default, data is not compressed. If you want to use data compression, set value to a number between 1 and 9, where a higher number calls for better compression. Be aware, however, that better compression is more CPU intensive. Typically you should use compression when communicating through a thin pipe. In a LAN environment the overhead required for compressing and uncompressing data is usually greater than the time saved transferring compressed data.

encryption=type This field determines the type of data encryption that should be used. Set this field to tls, which specifies that BMC BladeLogic should automatically negotiate an encryption method (usually AES).

host=value This field is used differently, depending on whether a secure file entry defines the special host name rscd:

■ When applied to an rscd entry, the host= field determines the address to which the agent should listen for client connections. If a system has a single NIC card, you do not have to set this field because the agent automatically listens on the default system NIC card (address). The host= field should only be used for systems with multiple NIC cards (real or virtual) so you can select the NIC (address) to which the RSCD agent should listen.

■ When applied to a non-rscd entry, the host= field can be used to redirect data between hosts. If the remote daemon to which the data is being sent is not another RSCD daemon, then it will be the responsibility of the of the remote daemon to forward the data to an RSCD daemon and also return any data it may return.

keepalive=value This field specifies whether the agent should send TCP keep-alive messages to the other side of a connection. If keep-alive messages are sent, the connecting system will notice the death of a connection or a machine crash. If TCP keep-alives are not sent, sessions may hang indefinitely leaving hung processes or threads on the agent. Possible values for this field are yes or no. The default value, if unset, is yes.



lock=value When set to a non-zero positive value, this field determines the maximum number of times a bad connection is allowed from a source address before the address is locked. A bad connection can happen if encryption is not set up properly or a particular host is not granted access. The address is locked for a period of time as defined by the unlock= field (see below).

port=value This field can be used to redirect data to a port other than the default port of 4750. On most UNIX systems, access to port numbers under 1024 requires root permissions. When selecting an alternate port number, make sure it does not conflict with some other existing service. Also, when using this field, make sure that both the client and server machines are configured to use the same port number.

protocol=value This field determines the transport protocol used for communication between BMC BladeLogic applications and the RSCD agent. Protocol 5, the default protocol, uses the TLS protocol (TLS is the successor to SSL) for communication between client and server.

auth_profile=profile This field identifies the authentication profile that should be used to provide session credentials to Network Shell when communicating with a Network Shell Proxy Server. If you need to use multiple Network Shell Proxy Servers, you can set up a different secure file entry for each profile. Using the BL_AUTH_PROFILE_NAME environment variable, you can override the value defined with this field. For more on Network Shell Proxy Servers, see “Configuring the Network Shell Proxy Service” on page 142.

auth_profiles_file=filename This field provides the Network Shell-style path to the file containing authentication profile definitions, which are necessary when Network Shell communicates with a Network Shell Proxy Server. Using the BL_AUTH_PROFILES_FILE, you can override the value defined with this option. For more on Network Shell Proxy Server, see “Configuring the Network Shell Proxy Service” on page 142.

timeout=secs When first contacting a remote server, the TCP protocol may continue to contact an offline or unavailable server for several minutes before finally giving up and reporting that a server is unavailable. This option lets you set the maximum number of seconds that a client will wait before giving up. The default value is 30 seconds.

This timeout mechanism is implemented within the BMC BladeLogic code and does not in any way alter any system wide TCP parameters. If the operating system has an effective TCP timeout less than the value defined here, the OS value will take precedence.

Option Description


Examples

Examples

The following examples are meant to serve as sample uses of the fields available in a secure file. To generate entries in a secure file like those shown below, use the secadmin utility. Using the secadmin utility ensures that the secure file is formatted correctly. For more information, see “Using the secadmin utility” on page 258.

The following example shows a typical default entry for BMC BladeLogic clients.

default:port=4750:protocol=5:encryption=tls

The following example shows a subnet in an entry:

@192.168.12.13/24:protocol=5:encryption=tls

tls_mode=value When using protocol 5, this field specifies one of the following values:

encryption_only Use the TLS protocol to auto-negotiate an encryption type (that is, a cipher) and then use that cipher to communicate. Client-side authentication or certificates are not required.

encryption_and_auth Use TLS for encryption and client-side authentication. This option requires a certificate. For more on certificates, see “Implementing security – Application Server to agents or repeaters” on page 202.

unlock=value This field is used in conjunction with the lock= field, which allows you to lock out IP addresses that repeatedly fail to connect to the (RSCD agent) server. These failures are limited to encryption misconfigurations and host authorization errors. With the unlock= field, you can specify how many minutes the IP address should be locked before allowing connection attempts to resume. If value is a negative number, the IP address is locked until the RSCD agent is restarted. The default value for unlock= is 1 minute.

x11_fwd=on |off This field turns off X11 forwarding. By default this field is set to on and X11 forwarding is enabled for this agent.

x11_port_offset=value This field defines an offset from 6000, and together these values specify the port that the agent binds to for X11 forwarding. By default X11 forwarding starts at port 6010 (6000 plus an offset of 10). Any new connections afterwards increments the offset by one (that is, 6011, 6012, and so forth).

Option Description


Securecert file

The following example instructs a Network Shell client to communicate with a Network Shell Proxy Server using an authentication profile called QAProfile. The authentication profile is stored in the default location for the authentication profile file:

default:protocol=5:encryption=tls:appserver_protocol=ssoproxy: auth_profile=QAProfile:auth_profiles_file=/opt/bmc/BladeLogic/version/NSH/br/ authenticationProfiles.xml

The following example shows how to use a port other than the default port of 4750. If you use host1 as the client host and host2 as the remote host, the following entry should be in the secure file of host1

host2:port=987

while the following entry should be in the secure file of host2:

host1:port=987

The following example shows how to instruct the RSCD agent to listen on a specific address for client connections:

rscd:host=192.168.10.20

Securecert fileThe securecert file stores passphrases used to encrypt the private keys for X.509 certificates. By storing passphrases in the securecert file, BMC BladeLogic can access those passphrases without any user interaction. Accessing passwords non-interactively is essential for setting up secure, certificate-based communication with an Application Server. It is also necessary when using secure communication to deploy assets via repeaters (that is, with an indirect deployment).

When setting up a securecert file for an Application Server, you must provide an entry for the owner of the process that communicates securely with repeaters and servers. The owner of the process is bladmin on UNIX-style systems and SYSTEM on Windows.

When setting up a securecert file for a repeater, you must provide an entry for all users that communicate with servers. On UNIX-style systems, you must provide an entry for any users to whom other users are mapped (typically root). On Windows, you must provide an entry for the user named BMC BladeLogicRSCD.

For more information on using the securecert file while setting up security for a BMC BladeLogic system, see Chapter 4, “Administering security.”.


Configuring the securecert file

The securecert file resides in different locations on Windows and UNIX-style systems, as described in the following table. On Windows, you can have multiple instances of BMC BladeLogic client applications, each with their own securecert file. The following table shows how the location of the securecert file on Windows varies between the first instance and all subsequent instances.

Configuring the securecert file

When configuring a securecert file, you can make entries for the Application Server and repeaters.

On the Application Server, create an entry like the following for the owner of the process that communicates securely with repeaters and servers:

[Default]

processOwner=********

where processOwner is bladmin for UNIX-style systems and SYSTEM for Windows.

You must use the secadmin utility to modify a securecert file. (For more on secadmin, see “Using the secadmin utility” on page 258 or the man page for secadmin). To create an entry like the one shown above using the secadmin utility, enter the following command:

secadmin -m default -cu bladmin -cp password

Enter the password in clear text. The secadmin utility encrypts the password.

On repeaters, create an entry like the following for the administrative user that communicates with servers:

Platform

Name and location of securecert file for first instance of BMC BladeLogic

Name and location of securecert file for additional instances


/usr/lib/rsc/securecert Not applicable

Windows WINDIR\rsc\securecert


installDirectoryN\version\NSH\conf\securecert



BMC BladeLogic log file reference

[Default]adminUser=********

where adminUser is typically root for UNIX-style systems and BladeLogicRSCD for Windows. Using the secadmin utility to create the entry like the one shown above, enter the following command:

secadmin -m default -cu root -cp password

BMC BladeLogic log file reference

About logging configuration for BMC BladeLogic

BMC BladeLogic uses log4j to capture log messages from the console and the BMC BladeLogic Application Server. Log4j is an open source logging framework used to control logging output from Java applications. For more information on log4j, see http://jakarta.apache.org/log4j/docs/.

Unless instructed otherwise by BladeLogic Support, the default logging configuration is recommended for normal operation. BladeLogic Support may ask the Application Server Administrator to enable DEBUG logging for a single logger when debugging a particular issue. This change will typically be backed out once the requested DEBUG information has been gathered.

Overview of BMC BladeLogic log files

A standard BMC BladeLogic installation provides default logging behavior that satisfies the needs of many organizations. Defaults vary for Windows and UNIX-style systems.

The default behavior for Windows is:

■ The RSCD agent logs to rscdInstallDirectory\rscd.log as a rollfile at the info1 level.

■ The RSCD agent service logs to rscdInstallDirectory\rscdsvc.log as a rollfile at the info level.

■ BLPackage Deploy Jobs log at the debug level to locations based on the name and location of the jobs.


http://jakarta.apache.org/log4j/docs/


■ BLPackage Deploy Jobs on the console log to stdout as a stream at the debug level. The priority level can be overridden using Transaction Options when defining the BLPackage Deploy Job. For more information, see the BMC BladeLogic Server Automation User Guide.

■ The Application Server logs to installDirectory\br\appserver.log as a stream at the info level.

The default behavior for UNIX is:

■ The RSCD agent logs to rscdInstallDirectory/log/rscd.log as a rollfile at the info1 level.

■ BLPackage Deploy Jobs log at the debug level to locations based on the name and location of the jobs.

■ BLPackage Deploy Jobs on the console log to stdout as a stream at the debug level. The priority level can be overridden using Transaction Options when defining the BLPackage Deploy Job. For more information, see the BMC BladeLogic Server Automation User Guide.

■ The Application Server logs to installDirectory/br/appserver.log as a stream at the info level.

Table 1 lists the various log files that are used by BMC BladeLogic which may be of interest to you.

Table 1 Overview of BMC BladeLogic log files (part 1 of 3)

Log file name Description and default location Where to configure

Application Server

appserver.log Application Server log

installDirectory/br/appserver.log

Infrastructure Management => AppServer Launcher => Edit AppServer LogfileName attribute

installDirectory/br/deployments/deploymentName/log4j.properties

AppServerLauncher.log AppServer Launcher log

installDirectory/br/AppServerLauncher.log

installDirectory/br/deployments/_template/log4j.properties

post_install.log Application Server configuration log

installDirectory/br/post_install.log




Console.log Application Server Console log

installDirectory/br/Console.log

Infrastructure Management => AppServer Launcher => Edit AppServer ConsoleLogfileName attribute

installDirectory/deployments/deploymentName/log4j.properties

RSCD Agent (Windows)

rscd.log* Windows RSCD Agent log

rscdInstallDirectory\rscd.log

rscdInstallDirectory\log4crc.txt

keystroke.log* nexec session log

rscdInstallDirectory\keystroke.log*


rscdsvc.log* RSCD agent service

rscdInstallDirectory\rscdsvc.log


*.log Deploy Job log

rscdInstallDirectory\Transactions\log\*.log


RSCD Agent (UNIX)

rscd.log* UNIX RSCD Agent log

rscdInstallDirectory/log/rscd.log

rscdInstallDirectory/log4crc.txt

keystroke.log* nexec session log

rscdInstallDirectory/log/keystroke.log*


*.log Deploy Job log

rscdInstallDirectory/Transaction/log/*.log


RCP Client (Windows)

.log BMC BladeLogic Console log

WindowsHomeDirectory\BladeLogic\1_1_2\Workspacen\.metadata\.log

installDirectory\br\rcp.cf

BLWorkbenchPlugin.log BLWorkbenchPlugin log

WindowsHomeDirectory\BladeLogic\1_1_2\Workspacen\.metadata\.plugins\com.bladelogic.client.ui\BLWorkbenchPlugin.log

installDirectory\br\rcp.cf

RCP Client (UNIX)

.log BMC BladeLogic Console log

/root/.bladelogic/1_1_2/Workspacen/.metadata/.log

installDirectory/br/rcp.cf




Application Server logging


Logging is controlled at the Application Server instance level. Within the configuration files for each specific deployment, logging is controlled by the log4j.properties configuration file, which is located in the Application Server installation directory for that deployment. By default, the file is located in

By default, Application Server logging output is written to the appserver.log file, also located in the Application Server installation directory for the specific deployment.

The following sections provide information on the log4j.properties file.

BLWorkbenchPlugin.log BLWorkbenchPlugin log

/root/.bladelogic/1_1_2/Workspacen/.metadata/.plugins/com.bladelogic.client.ui/BLWorkbenchPlugin.log

installDirectory/br/rcp.cf

PXE server

pxesrvr.log* PXE Server log

installDirectory/br/pxesrvr.log*

installDirectory/br/deployments/_pxe/log4j.properties

tftpsvr.log* TFTP Server log

installDirectory/br/tftpsvr.log*

installDirectory/br/tftpsvr.cf

BLCLI (Windows)

blcli.log BLCLI Windows log

C:\Documents and Settings\Administrator\Application Data\BladeLogic\blcli.log

C:\Documents and Settings\Administrator\Application Data\BladeLogic\blcli-log.cf

BLCLI (UNIX)

blcli.log BLCLI UNIX log

/.bladelogic/blcli.log

/.bladelogic/blcli-log.cf






Modifying logging configuration using log4j.properties

In addition to controlling the logging information, the log4j.properties file can also control where the logging information is stored and how the log files are managed. This section describes how to manipulate some of the basic properties of the configuration file.

Modifying basic logging attributes

Table 2 on page 268 describes some of the basic log attributes that can be controlled by modifying options in the log4j.properties file. There are comments within the file describing other options not defined here.

Additional debug logging

The log4j.properties file contains a large list of loggers that can be configured to add useful debug information. These loggers are initially configured with the log level INFO to prevent the log files from containing too much information. When debugging specific issues with the system, you can modify one or more of the specified loggers in the file to set the log level to DEBUG.

Table 2 Modifying basic Application Server logging attributes


Log Files Location You can set the log file location using the log4j.appender.R.File option, specifying the relative or full path of the log file. This option instructs the log4j system to use the specified path for logging.

Maximum file size You can set the maximum file size for the log file using the log4j.appender.R.MaxFileSize option. By default, the maximum log file size is 5000KB.

Number of roll-over files You can set the number of roll-over files using the log4j.appender.R.MaxBackupIndex option. When a log file reaches its maximum size, a backup file will be made and a new log file will be created. This value controls how many backup files will be retained. By default, the maximum number of roll-over files is 5.

Performance logging You can enable logging of performance-related information pertaining to the Application Server. To do so, locate the BlDeploy appserver performance logging section in the file and uncomment the lines in that section.

Timing for Deploy Jobs You can enable logging of timing information pertaining to the Deploy Jobs. To do so, locate the timing for deploy jobs section in the file and uncomment the lines in that section.

Content Authoring Log configuration

You can enable logging of Content Authoring debug information. To do so, locate the Content Authoring related debug logs section in the file and uncomment the lines in that section.



There are many logger options that give you the ability to enable debug logging for very specific tasks. For example, the following options in the log4j.properties file control loggers that are useful for debugging:

■ log4j.logger.com.bladelogic.app.db.DBServiceImpl – This logger controls messages generated by the database service.

■ log4j.logger.com.bladelogic.mfw.demux.Demux – This logger controls messages generated by the networking layer.

See the comment lines in the log4j.properties file for additional information on these logger options.

To enable basic debug logging

1 Open the log4j.properties file.

2 Locate the following line:

3 Modify the line to read:

Once saved, the application server will automatically detect the logging level modification after a short period of time and being logging data in debug mode.

Modifying log file names from the BMC BladeLogic Console

You can also modify basic logging options for the Application Server from the BMC BladeLogic Console.




NOTE Debugging issues with the Application Server often require assistance by BMC BladeLogic Customer Support.

log4j.rootLogger=INFO, R, C

log4j.rootLogger=DEBUG, R, C



4 In the Edit Application Server Profile dialog, add or change values for the following attributes.

5 When you are finished editing the profile, click OK.

6 Click OK on the warning that configuration changes do not take effect until you restart the Application Server.

7 Start or restart the Application Server to have changes take effect.

Enabling more detailed logging

In addition to the appserver.log file, an Application Server running on Linux or Solaris can be configured to write all the standard output and standard error information into a file called console.log.

The console.log file is useful for debugging when certain output is not captured by the regular log files. The console.log file contains the same information as the appserver.log file, but in addition it also captures any output that does not go through the log4j logging system. For example, information such as the java thread dump and any messages generated by third party code used by the Application Server that logs messages to standard out/err.

As with the Application Server log files, the console log files are configured to rollover. You can set the number of roll-over files for the console log file in the log4j.properties file accessed from the _template deployment directory (/br/deployments/_template/log4j.properties).


ConsoleLogfileName The name of the console log file for the Application Server. The console log file contains all information logged to the Application Server log, plus any information logged to the console.

When you create a new Application Server, BMC BladeLogic sets the console log file’s name to the Application Server name plus “_console”. This convention avoids conflicts when there are multiple Application Servers on the same host.


Console logging is enabled by default. To disable console logging, set the ConsoleLogfileName to be empty.

LogfileName The name of the log file for the Application Server.

When you create a new Application Server, BMC BladeLogic sets the log file’s name to the Application Server name plus the .log extension. This convention avoids conflicts when there are multiple Application Servers on the same host.



Agent logging

Agent logging

The log4crc.txt file allows you to control Agent logging in BMC BladeLogic so that all Agent events are logged using consistent formats. The log4crc.txt file is XML-based. By modifying XML tags in log4crc.txt, you can control which log files BMC BladeLogic generates, how much information is included in each file, where each log file is generated, how often logs are rotated, and what sort of layout the contents of each log should use.

For detailed information, see “About the Log4crc.txt file” on page 272.

PXE Server logging

The log file for the PXE Server is controlled with the log4j.properties file located in the PXE server deployment (_pxe directory).

Additional log files of interest

Additionally, BMC BladeLogic uses the following configuration files (all found in installDirectory/br) to control logging with log4j:

■ ui.cf—Configures ui.log, which logs messages from the BMC BladeLogic Console.

■ tftpsvr.cf—Configures tftpsvr.log, which logs messages from the TFTP server.

For more information on log4j, see http://jakarta.apache.org/log4j/docs/.

Collecting log data

You can use the Support Data Generation tool to capture log data that you can then send to BMC Software Customer Support. You access the tool from the BMC BladeLogic Console by selecting Configuration => Generate Support Data.

The Generate Support Data tool generates data about the Application Servers and other components in the BMC BladeLogic environment and packages that data into a zip file. This data can be useful for diagnostic purposes when you contact Customer Support.

For specific instructions, see “Generating data for support” on page 19.


http://jakarta.apache.org/log4j/docs/

About the Log4crc.txt file


The log4crc.txt file allows you to control Agent logging in BMC BladeLogic so that all Agent events are logged using consistent formats. The log4crc.txt file is XML-based. By modifying XML tags in log4crc.txt, you can control which log files BMC BladeLogic generates, how much information is included in each file, where each log file is generated, how often logs are rotated, and what sort of layout the contents of each log should use.

The log4crc.txt file resides in different locations on Windows and UNIX-style systems, as described in the following table. On Windows, you can have multiple instances of BMC BladeLogic client applications, each with their own log4crc.txt file. The following table shows how the location of the log4crc.txt file on Windows varies between the first instance and all subsequent instances.

Syntax

The syntax of the log4crc.txt file consists of three tags:

<category><appender><layout>

NOTE The log4crc.txt file is used to control Agent logging. For Application Server logging, you control logging attributes using the Infrastructure Management window on the BMC BladeLogic Console and in the Application Server profiles of each default and custom profiles. The log appender, logging level, and logging format for Application Server logs are controlled using the log4j.properties file. For more information, see “Application Server logging” on page 267.

Platform

Name and location of log4crc.txt file for first instance of BMC BladeLogic

Name and location of log4crc.txt file for additional instances


/usr/lib/rsc/log4crc.txt Not applicable

Windows WINDIR\rsc\log4crc.txt


installDirectoryN\version\NSH\conf\log4crc.txt




category

The <category> tag identifies the types of logging that BMC BladeLogic generates. The <category> tag can include three options: name, priority, and appender. The following list shows the <category> tags included by default in the log4crc.txt file in a Windows installation. Default values vary somewhat for UNIX-style installations.

The name= option identifies the type of log file BMC BladeLogic generates. The following table identifies all possible names:

The priority= option specifies the amount of information included in a log. The following table identifies the possible priority levels:

<category name="root" priority="info"/><category name="rscd" priority="info1" appender="C:/Program Files/BMC Software/BladeLogic/version/RSCD/rscd.log" debugappender="stderr"/><category name="rscdsvc" priority="info" appender="C:/Program Files/BMC Software/BladeLogic/version/RSCD/rscdsvc.log" debugappender="stderr"/><category name="bldeploy" priority="debug"/><category name="bldeployConsole" priority="debug" appender="stdout"/><category name="bldeployAppserver" priority="error" appender="blbasic"/>

Name Description

rscd Generates a log for the RSCD agent.

keystroke Generates a keystroke log that records nexec sessions. By default, this is disabled (commented out). Uncomment it to enable keystroke logging. For more information, see “Enabling keystroke logging” on page 283.

rscdsvc Generates a log for the RSCD agent server, which monitors the RSCD agent and restarts the agent if necessary. This option only applies to Windows installations.

bldeploy A category managed internally by Deploy Job executables. Do not modify this <category> tag.

bldeployConsole Agitator managed internally by Deploy Job executables. Do not modify this <category> tag.

bldeployAppserver Agitator managed internally by Deploy Job executables. Do not modify this <category> tag.

Priority Description

fatal Logs only fatal errors.

error Logs all errors, including fatal errors.

warn Logs all warnings and errors.

info Logs only connection information.



Note that keystroke logs (where name is set to keystroke) support only the following options:

The appender= tag provides a name and path for a log file. Enter the path using a UNIX or Windows format. Do not use a Network Shell-style path.

appender

The <appender> tag specifies whether logging information is stored as a stream in a file or periodically rolled over into a new file, usually to prevent log files from getting excessively large. You can specify that log files are rolled at specified intervals or when log files reach a particular size. The <appender> tag also lets you specify secure agent logging and keystroke logging.

When a log file is rolled, the file is renamed with a number appended to its name. For example, rscd.log is renamed to rscd.log1. All new information is then recorded in the rscd.log file. When the log file is rolled again, rscd.log1 is renamed to rscd.log2, the current log file is renamed to rscd.log1, and all new information is recorded in rscd.log.

info1 Logs connection information and user actions. This priority is only valid for the RSCD agent log (that is, the <category> tag named rscd). This priority corresponds to logging level 1 in older releases of BMC BladeLogic.

info2 Logs connection information and user actions, as well as all the system calls that an RSCD agent performs to execute user actions. This priority is only valid for the RSCD agent log (that is, the <category> tag named rscd). This priority corresponds to logging level 2 in older releases of BMC BladeLogic.

debug Logs all messages.


info Logs only the STDIN stream of the command being run by nexec.

info1 Logs the STDIN and STDERR streams of the command being run by nexec.

info2 Logs the STDIN, STDERR, and STDOUT streams of the command being run by nexec.




The <appender> tag can include three options: name, type, and layout. The following list shows the <appender> tags that are included by default in the log4crc.txt file.

The name= option must match the name (including its full path) assigned to an appender option in a <category> tag.

The type= option specifies what type of log file to generate. The following table identifies the possible types:

<appender name="stdout" type="stream" layout="basic"/><appender name="stderr" type="stream" layout="basic"/><appender name="syslog" type="syslog" layout="basic"/><appender name="/tmp/bllog" type="stream" layout="dated"/><appender name="C:/Program Files/BMC Software/BladeLogic/version/RSCD/rscd.log" type="rollfile" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="dated"/>

 <appender name="C:/Program Files/BMC Software/BladeLogic/version/RSCD/rscdsvc.log" type="rollfile" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="dated"/>

NOTE The two commented out entries (where type is set to digisign or encrypt) are used in secure logging, a feature that is disabled by default. For information about secure logging, see “Using secure agent logging” on page 277 and “Using keystroke log files” on page 281.

NOTE You can only roll log files when one source of logging data is being used to create a log file. In other words, only one category can be output to a single log. If multiple sources are output to the same log, you cannot use type=rollfile to roll log files. Instead, you must set type=stream.

Type Description

stream Logging information is output in a continuous stream to a file.

syslog Logging information is output to the UNIX syslog. If you are using this option for UNIX systems, you must configure the UNIX syslog daemon (see “Configuring the UNIX syslog” on page 284).



rollfile Logging information is output to a file that is periodically rolled over into another file. If you set type=rollfile, you can specify how log files are rotated by including one or more of the following options in the <appender> tag:

rollsize Specifies a maximum number of characters for the log file. When the file reaches that maximum, log files are rolled.

rolltimeinsec Specifies an interval in seconds for rolling log files.

rollmaxfiles Specifies the maximum number of files used for logging. For example, if you set rollmaxfiles=10, you can store log files named log.1 to log.10. In this case, if you have already generated ten log files, the next time the log files roll over, the information in file log.10 is lost.

digisign As with rollfile, logging information is output to a file that is periodically rolled over into another file. In addition, log entries and rolled log files are protected using the security mechanisms described in “Using secure agent logging” on page 277.

The parameters rollsize, rolltimeinsec and rollmaxfiles mean the same as they do for rollfile.

In addition to these parameters, digisign needs the following additional parameters:

certfile Specifies the file containing the agent’s certificate.

privatekeyfile Specifies the file containing the agent’s private key.

encrypt Used for keystroke log files. As with rollfile, logging information is output to a file that is periodically rolled over into another file. In addition, log entries and rolled log files are encrypted and protected using the security mechanisms described in “Using keystroke log files” on page 281.

The parameters rollsize, rolltimeinsec, and rollmaxfiles mean the same as they do for rollfile.

In addition to these parameters, encrypt needs the following additional parameters:

certfile Specifies the file containing the agent’s certificate.

privatekeyfile Specifies the file containing the agent’s private key.

Type Description



The layout= option specifies the type of layout used for logging information. The following table identifies all possible layouts:

<layout>

The <layout> tag defines the format of logging entries. Users should not modify the syntax of the <layout> tag. To develop additional logging formats, contact BMC Software support.

Using secure agent logging

Secure agent logging is a rolling log mechanism that protects your RSCD agent log files by:

■ Securing each entry in the current log file with a Message Authentication Code (MAC) and sequence number.

■ Protecting rolled log files with digital signatures.

■ Verifying the integrity of log files, and recording the status of each verification. You can later check log file integrity by using the bllogman command.

For additional information about secure agent logging, see:

■ Overview of the security processes■ Verifying the integrity of log files■ Enabling secure agent logging■ Disabling secure agent logging

Overview of the security processes

Here is an overview of the security processes that take place as an agent writes and rolls a log file.

Type Description

basic Log entries use the same format of the data that is generated for the log message.

dated A time stamp precedes all log entries. Except for the time stamp, log entries use the same format as the data that is generated for the log message.

rawtime Used only when type is set to encrypt. This layout outputs minimal information in the log file—just the timestamp and the actual message. It does not output the category name and log level that the basic and dated layouts do.



1. Before beginning to write its first log file, the RSCD agent generates a random session key. The agent will use this key to calculate a Message Authentication Code (MAC) for each entry in the log file.

Note that this session key will be used only for the writing of this one log file. When this log file is rolled and it is time to start a new log file, the agent will generate a new session key.

2. The RSCD agent starts writing its first log file—rscd.log.

As it writes each log entry, it uses the session key to calculate a MAC and associate this MAC with each log entry. It also associates a sequence number with each entry.

3. When it is time for a rollover, rscd.log is rolled to rscd.log1.

The following events take place at rollover:

■ MAC verification test and sequencing test.

The agent verifies the integrity of each log entry in the rolled log file, rscd.log1, against each entry’s MAC. It also verifies the sequence number (or in other words, the order) of each log entry.

If either the MAC test or the sequencing test fails, the agent raises an event (in EventLog on Windows and syslog on UNIX-style systems) indicating that the file has been tampered with.

■ Digital signature file.

The agent creates a corresponding digital signature file for the rolled log file rscd.log1. In this case, the corresponding signature file would be called rscd.log.sig1.

— The signature file has a status field. If the rolled log file failed the MAC test or the sequencing test, the status field is set to Inconsistent. If the rolled log file passed the MAC test and the sequencing test, the status field is set to Consistent.

MAC Sequence number

3d8591f27a805b0edac5 0000000012 07/28/07 02:45:16.269 INFO

rscd - 10.20.21.222 23694 99/99 (Administrator): nexec: nexec engrhes40vm10

ifconfig -a



You can use the information stored in the status field to verify the integrity of a rolled log file, as described in “Verifying the integrity of log files” on page279.

— The MAC and sequence number fields are stripped as part of the process of signing the rolled log file.

— At the next roll, the signature file will be rolled along with its associated log file.

4. The cycle begins again, with the creation of a new random session key for use in creating MACs for the next version of rscd.log.

Verifying the integrity of log files

You can verify the integrity of all agent log files by using the NSH command, bllogman.

Example:

In the above example, there are five log files on the agent machine, engrhes40vm10. One file (rscd.log3) is reported as Inconsistent, which indicates that it has been tampered with.

For additional information about bllogman, see the bllogman man page.

Enabling secure agent logging

You can enable secure agent logs as part of your initial installation (see the BMC BladeLogic Server Automation User Guide) or later on, as described the procedure below.

NOTE If an agent is restarted, the previous log file is automatically rolled and signed at agent startup. The agent also does the MAC verification test and sequencing test on the rolled log file.

engw2k3agt1% bllogman list --verify engrhes40vm10

Logfile(s) for host engrhes40vm10 with status:

/opt/bmc/BladeLogic/version/NSH/log/rscd.log () --> Consistent/opt/bmc/BladeLogic/version/NSH/log/rscd.log1 () --> Consistent/opt/bmc/BladeLogic/version/NSH/log/rscd.log2 () --> Consistent/opt/bmc/BladeLogic/version/NSH/log/rscd.log3 () --> Inconsistent/opt/bmc/BladeLogic/version/NSH/log/rscd.log4 () --> Consistent

engw2k3agt1%



1 Back up all your existing agent log files (if any). These files have names like rscd.log, rscd.log1, rscd.log2, and so on.

2 Stop the RSCD agent.

3 Delete all the agent log files.

4 Make the following changes to the log4crc.txt configuration file:

In the <appender> section, remove or comment out the rscd.log appender entry that has type set to rollfile:



Uncomment or add the following entry where type is set to digisign:

5 Start the RSCD agent.

Disabling secure agent logging

If you have enabled secure agent logging and you now want to disable it:

1 Back up the certificate.pem file and the signature files.

2 Back up all your existing agent log files (if any). These files have names like rscd.log, rscd.log1, rscd.log2, and so on.


4 Delete all the agent log files.


<appender name="C:/Program Files/BMC Software/BladeLogic/version/RSCD/rscd.log"type="digisign" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="dated" certfile="C:/WINDOWS/rsc/certificate.pem" privatekeyfile="C:/WINDOWS/rsc/certificate.pem"/>

NOTE On UNIX agents, secure agent logs are only enabled (even if you have followed these steps) if the server on which the agent is running has either a working random number generator or PRNGD installed. Otherwise, usual rolling logs will be generated. See the BMC BladeLogic Server Automation Installation Guide for more information.



In the <appender> section, add or uncomment the rscd.log appender entry that has type set to rollfile:

Comment out or delete the following entry where type is set to digisign:

■ Start the RSCD agent.

Using keystroke log files

You can configure the BMC BladeLogic RSCD agent to generate keystroke logs that record nexec sessions. Whenever a remote user uses the NSH command nexec to execute a command on an agent machine, the keystroke log captures and stores the command’s STDIN, STDOUT, and STDERR streams.

Keystroke logs are similar to the secure agent logs described in “Using secure agent logging” on page 277: keystroke logs are rolled periodically and are digitally signed after they are rolled. Additionally, keystroke logs are encrypted and so are not readable. Similar to the secure agent logs, each keystroke log file is accompanied by a digital signature file, which lets you verify the integrity of a keystroke log file.

By using the NSH command blkeylogman, you can verify the integrity of all the keystroke logs on an agent machine, or a particular keystroke log file on an agent machine.

appender name="C:/Program Files/BMC Software/BladeLogic/version/RSCD/rscd.log"type="rollfile" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="dated"





Example:

In the above example, there are ten keystroke log files on the agent machine. One file (keystroke.log5) is reported as Inconsistent, which indicates that it has been tampered with.

The active keystroke log file (/opt/bmc/BladeLogic/version/NSH/log/keystroke.log in the above example) is also protected by MAC codes and sequence numbers.

When the active keystroke log file is rolled, the agent tests it for consistency using the MACs and the sequence numbers. These two are then stripped off from the file and a digital signature is computed for it. If the log file was detected Inconsistent during this process, an event is raised (In the Eventlog on Windows and syslog on UNIX-style systems).

The blkeylogman utility also lets you:

■ View the decrypted contents of keystroke log files.

■ View a list of various nexec sessions that have been recorded in the keystroke logs.

■ Copy a (decrypted) keystroke log file from an agent to the client host.

For more details, see the blkeylogman man page.

engw2k3agt1% blkeylogman list --verify engrhes40vm10

Keystroke Logfile(s) for host engrhes40vm10 with status:\/opt/bmc/BladeLogic/version/NSH/log/keystroke.log () --> Consistent/opt/bmc/BladeLogic/version/NSH/log/keystroke.log1 () --> Consistent/opt/bmc/BladeLogic/version/NSH/log/keystroke.log2 () --> Consistent/opt/bmc/BladeLogic/version/NSH/log/keystroke.log3 () --> Consistent/opt/bmc/BladeLogic/version/NSH/log/keystroke.log4 () --> Consistent/opt/bmc/BladeLogic/version/NSH/log/keystroke.log5 () --> Inconsistent/opt/bmc/BladeLogic/version/NSH/log/keystroke.log6 () --> Consistent/opt/bmc/BladeLogic/version/NSH/log/keystroke.log7 () --> Consistent/opt/bmc/BladeLogic/version/NSH/log/keystroke.log8 () --> Consistent/opt/bmc/BladeLogic/version/NSH/log/keystroke.log9 () --> Consistent/opt/bmc/BladeLogic/version/NSH/log/keystroke.log10 () --> Consistent

engw2k3agt1%

MAC Sequence number

967ff34b84f754c0774a 0000000011 Zl8abih3bvmLNHwTnE4iK5UqeYXWMk2ZQ42xdR3nNo8lE2/xUoVxPOd8CSlg7hAygMQgO7D6VmbB2QZVAG6ucg==



You can enable keystroke logs as part of your initial installation (see the BMC BladeLogic Server Automation Installation Guide) or later on, as described in “Enabling keystroke logging” on page 283. To disable keystroke logging, see “Disabling keystroke logging” on page 283.

Enabling keystroke logging

You can enable keystroke logging as part of your initial installation (see the BMC BladeLogic Server Automation Installation Guide) or later on, as described in the procedure below.



In the <category> section, uncomment or add the following entry, where name is set to keystroke:

In the <appender> section, uncomment or add the following entry, where type is set to encrypt:

3 Start the RSCD agent.

Disabling keystroke logging

If you have enabled keystroke logging and you now want to disable it:

1 Back up the certificate.pem file.



<category name="keystroke" priority="info1" appender="C:/Program Files/BMC Software/BladeLogic/version/RSCD/keystroke.log"/>

<appender name="C:/Program Files/BMC Software/BladeLogic/version/RSCD/keystroke.log" type="encrypt" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="rawtime" certfile="C:/WINDOWS/rsc/certificate.pem"privatekeyfile="C:/WINDOWS/rsc/certificate.pem"/>

NOTE On UNIX agents, keystroke logging is only enabled (even if you have followed these steps), if the server on which the agent is running has either a working random number generator or PRNGD installed. See the BMC BladeLogic Server Automation Installation Guide for more information.



In the <category> section, comment out or delete the following entry, where name is set to keystroke:

In the <appender> section, comment out or delete the following entry, where type is set to encrypt:

■ Start the RSCD agent.

Configuring the UNIX syslog

If you are logging output to the UNIX syslog, you must configure the syslog daemon to accept output from BMC BladeLogic.

Within /etc/syslog.conf, configure a facility, a priority level, and a location for the syslog by creating an entry like the following:

local6.debug /var/log/rscd-syslog

BMC BladeLogic uses the local6 facility.







/-->

Default default log4crc.txt file examples

The following is an example of a default log4crc.txt file for a Windows installation.

<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE log4c SYSTEM ""><log4c version="1.1.0"><category name="root" priority="info"/><category name="rscd" priority="info1" appender="C:/Program Files/BMC Software/BladeLogic/version/RSCD/rscd.log" debugappender="stderr"/><category name="rscdsvc" priority="info" appender="C:/Program Files/BMC Software/BladeLogic/version/RSCD/rscdsvc.log" debugappender="stderr"/>

<category name="bldeploy" priority="debug"/><category name="bldeployConsole" priority="debug" appender="stdout"/><category name="bldeployAppserver" priority="error" appender="blbasic"/>

<appender name="stdout" type="stream" layout="basic"/><appender name="stderr" type="stream" layout="basic"/><appender name="syslog" type="syslog" layout="basic"/><appender name="/tmp/bllog" type="stream" layout="dated"/><appender name="C:/Program Files/BMC Software/BladeLogic/version/RSCD/rscd.log" type="rollfile"rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="dated"/><layout name="basic" type="basic"/><layout name="dated" type="dated"/><layout name="rawtime" type="rawtime"/></log4c>



The following is an example of a default log4crc.txt file for a UNIX-style installation.

<?xml version="1.0" encoding="ISO-8859-1"?><!DOCTYPE log4c SYSTEM ""><log4c version="1.1.0">  <category name="root" priority="info"/> <category name="rscd" priority="info1" appender="/opt/bmc/BladeLogic/version/NSH/log/rscd.log" debugappender="stderr"/>  <category name="rscdsvc" priority="info" appender="/tmp/rscdsvc.log" debugappender="stderr"/> <category name="bldeploy" priority="debug"/> <category name="bldeployConsole" priority="debug" appender="stdout"/> <category name="bldeployAppserver" priority="error" appender="blbasic"/>

 <appender name="stdout" type="stream" layout="basic"/> <appender name="stderr" type="stream" layout="basic"/> <appender name="syslog" type="syslog" layout="basic"/> <appender name="/tmp/bllog" type="stream" layout="dated"/> <appender name="/opt/bmc/BladeLogic/version/NSH/log/rscd.log" type="rollfile" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="dated"/>   <appender name="/tmp/rscdsvc.log" type="rollfile" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="dated"/>

 <layout name="basic" type="basic"/> <layout name="dated" type="dated"/> <layout name="rawtime" type="rawtime"/></log4c>


C h a p t e r 6
6 Managing BMC BladeLogic data
BMC BladeLogic provides a suite of tools for managing data in the BMC BladeLogic system and controlling its growth where necessary. These tools let you delete unused data or data no longer needed for BMC BladeLogic operations.

You can manage data in these areas:

■ The BMC BladeLogic Console. You can reduce clutter in your workspace from objects created by job runs, patch analysis, and auto-remediation. You can mark these objects for deletion; the objects are deleted from the database the next time the database clean-up utility is run. For information, see “Marking data for deletion” on page 289.

■ The BMC BladeLogic Database. You can reduce the amount of space taken up by unused data in the database by executing the database clean-up utility. This utility deletes from the database objects users have deleted in the BMC BladeLogic Console and objects marked for deletion with the retention policy utility. The database clean-up utility also deletes old audit trail entries, snapshot results, audit results, and compliance results. For information, see “Cleaning up the BMC BladeLogic database” on page 288.

■ Target Servers (Agents). You can delete data that has accumulated on target servers (BMC BladeLogic agents) from Deploy Jobs. This data consists of old files that are no longer accessed; you can use the target server clean-up utility to delete these files. For information, see “Cleaning up target servers (Agents)” on page 293.

■ Repeater Servers. Data from Deploy Jobs can also accumulate in the staging directory on repeater servers. You can delete these files by using the repeater clean-up utility. For information, see “Cleaning up repeater servers” on page 294.

■ The Application Server Cache. You can reduce the number of temporary files in the Application Server cache (directory) by using the Application Server clean-up utility. This utility lets you delete old temporary files from a specific Application Server, the Application Server to which you are connected, or all accessible Application Servers. For information, see “Cleaning the Application Server cache” on page 293.


Cleaning up the BMC BladeLogic database

■ The BMC BladeLogic File Server. You can delete unused files from the file server. For information, see “Cleaning up the file server” on page 295.

Cleaning up the BMC BladeLogic databaseBMC BladeLogic provides a database clean-up utility (cleanupDatabase) to minimize the amount of space taken up by unused data. This clean-up utility deletes any data from the database that has been previously marked for deletion. This data includes:

■ Objects users have already deleted in the BMC BladeLogic Console.

■ Objects marked as deleted with the retention policy utility. These objects include old job runs and job and depot objects automatically created during patching and auto-remediation.

About the clean-up utility

The database clean-up utility works in conjunction with the retention policy utility. This utility lets you mark for deletion from the BMC BladeLogic database old job runs and objects automatically generated by operations such as auto-remediation and patch analysis. For information on the retention policy utility, see “Marking data for deletion” on page 289.

To run the database clean-up utility, see “Executing the database clean-up utility” on page 292.

Before using the database clean-up utility, you can run the following database query to determine how many depot objects the database clean-up utility will delete:

select count (*) from depot_object where is_deleted = ‘1’;

While the database clean-up utility is running, if you query again, the initial result displays until the cleanup completes. The result drops to 0 when the cleanup completes.

To execute the retention policy utility using the CLI or to run the database clean-up utility, you must first start the Network Shell and then start the BMC BladeLogic command line interface (CLI). For more information on the CLI, see the BLCLI Help.

TIP BMC Software recommends that you run the clean-up utility once per week, to avoid long-running clean-up runs.


Marking data for deletion

If you want to remove historical data, such as audit trail information and job run events, you can use the CLI to run the Delete:cleanupHistoricalData command. For more information on this command see the BLCLI Help.


BMC BladeLogic includes a retention policy utility that allows you to mark objects for deletion from the BMC BladeLogic database. These objects include old job runs and job and depot objects automatically created during patching and auto-remediation. Once they are marked for deletion, the objects are deleted from the database the next time the database clean-up utility is run. (In addition, files associated with the objects are deleted from the File Server the next time the file server clean-up utility is run.) Using the retention policy utility in this way lets you manage the amount of physical space the database requires and avoid potential performance issues resulting from your database getting too large.

By default, the retention policy utility is not enabled to avoid the possibility of deleting data unknowingly. By enabling the utility and setting the retention period, the objects that are candidates for deletion (because they are older than the specified retention period) are marked for deletion when the retention policy is executed. Once they are marked for deletion, the objects are deleted from the database the next time the database clean-up utility is run.

The following master procedure summarizes the steps for marking job runs for deletion:

1 Enable the retention policy utility. See “Enabling/disabling the retention policy utility” on page 289.

2 Set the retention period for objects you want to mark for deletion.

■ For information on setting the retention period for job runs, see “Setting the retention period for job runs” on page 290.

■ For information on setting the retention period for automatically-generated objects, see “Setting the retention period for automatically-generated objects” on page 291.

3 Execute the retention policy utility. See “Executing the retention policy utility” on page 291.

Enabling/disabling the retention policy utility

The following procedure lets you enable or disable the retention policy.




2 To enable or disable the retention policy utility, enter the following:

set Cleanup EnableRetentionPolicy true|false

Where:

true — Enables the retention policy utility, which lets you mark objects for deletion from the BMC BladeLogic database. (Objects are deleted from the database the next time the database clean-up utility is run. In addition, files associated with the objects are deleted from the file server the next time the file server clean-up utility is run.)

false — Disables the retention policy utility. You cannot mark objects for deletion during database cleanup.

3 Restart the Application Server to have this change take effect. (See “Starting the Application Server Administration console” on page 45.)

Setting the retention period for job runs

You can set the number of days to retain job runs before marking them for deletion.

To set the number of days to retain job runs before marking them for deletion, do any of the following:

■ To set the default retention period for all jobs, set the RESULTS_RETENTION_TIME property for the Job property class in the Property Dictionary. For details on setting a property using the Property Dictionary, see the BMC BladeLogic Server Automation User Guide.

■ To set the default retention period for all jobs of a specific type, set the RESULTS_RETENTION_TIME property for the specific job property class in the Property Dictionary (for example, the SnapshotJob property class). For details on setting a property using the Property Dictionary, see the BMC BladeLogic Server Automation User Guide.

■ To set the default retention period for job runs of a specific job, set the RESULTS_RETENTION_TIME property using the Properties tab for a specific job. For information on setting property values using the Properties tab for a system object (such as a job), see the BMC BladeLogic Server Automation User Guide.



Setting the retention period for automatically-generated objects

To set the number of days to retain automatically-generated objects before marking them for deletion, do the following:


2 Specify the retention period (in days) with the set command:

set Cleanup AutoGeneratedRetentionTime #days

Where:

#days — is the number of days that job and depot objects are retained before being marked for deletion (when you execute the retention policy utility).

3 Restart the Application Server to have this change take effect. For information, see “Starting the Application Server Administration console” on page 45.

Executing the retention policy utility

To execute the retention policy utility, do the following:

1 Start the Network Shell and then issue the CLI command that executes the retention policy utility by entering the following:

#nshServer1% blcli Delete executeRetentionPolicy

For more information about this command, see the Delete name space of BLCLI Help.

2 If you have not cached your session credentials, the CLI prompts you for a user name and password. Enter a user name and password that you use for accessing BMC BladeLogic.

NOTE The most specific retention value will be used when executing a retention policy. For example, a specific job value overrides any value defined for the specific job type or for all job types.


Executing the database clean-up utility

For information on using the retention policy utility, see “Marking data for deletion” on page 289.

Executing the database clean-up utility

Use this procedure to remove superfluous BMC BladeLogic data from Oracle and SQL Server databases.

To execute a database clean-up operation, your role must be granted the BL_Administration.System_Cleanup authorization.

1 Start the Network Shell and then issue the CLI command that executes the database clean-up utility by entering the following:

#nshServer1% blcli Delete cleanupDatabase



NOTE If you are authenticating with SRP, you can cache your authentication information for repeated use over a given time period, storing this information in the credentials cache. For information, see “Single sign-on” on page 121.


NOTE BMC BladeLogic also provides the performFullCleanupJob CLI command for database cleanup. For information, see the Delete name space of BLCLI Help.



Cleaning the Application Server cache

Cleaning the Application Server cacheEach Application Server has a file cache (directory) containing files that it uses for operations it performs. These files are temporary files no longer needed after the operation; you can use the Application Server cache clean-up utility to delete them from the cache. The utility lets you specify parameters for the cleanup, such as Application Server name and the minimum elapsed time before files can be considered for deletion. You can also use the utility to clean up caches of all accessible Application Servers.

To execute a clean-up operation, your role must be granted the BL_Administration.System_Cleanup authorization.

1 Start the Network Shell and then issue the CLI command that executes the Application Server cache clean-up utility by entering the following:

#nshServer1% blcli Delete cleanupAppServerCache <retention time>



Cleaning up target servers (Agents)During Deploy Jobs, objects such as BL packages, transaction information and log files are created on the target servers and in certain cases are not deleted. These files are temporary and will probably no longer be accessed. To delete these objects from a target server, use the target server clean-up utility

To clean up transactions, the target server clean-up utility uses the value of the server’s TRANSACTIONS_DIR property to locate the transactions directory. For information on configuring this property, see the BMC BladeLogic Server Automation User Guide.



Cleaning up repeater servers


1 Start the Network Shell and then issue the CLI command that executes the target server clean-up utility by entering the following:

#nshServer1% blcli Delete cleanupAgent



To clean up a set of target servers, use the command in a Network Shell Script Job. See “Scheduling the target server (Agent) cleanup” on page 300.

Cleaning up repeater serversOld temporary files from Deploy Jobs can accumulate in the staging directory on repeater servers. You can use the repeater clean-up utility to delete these files. The utility lets you specify parameters for the cleanup, such as maximum size for the staging directory and the minimum elapsed time before files can be considered for deletion.


1 Start the Network Shell and then issue the CLI command that executes the repeater server clean-up utility by entering the following:

#nshServer1% blcli Delete cleanupRepeater




Cleaning up the file server


Cleaning up the file serverWhen users delete objects from the BMC BladeLogic Console, the system marks for deletion from the file server all files associated with the objects. You can use the file server clean-up utility to delete these unused files from the file server and from the temporary file storage on the Application Server.

Before you begin

When a Custom Package Deploy Job runs, it creates a subdirectory under the BLPackage directory for every iteration. Even after the job run history is removed by the retention policy, these directories still exist. Neither the file server clean-up utility or database clean-up utility removes these directories.

Prior to running the Delete cleanupFileServer command, you must run the Delete updateDeleteDependencies to remove these directories.

To clean up the file server

1 Start the Network Shell and then issue the CLI command that executes the file server clean-up utility by entering the following:

#nshServer1% blcli Delete cleanupFileServer





Cleaning up historical data

Cleaning up historical dataAs part of its operation, the database clean-up utility (cleanupDatabase) cleans up historical data from the database. However, you can also clean up historical data by using the historical data clean-up utility. The utility deletes the following objects:

■ Old audit trail entries■ Audit results■ Job run events■ Compliance results■ Snapshot results■ Job schedules

Using this utility, you can delete all historical data or only one specific type of object, for example, snapshot results.


1 Start the Network Shell and then issue the CLI command that executes the historical data clean-up utility by entering the following:

#nshServer1% blcli Delete cleanupHistoricalData

This command deletes all historical data. To clean up one specific type of object, enter the command and specify a value for the objectName variable.





Scheduling the cleanup

Scheduling the cleanupThe clean-up utilities can be run as Network Shell Script Jobs. Running a utility as a script job lets you schedule the job so it executes on a regular basis rather than running it interactively. You can set up Network Shell Script Jobs for performing these clean-up tasks:

■ Marking data for deletion (See “Scheduling the retention policy utility to mark data for deletion”.)

■ Database cleanup (See “Scheduling the database cleanup” on page 298.)

■ File Server cleanup (See “Scheduling the file server cleanup” on page 299.)

■ Application Server cache cleanup (See “Scheduling the Application Server cache cleanup” on page 299.)

■ Repeater cleanup (See “Scheduling the repeater server cleanup” on page 300.)

■ Target server (agent) cleanup (See “Scheduling the target server (Agent) cleanup” on page 300.)

Scheduling the retention policy utility to mark data for deletion

Use this procedure to run the retention policy utility as a Network Shell Script Job.

1 In a text editor, create a Network Shell script to run the retention policy utility. The script should consist of the CLI command that invokes the utility:

blcli Delete executeRetentionPolicy


NOTE BMC BladeLogic recommends that you create all Network Shell Script Jobs for cleanup in a single directory, for example: /Jobs/BMC BladeLogic Administration/Cleanup


Scheduling the database cleanup

2 Using the BMC BladeLogic Console, add the Network Shell script to the Depot. For information, see the BMC BladeLogic Server Automation User Guide.

A Assign any name to the script.

B When you specify the Script Type, choose the first option.

3 Create a Network Shell Script Job based on the script you added to the Depot in the previous step. For information, see the BMC BladeLogic Server Automation User Guide.

A For the target server, specify the server functioning as the Application Server.

B Schedule the job to run at a frequency you prefer.

Scheduling the database cleanup

Use this procedure to run the database clean-up utility as a Network Shell Script Job.

1 In a text editor, create a Network Shell script to run the database clean-up utility. The script should consist of the CLI command that invokes the utility:

blcli Delete cleanupDatabase

2 Using BMC BladeLogic Console, add the Network Shell script to the Depot. For information, see the BMC BladeLogic Server Automation User Guide.








Scheduling the file server cleanup

Scheduling the file server cleanup

Use this procedure to run the file server clean-up utility as a Network Shell Script Job. See “Cleaning up the file server” on page 295 for notes on pre-requisites for running the utility.

1 In a text editor, create a Network Shell script to run the file server clean-up utility. The script should consist of the CLI command that invokes the utility:

blcli Delete cleanupFileServer

2 Using BMC BladeLogic Console, add the Network Shell script to the Depot. For information, see the BMC BladeLogic Server Automation User Guide.






Scheduling the Application Server cache cleanup

Use this procedure to run the Application Server cache clean-up utility as a Network Shell Script Job.

1 In a text editor, create a Network Shell script to run the Application Server cache clean-up utility. The script should consist of the CLI command that invokes the utility:

blcli Delete cleanupAppServerCache <retention time>





Scheduling the repeater server cleanup




Scheduling the repeater server cleanup

Use this procedure to run the repeater server clean-up utility as a Network Shell Script Job.

1 In a text editor, create a Network Shell script to run the repeater server clean-up utility. The script should consist of the CLI command that invokes the utility:

blcli Delete cleanupRepeater





A For the target server, specify the repeater servers you want to clean up.


Scheduling the target server (Agent) cleanup

Use this procedure to run the target server clean-up utility as a Network Shell Script Job.

1 In a text editor, create a Network Shell script to run the target server (agent) clean-up utility. The script should consist of the CLI command that invokes the utility:

blcli Delete cleanupAgent







A For the target server, specify the target servers (agents) you want to clean up.





C h a p t e r 7
7 Configuring Advanced File Servers and Advanced Repeaters
An advanced file server or Advanced Repeater server uses BMC BladeLogic Advanced Repeater technology with deploy jobs to enable file servers and repeater servers to store and share deploy data more efficiently.

Overview Using advanced file servers and Advanced Repeater servers can help you improve the bandwidth utilization between the central file server and the repeaters. With the standard BMC BladeLogic Server Automation file server and repeater, the Depot objects are sent to the repeater in their entirety whenever they are required for a deployment.

Using an Advanced File Server on the existing File Server with one or more Advanced Repeaters uses a more efficient protocol to ensure that only changes to the content are downloaded across the network. You can also configure bandwidth throttling on links between the Advanced File Server and the Advanced Repeater. Figure 1 shows a sample configuration.


Key terms

Figure 1 Sample configuration

Key terms

The BMC BladeLogic Advanced Repeater is the combination of Advanced File Server and Advanced Repeater server. Both the Advanced Repeater and Advanced File Server are built on BMC BladeLogic Server Automation Client Automation technology. The three key components are the Content Replicator, the Transmitter (used by the Advanced File Server), and the BMC BladeLogic Server Automation Client Automation Proxy (used by the Advanced Repeater server).

The following list defines some of these key terms.

■ Advanced File Server - an enhanced Java application server running on an existing File Server. It uses the BMC BladeLogic Server Automation Client Automation master transmitter component to hold a second copy of the depot content in a compressed, proprietary format that is well suited to providing bandwidth efficient transfer of data.


What is the BMC BladeLogic Advanced Repeater?

■ Advanced Repeater - a Java application that runs instead of the traditional BMC BladeLogic Server Automation repeater and uses the BMC BladeLogic Server Automation Client Automation Proxy component to efficiently download data from the Advanced File Server. An RSCD agent must be installed on the servers hosting both the Advanced Repeater and Advanced File Server components.

■ Content Replicator - used to publish the content from the existing file server to the Transmitter on the Advanced File Server. It is also used to pull the content down to the file system on the Advanced Repeater, using the BMC BladeLogic Server Automation Client Automation proxy.

■ Advanced Repeater installer - the Advanced Repeater and Advanced File Server are both installed from the same installation file.

What is the BMC BladeLogic Advanced Repeater?

The BMC BladeLogic Advanced Repeater provides scalable transport of data over wide-area networks, and is an alternate option when configuring file servers or repeater servers. If you are using deploy jobs in a large-scale environment, consider setting up Advanced File Servers and using Advanced Repeater servers.

Using the BMC BladeLogic Advanced Repeater technology for deploying data offers several key benefits:

■ Improved performance of staging data for deploy jobs. Using BMC BladeLogic Advanced Repeater technology enables file servers and repeater servers to store and share deploy data efficiently.

■ Ability to manage the use of network resources by the Advanced File Server and Advanced Repeater server. See “Best practice information” on page 306.

If the BMC BladeLogic Advanced Repeater components have been installed, you can configure an Advanced File Server and one or more Advanced Repeaters, which use the BMC BladeLogic Advanced Repeater.

When a Deploy Job is run and is set for indirect staging, any targets which have been configured through Routing Rules to use an Advanced Repeater will make use of the BMC BladeLogic Advanced Repeater. Any targets which have been configured to use a standard repeater continue to do so. Any targets which are not configured to use a repeater stage the data directly on the target.

NOTE For instructions on installing the BMC BladeLogic Advanced Repeater, see “Installing the BMC BladeLogic Server Automation Advanced Repeater” on page 307.


Best practice information

Best practice information

Disk space

If you are implementing an Advanced File Server, the file server must have a minimum of 72 GB of available, non-redundant, disk space. BMC BladeLogic recommends that the file server have 200 GB or more of available RAID 5 disk space.

When the BMC BladeLogic Advanced Repeater has enough disk space, it maintains three times the size of the data as cache, and attempts to maintain at least 10% free disk space. The Advanced Repeater transmitter component uses the additional space for optimizations that improve the efficiency of data replication, such as diffing, caching, and compressing. It is possible to run the transmitter with less than optimal disk space, but efficiency degrades.

If the transmitter does not have enough disk space to maintain the optimal storage size ratio, it runs in limited disk space mode. In limited disk space mode, the transmitter stops maintaining storage size ratio, and starts maintaining free disk space instead, by removing cache files to reduce the amount of storage.

CPU utilization

The advanced file server does not make intensive usage of the CPU, but the CPU usage will spike when new content is published as this needs to be compressed. In addition, using SSL also increases the CPU usage by about 40% due to the encryption and decryption of the content.

Memory utilization

The default Java heap size is configured for a maximum of 512MB in the advanced file server. This setting means that about 1GB RAM should be allowed to run the advanced file server.

NOTE Note the following requirements when configuring Advanced File Servers and repeater servers:

■ An Advanced Repeater server cannot be enabled unless an Advanced File Server is enabled.

■ An Advanced File Server cannot be disabled if there are existing Advanced Repeater servers.


Installing the BMC BladeLogic Server Automation Advanced Repeater

Installing the BMC BladeLogic Server Automation Advanced Repeater

You can install the BMC BladeLogic Server Automation Advanced Repeater using the installation program or by performing an unattended (silent) installation.

Installing using the installation program

To install the BMC BladeLogic Advanced Repeater

1 Download the BMC BladeLogic Advanced Repeater installation file according to the download instructions in provided in the “Before you begin” chapter of the BMC BladeLogic Server Automation Installation Guide.

The download instructions in the BMC BladeLogic Server Automation Installation Guide provide a standard method for downloading the product files from the BMC Software Electronic Product Download (EPD) website. The installer files applicable to the Advanced Repeater are labeled BMC BladeLogic Advanced Repeater for hostPlatform on the EPD site.


■ In Microsoft Windows environments, copy the installation file to a directory on the server you want to configure as an Advanced File Server or Advanced Repeater Server.

■ In Linux Environments, upload the installer bin to the file server or repeater server.

3 Start the BMC BladeLogic installation program for your platform.

Different installers are provided for 32-bit and 64-bit Windows.

4 On the BMC BladeLogic Server Automation Advanced Repeater Installation screen, click OK.

5 On the Welcome screen, click Next.

6 Accept the license agreement and click Next.


Installing using the installation program

7 Specify the destination directory, or accept the default. Click Next.

The Workspace Directory window opens.

8 Specify the workspace directory (where the Advanced Repeater stores its channels), or accept the default. Click Next.

The Advanced Repeater Credentials window opens.

9 Specify the credentials for the Advanced Repeater administrator, or accept the default credentials by selecting Use default tuner credential settings. Click Next.

The Advanced Repeater Service Port window opens.

10 Specify the following:

— Transmitter RPC Port: If the server is using remote procedure calls (RPC), enter the port number used to establish a new connection for each RPC client connecting to the RPC server.

— Transmitter Listener Port: Specify the TCP port for the Transmitter service listener. Specify an integer between 0 and 65535. You can use any port, as long as the port number is not already in use. The default port is 5282.

— Proxy Listener Port: Specify the TCP port for the Proxy Service listener. Specify an integer between 0 and 65535. Specify this TCP port if you are installing the BMC BladeLogic Advanced Repeater behind a firewall. The default port is 8081.

— Click Next.

A notification panel window appears if the installation program detects an existing installation. Click Next to upgrade the installation.

11 Review the current settings to confirm that you have specified the correct installation configuration, and then click Install.

12 When the installation completes, click Finish.

NOTE The default installation folder (AdvancedRepeater) is the same for both Advanced File Server and Advanced Repeater Server.

NOTE You must use the RPC port number that was set during installation.port number to be used by the BMC BladeLogic Advanced Repeater. The default port is 7717.


Performing an unattended (silent) installation

To uninstall the BMC BladeLogic Advanced Repeater


■ On Microsoft Windows, select Start => All Programs => BMC BladeLogic Server Automation Suite => Uninstall Advanced Repeater and follow the prompts on the uninstall wizard.

■ On Linux, enter the following command and follow the prompts on the uninstall wizard:

where version is the version number for BMC BladeLogic Server Automation (for example, 8.1).


Install the Advanced Repeater using silent mode

You can perform an unattended (silent) installation of the BMC BladeLogic Server Automation Advanced Repeater.

Before you begin

Certain Terminal Server configuration options that pertain to temporary folders must be turned off, to enable running the installation wizard through a Terminal Services connection or a remote desktop session.

To install the Advanced Repeater in silent mode

1 In a text editor, create an options file and add the options for the installation that you want to run. For example:

:/opt/adv/rptr/version/AdvancedRepeater/UninstallAdvancedRepeater # ./uninstall

-A featureAdvancedRepeater-P installLocation=installationDirectory-J WORKSPACE_DIRECTORY=pathToWorkspace-J TUNER_ADMINISTRATION_USER_NAME=admin-J TUNER_ADMINISTRATION_PASSWORD=password-J TUNER_ADMINISTRATION_PORT_NUMBER=7177-J PROXY_PORT_NUMBER=8081-J XMITTER_PORT_NUMBER=5282



Where:

Guidelines

■ Each option must be on a single line.

■ Values for options may contain spaces.

Option Description

-P installLocation=installationDirectory

Sets the installation directory for the product.

For example, on Windows:

-P installLocation=C:\Program Files\BMC Software\BladeLogic\8.0\AdvancedRepeater

On UNIX:

-P installLocation=opt/bmc/BladeLogic/8.0/AdvancedRepeater

-A featureAdvancedRepeater Specifies installation of the Advanced Repeater.

-J WORKSPACE_DIRECTORY=pathToWorkspace

Specifies the workspace directory (where the Advanced Repeater stores its channels).

For example, on Windows:

-J WORKSPACE_DIRECTORY=C:\Program Files\BMC Software\BladeLogic\8.0\AdvancedRepeater\tuner

On UNIX:

-J WORKSPACE_DIRECTORY=/opt/bmc/BladeLogic/8.0/AdvancedRepeater/tuner

-J TUNER_ADMINISTRATION_USER_NAME=-J TUNER_ADMINISTRATION_PASSWORD=

The user name and password for Advanced Repeater administrator.

-J TUNER_ADMINISTRATION_PORT_NUMBER=

The TCP port to be used by the BMC BladeLogic Server Automation Advanced Repeater. Specify an integer between 0 and 65535. The default is 7717.

-J PROXY_PORT_NUMBER= The TCP port for the Proxy Service listener. Specify an integer between 0 and 65535. Specify this TCP port if you are installing the BMC BladeLogic Server Automation Advanced Repeater behind a firewall. The default is 8081.

-J XMITTER_PORT_NUMBER= The TCP port for the Transmitter service listener. Specify an integer between 0 and 65535. You can use any port, as long as the port number is not already in use. The default is 5282.



■ All Java properties have default values if not specified in the options file. However, you should specify TUNER_ADMINISTRATION_USER_NAME and PASSWORD.

2 Change directory to the location where the installer resides.

3 Run the installation program with the -i silent option.

You must use an absolute path to the options file.

Windows example

UNIX example

Upgrade the Advanced Repeater using silent mode

You can perform an unattended (silent) upgrade of the BMC BladeLogic Server Automation Advanced Repeater.

1 In a text editor, create an options file that contains this option:

2 Change directory to the location where the installer resides.

3 Run the installation program with the -i silent option.

AdvancedRepeaterInstallerName -i silent -DOPTIONS_FILE=silentOptionsFilePath

You must use an absolute path to the options file.

Windows:

AdvancedRepeaterInstallerName -i silent -DOPTIONS_FILE=silentOptionsFilePath

AdvancedRepeater_8_1_win32.exe -i silent -DOPTIONS_FILE=/opt/bmc/BladeLogic/8.0/silent_install.txt

sh AdvancedRepeater_8_1_win32.bin -i silent -DOPTIONS_FILE=/opt/bmc/BladeLogic/8.0/silent_install.txt

-A featureAdvancedRepeater

AdvancedRepeater_8_1_win32.exe -i silent -DOPTIONS_FILE=C:\Program Files\BMC Software\BladeLogic\8.0\silent_upgrade.txt


Configuring Advanced File Servers and Advanced Repeater servers

UNIX:

Configuring Advanced File Servers and Advanced Repeater servers

To adjust the configuration settings for the an Advanced File Server or Advanced Repeater server, see the following:

■ Configuring Advanced File Servers

■ Configuring Advanced Repeater servers

■ Changing the administrator user and password for Advanced Repeater Servers

Before you begin

Set up credentials

If you have not already done so, create an automation principal which contains the user-defined Administrator credential used to configure the Advanced File Server. An automation principal defines a user credential that can be used for accessing external systems.

See the BMC BladeLogic Server Automation User Guide for information on creating automation principals.

sh AdvancedRepeater_8_1_win32.bin -i silent -DOPTIONS_FILE=/opt/bmc/BladeLogic/8.0/silent_upgrade.txt

NOTE Configuring an Advanced Repeater server behind a SOCKS proxy server is not supported.


Configuring Advanced File Servers


Use this procedure to modify a file server to be used as an Advanced File Server, which uses the BMC BladeLogic Advanced Repeater.

1 Create a file server as described in “Setting up the file server” on page 75.

2 Install the BMC BladeLogic Advanced Repeater on the file server, as described in “Installing the BMC BladeLogic Server Automation Advanced Repeater” on page 307.

3 On the BMC BladeLogic Server Automation Console, select Configuration => Infrastructure Management.

4 Right-click the file server and select Properties to open the Modify File Server dialog.

5 On the General tab, click Enable Advanced File Server.

If necessary, change the Advanced File Server root directory path to point to the BMC BladeLogic Advanced Repeater installation directory. If you do not specify the install directory, the Transmitter and Performance tabs are not accessible.

NOTE The Advanced File Server Root Directory path is different than the File Server Root Path. The Advanced File Server Root Directory points to the BMC BladeLogic Advanced Repeater installation directory, while the File Server Root Path points to the directory on the file server where data is stored.



6 On the Security tab, specify the following:

Option Description

SSL Settings By default the traffic between the advanced file server and advanced repeater is not encrypted. However, you can use SSL if your environment requires encryption. See “Securing communication between Advanced File Servers and Advanced Repeater servers (optional)” on page 319.

If you have configured secure communication for the file server, check SSL Enabled.

Advanced File Server Administrator

Select an Automation Principal from the drop-down list.

The automation principal is used to access and configure the Advanced File Server.

■ If you have not changed any credential during the installation or post-installation procedures, select "Default". This default automation principal matches the built-in administrator credential.

■ If you specified a custom user/password combination during installation or in the post-install procedure, select the automation principal that was created for that user/password combination. This credential is needed by BMC BladeLogic Server Automation to access and configure the Advanced File Server.



7 On the Transmitter tab, specify the following:

Option Description

Transmitter Host Name

By default, the transmitter is located on the same host as the File Server.

Transmitter Root Directory

Select the BMC BladeLogic Advanced Repeater installation directory.

By default, the transmitter (in the Advanced File Server) is located on the same host as the existing file server. In this case, you only need to install one copy of the Advanced Repeater on the file server host. The Advanced File Server Root Directory field on the General tab will be the same as the value specified here. The Host field on the General tab will be the same as the Transmitter Host Name field on the Transmitter tab.

In some cases, however, you may want the transmitter to be on a different host than file server. For example, if there is not sufficient disk space on the file server host. In this case, you must install two copies of the Advanced Repeater.

■ Install Copy A on an existing file server host. The value Advanced File Server Root Directory on the General tab reflects the installation directory for Copy A.

■ Install Copy B on a separate transmitter host.

In this case, the value for the Transmitter Root Directory field reflects the installation directory for Copy B.

Transmitter Listener Port

Enter the port on which the Advanced Repeater listens for requests. You can use any port as the listener port, as long as the port number is not already in use.

RPC Port The RPC port is used to administer the Advanced Repeater components. Enter the RPC port number that was set during installation.



8 On the Performance tab, specify the following:

9 On the Network tab, you can specify options that help you control the amount of network resources used during deployment. Specify the following:

10 Click OK.

Option Description

Disk resources Enter the minimum amount of disk space (as a percentage) that the transmitter should keep free. To keep the specified amount of disk space free, the transmitter automatically deletes optional files, such as files in the index cache.

File transfer efficiency Specify the following:

■ Compression enabled - specifies whether the Advanced File Server should compress the files it sends.

■ Compression level - specifies the level of compression the transmitter should use for the files it sends.— low - the compression is fast but the file size isn't reduced as

much as on high (however the byte-savings difference is minimal).

— medium - balances time and size. — high - the file is compressed as much as possible, but for

large files the process can take a long time and can use many CPU resources.

■ Differencing enabled - specifies whether the transmitter should use byte-level differencing, which allows the transmitter to send faster payload updates and to use less bandwidth. Instead of transferring entire files when updating payloads, the transmitter uses byte-level differencing to send only the changed bytes.

Set the amount of memory to allocate for differencing.

Option Description

Network connections Enter the number of clients (Advanced Repeaters) allowed to connect to the Advanced File Server at one time.

Network bandwidth If you select the Enable bandwidth management option, specify the following:

■ Percentage of bandwidth - enter the maximum amount of available bandwidth (as a percentage) that the transmitter can use. This setting limits the total traffic leaving the transmitter, across all parallel connections. A bandwidth setting of “0” (zero) sets specifies maximum bandwidth speed (unlimited).

■ Maximum throughput - specify the number of kilobits per second that the Advanced File Server can use as throughput.


Configuring Advanced Repeater servers


Use this procedure to create or modify a server to be used as an Advanced Repeater server, which uses the BMC BladeLogic Advanced Repeater.

1 Install the BMC BladeLogic Advanced Repeater on the system that you will use as an Advanced Repeater server, as described in “Installing the BMC BladeLogic Server Automation Advanced Repeater” on page 307.

2 On the BMC BladeLogic Server Automation Console, select Configuration => Infrastructure Management.


— Right-click Repeater Servers and select New Repeater Server to start the New Repeater Wizard.

— Right-click an existing repeater server select Properties to open the Modify Repeater Server dialog.

4 On the General panel, click Enable Advanced Repeater.

If necessary, change the Advanced Repeater root directory path.

NOTE You must have first configured an Advanced File Server before you can configure an Advanced Repeater server. See “Configuring Advanced File Servers and Advanced Repeater servers” on page 312.

NOTE The Advanced Repeater server must be able to access the Advanced File Server directly using the user name defined in the exports file on the file server. For more information, see the Exports File section in the BMC BladeLogic Server Automation Administration Guide.



5 On the Security tab, specify the following:

6 On the Cache and Port panel, specify the following:

Option Description

SSL Settings By default the traffic between the advanced file server and advanced repeater is not encrypted. However, you can use SSL if your environment requires encryption. See “Securing communication between Advanced File Servers and Advanced Repeater servers (optional)” on page 319.

If you have configured secure communication, check SSL Enabled.

Advanced Repeater Server Administrator

Select an Automation Principal from the drop-down list.

The automation principal is used to access and configure the Advanced File Server.

■ If you have not changed any credential during the installation or post-installation procedures, select "Default". This default automation principal matches the built-in administrator credential.

■ If you specified a custom user/password combination during installation or in the post-install procedure, select the automation principal that was created for that user/password combination. This credential is needed by BMC BladeLogic Server Automation to access and configure the Advanced Repeater.

Option Description

Cache management options

Cache maximum size Enter the total size (in MB) for the Advanced Repeater cache. The cache does not exceed this disk-space limit. Once the cache reaches the maximum cache size, the Advanced Repeater starts garbage collection to delete older channel files from the cache.

Cache low watermark Enter a percentage that represents the lower limit (cache low watermark) for the Advanced Repeater cache size. When the Advanced Repeater starts cache garbage collection, it takes a snapshot of the cache and then determines the number of files it must delete to reach the low watermark. BMC Software recommends that you set the cache low watermark to a value between 75 and 80 (indicating that it is 75% to 80% of the maximum cache size).


Changing the administrator user and password for Advanced Repeater Servers

7 On the Network panel, you can specify options that help you control the amount of network resources used during deployment. Specify the following:

8 Click OK.

Changing the administrator user and password for Advanced Repeater Servers

You can change the administrator user and password for Advanced Repeater Servers in any of the following ways:

■ In the installation wizard, when running the installation program.

■ If you know the administrator user/password combination, you can change it using a Runchannel command.

— Navigate to the Advanced Repeater Server installation directory. (On Windows, the default directory is C:\Program Files\BMC Software\Bladelogic\8.0\AdvancedRepeater\tuner\).

— From a command prompt, execute the following command:

Port management options

Listener port Enter the port on which the Advanced Repeater listens for requests. You can use any port as the listener port, as long as the port number is not already in use.

RPC port The RPC port is used to administer the Advanced Repeater components. Enter the RPC port number that was set during installation.

Option Description

Network connections Enter the number of concurrent connections to the Advanced Repeater.

Network bandwidth If enabled, specify the following:

■ Percentage of bandwidth - enter the maximum amount of available bandwidth (as a percentage) that the Advanced Repeater can use. This setting applies for each repeater to file server connection. A bandwidth setting of “0” (zero) sets specifies maximum bandwidth speed (unlimited).

■ Maximum throughput - specify the number of kilobits per second that the Advanced Repeater can use as throughput.

Option Description


Securing communication between Advanced File Servers and Advanced Repeater servers (optional)

■ If you do not know the administrator user/password combination (for example, if you are using the built-in default user/password), you can use the Tuner program to override the current user/password combination. (Note that the Tuner program can only be run locally.)

— Navigate to the Advanced Repeater Server installation directory. (On Windows, the default directory is C:\Program Files\BMC Software\Bladelogic\8.0\AdvancedRepeater\tuner\).

— From a command prompt, execute the following command:

Securing communication between Advanced File Servers and Advanced Repeater servers (optional)

Optionally, all communication between the Advanced File Server and Advanced Repeater servers using the BMC BladeLogic Advanced Repeater can be encrypted using SSL. You can secure the link between the Advanced Repeater server and the transmitter located on the Advanced File Server. All other traffic is all local and does not require encryption.

Set up the Advanced File Server for secure communication

1 Start the Advanced Repeater, using one of the following methods:

■ On UNIX and Linux, use the following command:

runchannel http://localhost:5282/Marimba/Current/TunerAdministrator -tuner localhost:7717 -username oldAdminUser -password oldAdminPwd -set -property "marimba.tuner.admin" -value "newAdminUser,plain:newAdminPwd"

tuner.exe -admin "newAdminUser,plain:newAdminPwd"

NOTE The following instructions assume you have a valid certificate authority (using OpenSSL, for example) that is able to issue credentials used for PKI authentication.

/etc/init.d/advancedrepeater start


Generate the SSL certificate

■ On Windows, from the Start menu, click Programs => BMC Software => BladeLogic Server Automation Suite => Advanced Repeater.

2 Right-click the Certificate Manager option and select Start.

The Certificate Manager dialog is displayed.

3 In the left pane, select Root.

4 Click Import to display the Import Certificate dialog.

5 Browse to the location of the root certificate and select it.

6 When prompted for a password or nickname, leave the entry field blank.

7 On the Root Certificates dialog, select the root certificate you just imported and select SSL from the Trust Type group box.

The root certificate is now configured on the Advanced File Server.

Generate the SSL certificate

1 In the Certificate Manager dialog, select SSL in the left pane.

2 Click Request.

The SSL Certificate Request dialog is displayed.

3 Click Next.

4 On the Class 3 Digital ID Information panel, complete the fields and click Next.

5 Specify a password, and click Next.

TIP If you do not see any channels listed in the Channels list, select Channel => Show internal channels to populate the list.

TIP When specifying Host name, use the actual name of the Advanced File Server host system. Do not enter localhost.


Enable SSL on Advanced File Servers and Advanced Repeaters

6 Click inside the text box and enter characters until the counter reaches zero.

7 Click Copy CSR to paste buffer.

The certificate request is generated.

8 Copy the certificate request and paste it into a text file.

9 Forward the file to your Certificate Authority.

10 Once you have received the signed certificate, copy the contents of the file.

11 On the SSL Certificates dialog, click Install.

12 On the Install SSL Certificate dialog, paste the contents of the signed certificate and click Next.

13 Click Done to complete the SSL certificate.

Enable SSL on Advanced File Servers and Advanced Repeaters

To configure the BMC BladeLogic Advanced Repeater for secure communication, complete the following steps on the Advanced File Server.

1 In the Certificate Manager dialog, select SSL in the left pane.

2 Select the certificate you just created.

3 Click View.

The Unique ID is displayed on the Certificate Information dialog.

4 Using the Unique ID displayed in the certificate, enter the following commands to configure the transmitter to use the certificate and only accept https traffic:

where

■ uniqueID is the ID you obtained in step 3.

runchannel transmitterURL hostname property -setProperty transmitter.http.certID uniqueIDrunchannel transmitterURL hostname property -setProperty transmitter.http.savepw truerunchannel transmitterURL hostname property -setProperty transmitter.http.pw plain:passwordrunchannel transmitterURL hostname property -setProperty transmitter.http.secure true


Configure the Advanced Repeater server for secure communication

■ transmitterURL is the URL to the Transmitter Administrator of the BMC BladeLogic Advanced Repeater installed on the Advanced File Server. For example, http://localhost:5282/Marimba/Current/TransmitterAdministrator.

5 Validate that the communication type is enabled, by entering the following string in any browser address field:

transmitterURL is the URL to the Transmitter Administrator of the BMC BladeLogic Advanced Repeater. For example, https://localhost:5282/Marimba/Current/TransmitterAdministrator.

The browser should display the status information for the Advanced Repeater.

6 Restart the BMC BladeLogic Advanced Repeater on the Advanced File Server.

Configure the Advanced Repeater server for secure communication

1 Copy the root certificate you created to the Advanced Repeater server.

1 On the Advanced Repeater server, start the Advanced Repeater using one of the following methods:

■ On UNIX and Linux, use the following command:

■ On Windows, from the Start menu, click Programs => BMC Software => BladeLogic Server Automation Suite => Advanced Repeater.

2 Right-click the Certificate Manager option and select Start.

The Certificate Manager dialog is displayed.

3 In the left pane, select Root.

4 Click Import to display the Import Certificate dialog.

5 Browse to the location of the root certificate and select it.

https://transmitterURL/?status

/etc/init.d/advancedrepeater start


Configure the Advanced File Server to use secure communication

6 Click OK to bypass the Enter Password and Enter Nickname dialogs. Do not enter a password or a nickname.

7 On the Root Certificates dialog, select the root certificate you just imported and select SSL from the Trust Type group box.

For more information on using the Certificate Manager, see BMC Configuration Automation CMS and Tuner Guide.

Configure the Advanced File Server to use secure communication

You must configure the Advanced File Server to use SSL when communicating with the Advanced Repeater.

1 Select Configuration => Infrastructure Management.

2 Right-click the Advanced File Server and choose Properties.

3 Select Enable SSL.

4 Click OK.

Disabling SSL communication

1 Enter the following command to disable secure communication between the Advanced File Server and the Advanced Repeater server:

2 Restart the BMC BladeLogic Server Automation Advanced Repeater.

3 Validate that the secure communication type has been disabled, by entering the following string in any browser address field:

NOTE To disable SSL communication, clear the Enable SSL check box.

runchannel transmitterURL hostName property –setProperty transmitter.http.secure false


Troubleshooting advanced file servers and advanced repeaters

transmitterURL is the URL to the Transmitter Administrator of the BMC BladeLogic Advanced Repeater. For example, http://localhost:5282/Marimba/Current/TransmitterAdministrator.

The browser displays the status information for the Advanced Repeater.

Troubleshooting advanced file servers and advanced repeaters

The following topics may be useful if you are experiencing issues with advanced file servers and advanced repeaters.

■ Configuring bandwidth throttling between Advanced File Servers and Advanced Repeater servers

■ Location of log files

■ Location of configuration files

■ Starting and stopping the Advanced Repeater

Configuring bandwidth throttling between Advanced File Servers and Advanced Repeater servers

Both the Advanced File Server and Advanced Repeater server include options that you can use to control the use of network resources during file staging and deployment. The Network tab on the Advanced File Server or Advanced Repeater server Properties include options for controlling the number of network connections and the amount of network bandwidth. The options are

■ Network connections■ Network bandwidth (Percentage of bandwidth and Maximum throughput)

These options enable you to enter a maximum amount of available bandwidth that the Advanced File Server or repeater can use, as well as the number of kilobits per second that the Advanced File Server or repeater can use as throughput. The options are particularly useful in large scale environments, where data is being pushed out to a large number of servers.

http://transmitterURL:portNumber/?status


Location of log files

These options are described in detail in the procedures for Configuring Advanced File Servers and Advanced Repeater servers and Configuring Advanced Repeater servers.

Location of log files

Log files specific to the Advanced Repeater are listed in Table 3 on page 325.

NOTE The bandwidth setting on an Advanced File Server is different from the bandwidth setting on an Advanced Repeater server. The bandwidth setting on Advanced File Server limits the total traffic leaving the transmitter, across all parallel connections, while the bandwidth setting in Advanced Repeater server is a per connection setting (for each repeater to file server link).

Table 3 Log files for Advanced Repeater

Log file Default location

Tuner log files

history-<n>.log The tuner log file is located in:

Windows

C:\Program Files\BMC Software\BladeLogic\8.0\AdvancedRepeater\tuner\.marimba\BCAC\

UNIX

/opt/bmc/BladeLogic/8.0/AdvancedRepeater/tuner/.marimba/ws3/

Proxy log files

access-y<yyyy>-w<w>.log The proxy access log is located in:

Windows

C:\Program Files\BMC Software\Bladelogic\8.0\AdvancedRepeater\tuner\.marimba\proxyroot\logs\

UNIX

/opt/bmc/BladeLogic/8.0/AdvancedRepeater/tuner/.marimba/proxyroot/logs/


Location of configuration files

Location of configuration files

Configuration files specific to the Advanced Repeater are listed in Table 4.

In general these configuration files should not be modified. However, if you are experiencing problems on Linux or UNIX systems that are not running X-Windows, perform the following steps:

1 Add the following property to the properties.txt file (see Table 4 for location of file):

2 Restart the advanced file server.

admin-y<yyyy>-w<w>.log The proxy admin log is located in:

Windows

C:\Program Files\BMC Software\Bladelogic\8.0\AdvancedRepeater\tuner\.marimba\proxyroot\logs\

UNIX

/opt/bmc/BladeLogic/8.0/AdvancedRepeater/tuner/.marimba/proxyroot/logs/

marimba.tuner.display.nodisplay=true

Table 4 Configuration files for Advanced Repeater

Configuration file Default location

Properties file

properties.txt The main configuration file for the tuner is located in:

Windows

C:\Program Files\BMC Software\BladeLogic\8.0\AdvancedRepeater\tuner\lib\tuner\properties.txt

UNIX

/opt/bmc/BladeLogic/8.0/AdvancedRepeater/tuner/lib/tuner/properties.txt

Table 3 Log files for Advanced Repeater

Log file Default location


Starting and stopping the Advanced Repeater

Starting and stopping the Advanced Repeater

Use the following procedures to start and stop the BMC BladeLogic Advanced Repeater:

■ On UNIX, use the following command:

■ On Windows, use one of the following procedures:

— From the Start menu, click Programs => BMC Software => BladeLogic Server Automation Suite => Advanced Repeater.

— From the Services dialog, start or stop the BMC BladeLogic Advanced Repeater Service.

Preferences file

prefs.txt The preferences file is located in:

Windows

C:\Program Files\BMC Software\BladeLogic\8.0\AdvancedRepeater\tuner\.marimba\BCAC\prefs.txt

UNIX

/opt/bmc/BladeLogic/8.0/AdvancedRepeater/tuner/.marimba/ws3/prefs.txt

/etc/init.d/advancedrepeater {start|stop}

Table 4 Configuration files for Advanced Repeater

Configuration file Default location


C h a p t e r 8
8 Integrating BMC BladeLogic and Change Management
You can integrate BMC BladeLogic with your Change Management processes, enabling you to track infrastructure change actions.

Once configured and enabled, you can track infrastructure changes when a change is initiated by the BMC BladeLogic operator or when a remediation job is required due to the results of audit and compliance jobs.

The following topics provide an overview of integrating BMC BladeLogic with the BMC Remedy ITSM change management solution, and describe how to enable that integration within BMC BladeLogic.

Levels of integrationThe following sections provide an overview of the integration points, and describe the configuration tasks in BMC BladeLogic that are required to communicate with BMC Remedy ITSM.

■ The BMC Continuous Compliance for Servers solution

■ Requirements for integration

NOTE BMC BladeLogic supports integration with BMC Remedy ITSM Change Management.


The BMC Continuous Compliance for Servers solution


The BMC Continuous Compliance for Servers solution increases the value of BMC BladeLogic by providing an out-of-the-box integration with BMC Remedy ITSM applications, enabling an automated coordination of configuration management processes with other ITIL® processes, such as incident management and change management. This automation not only saves organizations time, but also reduces errors commonly associated with the manual coordination of change and configuration management.

The BMC Continuous Compliance for Servers solution automates the integration of BMC BladeLogic monitoring, auditing, compliance, and remediation processes with IT management systems such as BMC Remedy ITSM. The integration of BMC BladeLogic with BMC Remedy ITSM is accomplished through standard application interfaces (APIs).

For more information on the BMC Continuous Compliance for Servers solution, contact your BMC Software sales representative.

Benefits of the integration

Implementing the BMC Continuous Compliance for Servers solution enables compliance to the change process without requiring IT personnel to manually create change tickets. The solution reduces the risk of unauthorized and unplanned changes through enforced change tracking and automated documentation of all changes.

If you implement the solution, you can

■ facilitate the tracking of infrastructure change actions initiated by a BMC BladeLogic operator. See “Facilitating BMC BladeLogic operator-initiated change” on page 331.

■ ensure continuous compliance for servers. See “Ensuring continuous compliance for servers” on page 331.

■ enrich BMC Remedy ITSM incidents with server configuration information. See “Enriching BMC Remedy ITSM incidents with server configuration information” on page 331.

There are several configuration tasks you need to perform to enable the integration of BMC BladeLogic and BMC Remedy ITSM. These tasks are described in “Enabling BMC Remedy ITSM integration for job approval” on page 333.

There are also a number of installation and configuration tasks for other BMC Software tasks to enable the solution. For an overview of these tasks, see “Requirements for integration” on page 332. For complete details on installing and configuring BMC Atrium Orchestrator and setting up the BMC Remedy ITSM templates and filters, see BMC Continuous Compliance for Server Automation Solution Getting Started Guide.



Facilitating BMC BladeLogic operator-initiated change

When operations changes are implemented, operators need to document these changes in BMC Remedy ITSM Change Management. To automate this change tracking process, a change request is automatically created in BMC Remedy ITSM when a BMC BladeLogic operator submits a job that requires BMC Remedy ITSM tracking and approval. Once the change is approved in BMC Remedy ITSM, the job is scheduled for execution in BMC BladeLogic.

After the job has run, the BMC Remedy ITSM change task is closed with an associated completion status and any changed configuration items (CIs). The BMC Remedy ITSM user can launch the job details report from the task to verify the change actions.

The main benefit of this integration is to enforce continuous compliance to the change process without introducing labor intensive activities. The integration reduces the risk of unauthorized and unplanned changes through enforced change tracking.

Ensuring continuous compliance for servers

This integration involves automatically creating incidents and change requests if non-compliant servers are detected, or if deviations from a master server configuration are detected. The server auditing and server compliance capabilities in BMC BladeLogic involve:

■ detecting discrepancies between specific servers or component configurations against a baseline server or configuration

■ monitoring and detecting compliance violations between specific servers or component configurations against specific rules related to operations, security, and governance

BMC BladeLogic integrates the remediation of discrepancies and compliance violations in BMC BladeLogic to the change management processes facilitated by BMC Remedy ITSM management system.

Enriching BMC Remedy ITSM incidents with server configuration information

This integration involves automating the addition of information from various relevant sources (such as BMC Atrium Configuration Management Database (CMDB) and BMC BladeLogic servers) to the incident ticket when a server-related incident is detected in BMC Remedy ITSM. These details added to the workinfo note of incident include things such as:

■ audit trails■ basic server configuration information■ historical deployments in the past 24 hours■ links to BMC BladeLogic Decision Support for Server Automation reports


Requirements for integration

Requirements for integration

To integrate BMC BladeLogic with BMC Remedy ITSM, you must have several BMC Software products installed and configured:

■ BMC Atrium Orchestrator ■ BMC Remedy ITSM■ BMC BladeLogic Server Automation■ BMC BladeLogic Integration for Atrium

The BMC BladeLogic solution integrates the BMC Remedy ITSM and the BMC BladeLogic systems, using BMC Atrium Orchestrator as the enabling technology. To implement the solution, you must complete the following configuration tasks in BMC Atrium Orchestrator and BMC Remedy ITSM:

■ Tasks for integration with BMC Remedy IT Service Management

— Create the user ID which is used for monitoring the BMC Remedy alerts.

— Review default BMC Remedy templates - The BMC Atrium Orchestrator workflows create incidents, change tickets, and tasks using BMC Remedy ITSM templates.

■ Tasks for integration with BMC Atrium Orchestrator

— Configure and deploy the required Operations Actions (OA) management modules

— Configure BMC Atrium Orchestrator Run Book modules

For details on installing and configuring BMC Atrium Orchestrator and setting up the BMC Remedy ITSM templates and filters, see BMC Continuous Compliance for Server Automation Solution Getting Started Guide.

To complete the integration tasks associated with BMC BladeLogic, see “Enabling BMC Remedy ITSM integration for job approval”.


Enabling BMC Remedy ITSM integration for job approval

Enabling BMC Remedy ITSM integration for job approval

If your environment has been configured to integrate BMC BladeLogic with BMC Remedy ITSM Change Management (as described in BMC Continuous Compliance for Server Automation Solution Getting Started Guide), you can track these infrastructure changes when the change is initiated by the BMC BladeLogic operator.

To fully enable the integration, complete the following configuration tasks in BMC BladeLogic:

■ Configuring job approval for job types

■ Assigning job approval permissions

■ Setting up the connection to BMC Atrium Orchestrator

■ Enabling HTTPS support for the BMC Atrium Orchestrator connection

Configuring job approval for job types

The Approval Configuration option enables you to configure whether or not jobs of a given type require BMC Remedy ITSM approval. By default, the approval for each supported job type is turned off.

Use this procedure to enable or disable the BMC Remedy ITSM job approval capability at the job type level, if integration with BMC Remedy ITSM for job approval is desired.

To configure job approval for job types

1 From the BMC BladeLogic Console, select Configuration => Approval Configuration.

2 On the Job Approval Required Configuration dialog, set the Approval Required option for each available job type.

3 Click OK.

NOTE Two of these tasks—setting up the connection to BMC Atrium Orchestrator and (optionally) enabling HTTPS support—are necessary also for integrating with BMC Atrium Orchestrator for the creation of Workflow Jobs through the BMC BladeLogic Console. For more information about Workflow Jobs, see the BMC BladeLogic Server Automation User Guide.


Assigning job approval permissions

All job types with Yes specified for the Approval Required option will require the completion of the Approval tab information in the job wizard.

Assigning job approval permissions

Use this procedure to assign permissions to different BMC BladeLogic users for integrating job execution with BMC Remedy ITSM. Assign the appropriate approval type to each user role. When that user logs on, only the job approval type assigned for the user role is listed when running the job wizard.

To assign job approval permissions

1 In the RBAC Manager workspace of the BMC BladeLogic Console, select Roles.

2 Right-click a role and select Open.

3 Click the Systems tab.

4 Add any of the following RBAC controls to enable specific BMC Remedy ITSM job approval permissions

■ Automatic ■ Manual ■ Emergency ■ NoApproval

For example, you may create a role for junior operators that has only Manual permission, ensuring that any jobs they initiate would be reviewed and approved by a BMC Remedy ITSM prior to execution.

5 Click OK to save the updates.

6 Click OK to exit the Update Permissions panel.

NOTE By default, the BLAdmins Role has permissions to all approval permissions.


Setting up the connection to BMC Atrium Orchestrator

Setting up the connection to BMC Atrium Orchestrator

Through the BMC BladeLogic Console, you must add the configuration information required to connect to BMC Atrium Orchestrator.

Before you begin

From the BMC BladeLogic Console, ensure that your role is granted the AOConfig.* and the AutomationPrincipal.* authorizations.

To configure the connection with BMC Atrium Orchestrator

1 Select Configuration => AO Configuration.

2 On the AO Configuration dialog box, click Add.

3 On the Add new AO configuration dialog box, enter the configuration information required to connect to BMC Atrium Orchestrator, and then click OK.

NOTE The integration between BMC BladeLogic Server Automation and BMC Atrium Orchestrator supports connections to a single grid only.

The connection with BMC Atrium Orchestrator is established through the CDP or through a high availability CDP (HACDP). Other types of peers are not supported.


Host The IP address or fully-qualified host name of the BMC Atrium Orchestrator CDP server.

Port The port number used to connect to the BMC Atrium Orchestrator CDP.

Grid Name The name defined for the BMC Atrium Orchestrator grid.

Specify the name of a grid only if this is the first defined CDP connection. For any additional CDP connection (see step 4), this field is read-only, as all defined connections must be on the same grid.

User Name The name of the BMC Atrium Orchestrator user used to log on to the CDP. This user must be associated with the ADMIN role in BMC Atrium Orchestrator.

Password The BMC Atrium Orchestrator password for the specified user.

Time-out The amount of time, in seconds, before a BMC BladeLogic job that connects to BMC Atrium Orchestrator times out. The default is 300 seconds (five minutes).


Enabling HTTPS support for the BMC Atrium Orchestrator connection

If you want to test whether or not you can connect to the CDP with the host, port, grid name, user name, and password details that you specified, click Check Connection.

4 If you want to add additional CDP connections to BMC Atrium Orchestrator, to ensure high availability, repeat step 2 and step 3 for every additional CDP instance of the same grid.

If you define multiple BMC Atrium Orchestrator CDP instances, ensure that only one of your CDPs is set as the primary instance (using the Primary AO check box). Multiple CDPs installed on a grid form a High Availability (HACDP) environment and allow communication to continue even when the connection with one CDP fails.

5 Click Close on the AO Configuration dialog box.


If you want to secure the communication of data between BMC BladeLogic Server Automation and BMC Atrium Orchestrator, you must enable an HTTPS connection on both products.

To enable HTTPS support on BMC Atrium Orchestrator

1 On the system where the BMC Atrium Orchestrator CDP is installed, create the keystore file by entering a command such as the following example:

The value entered for the -dname option must match the host name where the BMC Atrium Orchestrator CDP is installed. In this example, the value is w2k3-sp-vm5.

Primary AO Whether to specify this CDP as the primary instance.

In a high-availability environment with multiple CDP instances, ensure that you select the correct CDP, as defined in BMC Atrium Orchestrator.

SSL enabled? Whether the connection to the CDP is SSL enabled and based on an HTTPS connection (as described in “Enabling HTTPS support for the BMC Atrium Orchestrator connection”).

keytool -genkey -alias w2k3-sp-vm5 -dname "cn=w2k3-sp-vm5" -keyalg RSA -keystore C:\.keystore -storepass changeit




2 Enable HTTPS on Tomcat by completing the following steps:

A Open the server.xml file.

B Uncomment the following block of configuration information and add two attributes.

The keystoreFile attribute points to the location where the keystore file resides and the truststoreFile attribute points to the CA issued certs in the JDK installation location.

3 Restart the BMC Atrium Orchestrator CDP.

To enable HTTPS support for BMC Atrium Orchestrator on BMC BladeLogic

1 If BMC Atrium Orchestrator is installed on a different machine, copy the C:\.keystore file from the BMC Atrium Orchestrator CDP system to the system where the BMC BladeLogic application server is installed.

2 On the system where the BMC BladeLogic application server is installed, export the public certificate from the keystore file which was generated for BMC Atrium Orchestrator to a temporary file by entering a command such as the following example:

In the command shown above, note the following:

■ file is the name and location of the certificate file that is going to be created from this command.

■ keystore is the keystore file name and location that you created for BMC Atrium Orchestrator.

■ alias is the name used to distinguish certificates.

3 Add the public certificate from the temporary file to the trusted certificate file by entering a command such as the following example:

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="C:\.keystore" truststoreFile="C:\Program Files\Java\jdk1.5.0_13\jre\lib\security\cacerts" />

keytool -export -alias w2k3-sp-vm5 -file C:\cert.csr -keystore C:\.keystore -storepass changeit



where C:\Program Files\BMC Software\BladeLogic\version is the default installation path of BMC BladeLogic. Change the path if BMC BladeLogic was installed in a different location.

4 Enter the following command to check whether the certificate was added to the cacerts file:

5 Restart the BMC BladeLogic application server.

keytool -import -alias w2k3-sp-vm5 -file C:\cert.csr -keystore "C:\Program Files\BMC Software\BladeLogic\version\NSH\jre\lib\security\cacerts" -keypass changeit

keytool -list -keystore C:\Program Files\BMC Software\BladeLogic\version\NSH\jre\lib\security\cacerts


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

Security Glossary This chapter provides definitions of terms commonly encountered when discussing network security.

AActive Directory

Microsoft's directory service, which provides a centralized system for automating management of networked entities, such as applications, files, printers, and users.

AD/Kerberos authenticationThe Active Directory/Kerberos (AD/Kerberos) approach to authentication, which integrates BMC BladeLogic with a key distribution center (KDC) to utilize the Kerberos v5 protocol for authenticating client-tier users.

AESThe Advanced Encryption Standard (AES) is an encryption algorithm that has become the encryption standard used in most commercial transactions.

asymmetric encryptionA method of encryption that uses public and private keys. The public key, known to everyone, is used to encrypt data, and the private key, known only to the recipient of the data, is used to decrypt the data.

authentication profileA collection of information that a BMC BladeLogic client (BMC BladeLogic Console, Network Shell, or the BLCLI) uses to specify the Authentication Service from which a session credential should be obtained and the authentication mechanism that should be USED to acquire that session credential.

Authentication ServiceA service implemented within the BMC BladeLogic Application Server that is responsible for authenticating a user and issuing a session credential. Typically, an authentication service is implemented within the BMC BladeLogic Application Server, but for BMC BladeLogic Decision Support for Server Automation, the authentication service stands alone.

Ccertificate authority (CA)



The trusted party issuing digital certificates (especially X.509 public-key certificates) to an identified end entity and vouching for the binding between the data items in a certificate. A certificate authority can be managed by an external certification service provider or the CA can belong to the same organization as the end entities in a public key infrastructure (PKI). CAs can also issue certificates to other sub-CAs. This leads to a tree-like certification hierarchy. The highest trusted CA in the tree is called a root CA.

certificatesDigital documents used for secure authentication of communicating parties. A certificate binds identity information about an entity to the entity's public key for a certain validity period. A certificate is digitally signed by a trusted third party who has verified that the key pair actually belongs to the entity. Certificates can be thought of as analogous to passports that guarantee the identity of their bearers.

certificate management protocol (CMP)A definition of the online interactions between end entities, registration authority (RA), and the certificate authority (CA) in a public key infrastructure (PKI).

certificate revocation list (CRL)A signed list containing the serial numbers of the certificates that have been revoked or suspended by the certificate issuer (the certificate authority (CA)) before their expiration date. The CA usually issues new CRLs at frequent intervals.

certification requestA request for a certificate, generated by end entities or registration authority (RA) and sent to the certificate authority (CA). A certification request contains at least the public key and some identity information about the entity making the request. A certificate is signed with the private key of the entity. If allowed by the certificate policy of the CA, a certificate can be issued based on the request.

certification service provider (CSP)An organization that acts as a trusted third party or a certificate authority (CA) host providing public key infrastructure (PKI) services to other organizations and individuals.

DData Encryption Standard (DES)

A common method of data encryption using a secret key that is shared by the sender and receiver.

distinguished nameAn PKCS entry that identifies a user for an LDAP server. A distinguished name consists of the name of an entry as well as the names of the objects above that entry in the LDAP directory. Those objects are listed from bottom to top. For example, a distinguished name might be CN=admin, CN=Users, DC=sub1, DC=kerbtest, DC=bladelogic, DC=com.

DN



An LDAP distinguished name.

Domain AuthenticationAn approach to authentication that is based on AD/Kerberos authentication. Domain Authentication only requires a user to provide a name, domain, and password when logging in. This information is passed to the Authentication Service, which delegates user authentication to the Active Directory domain controller.

domain controllerA role assigned to a server in a network of computers running the Windows NT operating system. In Windows NT, domains are used to manage access to network resources. A user can access network resources by logging into the domain. One server on the network functions as the primary domain controller by managing a master database of users for the domain. Additional servers can function as backup domain controllers. The primary domain controller periodically sends copies of its database to the backup domain controllers.

Ffailover

A mode of operating in which a secondary component takes over the functions of a primary component when the primary component cannot function.

IInternet Protocol Security (IPSec)

A protocol suite, defined by the Internet Engineering Task Force (IETF), for protecting IP traffic at the packet level. IPSec can be used for protecting the data transmitted by any service or application that is based on IP. The IPSec protocols are defined in RFC 2401.

JJKS

Java keystore. A type of keystore file used for holding certificates.

Kkeystore

A file used to store a list of certificates along with their private keys.

KerberosA cross-platform mechanism for mutual authentication between a client and server or between two servers before a network connection is opened between the two. The protocol uses strong cryptography so a client can prove its identity to a server (and vice versa) across an insecure network connection. After a client and server have used Kerberos to prove their identity, they can encrypt all of their communications to assure privacy and data integrity. The BMC BladeLogic implementation of Kerberos is based on MIT’s Kerberos v5.



LLDAP

Lightweight Directory Access Protocol (LDAP). The protocol for querying and modifying directory entries that are arranged in a hierarchical, tree-like structure.

Lightweight Directory Access Protocol (LDAP)A directory access protocol for accessing directories supporting the X.500 models. Many companies are using LDAP-based solutions as directories and user management systems.

Nnonce

A random number used for cryptographic processes. The number is used only once to ensure that any communication used for authentication cannot be reused.

PPKCS

A group of public key cryptography standards devised and published by RSA Security.

PKISee public key infrastructure (PKI).

proxy modeA method of using Network Shell to connect to a remote server via a Network Shell Proxy Server rather than connecting directly to the remote server.

public key cryptographyA method for authenticating a sender or encrypting a message sent over a network. In public key cryptography, the encryption and decryption of messages is done with different keys. This means that each participating entity (person or device) of the public key infrastructure (PKI) has two keys, a public key and a private key.

public key infrastructure (PKI)A collection of mechanisms that together allow network users to exchange data securely over a network. Public key infrastructure consists of a certificate authority (CA), certificate repositories (directories), and other mechanisms needed to authenticate, encrypt, and decrypt communication using public key cryptography. BMC BladeLogic provides an approach to user authentication based on PKI.

RRC4

An encryption algorithm, which requires a secure exchange of a shared key.



RBACThe BMC BladeLogic system of role-based access control (RBAC).

role-based access control (RBAC)A system of granting permissions to perform certain types of actions to a role and then assigning users who need those permissions to the role. In this way you can define a set of permissions that might be used by an entire class of users, such as expert administrators or help desk personnel. The RBAC Manager workspace in the BMC BladeLogic Console lets you define roles. For more information on RBAC, see the BMC BladeLogic Server Automation User Guide.

RSA SecurIDSee SecurID.

Ssecure remote password (SRP)

A protocol for integrating secure password authentication into networked applications. SRP is the default approach to user authentication in BMC BladeLogic.

SecurIDRSA’s authentication protocol based on two-factor authentication.

service URLThe identity and address of a BMC BladeLogic Application Service or Network Shell Proxy Service that can be accessed using a session credential.

session credentialA credential issued to a BMC BladeLogic client application after a successful user login. BMC BladeLogic clients use session credentials to establish secure sessions with BMC BladeLogic Application Servers and Network Shell Proxy Servers.

session keyA key used for encrypting and decrypting traffic during a communication session. Session keys are symmetric, meaning the same key is used to encrypt and decrypt data. Because symmetric encryption is very fast and asymmetric encryption is very slow, asymmetric encryption is used only to encrypt a session key. After the session key is decrypted, it is used for symmetric encryption of all subsequent communication during a session.

SHA1The most commonly used function in the Secure Hash Algorithm (SHA) family of cryptographic hash functions. A hash function like SHA1 takes a long string as input and produces a fixed-length string as output. This output is sometimes called a digital fingerprint. SHA1 is used for many security application and protocols, including TLS.

single sign-on



The capability for users to cache session credentials so they can be used to secure subsequent sessions between client-tier applications and the Application Server or Network Shell Proxy Server. As long as the session credential is valid, the user does not have to authenticate again.

TTransport Layer Security (TLS)

A protocol providing confidentiality, authentication, and integrity for stream-like connections. TLS is typically used to secure HTTP connections. TLS is the successor to the Secure Socket Layer (SSL) protocol.

trust storeA file used to store a list of trusted certificates.

XX.509

A standard for defining digital certificates. The ITU-T X.509 recommendation defines the formats for X.509 certificates and the X.509 certificate revocation list (CRL).



Index

Symbols<appender> tag

for log4crc.txt file 274<category> tag

for log4crc.txt file 273<layout> tag

for log4crc.txt file 277

Aaccess

to RSCD agents 233, 237accounts

locking out 88Active Directory

defined 339Active Directory/Kerberos 123AD/Kerberos

setting up Network Shell Proxy Servers 193user names 192

AD/Kerberos authenticationconfiguring Authentication Service 184, 185, 191console to Application Server 194copying keytab file to Application Server 185creating blappserv_krb5.conf file 186creating blappserv_login.conf file 188creating blclient_krb5.conf file 198creating blclient_login.conf file 196creating user accounts 181default users and roles 194defined 339exporting keytab file 181implementing 177locating KDC for client’s domain 197locating KDC for service principal 186overview 178registering Authentication Service 180requirements for Active Directory server 180running kinit to get a TGT 201sample domain structure 171updating config.properties file for clients 200updating Kerberos registry settings 196verifying a keytab file 190

advanced file serverconfiguring 312

network throttling options 315advanced repeater

configuring 316disk space recommendations 306installing 307network throttling options 318overview 305securing communication 319using network throttling 324

AESdefined 339

agent logsdisabling secure logging 280enabling secure logging 279security overview 277verifying integrity of 279

agentsand configuration files 233, 235cleanup of 293configuring to authenticate using client-side certs 206,

209exports file 240granting access 233, 237provisioning with SHA1 fingerprints 204, 208scheduling cleanup of 300secure file 253users file 247users.local file 247

anonymoususer on Windows 17

Application Serverinformation about 106reporting information about 108

Application Server Administration console 44binding to an IP address 67canceling jobs 60configuring Application Server 52configuring database server 78configuring file server 74configuring mail server 76configuring Network Shell Proxy Server 68configuring Perl 77configuring process spawner 79configuring remote execution objects 68configuring SNMP server 77configuring the PXE Server 89

Index 345


controlling user interface settings 84crossing mount points 82default permissions 86deleting group 84enabling asynchronous execution 92enabling import/export of property classes 87enabling import/export of Property Dictionary 87enabling/disabling the retention policy utility 289evaluating SOCKS Proxy Server rules 73job distribution 55limiting smart live browse results 85preparing HTTP proxy server support 66restricting size of configuration objects 83restricting size of extended objects 83scaling Application Server 52setting client idle time 60setting communication ports 65setting compliance results maximum 62, 70setting connection types 65setting database connections 64setting login requirements 88setting past due job behavior 63setting retention time for automatically-generated

objects 291setting time-out behavior 61showing no access nodes 84specifying update group location 87starting 45

Application Server cachescheduling cleanup of 299

Application Server Launchersediting access list for 113

Application Serversattributes for 100attributes of 96authentication framework 33canceling jobs 60changing access to 113changing configuration of 100cleanup of caches for 293communication ports 65compliance results maximum 62, 70configuration wizard 34configuring 29, 93creating client-side certs 203, 207creating multiple 97database connections 33, 64deleting the deployment of 110deployment directories for 95deployments 94discontinuing client-side certs 210introduced 15job distribution 32job execution thread 31managing 44maximum client idle time 60multiple 93, 96

346 BMC BladeLogic Server Automation Administratio

past due job behavior 63pausing 43profiles 93profiles for 96, 100provisioning agents with SHA1 fingerprints 204, 208restarting 111restricting size of configuration objects 83restricting size of extended objects 83scaling 52securing with certificates 223securing with client-side certs 202, 206security for 133setting up to cooperate 58shutting down gracefully 43starting 41, 42, 109stopping 42, 109, 111terminating process for 111tier 13time-out behavior 61types of 96undeploying 110understanding 30work item threads 31

Application Service 135configuring 140

architectureof BMC BladeLogic system 13

asymmetric encryptiondefined 339

asynchronous executionenabling 92

audienceintended 11

authenticationAD/Kerberos 123Application Server framework 33described 117domain 124for BMC Service Automation Reporting and Analytics

132LDAP 122, 158managing profiles with blcred 226PKI 123profile files 150, 151, 152profiles 124, 125SecurID 123, 163, 166single sign-on 121, 126, 128, 129, 135SRP 122

Authentication Service 135configuring 137configuring for AD/Kerberos 184, 191configuring for Domain Authentication 171registering in Active Directory domain 180

authorizationdescribed 120

automatically-generated objectssetting retention time for 291

n Guide


BBladeLogic integration

configure job approval for job types 333blappserv_krb5.conf file 173

creating for Application Server 186blappserv_login.conf file 174

creating for Application Server 188blasadmin utility 44

starting 45BLCLI

security 130settings for 84

blclient_krb5.conf filecreating for consoles 198

blclient_login.conf filecreating for consoles 196

blcredconfiguring for AD/Kerberos 194utility 125, 226

bltray 215BMC Atrium Orchestrator integration 333BMC BladeLogic

architecture 13, 14, 15configuration files 233, 233–264, 271configuring Application Server 29default permissions 16default security configuration 16introduced 11, 11–12overview 13, 13–19Perl support 17security 115, 115–231security glossary 339

BMC BladeLogic Consoleand secure file 253job parts 31jobs and Application Server 31security 130

BMC Service Automation Reporting and Analyticsauthentication 132security for 132server-side certificates 132

BMC Software, contacting 2browsing

limiting number of results 85

Ccaching

user information 230certificate

authority 339management protocol 340revocation list 340

certificate trust storefor LDAP 159

certificatesdefined 340for BMC Service Automation Reporting and Analytics

132for secure communication 258importing to clients 226managing with blcred 226setting up 223, 224verifying with OCSP 153

certificationrequest 340service provider 340

chrole command 128cleanup

of agents on servers 293of BMC BladeLogic database 288of repeater servers 294of the Application Server cache 293of the file server 295scheduling of 297

cleanupDatabase command 292client connections

maximum idle time 60client tier 13

of BMC BladeLogic 14clients

connections to database 64secure file 253use of term 11

client-side certs 119discontinuing use 210, 216, 222for Application Server 202, 203, 206, 207for Network Shell client 212, 216for repeaters 218, 219, 221, 222used by agents to authenticate 206, 209

commandsrestricting access with exports file 244

communication legsApplication Server to agent or repeater 133, 202, 206,

210BLCLI to Application Server 130console to Application Server 130, 194illustrated 116Network Shell to agent 133, 211, 212Network Shell to Network Shell Proxy Server 131repeater to agent 134, 217, 218, 219, 221, 222reports client to reports server 132security for 130

communication portssetting 65

Compliance Job resultssetting maximum number displayed 62, 70

config.properties file for clients 200configuration

for Domain Authentication 172, 173, 174, 175configuration files

exports file 240

Index 347


log4crc.txt 272–285logging 272, 272–285overview 233, 235secure file 253, 253–262securecert file 262setting up 233, 233–264, 271subnet designations 236users file 247, 247–253users.local file 247, 247–253

configuration objectsrestricting size 83

configuration wizardfor Application Server 34

connection typesfor Application Server 65

consolesettings for 84

conventionsused in documentation 12

copying objectsdefault permissions 86

cross-registeringusers in RBAC database 160, 166, 169, 176, 192

customer support 3

DData Encryption Standard

defined 340database cleanup 288, 289

scheduling 298utility for 292

database configurationfor Application Server 36

database connectionsfor Application Server 33, 64

databasesconfiguring 78connecting to Application Server 15connections to 64

default entryin secure file 256

deployments 95deleting for an Application Server 110of Application Servers 94

DESdefined 340

distinguished namesfor LDAP 160

documentationconventions 12for Network Shell 12

Domain Authentication 124configuring 171, 172, 173, 174, 175default users and roles 177implementing 170


user names 176domain controller

defined 341

Eencryption

described 118for secure communication 258

environment variables 129exports file 240, 240–247

configuring 241examples 246introduced 233, 235options for configuring 241restricting access to commands 244

extended objectsrestricting size 83

Ffile servers

cleanup of 295configuring 37, 74configuring advanced file servers 312scheduling cleanup of 299

Ggroups

deleting in console 84

Hhigh availability 159host entries

in secure file 257HTTP proxy server 66

Iimpersonation 119

described 119import and update process

specifying temporary group location 87indirect deployments

and certificates 262Infrastructure Management window

Application Server information 106installing the BMC BladeLogic Advanced Repeater 307integration and configuration checklist 332Internet Protocol Security

defined 341

n Guide


introductionto BMC BladeLogic administration 11, 11–12

IP addressbinding Application Server to 67

IPSecdefined 341

Jjob execution thread

for Application Server 31job parts

for BMC BladeLogic Console jobs 31job runs

setting retention time for 290jobs

canceling 60defining time-outs 60distributing between Application Servers 32, 55past due 63setting maximum for Application Server 52

KKDC

locating for client’s domain 197locating for service principal’s domain 186

Kerberosdefined 341

Kerberos authentication 123, 178client to Application Server 194configuring Application Server 185configuring Authentication Service 184, 191configuring blcred 194copying keytab file to Application Server 185creating blappserv_krb5.conf file 186creating blappserv_login.conf file 188creating blclient_krb5.conf file 198creating blclient_login.conf file 196creating user accounts 181default users and roles 194exporting keytab file 181implementing 177locating KDC for client’s domain 197locating KDC for service principal 186registering Authentication Service 180requirements for Active Directory server 180running kinit to get a TGT 201sample domain structure 171updating config.properties file for clients 200updating Kerberos registry settings 196verifying a keytab file 190

keystore filefor cooperating Application Servers 58

keystroke logs 281

disabling 283enabling 283

keytab files 128copying to Application Server 185exporting 181verifying 190

klistdisplaying SPN for Application Server 189

LLDAP

defined 342user names 160

LDAP authentication 122certificate trust store 159configuring 161distinguished names 160high availability 159implementing 158overview 158

listening portson Application Server 65

log4crc.txt file 272, 272–285<appender> tag 274<category> tag 273<layout> tag 277configuring syslog 284default values 285syntax 272

loggingconfiguration file 272configuring syslog 284default values 285

loginsetting requirements 88

Mmail server

configuring 76man pages 12middle tier

communication 118of BladeLogic 13of BMC BladeLogic 15

mount pointssetting up in Application Server 82

NNetwork Shell

and secure file 253caching private keys 214discontinuing use of client-side certs 216

Index 349


documentation 12man pages 12managing private keys 214securing with client-side certs 212security 131, 133

Network Shell Proxy Servers 68configuring 142configuring clients for 147configuring stand-alone 145setting up for AD/Kerberos 193user information for scripts 147

Network Shell Proxy Service 135configuring 142, 149

Network Shell Script Jobsfor Application Server cache cleanup 299for cleanup 297for database cleanup 298for file server cleanup 299for repeater server cleanup 300for retention policy utility 297for target server (agent) cleanup 300

network throttlingfor advanced file servers 315for advanced repeater 318overview 324

no access nodesshowing in console 84

nobodyuser on UNIX 17

notificationssetting through configuration wizard 38

OOCSP 153overview

BMC BladeLogic 13, 13–19of Application Server 30of configuration files 233, 235

Ppasswords

requiring periodic changes 88setting minimum length 88setting through configuration wizard 38

past due jobs 63Perl 17

configuring 77permissions

default 16for copied objects 86

PKCS#12defined 342

PKI


defined 342PKI authentication 123ports

Application Server 65for remote execution objects 68

Post-Install Configuration wizard 34database configuration 36file server configuration 37notification configuration 38password configuration 38

private keyscaching in UNIX 215caching in Windows 215managing 214

privilege mappingdescribed 119

process spawnerconfiguring 79

product support 3profiles 100property classes

enabling import/export 87Property Dictionary

enabling import/export 87protocol levels

defined in secure file 255for secure communication 258

public key cryptographydefined 342

public key infrastructuredefined 342

PXE Serverconfiguring 89

RRBAC 128

cross-registering users 160, 166, 169, 176, 192defined 343

RC4defined 342

remote execution objectsconfiguring ports 68

repeater serverscleanup of 294scheduling cleanup of 300

repeatersand certificates 262configuring advanced repeaters 316discontinuing use of client-side certs 222provisioning with SHA1 fingerprints 204, 208securing with client-side certs 218, 219, 221security for 134using advanced repeater servers 305

RESULTS_RETENTION_TIME property 290retention policy utility

n Guide


description of 289enabling/disabling 289executing 291scheduling for execution 297

retention timefor automatically-generated objects 291for job runs 290

rolesselecting 128

RSA SecurID 123RSCD agents

and configuration files 233, 235exports file 240granting access 233, 237secure file 253users file 247users.local file 247

rscd entryin secure file 256

Sscripts

user information for 147secadmin utility 258

introduced 233, 235secure agent logging 277

disabling 280enabling 279

secure agent logssecurity overview 277

secure file 253, 253–262certificates 258client and server interaction 254communication protocols 255configuring 255configuring for agents 210, 222configuring for Network Shell Proxy Servers 147default entry 256encryption method 258examples 261host entries 257introduced 233, 235options for configuring 258protocol levels 258rscd entry 256setting defaults for clients 256setting defaults for servers 256setting parameters for a client 257setting up for NSH clients 212, 216

secure remote passworddefined 343

securecert file 262configuring 263

SecurIDuser names 166, 169

SecurID authentication 123configuring 163, 167, 168configuring RSA Authentication Manager 163implementing 163, 166

securityadministering 115, 115–231Application Server to agent or repeater 133, 202authentication using client-side certs 117authorization 120BLCLI to Application Server 130console to Application Server 130default configuration 16for different communication legs 130fundamentals 117glossary 339impersonation 119Network Shell to agent 133, 211Network Shell to Network Shell Proxy Server 131privilege mapping 119repeater to agent 134, 217reports client to reports server 132session layer 118single sign-on 121, 135using blcred 226

self-signed certificates 119server tier

communication 119of BladeLogic 13of BMC BladeLogic 15

serversuse of term 11

server-side certificatesfor BMC Service Automation Reporting and Analytics

132service principal name

displaying with klist 189service URLs 117session credential cache file 150, 151, 152session credentials 121, 122, 123, 124, 126

managing with blcred 226session key

defined 343session layer security

described 118single sign-on 117

AD/Kerberos authentication 123authentication profiles 124, 125certificate verification using OCSP 153client file locations 152client files 150, 151described 121Domain Authentication 124environment variables 129implementing 135, 137, 140, 142importing CA certs to clients 226keytab files 128LDAP authentication 122

Index 351


overrides for client SSO files 150PKI authentication 123SecurID authentication 123selecting roles 128session credentials 126SRP authentication 122

smart card authentication 123SNMP server

configuring 77SOCKS Proxy Servers 73SPN

displaying with klist 189SRP

defined 343SRP authentication 122standard terminology 11subnet designations 236support, customer 3syntax

for log4crc.txt file 272syslog

configuring for logging 284system architecture

overview 13

Ttarget server

scheduling cleanup of 300target servers

cleanup of 293technical support 3terminology

BMC BladeLogic 11TGT

running kinit to get 201three-tier architecture 13ticket-gathering ticket

running kinit to get 201time-outs

defining for job parts 60defining for jobs 60

TLScommunication protocol 118middle tier communication 118server tier communication 119

TLS with client-side certsApplication Server to agent or repeater 202, 206, 210Network Shell to agent 212repeater to agent 218, 219, 221, 222

trusted keystore 150, 151, 152

Uupdate process


specifying temporary group location 87user accounts

adding default for AD/Kerberos 194adding default for Domain Authentication 177creating in Application Server’s domain 181locking out 88

user informationfor Network Shell scripts 147generating 230

user interfacessettings for 84

user privilege mapping 17, 119user_info.dat 128users

cross-registering 160, 166, 169, 176, 192requirements for names 160, 166, 169, 176, 192

users file 247, 247–253configuring 249examples 252introduced 233, 235options for configuring 251

users.local file 247, 247–253configuring 249, 250examples 252introduced 233, 235options for configuring 251

Wwild cards

using in users.local 250Windows client configuration

for Kerberos 196Windows user mapping 149work item threads

for Application Server 31, 52, 61Workflow Jobs 333

XX.509 certificates 118

n Guide

*193363**193363**193363**193363*

*193363*

BMCBladeLogicAdministration

Documents

program filesbmc

hklmsystemcurrentcontrolsetcontrollsakerberos

program filesbmc

installdirectorynshbr

settingsadministratorapplication

windirrsccertsbladelogicrscd

windirrsccertssystem

installdirectorybrrcp