BMC BladeLogic Server Automation

Administration Guide

Supporting
BMC BladeLogic Server Automation version 8.1
February 2011

www.bmc.com

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

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 customer_support@bmc.com. (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

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 customer_support@bmc.com. Use the Customer Support website at http://www.bmc.com/support.

4

BMC BladeLogic Server Automation Administration Guide

Contents
Chapter 1 Introduction 11 11 11 12 12 13 13 14 15 15 16 17 18 19 19 21 29 30 30 31 32 33 33 34 34 39 39 41 41 42 42 42 43 Intended Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Shell Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 2 Overview of BMC BladeLogic Server Automation

System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Client tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Middle tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Server tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Default permissions and security configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Perl support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tools for managing BMC BladeLogic data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Troubleshooting tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generating data for support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoring and diagnosing issues in the BMC BladeLogic environment . . . . . . Chapter 3 Configuring the Application Server

Understanding the application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application server processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Work item threads and the job execution thread . . . . . . . . . . . . . . . . . . . . . . . . . . . Job distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pooled database connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authentication framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Application Server Launcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the Post-Install Configuration wizard to configure the default application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the configuration of an application server . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the application server configuration wizard to change configuration settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting Application Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting all Application Servers on the host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Restarting Application Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Restarting all Application Servers on the host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stopping Application Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stopping all Application Servers on the host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Contents

5

Using the Application Server Administration console (blasadmin) to configure Application Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Starting the Application Server Administration console . . . . . . . . . . . . . . . . . . . . . 45 The set Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 The show Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 The help Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Specifying multiple values for a parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Changing the default separator for multiple values. . . . . . . . . . . . . . . . . . . . . . . . . 50 Deleting a configuration setting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Managing Application Server behavior with the Application Server Administration console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Configuring the Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Changing the heap size for BMC BladeLogic components . . . . . . . . . . . . . . . . . . . 71 Enabling/disabling SOCKS proxy rule evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . 73 Configuring the file server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Configuring a mail server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Configuring Perl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Configuring an SNMP server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Configuring a database server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Configuring the process spawner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Configuring expiration time for credentials of NSH Script Jobs . . . . . . . . . . . . . . 82 Processing across mount points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Restricting the size of configuration and extended objects . . . . . . . . . . . . . . . . . . . 83 Configuring user interface settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Setting SRP login requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Configuring the PXE Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Configuring the Licensing Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Enabling asynchronous execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Enabling web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Configuring multiple Application Servers on the same host. . . . . . . . . . . . . . . . . . . . . 93 About Application Server deployments and profiles. . . . . . . . . . . . . . . . . . . . . . . . 94 Creating additional Application Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Viewing and editing an Application Server’s profile . . . . . . . . . . . . . . . . . . . . . . . 100 Listing conflicting attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Getting information about Application Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 The Application Server Launchers node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Reporting Application Server information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Managing multiple Application Servers on the same host . . . . . . . . . . . . . . . . . . . . . 109 Starting a specific Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Stopping a specific Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Redeploying a stopped Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Terminating a specific Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Restarting a specific Application Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Removing an Application Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Adding unmanaged deployments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Editing the list of roles with Application Server Launcher access . . . . . . . . . . . . 113 Resetting database passwords for the Application Server . . . . . . . . . . . . . . . . . . . . . . 114

6

BMC BladeLogic Server Automation Administration Guide

Chapter 4

Administering security

115 117 117 118 119 120 121 122 122 123 123 123 124 124 126 128 128 129 130 130 130 131 132 133 133 134 135 137 140 142 150 153 158 158 159 159 160 160 161 163 163 163 166 166 167 169 170 171 171
7

Fundamentals of BMC BladeLogic security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Session layer security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impersonation and privilege mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SRP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RSA SecurID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PKI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Active Directory/Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Domain Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authentication profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Single sign-on session credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Keytab files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RBAC role selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security for different communication legs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementing single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the Authentication Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the Application Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the Network Shell Proxy Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting override locations for client SSO files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting up certificate verification using OCSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementing LDAP authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of LDAP configuration tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . High availability configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Certificate trust store. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Distinguished names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cross-registering users in the BMC BladeLogic database . . . . . . . . . . . . . . . . . . . Configuring LDAP authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementing RSA SecurID authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring RSA Authentication Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring SecurID authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cross-registering users in the BMC BladeLogic database . . . . . . . . . . . . . . . . . . . Implementing PKI authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring PKI authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cross-registering users in the BMC BladeLogic database . . . . . . . . . . . . . . . . . . . Implementing Domain Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sample domain structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring BMC BladeLogic for Domain Authentication . . . . . . . . . . . . . . . . .
Contents

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 Chapter 5 Setting up configuration files 233 Introduction to the configuration files . . . . . . . . 219 Configuring agents to authenticate incoming requests with client-side certificates 221 Discontinuing use of client-side certificates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Options for users and users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Generating a self-signed certificate for an Application Server . . . . . . . . . . . . . . . . . . 241 Options for exports file . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 8 BMC BladeLogic Server Automation Administration Guide . . . . . . . . . . . 254 Communication protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 Securecert file . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Typical scenarios . . . . . . . . 226 Options . . . and the secure file . . . . 246 Users and users. . . . . . 236 How BMC BladeLogic grants access to RSCD agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 TLS with client-side certs – Securing a UNIX-based Application Server . . . . . . . 222 Using certificates to secure communication between clients and Application Servers . . . . . . . . . . . . . . . . . . . . 211 TLS with client-side certs – Securing a Network Shell client . . . . . . . . . . . . . 194 Implementing security – Application Server to agents or repeaters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Examples . . . . 255 Configuring the secure file . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Provisioning agents with an SHA1 fingerprint of the repeater’s self-signed certificate. . . . . . . servers. . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Using the blcred utility . . . . . . . . . . . 212 Implementing Security – Repeater to agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 Implementing security – Network Shell to agent . . . . . . . . . . 241 Restricting commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Configuring the users or users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 Registering an Authentication Service in an Active Directory Domain . . . 253 Clients. . . . . . . . . . . . . 211 No authentication – Using a default installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Configuring an Authentication Service for AD/Kerberos authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 Configuration file functions . . . . . 184 Configuring a BMC BladeLogic Client for AD/Kerberos authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Overview of AD/Kerberos configuration tasks . . 228 Generating a user information file . . . . . . . . . . . . . . . . . . . . . . . . . 206 TLS with client-side certs – Discontinuing use of client-side certificates . . . . . . . . . . . . . . . 235 Subnet designations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Examples . . . . . . . . . . . . . . . . . . . . . . . 217 Creating a self-signed client-side certificate on the repeater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Securing communication with CA certificates . . . . . . . . . . . . . . . . . . 237 Exports file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Implementing Active Directory/Kerberos authentication. . . . . . . . . . . . . . . 240 Configuring the exports file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255 Options for secure file . . . . . . . . . . . . . . .local files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 TLS with client-side certs – Securing a Windows Application Server . . . . 244 Examples . . . . . . . . . . . . . . . 252 Secure file . . . . .local files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .local files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . Scheduling the cleanup . . . . . . . . . . . . . Additional log files of interest . . About the clean-up utility . . . . . . . . . . . . . . . . . Cleaning up repeater servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scheduling the target server (Agent) cleanup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Changing the administrator user and password for Advanced Repeater Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 Enable SSL on Advanced File Servers and Advanced Repeaters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 6 Managing BMC BladeLogic data 263 264 264 264 267 271 271 271 271 272 287 288 288 289 292 293 293 294 295 296 297 297 298 299 299 300 300 303 Cleaning up the BMC BladeLogic database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 Configuring Advanced Repeater servers. . . . . . . . . . Cleaning up historical data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Installing using the installation program. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Executing the database clean-up utility . . . . . . . . . . . Cleaning up target servers (Agents) . . . . PXE Server logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scheduling the repeater server cleanup . . . . . Collecting log data. . . . . . . . . . . . . . . . . . Scheduling the database cleanup . . Agent logging. . . . . . . . . . . . . . . . . . . . . . . . . . . BMC BladeLogic log file reference . . . . . Chapter 7 Configuring Advanced File Servers and Advanced Repeaters Overview . . . . . . . Scheduling the file server cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cleaning the Application Server cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 Set up the Advanced File Server for secure communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307 Performing an unattended (silent) installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scheduling the Application Server cache cleanup . . . . . . . . . . . . . . . . . . About the Log4crc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Configuring the securecert file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309 Configuring Advanced File Servers and Advanced Repeater servers. . . . . . . . . . . . . Marking data for deletion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Best practice information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306 Installing the BMC BladeLogic Server Automation Advanced Repeater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .txt file . . . . . 312 Configuring Advanced File Servers . . . . . . . . . . . . . . . . . . . . . . . 303 Key terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of BMC BladeLogic log files . . . 304 What is the BMC BladeLogic Advanced Repeater? . . . . . 321 Contents 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Application Server logging . . . . . . . . . . . . . . . . . 319 Generate the SSL certificate . . . . . . . . . . . About logging configuration for BMC BladeLogic . . . . . . . . . . . . . . . . . . Cleaning up the file server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312 Before you begin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scheduling the retention policy utility to mark data for deletion . . . . . . . . . . . . . . . . . . . . . . . . . . 318 Securing communication between Advanced File Servers and Advanced Repeater servers (optional). . . . . . .

. . . . . . . . . 324 Configuring bandwidth throttling between Advanced File Servers and Advanced Repeater servers. . . . . . 334 Setting up the connection to BMC Atrium Orchestrator . . . . . . . . 326 Starting and stopping the Advanced Repeater . . . . . . . . 327 Chapter 8 Integrating BMC BladeLogic and Change Management 329 Levels of integration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 Configuring job approval for job types. . . . . . . . . . . . . . . . . . . 324 Location of log files . . . . . . . . . . . . . . . . . . . . . . . . . 322 Configure the Advanced File Server to use secure communication. . . . . . 335 Enabling HTTPS support for the BMC Atrium Orchestrator connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 Enabling BMC Remedy ITSM integration for job approval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 Security Glossary Index 339 345 10 BMC BladeLogic Server Automation Administration Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 The BMC Continuous Compliance for Servers solution . . . . 330 Requirements for integration . . . . 333 Assigning job approval permissions . . . . . . . . . . 325 Location of configuration files . . . . . . . . . . . . . . .Configure the Advanced Repeater server for secure communication . . . . . . . . . . . . . . 323 Disabling SSL communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 Troubleshooting advanced file servers and advanced repeaters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

a server is a machine where an RSCD agent is installed. Terminology Throughout this document you will see discussions related to client and 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. and how to define user permissions using the BMC BladeLogic configuration files. If a connection is established. how to implement security restrictions. This document describes how to set up and maintain an Application Server. Intended Audience This document is intended for system administrators who manage data centers and networks of remote servers.Chapter 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”). Clients establish contact with servers by means of the RSCD agents installed on server machines. 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 . In the BMC BladeLogic context. Clients are machines running the BMC BladeLogic Console or Network Shell.

and in other contexts the same machine can be a client. Monospace fonts also depict file system paths. and secure configuration files. monospace. enter man <command>. users. Bold fonts identify Network Shell commands and utilities.Documentation Conventions In some contexts. users. 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. In addition. Despite that possibility for confusion. 12 BMC BladeLogic Server Automation Administration Guide . This document always calls the machine being contacted a server. Documentation Conventions In this document. select Add. a machine may be a BMC BladeLogic server. To display a man page while using Network Shell.local. serif fonts depict text that a user might enter at the command line or text that a system generates in response to user input. “From the File menu.” When describing paths. The following is an example of system text: ERROR: You must be "root" for pkgadd to execute properly. Within a procedure. a procedural step might read. Network Shell Documentation BMC BladeLogic provides descriptions of all Network Shell commands and utilities as man pages available on both Windows and UNIX-style systems. as well as the exports. this guide uses UNIX-style path separators (forward slashes) except in situations where a Windows-style path separators (backslashes) are specifically required. such as man nsh. bold text highlights actions that you should take. the BMC BladeLogic Server Automation Network Shell Command Reference provides a full description of all Network Shell commands and utilities. This can happen because you can install client applications on the same hosts where you have installed an RSCD agent. For example.

Chapter 2 Overview of BMC BladeLogic Server Automation 13 . as well as a discussion of other topics that apply to the BMC BladeLogic system as a whole. server.Chapter 2 Overview of BMC BladeLogic Server Automation 2 This chapter provides an overview the system architecture for BMC BladeLogic Server Automation (BMC BladeLogic). and middle tiers. The following graphic illustrates the relationship between the major components of the three-tiered BMC BladeLogic system. System architecture A BMC BladeLogic system has a three-tier architecture that consists of client.

Client tier BMC BladeLogic Console BLCLI reports client (web browser) Network Shell Client Tier PXE / TFTP Server Application Server(s) reports server Network Shell Proxy Server (optional) BMC BladeLogic core database Middle Tier reporting data warehouse Agent File Server Server Tier Remote Server Remote Server Agent Server Agent Server Agent Server Agent Server Agent Server 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. It also includes a web interface to the BMC BladeLogic Decision Support for Server Automation server. and Network Shell for ad hoc administration of one or more servers. 14 BMC BladeLogic Server Automation Administration Guide .

with the principal components being the PXE Server and the Application Server. It also lets system administrators provision operating systems onto servers. If necessary. AIX®. The reporting data warehouse is populated using information from the core BMC BladeLogic database. which controls how the BMC BladeLogic console communicates with remote servers.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. Network Shell is a network scripting language that enables cross-platform access through a command line interface. If a site is running BMC Service Automation Reporting and Analytics. BMC Service Automation Reporting and Analytics uses the Application Server to authenticate users. The Application Server provides servers being provisioned with the instructions necessary to provision the machine. Network Shell can optionally incorporate a middle tier component—an Application Server that is configured to run a Network Shell Proxy Server. and it reads data from the core BMC BladeLogic database as well as a reporting data warehouse. The PXE Server delivers instructions to servers being provisioned so they can download a bootstrap program. it also controls interaction with the database and file servers. The middle tier also includes several components used for provisioning servers. All BMC BladeLogic client-tier applications let you manage Solaris®. 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. and Microsoft Windows 2000/2003/2008 servers. Linux® (Red Hat and SUSE). HP-UX. allowing administrators to adjust its performance to accommodate added users and increased database activity. the middle tier includes an Apache Tomcat server. Not only does the Application Server manage communication between consoles and remote servers. The Application Server is completely scalable. Server tier The BMC BladeLogic server tier consists of RSCD agents on remote servers. a BMC BladeLogic system can incorporate multiple Application Servers that cooperate by balancing job processing workloads. Middle tier The primary component of the middle tier is the Application Server. the Network Shell Proxy Server authenticates Network Shell client users and ensures traffic is encrypted between clients and managed servers. Chapter 2 Overview of BMC BladeLogic Server Automation 15 . Operating as an intermediary between Network Shell clients and the managed servers those clients target.

the successor to Secure Socket Layer (SSL). 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. you do not have to modify the agent configuration files. ■ 16 BMC BladeLogic Server Automation Administration Guide . 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. you can control user access through a combination of role-based and system object-based authorizations. see the BMC BladeLogic Server Automation User Guide. All clients and servers are set to communicate using protocol 5. If your installation requires additional refinement. For many BMC BladeLogic installations. a BMC BladeLogic protocol for secure communication based on Transport Layer Security (TLS). you should understand the default configuration of BMC BladeLogic. such as QA engineers or web administrators. he or she is granted the authorizations defined for that role. With protocol 5. The system’s default configuration provides sufficient functionality and appropriate user permissions. For more information on managing access at the console level. When a user is assigned to a role. TLS automatically negotiates the strongest form of encryption that clients and servers can support.Default permissions and security configuration Default permissions and security configuration In BMC BladeLogic. When you install BMC BladeLogic on clients and servers. A system object is an object you can interact with in the BMC BladeLogic Console. the following permissions and security configurations are set by default for each RSCD agent: ■ All clients are granted read/write access to all servers. access control can be managed at multiple levels. Using the BMC BladeLogic Console. A role is a set of authorizations and other information that reflects the capabilities of an organizational entity.

Perl support ■ Users are granted permissions on managed servers through two different processes: — For Windows servers. This process allows a role to be mapped to a local or domain user who has permissions for a Windows server. If so. For more information on Windows user mapping. “Setting up configuration files. Chapter 2 Overview of BMC BladeLogic Server Automation 17 . and members of the Administrator group in Windows are not automatically mapped to Administrator. users are mapped to user “nobody. see Chapter 4.” Incoming users can be granted the permissions of a specified user.” On Windows. you can use Perl scripts to perform functions on remote hosts (such as open. On UNIX. see Chapter 5. users are mapped to user “Anonymous. the script programming language. If a user does not have an equivalent local identity on the server. when a user attempts to connect to an agent. but that requires modification of the configuration files. For more information on securing communication between all components of a BMC BladeLogic system. — In all other situations. ■ For a complete discussion of how users are granted permissions on servers. However. which functions like a network-enabled version of libc. they are set up for SRP authentication when using BMC BladeLogic clients to communicate with Application Servers. root users on UNIX are not automatically mapped to root. Other forms of authentication are possible. “Administering security. 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.” By default when you add users to the BMC BladeLogic system. and write files) as long as those hosts are running RSCD agents. 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. Because of this integration. the core library for BMC BladeLogic. read. The BMC BladeLogic Perl module integrates with libnc. the connecting user is granted the permissions of that equivalent user. see the BMC BladeLogic Server Automation User Guide. the agent maps the incoming user to a default user with downgraded permissions. users can be granted permissions through a process called Windows user mapping. but they require additional configuration.” Perl support BMC BladeLogic provides built-in support for Perl.

An Application Server cache clean-up utility. “Managing BMC BladeLogic data. You can use this utility to delete unused files from the file server. the Perl module is automatically installed. The BMC BladeLogic file server clean-up utility.Tools for managing BMC BladeLogic data When you install Network Shell on a platform that can support a BMC BladeLogic Application Server. You can delete these files by using the repeater server clean-up utility. see Chapter 6. You can use this utility to delete old files that accumulate on target servers (agents) from Deploy Jobs. If you are using Perl in conjunction with the BMC BladeLogic Console. Tools for 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.” 18 BMC BladeLogic Server Automation Administration Guide . objects marked for deletion with the retention policy utility. Data from Deploy Jobs can also accumulate in the staging directory on repeater servers. and historical data such as old audit trail entries. See the BMC BladeLogic Server Automation Installation Guide for a list of the platforms for which BMC BladeLogic provides Perl support. A repeater server clean-up utility. These tools let you delete unused data or data no longer needed for BMC BladeLogic operations. A target server clean-up utility. you must configure the Application Server so it knows the location of Perl. ■ ■ ■ ■ For more information on these tools. You can use this utility to delete old temporary files in the Application Server cache (directory). This utility deletes from the database objects users have deleted in the BMC BladeLogic Console. 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. audit results. as described in “Configuring Perl” on page 77. snapshot results and compliance results.

3 Select the data you want to include in the zip file.Troubleshooting tools Troubleshooting tools BMC 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. ■ ■ ■ 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. 2 In the Generate Support Data dialog. select Configuration => Generate Support Data. This data can be useful for diagnostic purposes when you contact Customer Support. Chapter 2 Overview of BMC BladeLogic Server Automation 19 . Click Select All or click the data types you want. your role must be granted the BL_Administration. 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. Database Diagnostics — Run predefined tests from the command line that evaluate the status of the BMC BladeLogic database and identifies potential issues. select the Application Servers from which you want to collect data. use Shift + Click or Ctrl + Click.) To select multiple Application Servers. 1 In the BMC BladeLogic Console.Read authorization. Application Server Diagnostics — Runs predefined tests that evaluate the status of the BMC BladeLogic environment while it is running and identifies problems. (The Select Application Servers dialog lists only Application Servers configured to use the same database and file server and that are currently accessible.provides additional diagnostic information to the job log. DEBUG_MODE_ENABLED job property . NOTE To use the Support Data Generation tool.

suppose you set the size to 20 MB for the appserver. You can also include Agent logs that have been rolled over. Console log The current console log.local home Application Server Security Files Deploy Job Target Logs (Failed Targets Only) Security files from the Application Server. A file containing all status information for the Application Server. The file’s name is System Properties. if any. the Secure file is included.txt.1). all security files are included. If an Agent resides on the Application Server. You can also include console logs that have been rolled over. When the log file reaches that size. group of servers. 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 StatusReport. For example. or a Smart Group of servers. group of servers. At a minimum. a new log file is automatically created (appserver. Application Server Deployment files Application Server status The entire deployment directory for the specified Application Servers.txt.log file. You can also include Application Server logs that have been rolled over. Click Deploy Job Logs and use the Browse button (three dots) to select one or more jobs. The log from one or more Agents.Generating data for support This selection: Includes: Application Server log The currently active Application Server log. 20 BMC BladeLogic Server Automation Administration Guide . Agent Security Files The current security files from one or more Agents. (This information is the same as that generated by the Export Detail Report operation in the Infrastructure Management window. Click Agent Log and use the Browse button (three dots) to select a server. A “rolled-over” log file is one that is generated after a preset size has been reached for the currently active log file. All transaction logs for target servers that failed to execute the specified Deploy Job run. or a Smart Group of servers. Click Agent Security Files and use the Browse button (three dots) to select a server. Security files included are: ■ ■ ■ ■ ■ System Properties table Agent log Secure Exports Users User.log.

These predefined tests collect data on the status of the BMC BladeLogic environment while it is running. Monitoring and diagnosing issues in the BMC BladeLogic environment 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. your role must be granted the BL_Administration.Monitoring and diagnosing issues in the BMC BladeLogic environment This selection: PXE Server Files Includes: Information about the PXE server and the services it runs. Network Information 4 Click Generate Data. The file’s name is NetworkInformationReport.zip as the file name. Chapter 2 Overview of BMC BladeLogic Server Automation 21 . If you selected multiple Application Servers.zip and data_10_08-appserver1. compare the data to expected behavior. BMC BladeLogic generates the data and creates a zip file.zip. 5 Specify a path to the location where you want to store the zip file. For example. suppose you selected configserver1 and appserver1 and specified data_10_08.) A file of information about network configuration and status for each Application Server.txt. NOTE To use the Support Data Generation tool. 7 Click Save.Read authorization. and analyze it to determine test success or failure. the zip file for each has a name based on the file name you specified plus the Application Server name. (This information is the same as that reported in the Infrastructure Management window. 6 In the Object Name field. For each Application Server you selected. type a name for the zip file. The zip files created would have the names: data_10_08configserver1.

Tests the Application Server’s connectivity with the database and executes test queries.) Select a group of tests from the Diagnostic Group drop-down menu. Checks whether the bladelogic.Monitoring and diagnosing issues in the BMC BladeLogic environment 1 In the BMC BladeLogic Console. Tests the job execution framework. The Select Application Servers dialog lists Application Servers configured to use the same database and file server. selecting the Configuration test group runs both the AppServer Test and the Service Deployment Test. both of which test the Application Server configuration. Tests the job framework. Tests the Application Server’s deployment to determine if the Application Server has been properly configured Database Diagnostic Test Environment KeyStore Test File Manager Diagnostic Test Pseudo Job Diagnostic Test Service Deployment Diagnostic Test 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.Tests are grouped by the type of evaluation they do. 3 The Application Server Diagnostics area lists the tests to be run. 2 In the Application Server Diagnostics view. Selecting a test group lists those tests in the Application Server Diagnostics area. (Use Shift + click or Ctrl + click to select multiple tests. Accept the default selection (the Application Server to which you are connected) or click Browse and select one or more Application Servers. select Configuration => Application Server Diagnostics View. For example. Test AppServer Test BlExec Job Diagnostic Test Description Tests the Application Server’s configuration connectivity with other Application Servers. ■ 22 BMC BladeLogic Server Automation Administration Guide . Tests the Application Server’s connectivity with the File Server. including parallel execution. select the Application Servers from which you want to collect data. using a job created for test purposes. however. they do not need to be running on the same host. using a job created for test purposes. You can select one or more tests from the list.keystore files are properly synchronized between the various deployments (each deployment has its own keystore file).

Log. the Status column shows an icon that indicates the success or failure of each test. select the Application Server for which you want to display test results. and description for all diagnostics. Lists all diagnostics with full details (for example. Then click the Test Output.Monitoring and diagnosing issues in the BMC BladeLogic environment 4 Click Run All Tests to run all tests listed in the Application Server Diagnostics area.exe or dbdiagnostic. 6 On the Diagnostic Results dialog. which are listed in the BMC BladeLogic Server Automation Installation Guide.. Select a test and click the View Results icon to show detailed test results.sh with any of the parameters shown in Table 1. Chapter 2 Overview of BMC BladeLogic Server Automation 23 . Or click Run Selected Tests to run only the tests you selected in that area. click Close. 5 In the Application Server Diagnostics area. 7 When you are finished viewing test results. Consult with your DBA to see whether these recommendations can be applied. run dbdiagnostics list to determine the ID for each specific diagnostic test. open a shell (in Linux) or a command prompt (in Microsoft Windows). the parameters and their children).NSH/bin folder. 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. or Failure Advice tab. 2 From the . 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. Lists only the ID. name. Table 1 Parameter help list listFull Parameters for the DBdiagnostic command (part 1 of 2) Description Displays the help for the command. 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.. execute either dbdiagnostic. For the diagId argument used by some of the parameters.

NOTE The Top_N_tables_chk and JRE_Row_Count_Chk diagnostic tests apply to both Oracle and SQL Server databases. delAllRes runDiag Deletes all results for all diagnostics. such as statistics on the last execution of the diagnostic. 24 BMC BladeLogic Server Automation Administration Guide . 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. 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. getDiagParams diagId=diagId Displays the parameters for a diagnostic. To run a diagnostic test. diagId=<diagId> optName1=val1 optName2=val2 Runs a specific diagnostic using optional parameters. Table 2 on page 25 shows example IDs for each of the diagnostic tests available with the dbdiagnostics tool. The remaining tests apply to Oracle databases only. 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. the status of the run. You can find the list of parameters for a diagnostic by running the diagnostic with the getDiagParams parameter followed by the diagId. and the parameters used for that run.Monitoring and diagnosing issues in the BMC BladeLogic environment Table 1 Parameter getDiag Parameters for the DBdiagnostic command (part 2 of 2) Description diagId=diagId Displays information for a specific diagnostic. delRes diagId=diagId Delete the results for a specific diagnostic.

and recommends remediation if the statistics are not current. 1000001 ORACLE CHECK NUMBER PROCESSES ALLOWED Checks the number of Oracle processes and provides advice. which displays the results of the last execution for this diagnostic (shown in Figure 2). 1000003 ORACLE OPTIMIZER SETTINGS CHK Checks the Oracle optimizer settings. 1000006 DBMS_STATS_CHK Checks to see if the Schema statistics are current (based on a user-supplied expiration). Chapter 2 Overview of BMC BladeLogic Server Automation 25 . 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. while Figure 1 shows the output returned from the command. see the “Before you install” chapter of the BMC BladeLogic Server Automation Installation Guide Example syntax and output The following example shows the command format you would use to run the ORACLE CHECK BLOCK SIZE diagnostic.Monitoring and diagnosing issues in the BMC BladeLogic environment Table 2 ID 1000000 Diagnostic names and description Diagnostic name and description ORACLE CHECK BLOCK SIZE Checks the Oracle block size and provides advice. dbdiagnostics runDiag diagId=1000000 Figure 1 output from the command You can then view the results of the diagnostic by running the command with the getResLastExec parameter. For a description of how to use this diagnostic to verify that Schema statistics are current.

0 Running a job in debug mode If you are experiencing issues with job execution. 4 Click OK. The Set Job Properties window is displayed.0 messageLevel=INFO message=ORACLE CHECK BLOCK SIZE: Block size on the Database is 8192. messageTime=2010-03-22 12:47:03. — In the Properties tab. as running the job in debug mode does have a negative impact on performance. 26 BMC BladeLogic Server Automation Administration Guide . 3 Set the property value to TRUE. you can use the DEBUG_MODE_ENABLED job property to provide additional diagnostic information to the job log.Monitoring and diagnosing issues in the BMC BladeLogic environment dbdiagnostics getResLastExec diagId=1000000 Figure 2 Sample output for ORACLE CHECK BLOCK SIZE diagnostic diagId=1000000 execDiagId=2000002 execStartTime=2010-03-22 12:47:02. To set the DEBUG_MODE_ENABLED job property 1 In the Jobs folder. The default value for the DEBUG_MODE_ENABLED property is FALSE. which is large enough. select DEBUG_MODE_ENABLED from the Extended properties list. 2 Do one of the following: — Right-click the job and select Set Property. NOTE Be sure to set the DEBUG_MODE_ENABLED property back to FALSE when not diagnosing an issue. Select DEBUG_MODE_ENABLED from the Name drop-down list. select a job. The additional level of logging provides you or BMC Software Customer Support representatives with more detailed information when diagnosing issues with job execution.

use the Run Details drop-down to select Errors. The Log Item Details dialog opens. or All. navigate to a job or Execution Task. right-click. 2 Select a run of a job. double-click on a message. You can also review the log file on the Application Server for the additional diagnostic information. 4 To display messages in a dialog that allows you to scroll through messages one by one.00\NSH\br/appserver. see “Considerations for troubleshooting jobs in a MAS environment” on page 57. 3 To filter messages so the job log only shows servers with specific job results. Click Close to close the dialog.00/NSH/br/appserver. the Application Server log file is located in: UNIX /opt/bmc/BladeLogic/8.0. Click the Up arrow or the Down arrow to scroll through messages one by one. A window displays log messages generated by the job. Chapter 2 Overview of BMC BladeLogic Server Automation 27 .log Windows installationDirectory\BladeLogic\8. and select Show Log.Monitoring and diagnosing issues in the BMC BladeLogic environment To view the job log 1 Open the Jobs folder.0.log If you are running a multiple Application Server environment. right-click the job or Execution Task and select Show Results to display its job runs. Success. Warnings. 5 Click Close to close the log messages window. By default.

Monitoring and diagnosing issues in the BMC BladeLogic environment 28 BMC BladeLogic Server Automation Administration Guide .

NOTE The Application Server and the RCP client (BMC BladeLogic console) must be located on the same Local Area Network (LAN). Controlling communication between clients and servers as well as access to database. See “Configuring multiple Application Servers on the same host” on page 93. Remote users can use the console through either RDP or Citrix from a remote machine to the machine where the console resides. you use the PostInstall Configuration wizard to perform the initial configuration of the Application Server. you can run the Application Server Configuration wizard. Chapter 3 Configuring the Application Server 29 . see “Using the application server configuration wizard to change configuration settings” on page 39. With this basic configuration. During installation.Chapter 3 3 Configuring the Application Server The core of the three-tier architecture in BMC BladeLogic is the Application Server. See “Using the Post-Install Configuration wizard to configure the default application server” on page 34. For information. file. you can start the Application Server and then fine-tune it as needed. and mail servers. the Application Server can be adjusted to scale a system and to fine tune its performance. ■ 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. Use the following tools to make configuration changes: ■ To make changes to basic configuration settings at a later time. 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.

Using this approach. which launches new processes external to the Application Server process. see “Using the Application Server Administration console (blasadmin) to configure Application Servers” on page 44. and you can also use it to set other more complex configuration options. When a client requests any type of activity. So is the number of open client connections. you can configure the Application Server so the process spawner does not run as an external process. If you prefer. For information. Rather than dedicating a thread to each client connection. For information. (The number of worker threads in the pool is configurable. 30 BMC BladeLogic Server Automation Administration Guide .Understanding the application server ■ BMC BladeLogic provides a utility called the Application Server Administration console. the Application Server picks a worker thread from the pool to execute that task. the Application Server maintains a pool of threads that can be used for processing client activity. Process spawning is primarily used for Network Shell Script Jobs and some types of extended objects. See “Scaling the Application Server” on page 52 for more on configuration. use the Infrastructure Management window. When the request is complete. One process runs the core functionality of the Application Server. The other process is a process spawner. Spawning processes externally to the Application Server can be beneficial for memory management. BMC BladeLogic calls these worker threads. which is a command line utility that allows you to set all parameters used by the Application Server. ■ Understanding the application server Application server processes The BMC BladeLogic Application Server is designed to process connections from many clients simultaneously. The Application Server Administration console lets you set the same parameters as those available in the Post-Install Configuration wizard.) Typically. see “Managing multiple Application Servers on the same host” on page 109. To manage multiple Application Servers on the host or change their configurations. See “Configuring the process spawner” on page 79 for more on configuration. the BMC BladeLogic Application Server runs as two distinct processes. the worker thread is returned to the pool. the Application Server can handle many more client connections than it has worker threads.

The next work item thread goes to the third job in the queue. and so forth. However. which perform all work required for that job. For most job types. it is assigned to the second job in the queue. it is assigned to the first job in the queue of pending jobs. one work item thread is required to execute each part of the job. For more information on specifying the number of available work item threads.) 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. the Application Server assigns equal preference to all pending jobs. When the next work item thread becomes available. see “Scaling the Application Server” on page 52. In addition. starting with the first job in the queue. see the BMC BladeLogic Server Automation User Guide. when a work item thread becomes available. all jobs can begin processing as soon as a work item thread becomes available.) When a job comes due. the job execution thread continues to watch for other scheduled jobs. When an Application Server is running multiple jobs. (Note that a job set to run immediately is considered a scheduled job. Deploy Jobs can optionally utilize a special pool of lightweight work item threads used only for processing Deploy Job phases that access target servers. For a description of how jobs are divided into job parts. see “Job distribution” on page 32. a sufficient number of work item threads may not be available for simultaneously processing all jobs. The job execution thread constantly watches for scheduled jobs. the number of job parts equals the number of target servers.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 loads the job and allocates work item threads. When allocating work item threads. but there are exceptions to this rule. With this system. Chapter 3 Configuring the Application Server 31 . After initiating a job in this way. Then the cycle of allocating work item threads begins again. In this case. until a work item thread has been assigned to all jobs in the queue. jobs with fewer job parts may complete sooner than jobs with many job parts. (For a description of how multiple Application Servers can process jobs cooperatively.

NOTE You cannot enable or disable work item sharing at the job type level. work items are not shared to or from that Application Server.Job distribution Job distribution If you have multiple Application Servers installed and they all access the same database. if a BMC BladeLogic installation consists of two Application Servers that are both configured to run the same maximum number of jobs. scheduled jobs are delegated to the first Application Server that requests a job. By default. by default) in the Application Server’s profile. Best Practice: Do not mix-and-match the value of the MultiAppServerEnabled attribute between Application Servers. Although work for an individual job can be spread among multiple Application Servers. only one Application Server manages each individual job. 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. provided that the Application Server making the request is not already executing the maximum number of jobs that it can run simultaneously. 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. 32 BMC BladeLogic Server Automation Administration Guide . This work item sharing capability is controlled by the MultiAppServerEnabled attribute (which is set to true. the Application Server will distribute work items to other Application Servers that have idle work item threads. For more information on configuring cooperation between Application Servers. When multiple Application Servers are configured to execute jobs.) For example. Using additional Application Servers increases the job execution capacity of the system and in most cases speeds overall job processing. However. those Application Servers can cooperate by distributing jobs to balance their processing workloads. if all local work item threads are already processing work items. If this attribute is set to False. or all Application Servers should have the attribute set to False. each Application Server will be given the same number of jobs to run (assuming there are an even number of jobs to execute). Generally. Application Servers are configured to cooperate when executing jobs. see “Setting up job distribution between multiple Application Servers” on page 55. (That maximum number can be configured. Typically. all Application Servers should have this attribute set to True. During job execution. the number of work items processed during a job run directly corresponds to the number of target servers for the job.

the Authentication Service uses the appropriate mechanism to authenticate that user. Authentication framework A BMC BladeLogic Application Server employs a unified framework for processing all user authentication requests. If authentication succeeds. see “Setting the number of database connections” on page 64. A thread watches the pool of database connections. When a worker thread or a work item thread needs a database connection. If the number of database connections reaches the high boundary. ■ ■ The Authentication Service and the Application Service are always located on the same host. the thread attempts to trim the number of database connections back to the low boundary. or it can be set up on a stand-alone machine even though it is still associated with an Application Server. ensuring that the number of connections stays within high and low boundaries. A Network Shell Proxy Service can be located on the same host. You can configure the high and low boundaries to accommodate user needs. The client application can then initiate a session by presenting the session credential to an Application Service or Network Shell Proxy Service. such as client connections. Chapter 3 Configuring the Application Server 33 . Application Service—An entity that encapsulates the functionality of a BMC BladeLogic Application Server. the database connection is returned to its pool. When the database activity is complete. the Authentication Service issues a session credential to the client application. Based on the authentication protocol. the client contacts the Authentication Service using any supported authentication protocol. When users on a BMC BladeLogic client application (except BMC BladeLogic Decision Support for Server Automation) want to authenticate. Network Shell Proxy Service—An entity that encapsulates the functionality of a Network Shell Proxy Server. it acquires one from the appropriate pool of database connections.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. That framework is based on three services: ■ Authentication Service—An entity dedicated to authenticating users by means of all supported authentication protocols. For more information.

stopping. Use the configuration wizard to configure your database connection. see Chapter 4. It is so called because it launches (starts) and controls these additional Application Servers. 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. Starting. See “Configuring multiple Application Servers on the same host” on page 93. The Application Server Launcher lets you configure and manage (start. terminate. Available for both Windows and UNIX-style installations. “Administering security. and restarts the Application Server Launcher. The Post-Install Configuration wizard presents those essential tasks in a graphical user interface and provides explanatory information for each step in the process. 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 commandline mechanisms for configuring all possible Application Server options. The Application Server Launcher must be running on the host in order for you to perform these operations. 34 BMC BladeLogic Server Automation Administration Guide .” The Application Server Launcher An Application Server Launcher is a mechanism for configuring and controlling multiple Application Servers on the same host. The BMC BladeLogic environment supports one Application Server Launcher per host. only a few must be set to make a BMC BladeLogic system functional. restart. and restarting the Application Server on the host also starts. Installing the Application Server on a host also installs the Application Server Launcher. stops. including a description of how BMC BladeLogic Decision Support for Server Automation authenticates users. stop. remove and redeploy) each additional Application Server on the host.The Application Server Launcher For more information on authentication and other security features.

Use the configuration wizard to identify the file server and a directory within the file server. The RBACAdmin user has full permission to manage roles and users in the RBAC Manager workspace in the BMC BladeLogic Console. — On a Windows system. BLPackages. The installation program gives you the option of launching the wizard at the end of the installation procedure. ■ 1 To start the Post-Install Configuration wizard. you cannot configure the Application Server. Use the configuration wizard to identify an SMTP server. the OS-specific x11 libraries must be installed. enter the following: ■ ■ Chapter 3 Configuring the Application Server 35 . and the SNMP destination to which all SNMP traps are sent. From the Windows Start menu. Obtain the necessary connection information and run the PostInstall Configuration wizard again to complete your system configuration. where you can assign permissions for all users. Click Cancel to close the wizard. 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. Use the configuration wizard to provide SRP passwords for the RBACAdmin and BLAdmin users. If you are running the Post-Install Configuration wizard on UNIX.Using the Post-Install Configuration wizard to configure the default application server ■ File server—The BMC BladeLogic Console uses a file server to store large snapshots of files. do one of the following: ■ Perform an installation that includes installation of the Application Server. Network Shell scripts. Windows installables. and other types of information that is not easily stored in a database. the address from which the notification emails originate. The BLAdmin user has Read access for all system objects within the BMC BladeLogic Console. Notification servers—The BMC BladeLogic Console optionally generates email and SNMP traps that send notifications when a job completes. Super-user passwords—The BMC BladeLogic Console provides several predefined users. ■ ■ 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.

or. By default a BMC BladeLogic installation uses the following database ports: Database Type Oracle SQL Server Port Number 1521 1433 Database Name—SQL Server database name. 3 Choose a Database Type—either Oracle or SQL Server..exe — On a UNIX-style system. The configuration wizard opens. (This option is only available for SQL Server databases.. enter the following: . If you are using a custom connection string. By default the database name is bladelogic. Password—Password assigned to the user ID. the wizard will display configuration settings that have already been entered for the Application Server and allow you to change those settings.) SID—System ID of the Oracle database./br/blappconf NOTE If you invoke the wizard without passing the -install flag. provide the following database configuration information: 36 BMC BladeLogic Server Automation Administration Guide . 2 Read the introductory page and click Next. Database Port—Port the database listens on. The Database page displays. provide the following database configuration information (and do not select the Advanced option): Database Server—Server running the database. 4 If you are not using a custom connection string. (This option is only available for Oracle databases.Using the Post-Install Configuration wizard to configure the default application server \bin\ blappconf.) User ID—User name that the database needs to authenticate your connection.

Password—Password assigned to the user ID. create an entry like the following in the users. 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. BMC BladeLogic recommends that the file server have 200 GB or more of available RAID 5 disk space. 72 GB of available. 5 Click Next. 6 Provide the following file server configuration information: File Server Name—Name of the server where data is stored. non-redundant. disk space. ■ The internal System:System role/user must be mapped to the user name defined on the file server. Advanced—Select this option to indicate that you are providing a custom connection string.Using the Post-Install Configuration wizard to configure the default application server User ID—User name that the database needs to authenticate your connection. Connection String—Type the custom connection string in the field below the Advanced checkbox. A file server should meet the following requirements: ■ An RSCD agent must be installed and licensed. All users need to be mapped to the same user on the file server. The File Server page displays. Without this mapping a user may not be able to access a file that another user has stored on the file server. the directory of the file server is appserverInstallDirectory/storage. A user name must be defined on the file server.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. as a minimum. 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.local file on the file server: Chapter 3 Configuring the Application Server 37 . and all users must be mapped to that user. To accomplish the mapping. By default. NOTE Do not limit access to the file server by pushing agent ACLs to the agent on the file server. ■ A file server must have.

If the required directory structure does not already exist on the file server. 9 If you are using SNMP trap notifications. 7 Click Next. Passwords are used to authenticate the RBACAdmin and BLAdmin users via the SRP authentication protocol. 11 Under both RBACAdmin User and BLAdmin User. enter a password and then retype the password to confirm your entry. 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. 12 Click Finish. 10 Click Next.) Email From—Email address from which BMC BladeLogic-generated email is sent.Using the Post-Install Configuration wizard to configure the default application server System:System rw. BMC BladeLogic jobs can generate email upon their completion. For more information on the RBACAdmin and BLAdmin users. the process will attempt to create it.user=userName where userName is the name to which all users are mapped. The BLAdmin user has Read access for all system objects within BMC BladeLogic. where you can assign permissions for all BMC BladeLogic users. By default the port is set to the standard SNMP port of 162. The User Passwords page displays. You will not be able to enter a password if a password has already been set. The RBACAdmin user has full permission to manage roles and users in the RBAC Manager workspace in the BMC BladeLogic Console. 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. typically bladmin or administrator. The Notification Servers page displays. SNMP Port—The port on the SNMP server that listens for SNMP traps. see the BMC BladeLogic Server Automation User Guide. 38 BMC BladeLogic Server Automation Administration Guide . (SMTP stands for simple mail transfer protocol.

the clock on client machines in San Francisco should be set to 4:04. Chapter 3 Configuring the Application Server 39 . For information. except that it is in a tabbed format and shows current settings in the text boxes. See in an Application Server’s profile (when there “Viewing and editing an Application Server’s are multiple Application Servers on the same profile” on page 100. The Application Server Configuration wizard. host) Using the application server configuration wizard to change configuration settings To change configuration settings on an Application Server. See “Using the Application Server Administration console (blasadmin) to configure Application Servers” on page 44... you can use the Application Server Configuration wizard (blappconf). Database connection File server Notification servers Most configuration settings or to set additional configuration parameters on an Application Server The Application Server Administration console (blasadmin).Changing the configuration of an application server NOTE BMC BladeLogic recommends that you synchronize the clock on the Application Server and all client machines. where the time is 7:04. You can also use the Application Server Administration console (blasadmin) to change these settings. Initial (post-installation) configuration settings for the Application Server: ■ ■ ■ You can use.. Clocks should be synchronized to the minute. Changing the configuration of an application server There are three tools you can use to change an Application Server’s configuration. To change. Attributes (configuration settings) specified The Infrastructure Management window. Which tool you use depends on the settings you want to change.. see “Using the application server configuration wizard to change configuration settings” on page 39. This wizard presents the same information as the Post-Installation Configuration wizard. if an Application Server is in Boston. For example.

enter the following: \bin\blappconf -s applicationServerName Where applicationServerName is the name of the Application Server you want to change. You must use the RBAC Administration tool. 1 Start the Application Server Configuration wizard: ■ To change the configuration of the default Application Server.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 ■ ■ NOTE After super-user passwords are set in the Post-Installation Configuration wizard. enter the following: \bin\blappconf — On a UNIX-style system. For example: blappconf -s JobServer1 40 BMC BladeLogic Server Automation Administration Guide . enter the following: . you cannot use the Application Server Configuration wizard to change them.exe ■ To change the configuration of a specific Application Server when there are multiple Application Servers on the same host. select Programs => BMC Software => BladeLogic Server Automation Suite => Utilities => Application Server Configuration Wizard./br/blappconf. use one of the following methods: — From the Windows Start menu. from the directory where BMC BladeLogic is installed. — From the directory where BMC BladeLogic is installed.

Application Servers created on the host in the future will not have the changes. do one of the following: ■ On Windows. select Settings => Control Panel. 3 Click OK.Starting Application Servers NOTE If you specify blappconf -s. To start all Application Servers on the host. Make changes you want. enter the following: /etc/init. Starting Application Servers There are two methods for starting Application Servers. use this command to configure the template deployment: blappconf -s _template 2 The Application Server Configuration wizard appears. and double-click Services. from the Start menu. see “Starting all Application Servers on the host”. To start a specific Application Server (when additional Application Servers are configured on the host). Right-click BladeLogic Application Server and select Start from the pop-up menu. from the directory where BMC BladeLogic is installed. See “Starting a specific Application Server” on page 109. On a UNIX-style system. ■ 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. changes affect the specified deployment. 4 Restart the Application Server.d/blappserv start ■ Chapter 3 Configuring the Application Server 41 . The method you use depends on the Application Servers you want to start: ■ To start all Application Servers on the host. use the Infrastructure Management window. To have changes affect future Application Servers. whether a single (default) Application Server or multiple Application Servers. If you specify blappconf with no -s option. Double-click Administrative Tools. changes affect only the default deployment.

the default Application Server must already be started. whether a single (default) Application Server or multiple Application Servers. To restart a specific Application Server (when additional Application Servers are configured on the host). To use this restart operation. ■ 42 BMC BladeLogic Server Automation Administration Guide . To stop a specific Application Server (when additional Application Servers are configured on the host). On a UNIX-style system. Double-click Administrative Tools. See “Stopping a specific Application Server” on page 109.Restarting Application Servers Restarting Application Servers There are two methods for restarting Application Servers. select Settings= > Control Panel. The method you use depends on the Application Servers you want to restart: ■ To restart all Application Servers on the host. and double-click Services. from the Start menu. see “Stopping all Application Servers on the host” on page 43. Right-click BladeLogic Application Server and select Restart from the pop-up menu. see “Restarting all Application Servers on the host”. whether a single (default) Application Server or multiple Application Servers.d/blappserv restart ■ Stopping Application Servers There are two methods for stopping Application Servers. use the Infrastructure Management window. enter the following: /etc/init. the default Application Server must already be started. whether a single (default) Application Server or multiple Application Servers. To use this stop method. Do one of the following: ■ On Windows. The method you use depends on the Application Servers you want to stop: ■ To stop all Application Servers on the host. ■ Restarting all Application Servers on the host This operation restarts all Application Servers on the host. See “Restarting a specific Application Server” on page 111. use the Infrastructure Management window.

select Settings => Control Panel. enter the following: /etc/init. and double-click Services. resume.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. The BLCLI provides commands that allow you to shut down Application Servers more gracefully (see “Shutting down Application Servers gracefully”). On a UNIX-style system. You can use these commands to shut down. or shut down an Application Server When you pause an Application Server. Chapter 3 Configuring the Application Server 43 . Double-click Administrative Tools. the following occurs: ■ The job execution thread on the Application Server no longer processes newly scheduled jobs. See the BLCLI Help for specific information on AppServerShutdown. From the Windows Start menu. Right-click BladeLogic Application Server and select Stop from the pop-up menu. even though they may be currently processing jobs. pause. These commands are available in the AppServerShutdown name space of the BLCLI. What happens when you pause. enter Control-C. To stop all Application Servers on the host.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. 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. See “Stopping a specific Application Server” on page 109. or resume a specific Application Server or all Application Servers on the host. 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). do one of the following: ■ From the Windows command line window where the Application Server is running.

file. the shutdown sequence begins. These parameters define the location and behavior of the application. versus the subset you can configure with the Post-Install Configuration Wizard. 44 BMC BladeLogic Server Automation Administration Guide . When you instruct a paused Application Server to resume work. When all jobs and work items have completed or a specified period of time has elapsed. it continues to process all of its current work items. When you use AppServerShutdown commands to shut down an Application Server. if requested. The job execution thread can again process scheduled jobs and the Application Server can request work item threads from other Application Servers. database. and SNMP servers. ■ ■ NOTE When you pause an Application Server. the Authentication Service. you essentially undo the actions listed above. mail. If any of those work items take a long time to finish. The blasadmin utility lets you configure all parameters. the Application Server continues to give out work item threads to other Application Servers. This section provides procedures to control all aspects of the Application Server’s behavior.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. the Application Server will not appear to be paused until all of those work items are complete. 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. The Application Server is temporarily set so it can no longer request work item threads from other Application Servers. and other components of an Application Server. as described above. the Application Server’s job framework is paused. To expedite the processing of any currently active jobs.

For example. enter the following: \bin\blasadmin. See “Starting the Application Server Administration console”. do one of the following: ■ On Windows. enter the commands. run the blasadmin command. you can both run the blasadmin utility and pass it a command at the same time. 2 At the prompt.Starting the Application Server Administration console To configure Application Servers with the Application Server Administration Console (blasadmin): 1 Start the Application Server Administration Console. For information. How you start this utility determines the Application Server configuration affected by the commands. see: ■ ■ ■ The set Command The show Command The help Command 3 Exit the blasadmin utility. TIP If you want to enter just one or two commands. you can change the location of a file server (on the default Application Server) by entering the following command blasadmin set fileserver location /tmp/Storage. 4 Restart the Application Server to have your configuration settings take effect. How you enter the command depends whether you want to configure the default Application Server or one of multiple Application Servers on the host.exe Chapter 3 Configuring the Application Server 45 . select Programs => BMC Software => BladeLogic Server Automation Suite => Utilities => Application Server Administration. 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. — From the directory where BMC BladeLogic is installed. do one of the following: — From the Start menu. Starting the Application Server Administration console To start the Application Server Administration console.

Starting the Application Server Administration console

Both options run the same command.

On a UNIX-style system, from the directory where BMC BladeLogic is installed, enter the following:
./br/blasadmin

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

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

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

46

BMC BladeLogic Server Automation Administration Guide

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.

Chapter 3 Configuring the Application Server

47

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 Descriptions of all parameters for all components At the bladmin> prompt, enter show descriptions For example:
bladmin> show descriptions [AccountConfig] AccountLockoutDuration - How long (in minutes) to keep the account locked AccountLockoutThreshold - How many failed logins before the account is locked MaxPasswordAge - How many days before a password needs to be changed MinPasswordLength - 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 server AppSvcPort - 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:0 AccountockoutThreshold:0 MaxPasswordAge:0 MinPasswordLength:0 [AgentConfig] EnableAgentRpc:false SecureFilePath: . . .

48

BMC BladeLogic Server Automation Administration Guide

The show Command

To Show

At the bladmin> prompt, enter

A component’s parameters show component (with descriptions) For example:
bladmin> show fileserver available options: [all|location|name] all - display all configuration parameters for this option location - the NSH style </c/temp> location name - the name of the fileserver

A component’s parameters show component all and settings For example:
bladmin> show snmpconfig all [SnmpConfig] SnmpPort:162 SnmpServer:

The current setting for a single parameter

show component parameter For example:
bladmin> show database MaxGeneralConnections MaxGeneralConnections:100

Chapter 3 Configuring the Application Server

49

The help Command

The help Command
The help command provides help on the set and show commands.
To get help on At the bladmin> prompt, enter

A list of components (with help set | show descriptions) you can specify with the command For example:
bladmin> help set AccountConfig - minimum password length configuration AuthServer - authorization configuration ConfigManagerUI - configuration for UI Database - the database configuration parameters . . .

All of the parameters for a help set | show component component For example:
bladmin> help set Database

A description of a parameter

help set | show component parameter For example:
bladmin> help show pxeserver listen_port the server port the PXE server listens on

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 adA@ACo.com,adB@ACo.com

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.

50

BMC BladeLogic Server Automation Administration Guide

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.

Chapter 3 Configuring the Application Server

51

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.

52

BMC BladeLogic Server Automation Administration Guide

Configuring the Application Server

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.

Chapter 3 Configuring the Application Server

53

lightweight work item threads behave exactly like work item threads.Configuring the Application Server When processing Deploy Jobs. Other than being limited to particular types of tasks. 54 BMC BladeLogic Server Automation Administration Guide . see “Work item threads and the job execution thread” on page 31. work item threads often sit idle while target servers process deployment tasks. 6 To specify a maximum size for the pool of lightweight work item threads that can be used for Deploy Jobs. These threads are only used during the Simulate and Commit phases of a Deploy Job. the Application Server can use a pool of lightweight work item threads to process phases of a Deploy Job that access target servers. 7 Restart the Application Server. For more on the role of work item threads. An Application Server can optionally provide a secondary pool of lightweight work item threads. Using lightweight work item threads helps you run more Deploy Jobs in parallel more efficiently. To avoid this kind of inefficiency. enter the following: set appserver MaxLightweightWorkItemThreads # where # is a number of lightweight work item threads. Lightweight work item threads primarily perform tasks on target servers and consequently consume almost no memory on an Application Server. By default this value is set to 0.

each Application Server periodically updates its time stamp. they automatically attempt to cooperate by balancing their job processing workloads.Configuring the Application Server Setting up job distribution between multiple Application Servers When Application Servers are configured to access the same database. For information on synchronizing bladelogic. 2 To specify a time span that indicates a remote Application Server has timed out. enter the following: set appserver ServerMonitorInterval # where # is the frequency with which an Application Server updates its own time stamp (that is. They accomplish this by distributing the processing of entire jobs or work items for large individual jobs to other Application Servers. Chapter 3 Configuring the Application Server 55 . its heartbeat). For Application Servers to cooperate. if RemoteServerTimeout is set to 5. see “Synchronizing keystore files of multiple Application Servers” on page 58. as described in “Starting the Application Server Administration console” on page 45. ■ 1 Start the Application Server Administration console. it also checks for the heartbeat of any remote Application Servers. For example. System clocks on all Application Servers must be synchronized to within a few seconds of each other. Application Servers that are cooperating monitor each other’s heartbeat to determine which Application Servers are in service. which functions as its heartbeat. 3 To specify an interval between heartbeats for an Application Server. and 10 seconds elapse between heartbeats.keystore file.keystore files. To accomplish this. they must know which Application Servers are in service. enter the following: set appserver RemoteServerTimeout # where # is number of seconds between heartbeats before a remote Application Server is considered out of service. When an Application Server updates its heartbeat. 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. the Application Server is considered out of service.

enter the following: set appserver RequireClientAuthentication true where true instructs the Application Server to require authentication from remote Application Servers. Generally. the connection times out. Once the maximum is exceeded. By default the RegistryPort is set to 9836. 8 To specify a port used for communication between Application Servers. 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. Once that maximum is exceeded.Configuring the Application Server 4 To specify a time-out for connecting to a remote Application Server. the connection times out. enter the following: set appserver SocketConnectTimeout # where # is the maximum number of seconds for obtaining an initial socket connection to a remote Application Server. 5 To specify a time-out for responses from a remote Application Server. enter the following: set appserver RegistryPort # where # is a port number. connections encrypted with SSL also require client authentication. 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. 9 Restart the Application Server. 56 BMC BladeLogic Server Automation Administration Guide . 7 To specify that remote Application Servers contacting the Application Server must authenticate.

which means that the log information is also distributed.log Windows installationDirectory\BladeLogic\8. In this example. For example.Configuring the Application Server 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.log Windows installationDirectory\BladeLogic\8. they automatically attempt to cooperate by balancing their job processing workloads.1/NSH/br/appserver.lo g Chapter 3 Configuring the Application Server 57 . with one job server running on each. the Application Server log file is located in: UNIX /opt/bmc/BladeLogic/8. Therefore you would need to review the log files on both Application Servers. By default.1/NSH/br/deploymentProfileName. and the Distribution Manager is dynamically allocating resource and running jobs on both Application Servers as needed.1\NSH\br/appserver. When Application Servers are configured to access the same database.1\NSH\br/deploymentProfileName. which by default are located in: UNIX /opt/bmc/BladeLogic/8. you may have two physical Application Servers (appserver1 and appserver2).log There are also individual log files for each Application Server deployment. the logging information for the job is actually distributed between the log files on both appserver1 and appserver2.

as it controls the maximum number of simultaneous work items that can be allocated for a given job. the Distribution Manager queues work items in respect to priority. Note that these priority levels are meaningful only in relation to each other. High. For a list of the permissions and authorizations required to modify Job Priority. By default. but with a low maximum parallelism level. see “Setting up job distribution between multiple Application Servers” on page 55. To synchronize keystore files of cooperating Application Servers. Synchronizing keystore files of multiple Application Servers Multiple Application Servers on different hosts can be set up to cooperate on processing jobs. ■ ■ For more information on setting the job priority level. or a class of jobs. with a relatively higher priority to ensure they are executed first in case of resource contention. see BMC BladeLogic Server Automation User Guide. the responsiveness of the target space. its target vector. For example.Configuring the Application Server Job distribution and job priority in a MAS environment You can use the PRIORITY* property to mark a job. if two concurrent jobs are competing for resources. Such a job would appear to relinquish resources to a lower priority job with a high parallelism level. note the following considerations regarding job priority: ■ While queuing work items across all jobs.) For this cooperation to take place. For example. 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. see “Authorizations for changing job priority” and “Setting job priority” in the BMC BladeLogic Server Automation User Guide.keystore file. (For information. all Application Servers must have the same bladelogic. and Lowest. the individual work items of the higher priority job are queued to be processed before the work items of the lower priority job. and so on). all job types have a priority of Normal. once the initial work item assignment quota for that Critical priority job is reached. consider the case of a job with a priority of Critical. Normal. do the following on each cooperating Application Server: 58 BMC BladeLogic Server Automation Administration Guide . You can assign one of any of the following priorities: Critical. The parallelism configuration of a job can significantly impact the appearance of the effectiveness of the job’s priority level. Low. If you have implemented a multiple Application Server environment.

enter: blasadmin -s _launcher E At the blasadmin prompt.keystore 3 Make sure that the passwords match for bladelogic.keystore file. enter: set appserverlauncher KeyStorePassword password F If the process spawner is in use.keystore file for all Application Server deployments: A On the cooperating Application Server.keystore files of all deployments of the cooperating Application Server.keystore file you copied into a deployment has a different password from that of the old bladelogic.keystore file from the _template directory of the central Application Server to each deployment directory of the cooperating Application Server. At the command prompt. change the keystore password for that deployment. At the command prompt. 2 Copy the bladelogic. enter: Chapter 3 Configuring the Application Server 59 . enter: blasadmin -s deployment_name For example: blasadmin -s default or blasadmin -s _template B At the blasadmin prompt. The file location is: installationDirectory/br/deployments/_template/bladelogic. If the new bladelogic. if it is in use. you can skip this step. change the keystore password for the _spawner deployment.) To change the password needed for the bladelogic. including the PXE server.Configuring the Application Server 1 Stop the cooperating Application Server. At the command prompt. start the Application Server Administration console for the deployment. enter: set appserver CertPasswd password C Repeat these steps for each deployment whose keystore file has changed. D Change the keystore password for the _launcher deployment. (If keystore passwords match.

When there is no traffic over the connection between a client and the Application Server for this period of time. 3 Restart the Application Server. 2 To specify an idle prune time. If the client exceeds these maximums. 1 Start the Application Server Administration console. If cancellation of a job part exceeds this maximum.Configuring the Application Server blasadmin -s _spawner G At the blasadmin prompt. enter: set ProcessSpawner KeyStorePassword password 4 Restart the cooperating Application Servers. 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. 60 BMC BladeLogic Server Automation Administration Guide . as described in “Starting the Application Server Administration console” on page 45. the job part is classified as stuck and the job part is aborted. 1 Start the Application Server Administration console. such as a prune time for idle connections or the maximum amount of time a client can perform read operations from the Application Server. the connection is closed. 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. as described in “Starting the Application Server Administration console” on page 45. enter the following: set appserver MaxTimeForCancelToFinish # where # is the maximum amount of time in minutes that should elapse for job cancellation. enter the following: set appserver IdleConnectionPruneTime # where # is a value in minutes. Setting limits for client connections The Application Server lets you specify certain limits for connections to the Application Server. the connection is considered expired.

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. If necessary. enter the following: set appserver SocketTimeout # where # is the maximum number of seconds for client socket reads before the socket times out. 3 Restart the Application Server. a work item thread is canceled when it exceeds the time period you have defined in the JOB_PART_TIMEOUT property. all other work item threads acting on the same server are also canceled. as described in “Starting the Application Server Administration console” on page 45. and the connections that have expired are pruned. a job waiting for the PXE client to boot). which means the connection never expired. 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. Setting time-out behavior for work item threads The Application Server lets you specify time-out behavior for work item threads. 4 Restart the Application Server. use this procedure. To ensure that these jobs are automatically restarted when the Application Server restarts. 1 Start the Application Server Administration console.Configuring the Application Server When a new incoming connection is made. By default. Chapter 3 Configuring the Application Server 61 . idle connections with non-zero IdleConnectionPruneTime values are checked. you can use this procedure to override the default behavior so that only one work item thread times out automatically. if you assign job part time-outs. Setting it to false means only the one work item thread is canceled. 3 To specify a time-out for client socket read operations from the Application Server. In addition. By default this value is set to 0. This prevents situations where multiple work item threads time out serially on the same unresponsive server.

A Compliance Job examines a component and compares its parts to conditions defined in compliance rules for a component template. you may tax your system resources. If results for a Compliance Job exceed the limits you set in this procedure.Configuring the Application Server 1 Start the Application Server Administration console. particularly disk space. 2 Enable automatic restart of provisioning jobs by entering the following: set appserver restartIdleProvisionJobs true 3 Restart the Application Server. Setting the outcome of Update Server Properties Jobs when target agents are unresponsive By default. You can. set the Update Server Properties Job to end in failed status whenever agents do not respond. 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. If you are running a Compliance Job that examines many server objects that fail a compliance condition. 1 Start the Application Server Administration console. an Update Server Properties Job always ends successfully. however. 62 BMC BladeLogic Server Automation Administration Guide . 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. as described in “Starting the Application Server Administration console” on page 45. Parts that do not comply are shown in Compliance Job results. the job run is marked with a warning and the job log includes a message saying that job results have been truncated. as the AGENT_STATUS property for the target servers is updated in any case. even if the RSCD agents on the remote target servers are unresponsive. 2 Set the outcome of Update Server Properties Jobs by entering the following: set JobFactory UspJobSucceedsWhenAgentDown true|false The default value is true. as described in “Starting the Application Server Administration console” on page 45.

enter the following: set scheduler MaxJobTimeInSchedulerQ # where # is a value in minutes. If you restart the Application Server and the specified period has elapsed. as described in “Starting the Application Server Administration console” on page 45. enter the following: set appserver ComplianceResultMaxNumberOfAssets # where # is a the maximum number of server objects displayed per failed condition in a compliance rule. all existing jobs remain in the job queue for the default amount of time—60 minutes. Setting this value to 0 means that all past due jobs execute when the Application Server starts. the scheduled occurrence of a one-time-only job does not execute but the scheduled occurrence of a recurring job does execute. ■ NOTE This procedure only defines behavior for new jobs. 3 Restart the Application Server. By default this value is set to 60. 2 To set a maximum for compliance results displayed. 2 To set past due job execution behavior. 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. 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. No matter how you define this value.Configuring the Application Server 1 Start the Application Server Administration console. 3 Restart the Application Server. the scheduled occurrence of a job does not execute. 1 Start the Application Server Administration console. Chapter 3 Configuring the Application Server 63 . as described in “Starting the Application Server Administration console” on page 45.

non-job-related purposes. 64 BMC BladeLogic Server Automation Administration Guide . You can also set the maximum and minimum number of database connections used for general. NOTE Because each work item in an Audit Job requires a dedicated database connection. use either of the following commands: set database MaxGeneralConnections # set database MinGeneralConnections # where # is a number of database connections. 1 Start the Application Server Administration console. By providing separate settings for job-related and non-job-related activity. 3 To set a maximum and minimum number of non-job-related database connections. You can set the maximum and minimum number of database connections that jobs use. 4 Restart the Application Server. such as client connections to the database. 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. as described in “Starting the Application Server Administration console” on page 45.Configuring the Application Server Setting the number of database connections Use this procedure to set maximums and minimums for database connections. increasing the value for MaxJobExecutionConnections can sometimes increase the performance of large Audit Jobs. NOTE The sum of the maximum numbers you define for MaxJobExecutionConnections and MaxGeneralConnections cannot exceed the connection limit specified by the database server. you can help to prevent situations where client connections seem to hang because large jobs are using all available database connections.

You can modify this value if necessary. This communication is used for various administration tasks. the Application Server does not run an Authentication Service. By default the Application Service runs and listens on port 9841. This port is used in a multiple Application Server configuration for Application Server to Application Server communication. By default the Authentication Service runs and listens on port 9840. It is used in conjunction with the RMI Execution Port 9850+ (which is obtained from the MaxPort/MinPort range when the Application Server starts). If this value is blank. If this value is set to 0. Typically. and is used in conjunction with the JMX Management Port 9838 (by default) to authenticate the client AppSvcPort (port 9841 by default). the ProxySvcPort is automatically set to the Base Port plus 42. coordinate job work item execution.Configuring the Application Server Setting communication ports The following sections list the port requirements for both the Application Server and the Application Server Launcher. ProxySvcPort 9842 RegistryPort 9836 Listening port for traffic between Application Servers that cooperate by distributing jobs to each other. Application Server ports By convention the Application Server listens to the ports listed in the following table: Port Number (By Convention) 9840 Traffic Type AuthSvcPort Description Listening port for the Authentication Service associated with an Application Server. such as to pull Application Server statistics. and so on. You must manually define a listening port for the default deployment of an Application Server. When you deploy a new Application Server with its type set to NSH_PROXY or ALL. If this value is set to 0. Chapter 3 Configuring the Application Server 65 . The listening port for a Network Shell Proxy Service. the Application Server does not run a Network Shell Proxy Service. update the remote heartbeat status. the service that accepts client connections). This port is used for BMC BladeLogic Console to Application Server communication. the Application Server does not run an Application Service. AppSvcPort 9841 Listening port for the Application Service (that is. ProxySvcPort is set to 9842 for the default Application Server.

Default communications port used for Application Server communication with the Application Server Launcher. as described in “Starting the Application Server Administration console” on page 45. the following ports are used by the Application Server Launcher for BMC BladeLogic Console to AppServerLauncher communication: Port Number (By default) 9700 Traffic Type JMX Description Default Java Management Extensions (JMX) port used by the BMC BladeLogic Console to communicate with the Application Server Launcher. which the Application Server can provide if you perform the following procedure. 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. and # is the number of the port. Ports used in a multiple application server deployment by the Application Server Launcher By default. Many organizations provide Internet access through a proxy server. 2 To specify a listening port. it requires a user name and password. listeningport is the type of listening port. such as AuthServer. such as AuthSvcPort. use this port is used for BMC BladeLogic Console /Application Server Launcher communication. The patch management component of BMC BladeLogic incorporates the ability to download files from the Internet. If the HTTP proxy server authenticates users. 66 BMC BladeLogic Server Automation Administration Guide . Each managed Application Server uses this port to notify the Application Server Launcher that the Application Server is up and in a ready state. enter the following: set appServerComponent listeningport # where appServerComponent is the option category you want to modify. This communication is all local traffic for this port Incoming messages 9701 RMI execution 9702 In a firewall environment. 3 Restart the Application Server.Configuring the Application Server 1 Start the Application Server Administration console.

enter the following: set appserver SocketsBindAddress IP_address|all Chapter 3 Configuring the Application Server 67 . enter the following: set appserver HTTPProxyUser userName where userName is the name of a valid user on the proxy server. enter the following: set appserver HTTPProxyName serverName where serverName is the name of the HTTP proxy server.Configuring the Application Server 1 Start the Application Server Administration console. as described in “Starting the Application Server Administration console” on page 45. 4 To specify a user name provided to the HTTP proxy server. enter the following: set appserver HTTPProxyPort # where # is the port used to contact the proxy server. enter the following: set appserver HTTPProxyPassword password where password is the password assigned to the proxy user you identified in the previous step. You can also instruct the Application Server to listen for connections on all of its IP addresses. as described in “Starting the Application Server Administration console” on page 45. 2 To identify a proxy server. 1 Start the Application Server Administration console. 5 To specify a password. 2 To specify an IP address to which the Application Server should listen. Binding the Application Server to an IP address Use this procedure to specify an IP address to which an Application Server should listen. 6 Restart the Application Server. 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. 3 To specify a listening port for the HTTP proxy server.

see “Configuring the process spawner” on page 79. the packet is not delivered. If you have previously instructed an Application Server to listen for a specific IP address. You can use this procedure to turn off packet inspection. 68 BMC BladeLogic Server Automation Administration Guide . you must use all in this command to change those instructions so the Application Server listens on all IP addresses. the Application Server listens on all IP addresses. Enabling and disabling Network Shell proxy inspection To ensure data integrity. 1 Start the Application Server Administration console. such as the management object used by JConsole. if you enter all in the command shown above. BMC BladeLogic inspects data packets traveling between Network Shell clients and proxy servers. enter the following: set appserver RMIExecutionPort # where # is the number of the port. as described in “Starting the Application Server Administration console” on page 45. the Application Server listens on all of its IP addresses. 3 To specify a port used to access JConsole. 3 Restart the Application Server.Configuring the Application Server In the command shown above IP_address is the IP address or host name to which the Application Server should listen. 2 To specify a port used to access the Application Server’s remote execution objects. enter the following: set ProcessSpawner RMIExecutionPort # For more on the process spawner. enter the following: set appserver JMXManagementPort # 4 To specify a port used to access the process spawner’s remote execution objects. When this inspection reveals a problem. Similarly. Configuring ports for remote execution objects Use this procedure to configure ports used to access remote execution objects. 5 Restart the Application Server. If you do not specify an IP address or host name.

minor — Sets the check to compare the major and minor parts of the version numbers. 5 is the minor part. If the version numbers are not the same. 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. and so on. build — Sets the check to compare all four parts of the version numbers. If you specify: set appserver VersionCompatibilityCheck micro The check would find that the version numbers are the same and allow the connection. at a level of detail you specify.123.0. as described in “Starting the Application Server Administration console” on page 45. as described in “Starting the Application Server Administration console” on page 45. and micro parts of the version numbers. suppose the Application Server version is 7. 2 Enter the following command: set appserver VersionCompatibilityCheck major|minor|micro|build (In the version number 7.) major — Sets the check to compare only the major part of the version numbers. 1 Start the Application Server Administration console. 3 Restart the Application Server.125 and the client version is 7. micro — Sets the check to compare the major. Chapter 3 Configuring the Application Server 69 .0. This check compares the version numbers of the client and the Application Server.5. you can set up a version compatibility check.Configuring the Application Server 1 Start the Application Server Administration console. By default proxy inspection is turned on. For example.0.5.125. This is the default. minor. the Application Server refuses the connection.5. 7 is the major part. 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.

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. The default value is 5000. For example. 3 Restart the Application Server. 2 To set a maximum cache size for file system objects. as the file system object is stored in the cache and can be reused. if you take a snapshot of a directory structure contains multiple instances of the same. 1 Start the Application Server Administration console. You can use this setting to improve database performance.Configuring the Application Server If you specify: set appserver VersionCompatibilityCheck build The check would find that the version numbers differ and would refuse the connection. 70 BMC BladeLogic Server Automation Administration Guide . the Job does not have to write the same file to the database multiple times. as described in “Starting the Application Server Administration console” on page 45. 3 Restart the Application Server. enter the following: set appserver FileSystemObjectCacheMaxSize # where # is a the maximum number of file system objects that will be stored in the cache.

2 Expand the hierarchy of the Application Servers node. TIP In the BMC BladeLogic Console. smart groups. 3 Restart the Application Server. the Application Server Launcher. select Infrastructure Management. folders. search groups. 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. 2 To set a maximum page size. as described in “Starting the Application Server Administration console” on page 45. You can adjust this display number by selecting Window => Preferences. You must choose File => Refresh after changing the default to have the change take effect. and server objects in the Configuration Object Dictionary. 1 Start the Application Server Administration console. Chapter 3 Configuring the Application Server 71 . by default. These records are used when working with groups. per page. database assets. from the Configuration menu. The default value is 1000. custom objects. large numbers of objects are presented in groups of 50. You can then page through these groups to make working with large numbers of objects more manageable. From the BMC BladeLogic Console 1 In the BMC BladeLogic Console. Expand BMC and Paging Options to change the default. Changing the heap size for BMC BladeLogic components You can change the heap size for the Application Server. enter the following: set appserver MaxPageSize # where # is a the maximum number of items retrieved per page. for example. and other BMC BladeLogic components as described in the following sections.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.

change the values for the MaxHeapSize attribute. update the registry key HKEY_LOCAL_MACHINE\SOFTWARE\BladeLogic\Operations Manager\Application Server\option1 72 BMC BladeLogic Server Automation Administration Guide . perform the following steps: 1 Start the Application Server Administration console.2048 MB Changing the heap size for the Application Server Launcher You can also change the heap size for the Application Server Launcher. Using the Application Server Administration console (blasadmin utility) To change the heap size for the Application Server using the blasadmin utility.Changing the heap size for BMC BladeLogic components 3 Right-click the Application Server you want to edit and select Edit. To change the heap size for the Application Server Launcher. ■ On Windows platforms. the recommended Max Heap Size value for each platform is as follows: ■ ■ ■ Windows .1024 MB Linux . 2 Enter the following command: set AppServer MaxHeapSize heapSize For example: set AppServer MaxHeapSize 1024M TIP Assuming that the Application Server has the recommended configuration of 4GB or more of physical memory. In a multiApplication Server environment. Application Servers inherit the heap size value from the Application Server Launcher. perform the following steps according to your environment. by default. 4 In the Edit Application Server Profile dialog. as described in “Starting the Application Server Administration console” on page 45. The Edit Application Server Profile dialog opens.1536 MB Solaris .

To change the heap size for the BMC BladeLogic Console on UNIX or Linux. ■ For Windows platforms. for example. modify the following line in the blappserv script.. Changing the heap size for other BMC BladeLogic components To change the heap size for other BMC BladeLogic components. Changing the value to Xmx1G. specifies a max heap size of 1GB. you modify the blclient script..io. Enabling/disabling SOCKS proxy rule evaluation By default. which is located in the .io. Chapter 3 Configuring the Application Server 73 . modify the corresponding configuration (. For example. modify the following line in the corresponding script.tmpdir=$BLADELOGIC_HOME/tmp……. where -Xmx512M specifies a max heap size of 512Mb.cfg file. the format for setting the max heap size is jvm. you can disable routing rule evaluation./usr/nsh/br directory: $JAVA_HOME/bin/java -Xss2m -Xmx512M Djava.arg=-Xmx1024M. By default. In the configuration file.tmpdir=$BLADELOGIC_HOME/tmp…….Enabling/disabling SOCKS proxy rule evaluation ■ For UNIX and Linux platforms. which is located in the . for example. you modify the blasadmin. specifies a max heap size of 1GB. where -Xmx512M specifies a max heap size of 512Mb.. Changing the value to Xmx1G. 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.cfg) file in the br directory./usr/nsh/br directory: $JAVA_HOME/bin/java -Xss2m -Xmx512M Djava.. ■ For UNIX and Linux platforms. the configuration files are located in C:\Program Files\BMC Software\Bladelogic\versionNumber\NSH\br. If your system does not use SOCKS Proxy Servers to route to remote servers. to change the heap size for the blasadmin utility on Windows. you modify the configuration script or file for the component.

software packages. Network Shell scripts. see the BMC BladeLogic Server Automation User Guide. as described in “Starting the Application Server Administration console” on page 45. By default.Configuring the file server 1 Start the Application Server Administration console. The system evaluates communication requests against routing rules. A file server should meet the following requirements: ■ An RSCD agent should be installed and licensed. routing rule evaluation is turned on. and metabase values longer than 255 characters. 74 BMC BladeLogic Server Automation Administration Guide . the system does not evaluate communication requests against routing rules. Configuring the file server To configure a file server you must specify a host and directory where BMC BladeLogic stores content. COM+. NOTE Do not limit access to the file server by pushing agent ACLs to the agent on the file server. BLPackages. ■ The file server should have substantial disk space (see the BMC BladeLogic Server Automation Installation Guide for exact recommendations). In addition. 3 Restart the Application Server. false — Turns off routing rule evaluation. enter the following: set RoutingConfig EvaluateSocksProxyRules true|false Where: true — Turns on routing rule evaluation. and other types of information that is not easily stored in the database. you must perform this procedure. BMC BladeLogic uses the file server to store the contents of files included in snapshots. 2 To enable or disable routing rule evaluation. the file server stores registry. Before you can start BMC BladeLogic for the first time after a fresh installation. All users need to be mapped to the same user on the file server. For information on setting up communications to remote servers through SOCKS Proxy Servers.

and all BMC BladeLogic users must be mapped to that user. 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. 2 Right-click the file server and select choose from the following options: Option Update File Server Status Description Contacts the file server to determine current status Chapter 3 Configuring the Application Server 75 . Setting up the file server 1 Start the Application Server Administration console. such as C:\FileServer. For more information see “Exports file” on page 240. as described in “Starting the Application Server Administration console” on page 45. Without this mapping a user may not be able to access a file that another user has stored on the file server. 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. 2 To specify the name of the file server. as opposed to a Windows-style path. 4 Restart the Application Server.Configuring the file server ■ A user name must be defined on the file server. 1 Select Configuration => Infrastructure Management. 3 To specify the location of the file server directory. Updating a file server You can update the status or change the properties of a file server using the Infrastructure Management window. such as /c/FileServer. 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. enter the following: set fileserver name hostname where hostname is the name of the server where data is stored.

enter the following: set emailconfig fromaddress address where address is the address from which mail should be sent. enter the following: set emailconfig smtpserver hostname where hostname is the name or IP address of the host managing email. as described in “Starting the Application Server Administration console” on page 45. 1 Start the Application Server Administration console. see “Configuring Advanced File Servers and Advanced Repeater servers” on page 312 Configuring a mail server BMC BladeLogic jobs can generate email upon their completion. 2 To specify the name or IP address of the SMTP server. select the Enable Advanced File Server option. where you can modify the host name or the file server root directory. you must configure a mail server. enter the following: show emailconfig techsupport NOTE The techsupport parameter is a read-only parameter.Configuring a mail server Option Refresh Properties Description Updates the status of the server Launches the properties dialog. You do not have to configure a mail server if you are not using the system’s ability to generate email. 5 Restart the Application Server. 76 BMC BladeLogic Server Automation Administration Guide . To enable this capability. To modify the file server to an advanced file server. (SMTP stands for simple mail transfer protocol. 4 To display the email address for technical support. For more information.) 3 To specify the email address from which system-generated email is sent.

3 To specify a listening port for the SNMP server.exe. In addition. it too can generate an SNMP trap. To enable SNMP traps. 1 Start the Application Server Administration console. 4 Restart the Application Server. as described in “Starting the Application Server Administration console” on page 45. If you are using Perl.Configuring Perl Configuring Perl The BMC BladeLogic Console and Network Shell both support the Perl scripting language. you must configure an SNMP server. enter the following: set snmpconfig snmpport # where # is the port used to contact the SNMP server. 2 To specify the name or IP address of the SNMP server. such as /c/perl/bin/perl. Chapter 3 Configuring the Application Server 77 . it can generate an SNMP trap. 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. enter the following: set snmpconfig snmpserver hostname where hostname is the name or IP address of the host managing SNMP trap notifications. 3 Restart the Application Server. you should configure the Application Server so it knows the location of the Perl executable. 1 Start the Application Server Administration console. when an Audit Job detects consistent or inconsistent results. as described in “Starting the Application Server Administration console” on page 45. Configuring an SNMP server When a BMC BladeLogic job completes.

2 To specify a connection string for the database. you can manually configure the Application Server to communicate with the database.OracleDriver 78 BMC BladeLogic Server Automation Administration Guide . The installation program can configure the Application Server to communicate with this database. Replace PORT with the port number the database is listening on. do the following: ■ Replace DBServer with the name or IP address of the server running the database. you can define the class with one of the following strings: ■ oracle. Depending on the type of database you are using. the port the database listens on. enter the following: set database connectionstring string where string is a string that specifies the database type.driver. the server running the database. and SQL Server database name or Oracle SID.DatabaseName=DBNAME. 1 Start the Application Server Administration console. as described in “Starting the Application Server Administration console”. However. By default. a BMC BladeLogic installation uses the following database ports: Port Number 1521 1433 ■ ■ Database Type Oracle SQL Server 3 To specify the driver class for the database.Configuring a database server Configuring a database server BMC BladeLogic works in conjunction with an Oracle® or SQL Server database server.SelectMethod=cursor When using one of the formats shown above. The connection string can use one of the following formats: ■ ■ jdbc:oracle:thin:@DBSERVER:PORT:SID jdbc:sqlserver://DBSERVER:PORT. Replace DBNAME with the name of the database or replace SID with the Oracle SID. enter the following: set database driverclass class where class is the Java® class used to communicate with the database. as described in this procedure.jdbc.

SQLServerDriver 4 To specify the user ID and password for the database. you may want to consult your Oracle DBA to achieve best results when defining a commit size. 6 Restart the Application Server. Spawning processes externally can be beneficial for memory management. When the Application Server needs to spawn a process.microsoft. The Application Server transfers the necessary information to the child process. which starts a new child process.sqlserver. Chapter 3 Configuring the Application Server 79 . but at the same time you run the risk of losing more data should a database process fail. If you configure an Application Server in this way. Configuring the process spawner An Application Server can be configured to spawn processes externally to the Application Server process itself.jdbc. an Application Server spawns processes for Network Shell Script Jobs and some types of extended objects. 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. it contacts the process spawner. enter the following two commands: set database userid id set 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.Configuring the process spawner ■ com. a separate dedicated process (the process spawner) is used only for spawning processes. TIP Because Oracle databases can be highly tuned. Primarily. Commit size is primarily used when taking snapshots or performing audits in BMC BladeLogic. A larger commit size means database processes execute more quickly. 5 To specify a commit size for an Oracle database.

4 Restart the Application Server. see “Starting the Application Server Administration console” on page 45. The default port is 1067 and is the port recommended by BMC BladeLogic. Enter the following: set ProcessSpawner SpawnExternally true Setting this value to false indicates the process spawner runs within the Application Server process. For example: blasadmin -s JobServer1 For more information on methods for starting this console. 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. See “Configuring an Application Server to use the process spawner”. NOTE If you set the ProcessSpawner SpawnExternally value to true. Enter the following: set ProcessSpawner RegistryPort # where # is the number of a port. this value is set to false.Configuring the process spawner To configure the process spawner. See “Configuring the process spawner” on page 81. By default. 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. 2 Configure the process spawner itself.d/blprocserv start (UNIX) net start “BladeLogic Process Spawner” (Windows) 3 Specify a port for communicating with the process spawner. 80 BMC BladeLogic Server Automation Administration Guide . do the following: 1 Configure the Application Server to use the process spawner. 2 Specify that processes be spawned externally from the Application Server process.

7 Restart the process spawner. Right-click BMC BladeLogic Process Spawner and select Restart from the pop-up menu. Do one of the following: ■ On Windows. from the Start menu. Enter the following: set AppServer RegistryPort # where # is the number of a port. see “Starting the Application Server Administration console”. enter the following: /etc/init. and double-click Services. On a UNIX-style system.d/blprocserv restart ■ Chapter 3 Configuring the Application Server 81 . The default port is 1067 and is the port recommended by BMC BladeLogic. Double-click Administrative Tools. select Settings > Control Panel.Configuring the process spawner Configuring the process spawner 5 Start the Application Server Administration console for the process spawner deployment. 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. blasadmin -s _spawner For more information on methods for starting this console.

Choosing not to cross mount points can substantially increase the speed of snapshots. For example. 2 To specify how UNIX mount points are processed. as described in “Starting the Application Server Administration console” on page 45. For more on the process spawner. enter the following: set mountconfig SnpAudPkgCrossMounts true|false 82 BMC BladeLogic Server Automation Administration Guide . 1 Start the Application Server Administration console. 1 Start the Application Server Administration console. By default. and packaging of BLPackages. processing does not cross mount points.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. NOTE If a job exceeds the timeout value in the NshScriptJobCredentialTimeout setting. if you want to cross mount points. 3 Restart the Application Server. Once the credentials expire. enter the following: set ProcessSpawner NshScriptJobCredentialTimeout # where # is the number of hours (minimum of 24). The default setting is 96 hours. as described in “Starting the Application Server Administration console” on page 45. 2 To set a timeout value for the job session credentials. and BLPackages in BMC BladeLogic can be processed across UNIX mount points and network mount points for remote file systems shared through NFS. The NshScriptJobCredentialTimeout setting is a global setting that applies to all jobs. an error message is written to the Application Server log and the job log. audits. see “Configuring the process spawner” on page 81. audits. you can perform a snapshot or audit of / and processing can traverse other volumes such as /home or /usr that may reside under /. all active client connections are closed. Processing across mount points Use this procedure to configure the Application Server so snapshots.

and BLPackages crosses network mount points. 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). 3 Restart the Application Server.000. particularly when the Application Server processes multiple configuration objects or extended objects on multiple servers simultaneously. 4 Restart the Application Server. as described in “Starting the Application Server Administration console” on page 45. the SnpAudPkgCrossMounts option must also be set to true (see step 2). enter the following: set AssetThresholds MaxConfigRecords # where # is the maximum number of records to be processed. false means that processing does not cross mount points (this is the default value). To set SnpAudPkgNetworkMounts to true. 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. true means processing of audits. By default this value is set to 50.Restricting the size of configuration and extended objects In the command shown above. 2 To limit the number of records that an Application Server can process for a single configuration object or extended object. Chapter 3 Configuring the Application Server 83 . 3 To specify how network mount points are processed. Audit. Configuration objects and extended objects can be used in component templates. snapshots. and in live browsing. snapshots. Using this procedure can help prevent the Application Server from running out of memory. Setting this value to 0 means no records are processed. and BLPackages crosses mount points. the job fails on that server with a parsing error. true means processing of audits. 1 Start the Application Server Administration console. Snapshot. and Compliance Jobs. If a job targets a server that returns more records for a configuration object or extended object than the limit set in this procedure.

3 Restart the Application Server. users can potentially see system objects even when those users do not have appropriate permissions to interact with those objects. 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. BMC BladeLogic users have the option of hiding or displaying no access nodes. If you use this procedure to show no access nodes at the Application Server level. BMC BladeLogic calls these type of objects no access nodes. If you use this procedure to hide no access nodes. true indicates that no access nodes can be shown in the BMC BladeLogic Console. users cannot display no access nodes. 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. 1 Start the Application Server Administration console. This procedure lets you globally show or hide no access nodes. users can delete groups and folders even when they contain system objects. 2 To show or hide no access nodes. as described in “Starting the Application Server Administration console” on page 45. enter the following: set ConfigManagerUI ShowNoAccessNodes true|false In the command shown above. 84 BMC BladeLogic Server Automation Administration Guide . false indicates no access nodes are hidden. which users can always delete.Configuring user interface settings 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. This setting has no effect on smart groups.

as described in “Starting the Application Server Administration console” on page 45. 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. 2 To specify whether users can delete groups or folders. enter the following: set ConfigManagerUI GroupsMustBeEmpty true|false In the command shown above. which can slow your system performance. false indicates users can delete groups and folders even when they contain objects. 3 Restart the Application Server. This procedure lets you set an arbitrary limit to the number of results that can be displayed during live browse. 3 Restart the Application Server. This procedure lets you specify whether properties should be created automatically during the import process. as described in “Starting the Application Server Administration console” on page 45. Chapter 3 Configuring the Application Server 85 .Configuring user interface settings 1 Start the Application Server Administration console. By default. true indicates that properties are automatically created. Selecting some nodes while browsing can potentially display large numbers of results. enter the following: set ConfigManagerUI AutoCreate true|false In the command shown above. false indicates properties are not automatically created. true indicates that groups must be empty before they can be deleted. 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. 1 Start the Application Server Administration console. properties are automatically created. 2 To turn the automatic creation of properties on or off. BMC BladeLogic can automatically create properties so you can map them to the properties referenced by the imported object.

By default this option is set to 50.000. The limit set in the console cannot exceed the limit established with this procedure. a * authorization). After you use blasadmin to perform this procedure. when users copy and paste an object. as described in “Starting the Application Server Administration console” on page 45. 3 Restart the Application Server. 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. By default this option is set to false.Configuring user interface settings In the BMC BladeLogic Console. Setting this number to 0 indicates no results are displayed. users can copy and paste an object. 3 Restart the Application Server. enter the following: set ACLCopy UseDefaultAclOnObjectCopy true In the command shown above. Also the user’s role is granted full permission to the object (that is. Normally. the newly created object has the same permissions that were defined for the object that was copied. the newly created object is granted a default set of permissions. 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. 2 To enable copying of objects so that the copied objects are assigned a default set of permissions. 2 To limit the number of live browse results that can be displayed. false means that when you copy and paste an object. users can set a preference that also establishes a limit for results displayed while browsing. 1 Start the Application Server Administration console. 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. the newly created object has the same permissions as those assigned to the object that was copied. true means that when you copy and paste an object. 86 BMC BladeLogic Server Automation Administration Guide . as described in “Starting the Application Server Administration console” on page 45. 1 Start the Application Server Administration console.

By default. enter the following: set ConfigManagerUI DefaultImportAndUpdateFolder /path/to/some/folder 3 Restart the Application Server. 1 Start the Application Server Administration console.Configuring user interface settings 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. 1 Start the Application Server Administration console. false indicates import/export is disabled. Chapter 3 Configuring the Application Server 87 . Setting temporary group location for update When you run any of the BLCLI importAndUpdate commands in the Template or BlPackage name spaces. 3 Restart the Application Server. This procedure lets you change this group to another name or location. By default this option is set to false. This temporary group is deleted at the end of the update operation. true indicates that you can export and import the Property Dictionary or custom property classes. 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. the temporary group is /importAndUpdate. 2 To enable or disable the import and export of the Property Dictionary or custom property classes. 2 To specify a new location for the temporary group. enter the following: set ConfigManagerUI PropertySync true|false In the command shown above. as described in “Starting the Application Server Administration console” on page 45. To enable import/export. this option must be set to true on both the exporting and the importing Application Server. as described in “Starting the Application Server Administration console” on page 45.

you can require users specifying passwords to provide a password of minimum length. ■ To specify how many times a user can fail to log in before being locked out. Entering a 0 indicates that users cannot be locked out because of login failures. ■ ■ 1 Start the Application Server Administration console. By default.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. enter the following: 88 BMC BladeLogic Server Automation Administration Guide . as described in “Starting the Application Server Administration console” on page 45. there is no minimum length for passwords. In RBAC you can specify that passwords never expire no matter what expiration period you specify. ■ To specify how long a user is locked out when he or she has surpassed the lockout threshold. For more information on RBAC see the BMC BladeLogic Server Automation User Guide. ■ To specify how long it takes for a password to expire. Entering a 0 indicates passwords do not expire. you can require users to change passwords at specified intervals. enter the following: set accountconfig AccountLockoutThreshold # where # is the number of failed logins that trigger a lockout. Account lockout—By setting a threshold and duration for account lockouts. 2 Do any of the following: ■ To specify a minimum password length. enter the following: set accountconfig MaxPasswordAge # where # is a period of time in days. Maximum password age—By setting a maximum password age. you can specify how many failed logins cause a user to be locked out and how long that lockout lasts. Entering a 0 indicates there is no minimum length for passwords. enter the following: set accountconfig MinPasswordLength # where # is the minimum length for passwords.

Multicast addresses must fall in the range 224. which provides instructions for downloading the bootstrap program needed to begin the provisioning process.0. Use this procedure to provide various parameters needed to run a PXE Server.0.255.255. a BMC BladeLogic PXE Server listens on the multicast address of 224. Entering a 0 indicates that users can only be unlocked by an administrator using RBAC.2.1. 1 Start the Application Server Administration console and specify the PXE Server deployment (_pxe). 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. 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. Configuring the PXE Server When provisioning some types of servers.0.255. For example.Configuring the PXE Server set accountconfig AccountLockoutDuration # where # is the number of minutes the user is locked out. 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. such as eth0 or eth1. Chapter 3 Configuring the Application Server 89 . you might enter the name of a network interface card. 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.0 to 239. By default. you must set up a PXE Server.

90 BMC BladeLogic Server Automation Administration Guide . 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. By default BMC BladeLogic uses port 1759. 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. 1—The PXE Server can use a multicast. the boot prompt does not display. 1—The PXE Server can use a broadcast. 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. If you enter 0.Configuring the PXE Server 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. 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. 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.

Configuring the Licensing Module 12 Identify the base directory on the TFTP server where operating system bootstrap programs are stored.com/ BMCBladelogicLicensingWS/services/BMCBladelogic LicenseService Chapter 3 Configuring the Application Server 91 . enter: show Licensing ServiceUsername 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. Enter the following: set pxeserver tftpd_base_dir directory where directory is the base directory on the TFTP server for storing bootstrap programs. For example. Configuring the Licensing Module The Application Server communicates with the BMC Software Licensing Portal to register or deregister managed servers. to display the user name the Application Server uses to connect to the Licensing Portal. Use the Licensing command to specify the information required to access the services of the Licensing Portal.bladelogic.com/services/LicensingWS set Licensing DeregisterServiceURL https://webapps. 14 Restart the PXE Server. 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. use the show parameter instead of the set parameter.bmc. TIP To display the value of a parameter you have set previously. Task Set the location of Licensing Portal for registering servers Set the location of Licensing Portal for deregistering servers Command set Licensing LicenseServiceURL http://www.

as described in “Starting the Application Server Administration console” on page 45. the password is displayed in encrypted form. When you use the show Licensing ProxyPassword command. 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. 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. enter the following: 92 BMC BladeLogic Server Automation Administration Guide . Turning asynchronous execution on or off does not affect the Staging phase of a Deploy Job. Notes Enter the fully-qualified name of the host machine.Enabling asynchronous execution Task Set the user name and password Command 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. Task Set the proxy host name Set the proxy port Set the proxy user name and password Command set Licensing ProxyHost hostName set Licensing ProxyPort portNumber set Licensing ProxyUsername userName set Licensing ProxyPassword password While the ProxyPassword is entered in clear text. the password is displayed in encrypted form. Asynchronous execution can occur during the Simulate and Commit phases of a Deploy Job as well as during an undo. When you use the show Licensing ServicePassword command. it is stored in the database in encrypted form. 2 To enable or disable asynchronous execution. Enabling asynchronous execution Asynchronous execution lets Deploy Jobs run without blocking work item threads for extended periods of time. 1 Start the Application Server Administration console.

see the BMC BladeLogic Server Automation Web Services Developer Guide.Enabling web services set appserver EnableAsyncExecution true | false By default this value is set to true. in addition to the Application Server initially installed. follow these steps: 1 If you have not done so already. You can configure each additional Application Server so it performs one or more distinct functions. see “Using the Post-Install Configuration wizard to configure the default application server” on page 34. Enabling web services To enable web services. To configure multiple application servers on the same host. Using separate Application Servers in this way. install and configure the Application Server on the host machine. All Application Servers on the same host must use the same database connection. 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. (For information. Configuring multiple Application Servers on the same host BMC BladeLogic lets you run multiple Application Servers on a single host. enter the following: set AppServer enableWebServices true For information about additional web services settings.) Chapter 3 Configuring the Application Server 93 . such as a Configuration Server or a Job Server. 3 Restart the Application Server. The easiest way to achieve this result is to run the Post-Install configuration wizard as the last step of the Application Server installation.

About Application Server deployments and profiles The following sections provide an overview of Application Server deployment and the different types of Application Servers. 94 BMC BladeLogic Server Automation Administration Guide . Application Server deployments A deployment is a directory of services that an Application Server runs. you must use options to specify the Application Server you are configuring or to specify configuration of all Application Servers on the host. NOTE When you start blasadmin. The table describes each deployment and the effect of configuration changes on it. See “Using the Application Server Administration console (blasadmin) to configure Application Servers” on page 44. The creation process not only creates the additional Application Servers but also gives them an “out-of-the-box” configuration. 3 Optionally. based on their Application Server Type and other information you specify. use the Application Server Administration console (blasadmin) to further configure Application Servers. See “Creating additional Application Servers”.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.

Configuration changes you make using blasadmin -a affect this deployment. When there are multiple Application Servers configured on the same host. This deployment is created when a single or initial Application Server is first started. See “Using the application server configuration wizard to change configuration settings” on page 39. Changes to this deployment affect all new Application Servers created. 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 contains default (“out-of-the-box”) settings and initial configuration settings made with the Post-Install Configuration wizard. The following configuration changes affect the deployment: ■ Changes you make using blasadmin -s appServerName or blasadmin -a. 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. Changes you make using blappconf -s appServerName For more information. See “Starting blasadmin to Configure the Default Application Server” on page 45.About Application Server deployments and profiles Deployment Name _template Description The “master” from which other Application Server deployments are created. see “Using the application server configuration wizard to change configuration settings” on page 39. This deployment is created during BMC BladeLogic installation. Changes you make using the Application Server Configuration Wizard or the blappconf command with no -s option. ■ Chapter 3 Configuring the Application Server 95 . each Application Server’s profile determines the number and type of services in its deployment. The start-up process copies the _template deployment to create the default deployment. See “Starting the Application Server Administration console” on page 45. ■ AppServerName The deployment for each Application Server created on the same host (in addition to the default Application Server).

While a CONFIGURATION server can create jobs and start the execution of jobs. See “Configuring the process spawner” on page 81. The deployment for the PXE Server. An Application Server profile can include attributes of one or more Application Server types. only a JOB server can run the work items needed to process a job. JOB 96 BMC BladeLogic Server Automation Administration Guide . The following table lists Application Server types and describes each.About Application Server deployments and profiles Deployment Name _spawner _pxe _launcher Description The deployment for the process spawner. provided that one or more of the connection ports (for example. A JOB server never responds to remote connection requests. See “The Application Server Launcher” on page 34. The deployment for the Application Server Launcher. and attributes. Application Server types The Application Server Type defines the work that an Application Server performs and services that it runs. Application Server Type CONFIGURATION Functional Description Handles all requests from the BMC BladeLogic Console and the BLCLI. 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). See “Configuring the PXE Server” on page 89. regardless of settings for the connection ports. AppSvcPort) is open. Each Application Server has a different profile. Executes work items needed to process a job. The attributes needed for each type are predefined in the profile for the type. type. You specify the Application Server types when you create the Application Server. A JOB server responds to local connection requests from the BMC BladeLogic Console or the BLCLI. Application Server profiles A profile is a definition of an Application Server’s identity: its name.

select Infrastructure Management. Then select New Application Server. 2 Expand the Application Server Launchers node and right-click the Application Server Launcher that you want to control the new Application Server. Chapter 3 Configuring the Application Server 97 . Note that you will not preserve the data that was in the previous unmanaged deployment.Creating additional Application Servers Application Server Type NSH_PROXY Functional Description Manages traffic between Network Shell clients and remote servers. JOB. ■ 3 In the New Application Server dialog. Click Yes to redeploy the unmanaged deployment with the base port and configuration type you specify. 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. 1 In the BMC BladeLogic Console. you are presented with the option of using the unmanaged deployment or creating a new one. An NSH_PROXY server cannot service requests from the BMC BladeLogic Console or the BLCLI. Choose one of the following options: ■ Click No to return to the new Application Server dialog. If there are unmanaged deployments which match this new Application Server request. entering the following information for the new Application Server. from the Configuration menu. NSH_PROXY) An Application Server with its type set to ALL performs the functions of all Application Server types. ALL 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). Equivalent to (CONFIGURATION.

The Application Server Type determines the attributes included in its Application Server profile. The name can include letters. _launcher. use Ctrl-Click to select individual items). For example. 98 BMC BladeLogic Server Automation Administration Guide . and underscores (_). However. The number must be between 1000 and 65536. Accept the default (All Server Types) or uncheck All Server Types and select one or more types. Follow these guidelines: ■ Specify a name that is unique on the host. To generate the numbers. Do not use the following reserved names: default. Application (Required) Specifies the type of Application Server to create: Server Type(s) CONFIGURATION. or ALL (a combination of all three types). digits. _install. (Use Shift + Click to select multiple contiguous types. Used internally within the BMC BladeLogic environment. you could specify 9900 as the base port for the new Application Server. 5 A prompt appears. _template. hyphens (-). _old. JOB. _spawner. see “Application Server types” on page 96. 9829 for SRP Port. you can change the Display Name. as well as for the Display Name in the interface. asking if you want to edit the new Application Server’s profile. and so on. if the default port numbers have a base of 9800 (9836 for Registry Port. Specify a number that makes the new Application Server’s default ports unique on the host. The system creates a profile for the new Application Server. The creation process sets the Registry Port to 9936. NSH_PROXY.Creating additional Application Servers Field Application Server Name Description (Required) The name for the new Application Server. Base Port (Required) The number that BMC BladeLogic uses to automatically generate default port numbers for the new Application Server. _postmig ■ ■ ■ You cannot change the Application Server Name after configuration. the SRP Port to 9929. For information on each type. The name can be no more than 200 characters in length. See “Viewing and editing an Application Server’s profile” on page 100. BMC BladeLogic uses the base port with the last two digits of the default port. and so on). _pxe. Do not use the same name as the default Application Server. 4 Click OK. _util.

For example. For information. You can either start the Application Server or deploy it and start it later. For guidelines for creating the name. the authentication port would be 9540.) ■ BMC BladeLogic creates the Application Server. The Edit Application Server Profile dialog appears. click Yes. see “Viewing and editing an Application Server’s profile” on page 100. the offset for the authentication port is 40 by default. NSH_Proxy. Chapter 3 Configuring the Application Server 99 . profile_type is a comma separated list of the type of Application Server to create: Configuration. see “Viewing and editing an Application Server’s profile” on page 100. To add a new deployment 1 Start blasadmin for the _template deployment by entering the following: blasadmin -s _template 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. To accept the profile. If the base_port is 9500. For information on each type. You can create deployments while executing from a shell or while reading in a file. or All (a combination of all three types). Creating additional Application Servers from the command line You can also add a new Application Server deployment using the blasadmin Create command. click No.Creating additional Application Servers ■ To add or change attributes for the server. 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. Job. (You can always edit the profile later. This command provides the ability to set up an environment from the command line.

3 Start the Application Server on the machine where you are setting up the deployment.Viewing and editing an Application Server’s profile NOTE For instructions on using blasadmin to create a stand-alone NSH Proxy. 3 Right-click the Application Server you want to edit and select Edit. 1 In the BMC BladeLogic Console. NOTE Always use the Edit Application Server Profile dialog to add or change the attributes (configuration parameters) in an Application Server’s profile. The Edit Application Server Profile dialog opens. select Infrastructure Management. To view an Application Server’s profile or change attribute values. Viewing and editing an Application Server’s profile An Application Server profile is a definition of an Application Server’s identity: its name. and attributes (configuration parameters). ■ ■ 100 BMC BladeLogic Server Automation Administration Guide . clear the field and type the value you want. type a value in the blank field. 2 Expand the hierarchy of the Application Servers node. see “Setting up a stand-alone Network Shell Proxy Server” on page 145. clear the field. add or change values for attributes. 4 In the Edit Application Server Profile dialog. from the Configuration menu. ■ To add an attribute to the Application Server’s profile or to change a default value. use the Edit Application Server Profile dialog. Do not use the blasadmin utility. The fields in this dialog are effectively overrides to default values or to previouslyspecified configuration parameters. See “Starting Application Servers” on page 41. To change an existing value. To remove an attribute from the profile. type.

■ A ServiceType of Manual. If you leave this field blank. the Display Name is the same as the Application Server name. You do not have to specify a name. and underscores (_). _util ■ ■ Default Deployment Shows whether the Application Server uses the default deployment. see “Editing the list of roles with Application Server Launcher access” on page 113. The following table describes all attributes that a profile can include. You cannot edit this attribute. as specified during configuration. the ServiceType is Automatic. rather than the Application Server name. or ALL. ServiceType Determines if the Application Server should be automatically started by the AppServerLauncher. follow these guidelines: ■ Specify a name that is unique on the host. Attribute Application Server Name Display Name Description The name for the Application Server. _launcher. JOB. Server Profile Type(s) The Application Server’s type. False —The Application Server do not use the default deployment. The type can be one or more of the following: CONFIGURATION. A ServiceType of Automatic means that the Application Server will be started automatically by the AppServerLauncher. Do not use the same name as the default Application Server.Viewing and editing an Application Server’s profile Attributes listed depend on the Server Profile Type (Application Server Type). _spawner. hyphens (-). NSH. The name can include letters. Do not use the following reserved names: default. specified during configuration. _template. digits. Chapter 3 Configuring the Application Server 101 . For information. You cannot edit this attribute. See “Application Server types” on page 96. ■ By default. ■ ■ True — The Application Server uses the default deployment. which means that the Application Server can only be started using the Infrastructure Dialog. _old. The name that appears in all user interfaces. _pxe. _install. If you specify a name. You cannot edit this attribute.

However. Note: When you create a job server (Application Server type JOB).10. If that Application Server is a JOB type Application Server.Viewing and editing an Application Server’s profile Attribute AppServiceURLs Description The Application Service URLs distributed in the session credentials issued by the Authentication Service. service:appsvc. Note: When you create a job server (Application Server Type JOB).bladelogic:blsess://10. AuthSvcPort The listening port for the Authentication Service (the service that authenticates user identities). This convention avoids conflicts when there are multiple Application Servers on the same host. If you set this value to 0.bladelogic:blsess://localhost:9841. unless the server is also a configuration server (Application Server Type JOB and CONFIGURATION). you can direct these commands to run on a particular Application Server. you do not need to specify a value for this attribute. However. BLCLI commands used for import or export must run on an Application Server with its type set to CONFIGURATION or ALL.10. AppSvcPort The listening port for the Application Service (the service that accepts client connections). When you create a new Application Server. specify one or more comma-separated values. if you want to run Network Shell Script Jobs that include BLCLI commands. that service accepts only connections from the local machine. By default BLCLI commands run on the Application Server processing the job.10:9841 Typically. the port is disabled. This convention avoids conflicts when there are multiple Application Servers on the same host. If you set this value to 0. In that case. 102 BMC BladeLogic Server Automation Administration Guide . it cannot process BLCLI commands used for import/export. BMC BladeLogic sets this value to the Base Port plus 41. the default is Base Port plus 40. When you create a new Application Server. the Application Server does not run an Authentication Service. this port defaults to 0. CLRProxyPort The listening port for Network Shell (NSH) communication. To include this attribute in the profile. BMC BladeLogic sets this value to the Base Port plus 40. the Application Server does not run an Application Service. it runs a ClientConnectionService. If you set this value to 0. unless the server is also a configuration server (Application Server Type JOB and CONFIGURATION). For example: service:appsvc.

MaxWorkItemThreads The maximum size of the pool of threads that can be used to process BMC BladeLogic Console jobs. the Application Server does not start. BMC BladeLogic sets the log file’s name to the Application Server name plus the . use the standard Java notation. To specify a value.log extension. The maximum dynamic port number. BMC BladeLogic sets this value to the Base Port plus 38. 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. If you do not specify a value. see the hardware requirements for the Application Server in the BMC BladeLogic Server Automation Installation Guide.Viewing and editing an Application Server’s profile Attribute ConsoleLogfileName Description The name of the console log file for the Application Server. specify a name that is unique on the host. this value is set to Base Port + 99. it is assumed to be valid and is used when the Application Server is started. MaxJobs MaxPort The maximum number of jobs the Application Server can execute simultaneously. When you create a new Application Server. This convention avoids conflicts when there are multiple Application Servers on the same host. When you create a new Application Server. The default is 20. The default is 50. for example: 1G or 225M. You do not need to specify a value for this attribute. This convention avoids conflicts when there are multiple Application Servers on the same host. Chapter 3 Configuring the Application Server 103 . JMXManagementPort The port used to access the BMC BladeLogic JConsole. This convention avoids conflicts when there are multiple Application Servers on the same host. JVMArgs Arguments to pass to Java Virtual Machine for this Application Server. MaxHeapSize You can specify a value for MaxHeapSize but you are not required to do so. If the value is not valid. MinPort The minimum dynamic port number. If you edit this attribute. the value for JVMArgs is used instead of MaxHeapSize. Determines how many targets can be processed in parallel. For information on recommended maximum Java heap size for Application Servers. By default. When you create a new Application Server. specify a name that is unique on the host. If you edit this attribute. BMC BladeLogic sets this value to the Base Port + 50. The console log file contains all information logged to the Application Server log. LogfileName The name of the log file for the Application Server. This value is usually adequate. When you create a new Application Server. If you specify a value. This convention avoids conflicts when there are multiple Application Servers on the same host. plus any information logged to the console. BMC BladeLogic sets the console log file’s name to the Application Server name plus “_console”. the Application Server uses the heap size set in the Application Server start-up script or service definition.

bladelogic:blsess://host1. If you leave this field blank. SSLPort The listening port for SSL communication. You can modify this value if necessary. there is no need to change this list.Viewing and editing an Application Server’s profile Attribute ProxyServiceURLs Description The Network Shell Proxy Service service URLs. BMC BladeLogic sets this value to the Base Port plus 36. You must manually define a listening port for the default deployment of an Application Server. the list is: sql/sqlmap. SqlFiles The list of SQL properties files used by the Database Service.bladelogic:blsess://host2. the Application Server does not run a Network Shell Proxy Service. specify a name that is unique on the host. This convention avoids conflicts when there are multiple Application Servers on the same host. If you edit this attribute. BMC BladeLogic sets the temporaryDirectoryName to the Application Server Name. If you leave this field blank. To override the default URLs.bladelogic. 104 BMC BladeLogic Server Automation Administration Guide . you can override the default list by typing a comma-separated list of properties in the field. For example: service:proxysvc. this name is the same as the Application Server Name and its location is: installDirectory/tmp/temporaryDirectoryName When you create a new Application Server. the system uses the default URLs.properties In most cases.bladelogic. Typically. TempDirectoryName The name of the directory that stores the Application Server’s tmp files.properties sql/streamable_sqlmap. This convention avoids conflicts when there are multiple Application Servers on the same host. When you create a new Application Server.properties sql/blas-sqlmap. When you create a new Application Server. This convention avoids conflicts when there are multiple Application Servers on the same host.properties sql/reports-sql. RegistryPort The listening port for traffic between Application Servers that cooperate by distributing jobs to each other. BMC BladeLogic sets this value to the Base Port plus 31. ProxySvcPort is set to 9842 for the default Application Server. the ProxySvcPort is automatically set to the Base Port plus 42. service:proxysvc.com:9842 ProxySvcPort The listening port for a Network Shell Proxy Service. If this value is blank. However. Usually. When you deploy a new Application Server with its type set to NSH_PROXY or ALL. type a comma-separated list in the field.com:9842.

All other attributes must be unique. Chapter 3 Configuring the Application Server 105 . select Infrastructure Management. MaxWorkItemThreads. For the most part. These conflicts prevent an Application Server from starting or restarting if it has conflicts with one or more currently running Application Servers. Typically. click OK. each should have a unique profile. 1 In the BMC BladeLogic Console. The Application Server Launcher automatically detects attribute conflicts among the Application Servers that it controls. You can also use the List Conflicts operation to identify attributes on an Application Server that conflict with attributes on other Application Servers. 6 Click OK on the warning that configuration changes do not take effect until you restart the Application Server. For information on identifying conflicts in Application Servers’ attributes. from the Configuration menu. When an Application Server’s profile has a conflicting attributes. Multiple Application Servers can have the same value for MaxJobs. or SqlFiles. its Application Server details shows State = CONFLICT. Failure to make them unique results in conflicts that can cause a start or restart failure in one or more Application Servers. a conflict occurs because the same port number has been assigned to more than one Application Server. regardless of what that value is. 7 Start or restart the Application Server to have changes take effect. see “Listing conflicting attributes” on page 105. attributes for these Application Servers cannot have the same values. 2 In the Infrastructure Management window.Listing conflicting attributes 5 When you are finished editing the profile. expand the hierarchy of the Application Servers node. ■ ■ Listing conflicting attributes When there are Application Servers on the same host. 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.

host (using the same database).Read authorization. Do the following: A list of Application Servers on the Expand the Application Servers node. from the Configuration menu. 1 In the BMC BladeLogic Console. the panel shows the attribute name and the name of Application Server that has the same attribute value specified. A Warning panel lists the attributes that conflict with those other Application Servers. NOTE To display information about the Application Server. For each attribute. select Infrastructure Management. 2 Expand the hierarchy of the Application Servers node. 4 Click OK.. Getting information about Application Servers You can display information about an Application Server and the services that it runs. The right pane shows: ■ ■ ■ ■ ■ ■ Software version Number of jobs running Number of work item threads Database connections Host operating system JVM memory usage 106 BMC BladeLogic Server Automation Administration Guide . To display. This information can be useful for diagnostic purposes. General information about an Application Server Click the Application Server’s name in the left pane. your role must be granted the BL_Administration.. The left pane lists each Application Server’s Display Name and Authorization Port.Getting information about Application Servers 3 Right-click an Application Server and select List Conflicts.

(For information. ServiceType — (Manual | Automatic) Whether the Application Server is automatically started by the AppServerLauncher. on the Application Server 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. ■ ■ Server Type— Application Server Type. Needs Restart — (True | False) Whether the Application Server has been reconfigured and needs to be restarted. The right pane shows: ■ The Application Server Launcher that controls the Application Server Name — The name for the Application Server. specified during configuration. Start Date — The date when the Application Server was started.) Chapter 3 Configuring the Application Server 107 . ■ ■ ■ ■ ■ A list of the services that an Application Server provides Status information about an Application Server service Expand the hierarchy of an Application Server.. Status — (Ready | Stopped | Starting) Whether the Application Server is ready to perform tasks.The Application Server Launchers node To display. stopped. or starting up. A menu of actions you can perform Right-click the Application Server. In the right pane.) Expand the hierarchy of the Application Server. Elapsed Time — The uptime of the Application Server.) Do the following: Click the Application Server’s name in the left pane. Display name— The name that appears in all BMC ■ ■ BladeLogic user interfaces. (This information is displayed if your role has authorization to access the Application Server Launcher. State — (VALID | CONFLICTS) Whether the Application Server’s profile has conflicts that can keep the Application Server from starting. Status information from the Application Server Launcher. see “The Application Server Launcher” on page 34. (The number and type of services vary according to the Application Server’s type. Click the service name.. scroll down.

4 On the dialog. General information for each PXE server connected to the database and detailed status information about each PXE Servers services. ■ ■ 1 In the BMC BladeLogic Console. enter the information for the report file: A For Object Name. B For Object Type. Information about the database to which the Application Server is connected. it is only through the Application Server Launcher that you can: ■ ■ ■ Obtain port information for the Application Server Launcher. Through the Application Server Launchers node.Reporting Application Server information The Application Server Launcher lists a node for each Application Server it controls. select a file format. However. such as UTF8 or Western (windows-1252). C For File Encoding. 108 BMC BladeLogic Server Automation Administration Guide . Reporting Application Server information You can generate a report containing information about all of the Application Servers on the host. Optionally. select Infrastructure Management. click Export Detail Report . from the Configuration menu. 3 On the Export AppServer Details Report dialog. type a file name for the report. 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. 2 In the Infrastructure Management window. select the type of character encoding that should be used for the exported data. select a subdirectory by double-clicking its name in the panel. select a directory where the report should be stored. Edit the list of roles allowed access to the Application Server Launcher. 5 Click Save. Create new Application Servers. from the pull-down menu. you can get the same information about Application Servers and perform the same operations as with the Application Servers node.

from the Configuration menu. Chapter 3 Configuring the Application Server 109 . 1 In the BMC BladeLogic Console. 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. providing a controlled shutdown. select Infrastructure Management. you manage the additional Application Servers through the Infrastructure Management window. 2 Expand the Application Servers node. NOTE You cannot use the stop operation on an Application Server to which a BMC BladeLogic Console is connected.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. if it has not been deployed. 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. You can select options for handling the running jobs.

3 Right-click the Application Server and select Redeploy. enter the following ■ Base port: enter a new base port. Stop when all running jobs finish. Stop when all running jobs finish OR after specified number of minutes. select the method for handling any running jobs: ■ ■ ■ Stop immediately without waiting for running jobs to finish. For example. 3 Right-click the Application Server and select Stop. from the Configuration menu. NOTE This action is only available for stopped Application Servers. JOB. 4 On the Redeploy Application Server dialog. whichever comes first. 2 Expand the Application Servers node. the offset for the authentication port is 40 by default. or ALL (a combination of all three types). from the Configuration menu. 4 On the Stop Application Server dialog. For information on each type. the authentication port would be 9540. 2 Expand the Application Servers node. select Infrastructure Management. 110 BMC BladeLogic Server Automation Administration Guide . Redeploying a stopped Application Server You can select a stopped Application Server and then redeploy it with a different profile type. see “Application Server types” on page 96. 1 In the BMC BladeLogic Console. NSH_PROXY. If the base_port is 9500. base_port is a number that is combined with offset values to determine Authentication and Application Server port numbers.Redeploying a stopped Application Server 1 In the BMC BladeLogic Console. select Infrastructure Management. Application Server Type: select the profile type for this Application Server: ■ CONFIGURATION. 5 Click OK.

2 Expand the Application Servers node. 3 Right-click the Application Server and select Terminate. This selection is useful in cases where Stop does not work. Chapter 3 Configuring the Application Server 111 . Restarting a specific Application Server The Restart operation first stops the Application Server and then starts it again. those options are ignored. 1 In the BMC BladeLogic Console. You cannot enter a new Application Server name. Terminating a specific Application Server The terminate operation terminates the Application Server process immediately. from the Configuration menu. In the case where there are options in the customized deployment that do not exist in the new deployment type.Terminating a specific Application Server ■ Preserve Existing Data: Check this box if you want to preserve deployment data from the existing deployment. NOTE You cannot use the restart operation on an Application Server to which BMC BladeLogic Console is connected. 5 Click OK to validate the information you entered and execute the action on the Application Server launcher. for example. This option automatically migrates any customizations from the existing deployment to the new deployment. when the Application Server is hung. Use this operation to have configuration changes take effect. select Infrastructure Management. NOTE You cannot use the terminate operation on an Application Server to which BMC BladeLogic Console is connected.

select Infrastructure Management. this selection removes the Application Server from the BMC BladeLogic environment. 3 Right-click the Application Server and select Restart. 2 Expand the Application Servers node. 2 Expand the Application Servers node. If you create a new Application Server with the same name. Removes the Application Server and deletes its deployment directory. the Application Server still appears under the Application Server Launchers node Removes the Application Server. In effect. select Infrastructure Management. 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. Option Preserve deployment Description Removes the Application Server but leaves its deployment directory unchanged. it uses this deployment directory.Removing an Application Server 1 In the BMC BladeLogic Console. and removes references to the Application Server from routing rules. In addition. 4 In the Remove Application Server dialog. from the Configuration menu. 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. The Application Server is removed from the Application Server Launcher. specify options for handling the Application Server’s deployment directory and the database registration. 112 BMC BladeLogic Server Automation Administration Guide . deletes its database entry. from the Configuration menu. Delete deployment Preserve server registration Delete server registration 5 Click OK. 3 Right-click the Application Server and select Remove. 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. 1 In the BMC BladeLogic Console.

To remove roles from the selected list. under Selected Roles. NOTE The option is displayed only if there are unmanaged deployments for this Application Server Launcher. 2 On the Add Unmanaged Deployments dialog. Users with this role can use the Edit Application Server Launcher Roles dialog to grant or deny authorization to other roles. from the Configuration menu. Then click the right arrow to move the role to the Selected Roles list. 1 Right-click an Application Server Launcher node and select Add Unmanaged Deployments. select one or more unmanaged deployments you want to add to the Application Server Launcher. Then click the left arrow. 1 In the BMC BladeLogic Console. 4 Under Available Roles. select one or more roles. select one or more roles you want to have access to the Application Server Launcher. but have had their deployments preserved (using the Preserve deployment option).Adding unmanaged deployments Adding unmanaged deployments If you have Application Servers which have been removed from the system. Chapter 3 Configuring the Application Server 113 . select Infrastructure Management. The Application Server Launcher added the deployments you selected as managed Server Profiles. you can add the deployment back into the system without having to restart the launcher. only the BLAdmins role is granted authorization to access to the Application Server Launcher. Editing the list of roles with Application Server Launcher access At BMC BladeLogic installation time. 3 Click OK. 2 Expand the Application Server Launchers node. 3 Right-click the Application Server Launcher and select Edit Role List. enabling you to manage these deployments as you would any other deployment in the system.

use this procedure to update the password on the Application Server. Resetting database passwords for the Application Server In the event that the database user password has been changed. delete from system_property where name = 'tpasswd. 1 Execute the following command to set the passwords to a blank value. click OK. See “Using the application server configuration wizard to change configuration settings” on page 39.conf_created_on'. update bluser set password = ''.Resetting database passwords for the Application Server 5 When you have finished editing the list. commit. 114 BMC BladeLogic Server Automation Administration Guide . 2 Run the application server configuration wizard and set the new password on the Database page of the wizard.

Chapter 4 Administering security 115 . In BMC BladeLogic.Chapter 4 4 Administering security This chapter describes the approaches to security that are possible with BMC BladeLogic. the approaches to security vary. depending on which system components are communicating. including a discussion of some fundamental security concepts (see “Fundamentals of BMC BladeLogic security” on page 117). The following graphic illustrates the various communication legs possible within a BMC BladeLogic system.

A discussion of network security requires many technical terms. 116 BMC BladeLogic Server Automation Administration Guide . This chapter includes links to specialized terms that are defined in the Chapter 9. “Security Glossary”.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.

For communication between most client tier applications (the BMC BladeLogic Console. when an Application Server establishes an authenticated connection with an agent. First. Often that entity is a user.Fundamentals of BMC BladeLogic security Fundamentals of BMC BladeLogic security To implement a secure data center automation system. the identity to be verified is the server hosting the Application Service. BMC BladeLogic uses different approaches for authentication. which are the identities and addresses of the Application Services and Network Shell Proxy Services that can be accessed using the session credential. 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. 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.509 certificates. 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 clientside X. Chapter 4 Administering security 117 . Written into the session credential are service URLs. BMC BladeLogic client applications can cache SSO session credentials obtained from the Authentication Service. If the user’s session credential is cached and the credential has not expired. Then the client uses that session credential to establish an application session with middle tier services. a user can launch the BMC BladeLogic Console and authenticate. or BLCLI) and middle tier applications (Application Server or Network Shell Proxy Server). In this way a user’s context can easily be passed between BMC BladeLogic client applications. depending on the communication leg. client users authenticate with the Authentication Service and acquire a BMC BladeLogic single sign-on (SSO) session credential. For more information on single sign-on. the user can then exit the console and start a BLCLI session without authenticating again. but in some situations the entity is a service. Network Shell. BMC BladeLogic employs a twostep process. For example. For example. On the other hand. when a user starts the BMC BladeLogic Console. allowing client users to re-establish new application sessions without re-authenticating. see “Single sign-on” on page 121.

Application. or Network Shell Proxy Services). 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. For the sake of simplicity.Session layer security NOTE Be aware of the following documentation conventions: ■ BMC BladeLogic supports both TLS and its predecessor. 118 BMC BladeLogic Server Automation Administration Guide . this document refers to that state as Network Shell operating in proxy mode. ■ ■ ■ The BMC BladeLogic Application Server and all client applications use FIPS 140-2 certified modules for cryptographic operations on all transported data. The client application displays the certificate’s content. Communication with middle tier When a BMC BladeLogic client establishes a TLS connection with a middle tier entity (that is. the Authentication Service) to authenticate and obtain an SSO credential. In all contexts (excluding BMC BladeLogic Decision Support for Server Automation).509 certificate.509 certificates. The client cannot recognize the certificate as trusted so the client prompts the user to accept or reject the self-signed certificate. middle tier entities are provisioned with self-signed X. (Optionally. as well as its SHA1 and SHA256 fingerprints. BMC BladeLogic system components employ TLS_RSA_WITH_AES_128_CBC_SHA for the TLS cipher suite. see “Securing communication with CA certificates” on page 224. the client must validate a certificate from that entity. At installation. If the user chooses not to trust the self-signed certificate. you can provision middle tier entities with certificates issued by a CA. the certificate is added to the client’s list of trusted certificates and a secure session is established for the client. ■ Session layer security BMC BladeLogic uses TLS for session layer security across all communications legs. If the user chooses to trust the self-signed certificate. SSL. In the course of the TLS handshake. the client establishes a TLS connection with the Application Server hosting the Authentication Service. the session is terminated. When Network Shell connects to a Network Shell Proxy Server. this document refers only to TLS. the client is presented with the Application Server’s self-signed X.) When a client first accesses a middle tier entity (by necessity. the Authentication. For more information.

) If entries in the configuration files map the client user to a local user. and Network Shell Proxy Service) share the same certificate. you can choose to use self-signed client-side certificates for TLS sessions with RSCD agents. Network Shell Proxy Server. These entities could be Application Servers. the agent temporarily acquires the privileges that the managed server’s operating system grants to this local user. BMC BladeLogic does not use client-side certificates. If this file is not present. Chapter 4 Administering security 119 . and users. see “How BMC BladeLogic grants access to RSCD agents” on page 237. Network Shell Proxy Server. BMC BladeLogic generates self-signed certificates when an agent is installed on a server. Application Service. When a client—that is an Application Server. but you can modify that location.509 certificate is added to or removed from the trusted certificate store. (For details on this process. If your installation employs multiple Application Servers or stand-alone Network Shell Proxy Servers. This file is known as a keystore. the user is no longer prompted to trust that certificate when establishing future sessions with any of these other related entities. or Network Shell client—contacts an RSCD agent on a remote server. A client’s list of trusted certificates are stored in a file written in the Privacy Enhanced Mail (PEM) format.local configuration files can specify the local user context under which the client’s commands should execute. By default.Impersonation and privilege mapping All client services running on a BMC BladeLogic Application Server (Authentication Service. In this way BMC BladeLogic takes advantage of the access control mechanisms provided by the remote server’s operating system. it is read every time an Application Server. they too share the same certificate. If this file is present. Communication with server tier Self-signed certificates are used to secure communication between entities that communicate directly with agents. or Network Shell client establishes a connection with the agent. the agent creates one. 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. repeaters. or Network Shell clients. repeater. Network Shell Proxy Servers. Once a client application has added the Authentication Service’s certificate to its list of trusted certificates. Self-signed server-side certificates are used to secure the exchange of TLS session keys between agents and entities that communicate with agents. you must provision agents with the SHA1 fingerprints of trusted clients’ self-signed certificates. The certificate is stored in a file called certificate. user.pem in the directory where the agent is installed. However. Client applications re-write the keystore file when a trusted X. To accomplish this. By default. The keystore resides in a default location. as described in “Setting override locations for client SSO files” on page 150. settings in the exports.

BMC BladeLogic uses a technique called user privilege mapping. If user equivalency is not possible (that is. (Network Shell users communicating directly with agents do not assume any particular role. Or. “Setting up configuration files. and those ACLs can grant a range of authorizations to users. but that same junior administrator cannot make any changes on those servers. Every system object that you manage with the BMC BladeLogic Console has ACLs defined for it. For example. If there is no user mapping defined in the exports. 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. 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).local configuration files. the user is assigned that user’s permissions in the same manner as if there was explicit mapping—that is. joe does not exist on the target server as a user). if a user authenticates as “joe” and then begins to use Network Shell. You can also define authorizations for Network Shell users if they are configured to communicate through a Network Shell Proxy Server. or ps on certain directories within a group of servers. For more on impersonation and privilege mapping. 120 BMC BladeLogic Server Automation Administration Guide . see Chapter 5. which allows the agent to temporarily grant the local user’s group privileges to an unprivileged user account called BladeLogicRSCD. users are mapped to an underprivileged account (nobody on UNIX or Anonymous on Windows). the agent fully impersonates a user through a call to the setuid command.Authorization If the managed server is a UNIX-style system. On Windows systems the agent performs user privilege mapping. BMC BladeLogic supports authorization via a role-based access control (RBAC) model and a set of very granular access control lists (ACLs). or users.” Authorization Authorization refers to the process of giving someone access to resources or permissions to perform certain actions. If the managed server is a Windows machine. grep. see the BMC BladeLogic Server Automation User Guide. a Network Shell user with a junior admin role can be permitted to perform read-only Network Shell commands such as ls. user.) For example. If there is a match. the user will take on the privileges and permissions of the user “joe” on the target server. 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. on UNIX systems the agent fully impersonates the user through setuid. For more on RBAC and authorization in BMC BladeLogic.

The BMC BladeLogic Console has user authentication utilities built into it. 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. A reports user logs in by providing the user credentials required for his or her authentication type. This constraint will be relaxed in a future release. Single sign-on functionality supports the following authentication mechanisms: SRP LDAP RSA SecurID PKI Active Directory/Kerberos Domain Authentication Chapter 4 Administering security 121 .Single sign-on Single sign-on BMC BladeLogic employs a two-stage procedure for authenticating client application users to their respective middle-tier servers. that credential can be used to establish a new client/server session without requiring the user to re-authenticate. First. If a client application's credential cache contains an unexpired session credential. Then. The two client command line applications (BLCLI and Network Shell) do not. which validates the credential and uses it to establish the identity of the client user. Users can authenticate with blcred and acquire session credential for the command line applications. Once the TLS session is established. the command line applications require access to a session credential that was acquired previously. 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. the client presents its SSO session credential to the service. SSO session credentials have a finite lifetime and can be cached in the file system of the client host. BMC BladeLogic provides a command linebased user authentication utility called blcred. 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. The reports server uses these credentials to authenticate to the BMC BladeLogic Authentication Service. the client application establishes a TLS session with a middle tier service—either an Application Service or Network Shell Proxy Service. having acquired a credential. To connect to a middle tier server. 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. All BMC BladeLogic client applications except BMC BladeLogic Decision Support for Server Automation can share the same session credential.

that registry is a user table in the central Application Server’s database. After successfully authenticating the SRP user. For SRP. The Authentication Service authenticates users by contacting the first available LDAP server in the list. 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. Information in the user table is derived from the RBAC utility in the BMC BladeLogic Console. To take advantage of automatic failover. the Authentication Service issues the client a session credential. Client-tier users are correlated to identities maintained in directories on external LDAP servers. tree-like structure.SRP SRP The secure remote password (SRP) protocol is a non-disclosing authentication protocol (also characterized as a zero-knowledge protocol). the BMC BladeLogic Authentication Service authenticates client-tier users against a registry of authorized users. the BMC BladeLogic Authentication Service connects to an LDAP server to authenticate the user. Non-disclosing authentication protocols protect against man-in-the-middle attacks. 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. allowing password-based mutual authentication of a client and server. When a BMC BladeLogic client-tier user logs in and provides an LDAP “distinguished name” and password. users can set up a list of multiple LDAP servers that provide the same directories of user information. 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. If the LDAP server successfully authenticates the user. the Authentication Service issues the client a session credential. In BMC BladeLogic. 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. 122 BMC BladeLogic Server Automation Administration Guide .

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. the Authentication Service issues the client a session credential. The current status of a certificate can be verified by contacting an OCSP Responder. which is obtained from an RSA SecurID token. a BMC BladeLogic client can access the appropriate certificate and private key on the smart card to authenticate the user. SecurID users authenticate by providing a user name and a passcode. Through middleware. 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. the user must insert a smart card into a card reader and enter a PIN. When an Active Directory domain user chooses to authenticate using AD/Kerberos. 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. After successfully Chapter 4 Administering security 123 . 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.RSA SecurID RSA SecurID BMC BladeLogic authentication can incorporate RSA’s Authentication Manager to utilize its two factor authentication mechanism. 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. 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. While logging into a BMC BladeLogic client. the Authentication Service issues the client a session credential. If authentication is successful. The passcode consists of a PIN and the current token code. 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). If the information the user enters is valid and the OCSP Responder verifies the validity of the user’s certificate.

a user can log into Windows as Sally@DOMAIN. and password. This information is passed to the Authentication Service. Although BMC BladeLogic Decision Support for Server Automation does not support AD/Kerberos authentication. If the domain controller successfully authenticates the user.COM. For example. 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. At that point. An authentication profile identifies the following: 124 BMC BladeLogic Server Automation Administration Guide .COM and then log into BMC BladeLogic as Administrator@DOMAIN. a Windows user credential. AD/Kerberos takes advantage of the Windows single-sign on functionality. which are collections of information that a BMC BladeLogic client application needs to log into the BMC BladeLogic Authentication Service. 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. BMC BladeLogic clients (the BMC BladeLogic Console or the blcred utility) accept a user’s name. Domain Authentication The Domain Authentication solution integrates BMC BladeLogic with Active Directory without requiring users to obtain a Kerberos ticket—that is. it can authenticate AD/Kerberos users who provide a user name. and password (see Domain Authentication). the BMC BladeLogic Authentication Service issues the BMC BladeLogic client an SSO session credential. In Domain Authentication. 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. the Authentication Service issues the client a session credential. Authentication profiles To facilitate single sign-on. which delegates user authentication to the Active Directory domain controller.Domain Authentication authenticating the domain user. 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. BMC BladeLogic clients use authentication profiles. Domain Authentication provides greater flexibility than AD/Kerberos. domain.

If a cached session credential includes information matching these specifications. the BMC BladeLogic Console prompts the user to log into the Authentication Service identified by the specified authentication profile. In Network Shell or BLCLI. users do not define authentication profiles. If the client application does not possess an appropriate session credential. an organization might employ three instances of BMC BladeLogic—one for Operations. Each reports server always accesses the same Authentication Service. he or she would need three different authentication profiles. Chapter 4 Administering security 125 . ■ ■ ■ A user can define multiple authentication profiles. 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. SecurID. For example. he or she would need an authentication profile for each mechanism. PKI. so a user does not have to specify an Application Server or listening port. he or she must specify an authentication profile. and one for Development. or Domain Authentication Information specific to individual authentication protocols. In another example.Authentication profiles ■ Application Server host name Listening port for the Authentication Service hosted by the Application Server Authentication protocol: SRP. If a user wants to connect to all three from the same client application. Each authentication profile specifies an Application Server hosting an Authentication Service. and an authentication mechanism. when logging on. Instead. if a user plans to log into the Application Server using various authentication mechanisms. each pointing to a different instance of BMC BladeLogic. AD/Kerberos. LDAP. users simply specify an authentication type. the port used to access the Authentication Service. the client application establishes a connection to the service listed in the session credential. such as the distinguished name template for LDAP. Using authentication profiles When a user launches a BMC BladeLogic client application (except BMC BladeLogic Decision Support for Server Automation). For BMC BladeLogic Decision Support for Server Automation. 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. one for QA. 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.

For more information on using environment variables. The BMC BladeLogic Console lets users choose to cache session credentials. see the BMC BladeLogic Server Automation User Guide.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 BMC BladeLogic command line applications provide various options for identifying an authentication profile by name. Within that file each authentication profile must have a unique name. Authentication profiles are stored in a single XML file. but you can modify that location. see “Using the blcred utility” on page 226. The following table summarizes these options. For more information on using blcred. Note that BMC BladeLogic Decision Support for Server Automation does not require authentication profiles so it is not listed in the table below. A session credential contains the following information: ■ BMC BladeLogic user name 126 BMC BladeLogic Server Automation Administration Guide . Mechanisms to Identify Authentication Profile environment variable: BL_AUTH_PROFILE_NAME secure file setting: auth_profile BLCLI command line option: -v authenticationProfileName environment variable: BL_AUTH_PROFILE_NAME Takes precedence over environment variable Application Network Shell (in proxy mode) Precedence Takes precedence over secure file setting BMC BladeLogic Console login dialog For more information on setting up authentication profiles for the BMC BladeLogic Console. The XML file resides at a default location. Single sign-on session credentials When an Authentication Service authenticates a user. as described in “Setting override locations for client SSO files” on page 150. The blcred utility always caches any session credential it obtains from the Authentication Service. see “Environment variables” on page 129. The blcred utility also can be used to add or delete authentication profiles. it issues a session credential to the client application. BMC BladeLogic clients use session credentials to establish secure sessions with Application Servers and Network Shell Proxy Servers.

its host address. SSO session credentials are cached in a file on the client host. A BMC BladeLogic service. The reports server relays this information to the Authentication Service and obtains a session credential for the user. the user provides data required for authentication. its host address. ■ ■ ■ ■ ■ ■ Session credentials are digitally signed by the issuing Authentication Service. On both Windows and UNIX. The reports server can potentially hold the user’s session credential even after the user’s connection with the reports server terminates. verifies the digital signature to ensure the credential’s authenticity and integrity. the reports server does not cache the session credential on the client’s system. SecurID. The session credential cache file resides at a default location. which identifies the Authentication Service that issued the session credential. upon being presented with a session credential. such as Application Services and Network Shell Proxy Services. AD/Kerberos. Each of these URLs specifies the type of service.Single sign-on session credentials ■ Protocol used to authenticate user: SRP. This allows users to schedule recurring report jobs. BMC BladeLogic relies on system access controls to restrict access to the session credential cache. 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. as described in “Setting override locations for client SSO files” on page 150. This restriction will be relaxed in a future release. Chapter 4 Administering security 127 . the credential cache can hold a maximum of one session credential at any time. Each time a user logs into the reports server from a browser. LDAP. but you can modify that location. BMC BladeLogic Decision Support for Server Automation can automatically renew the user’s session credential without requiring the user to re-authenticate. 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. or Domain Authentication Service URL. and its port.

for single sign-on. if multiple roles are defined 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 Takes precedence over environment variable 128 BMC BladeLogic Server Automation Administration Guide . Note that BMC BladeLogic also employs a keytab file for its AD/Kerberos implementation. the role may be specified through an environment variable.Keytab files Keytab files If you are using SRP authentication.dat. When a user is authorized for multiple roles. When using Network Shell or BLCLI. RBAC role selection When a session is established. BMC BladeLogic command line applications can specify a role using a command line option or an environment variable. For instructions on setting up user_info. Because of their sensitive nature. If a user is authorized for only one role. which lets you change roles after a Network Shell session is established. The following table summarizes the options available to specifying a role. Procedures for the AD/Kerberos implementation explain the use of a keytab file in that context. a user must be assigned to an RBAC role. the user can interactively select a role while logging into a BMC BladeLogic client application.dat. Network Shell also provides a command called chrole. keytab files are useful when running unattended automation scripts that make use of Network Shell proxy services or make calls to the BLCLI. The SRP keytab file is called user_info. see “Generating a user information file” on page 230. In this release. Application BMC BladeLogic Console BLCLI Mechanisms to Specify a Role Precedence GUI dialog. access to keytab files should be tightly controlled. he or she is assigned to that role after logging into an application. Keytab files provide the blcred utility with long-term user credentials that can be used to authenticate a user. BMC BladeLogic only supports a keytab file for SRP authentication. If a user is authorized for multiple roles.

The command line options take precedence over environment variable settings. BLCLI and blcred also provide command line options for providing the same data. 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 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. Environment Variable BL_SSO_TRUSTED_CERT_ KEYSTORE_FILE BL_RBAC_ROLE Description Specifies location of file storing trusted certificates Specifies RBAC role For More Information: “Trusted keystore” on page 151 “RBAC role selection” on page 128 BL_SSO_CRED_CACHE_FILE Specifies location of session “Session credential cache file” credential cache file on page 151 BL_AUTH_PROFILES_FILE Provides location of file containing authentication profile definitions Identifies authentication profile to use when authenticating “Authentication profile file” on page 151 “Using authentication profiles” on page 125 BL_AUTH_PROFILE_NAME Chapter 4 Administering security 129 . To set an environment variable.

authentication can be configured differently for the various communication legs. The BMC BladeLogic Authentication Service supports many authentication mechanisms. Client users obtain single sign-on credentials by authenticating themselves to the BMC BladeLogic Authentication Service.Security for different communication legs Security for different communication legs Although some aspects of security—session layer security. see “Implementing single sign-on” on page 135. Additional configuration is necessary if you want to customize the default behavior or use other authentication protocols. BMC BladeLogic relies on TLS to secure communication between client and server and single sign-on credentials to authenticate client users. For implementation details. and authorization—are consistent throughout BMC BladeLogic. BLCLI to Application Server For traffic between BLCLI and an Application Server. privilege mapping. Implementation A default BMC BladeLogic installation sets up a single sign-on system using SRP authentication and TLS session layer security. 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. 130 BMC BladeLogic Server Automation Administration Guide . SRP is the default user authentication mechanism.

Network Shell users obtain single sign-on credentials by authenticating themselves to the BMC BladeLogic Authentication Service. Network Shell can use that credential. SRP is the default user authentication mechanism. Additional configuration is necessary to set up a Network Shell Proxy Service. implement any authentication mechanism other than SRP.Network Shell to Network Shell Proxy Server BLCLI users obtain single sign-on credentials by authenticating themselves to the BMC BladeLogic Authentication Service. blcred. BMC BladeLogic relies on TLS to secure communication between client and server and single sign-on credentials to authenticate client users. Alternatively. Alternatively. or customize SSO behavior. The BMC BladeLogic Authentication Service supports many user authentication mechanisms. blcred. Network Shell users can use a separate user authentication command line utility. The BMC BladeLogic Authentication Service supports many user authentication mechanisms. BLCLI users can use a separate user authentication command line utility. For information on using the blcred utility to obtain session credentials. For implementation details. Users can acquire and cache a SSO session credential through the BMC BladeLogic Console. ■ Network Shell to Network Shell Proxy Server For traffic between a Network Shell client and a Network Shell Proxy Server. Additional configuration is necessary if you want to customize the default behavior or use other authentication protocols. Chapter 4 Administering security 131 . to authenticate themselves to an Authentication Service and acquire a SSO session credential. see “Implementing single sign-on” on page 135. Implementation ■ A default BMC BladeLogic installation sets up a single sign-on system using SRP authentication and TLS session layer security. to authenticate themselves to an Authentication Service and acquire a SSO session credential. SRP is the default user authentication mechanism. Network Shell does not have a built-in authentication utility. see “Using the blcred utility” on page 226. The BLCLI does not have a built-in authentication utility. Implementation ■ A default BMC BladeLogic installation sets up a single sign-on system using SRP authentication and TLS session layer security. Users can acquire and cache a SSO session credential through the BMC BladeLogic Console and the BLCLI can use that credential. see “Implementing single sign-on” on page 135. For implementation details.

but you can replace it with a custom certificate. Reports client to reports server A BMC BladeLogic Decision Support for Server Automation client is a web browser that connects to the reports server. you can use a tool such as OpenSSL. The reports server accesses the BMC SARA Authentication Service to authenticate a user and acquire SSO credentials in the name of the authenticated user. Server-side certificates are used during the TLS handshake to establish session keys for encrypting traffic between the web browser and the reports server. they are granted session credentials. the reports server obtains data for reports from the reports data warehouse. To generate a new certificate. user authentication functions much like authentication for other BMC BladeLogic applications. BMC BladeLogic relies on the HTTPS protocol (HTTP over TLS) to secure communication between the browser and reports server. see “Using the blcred utility” on page 226. Once a user on the reports client is authenticated. For traffic between the reports client and the reports server. which can authenticate AD/Kerberos users when they provide their user name. Organizations that want Kerberos-based authentication for BMC BladeLogic Decision Support for Server Automation can use the Domain Authentication protocol. Authentication For BMC BladeLogic Decision Support for Server Automation. domain.Reports client to reports server ■ For information on using the blcred utility to obtain session credentials. 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. By default 132 BMC BladeLogic Server Automation Administration Guide . BMC BladeLogic Decision Support for Server Automation data is packaged using Cognos Reports. By default the reports server uses a self-signed certificate. Implementation A default installation of BMC BladeLogic Decision Support for Server Automation sets up a BMC BladeLogic Authentication Service called BMC SARA Authentication. and password. BMC BladeLogic Decision Support for Server Automation supports all BMC BladeLogic authentication protocols except AD/Kerberos. After users are authenticated.

see “TLS with client-side certs – Securing a Windows Application Server” on page 202 or “TLS with client-side certs – Securing a UNIXbased Application Server” on page 206. when an Application Server connects to an agent or repeater. 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. For all implementation details. BMC BladeLogic relies on TLS to secure communication and the following options for authenticating the Network Shell client to the agent: Chapter 4 Administering security 133 . no authentication occurs. use these procedures as well. see the BMC BladeLogic Decision Support for Server Automation User Guide. Additional configuration is necessary if you want to use an Authentication Server that is not located on the same machine as the reports server. agents and repeaters are provisioned with the SHA1 fingerprints of the Application Servers’ self-signed certificates. Implementation A default installation of BMC BladeLogic provides no authentication for this communication leg. Implementation To implement this approach. ■ IP address—Limits incoming traffic for an agent or repeater to IP addresses of specific Application Servers. Network Shell to agent For traffic between a Network Shell client and an agent. To accomplish this. Implementation For implementation details. If you want to set up self-signed certificates for a Network Shell Proxy Server. modify the exports file on each agent or repeater. The procedure is identical. ■ No authentication—By default. see “Exports file” on page 240.Application Server to agent or repeater only SRP authentication is enabled on the BMC SARA Authentication Service. For more information.

Instead. Repeater to agent For traffic between a repeater and an agent. see “TLS with client-side certs – Securing a Network Shell client” on page 212.Repeater to agent ■ Self-signed. see “Exports file” on page 240. ■ IP address—Limits an agent’s incoming traffic to IP addresses of specific Network Shell clients. ■ No authentication—By default. BMC BladeLogic relies on TLS to secure communication and the following options for authenticating the repeater host to the agent: ■ Self signed. when a Network Shell client connects to an agent. modify the exports file on each agent. Implementation For implementation details.) Implementation To implement this approach. (If necessary. Implementation A default installation of BMC BladeLogic provides no authentication. Application Servers can also be specified in the same way. For more information. see “Implementing Security – Repeater to agent” on page 217. client-side certs—Enables agents to authenticate Network Shell clients. To accomplish this. 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. agents are provisioned with SHA1 fingerprints of Network Shell clients’ self-signed certificates. agents are provisioned with SHA1 fingerprints of repeaters’ selfsigned certificates. Implementation For implementation details. client-side certs—Enables agents to authenticate repeaters. this configuration relies on the host operating system of the Network Shell client to authenticate a user. 134 BMC BladeLogic Server Automation Administration Guide . To accomplish this.

the client application is issued a session credential. For more information. The Authentication Service processes all user authentication requests—that is.Implementing single sign-on ■ IP address—Limits an agent’s incoming traffic to IP addresses of specific repeaters.) Implementation To implement this approach. Application Servers and specific clients can be specified in the same way. Implementation A default installation of BMC BladeLogic provides no authentication for this communication leg. Chapter 4 Administering security 135 ■ ■ . A standard installation of the Application Server includes an Authentication Service. the client application is issued a session credential. SRP authentication is supported by default for all BMC BladeLogic applications. no authentication occurs. A standard installation of BMC BladeLogic Decision Support for Server Automation sets up a stand-alone Authentication Server for reports users. All communication with the Application Service occurs over TLS. Application Service—Used for accessing the functionality of the BMC BladeLogic Application Server. ■ No authentication—By default. you need the following services: ■ Authentication Service—Used for authenticating user identities and issuing session credentials to authenticated users. All communication with the Authentication Service occurs over TLS. Network Shell Proxy Service—Used for accessing the functionality of a Network Shell Proxy Server. when a repeater connects to an agent. A standard installation of the Application Server sets up the Application Service. Implementing single sign-on To implement the BMC BladeLogic single sign-on system. 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. see “Exports file” on page 240. 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. After a client user authenticates. (If necessary. All communication with the Network Shell Proxy Service occurs over TLS. After a client user authenticates. modify the exports file on each agent. all requests from the BMC BladeLogic Console or the blcred utility. Some configuration is necessary to set up a Network Shell Proxy Service.

OCSP verification is only enabled by default for PKI authentication. see “Configuring the Application Service” on page 140. 4 If you want to modify the location of any SSO files used by any BMC BladeLogic client application. A default installation of a BMC BladeLogic Application Server sets up an Authentication Service to support single sign-on for BMC BladeLogic client applications. You can optionally use OCSP verification for Application Servers provisioned with custom certificates. you can instruct a client application to use different files. 6 If you want the SSO system to support any authentication protocol other than SRP. see any of the following: Implementing LDAP authentication Implementing RSA SecurID authentication Implementing PKI authentication Implementing Active Directory/Kerberos authentication Implementing Domain Authentication 136 BMC BladeLogic Server Automation Administration Guide . A default installation of a BMC BladeLogic Application Server sets up an Application Service to support single sign-on. 5 If you want to set up OCSP verification of certificates. see “Setting up certificate verification using OCSP” on page 153. 1 If you want to modify the default behavior of an Authentication Service. see “Setting override locations for client SSO files” on page 150. Currently. Each of the steps in this procedure references a section that describes another procedure. 2 If you want to modify the default behavior of the Application Service. see “Configuring the Network Shell Proxy Service” on page 142. see “Configuring the Authentication Service” on page 137. The files used by the SSO system reside at default locations. If necessary.Implementing single sign-on Use the following master procedure to implement the single sign-on system. 3 If you want to use a Network Shell Proxy Server.

the session credential lifetime is 600 minutes (10 hours). ■ To enable or disable SecurID authentication. this value is set to false. Additional configuration is necessary to support other authentication protocols. as described in “Starting the Application Server Administration console” on page 45. 1 Start the Application Server Administration console (that is. of issued session credentials. Use the following procedure to set any of those options. do any of the following: ■ To enable or disable SRP authentication. enter the following: set AuthServer IsSecurIdAuthEnabled true|false Chapter 4 Administering security 137 .Configuring the Authentication Service 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. enter the following: set AuthServer SessionCredentialLifetime # where # is the lifetime. 3 To specify the duration of session credentials that the Authentication Service issues. Setting AuthSvcPort to 0 turns off the Authentication Service. 2 To specify a listening port other than 9840 for the Authentication Service. enter the following: set AuthServer IsSRPAuthEnabled true|false By default this value is set to true. The Authentication Service runs on the same machine as the Application Server. enter the following: set AuthServer IsLdapAuthEnabled true|false By default. in minutes. There are various options for modifying the standard behavior of an Authentication Service. the blasadmin utility). ■ To enable or disable LDAP authentication. 4 To specify the types of authentication mechanisms that are enabled. enter the following: set AuthServer AuthSvcPort # where # is the number of the port. By default.

■ To enable or disable Domain Authentication.bladelogic: blsess://host1.Configuring the Authentication Service By default. By default BLCLI commands run on the Application Server processing the job..com:9841 Typically. it cannot process BLCLI commands used for import/export.com:9841. bladelogic:blsess://host2. ■ To enable or disable AD/Kerberos authentication.. BLCLI commands used for import or export must run on an Application Server with its type set to CONFIGURATION or ALL. However. enter the following: set AuthServer AppServiceURLs " " Note the blank space between the quotation marks.bladelogic. ■ 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 IsDomainAuthEnabled true|false By default. this value is set to false.. this value is set to false. this value is set to false. this value is set to false...service:appsvc. enter the following: set AuthServer AppServiceURLs serviceURL.serviceURL where serviceURL. you do not need to change the default Application Server URL.bladelogic. do any of the following: ■ To override the default Application Service URL.. For example: set AuthServer AppServiceURLs service:appsvc. enter the following: set AuthServer IsADKAuthEnabled true|false By default. If that Application Server is a JOB type Application Server. ■ To enable or disable PKI authentication. enter the following: set PkiAuth IsEnabled true|false By default.serviceURL is a list of alternative Application Service’s service URLs... 138 BMC BladeLogic Server Automation Administration Guide . you can direct these commands to run on a particular Application Server. if you want to run Network Shell Script Jobs that include BLCLI commands. 5 To write non-default destination service URLs into a session credential.

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 Authentication Service ■ 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. NOTE If you provide a value for ProxyServiceURLs on an Application Server that is defined as type ALL. ■ 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). ■ To override the default Network Shell Proxy Service service URL. enter the following: set AuthServer ProxyServiceURLs " " Note the blank space between the quotation marks.bladelogic. bladelogic:blsess://host2. enter the following: set AuthServer ProxyServiceURLs serviceURL.com:9842 If you are setting up a stand-alone Network Shell Proxy Server.serviceURL where serviceURL.bladelogic. set AuthServer ProxyServiceURLs service:proxysvc. 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.service:proxysvc. Chapter 4 Administering security 139 .bladelogic: blsess://host1. enter the following: set AuthServer AppServiceURLs "" Note that there is no blank space between the quotation marks. For example. For more information on setting up a stand-alone Network Shell Proxy Server. enter the following: set AuthServer ProxyServiceURLs "" Note that there is no blank space between the quotation marks. you must identify the URL for the stand-alone server’s Network Shell Proxy Service service URL.serviceURL is a list of alternative Network Shell Proxy Service’s service URLs.com:9842.

Use the following procedure to set any of those options. enter the following: set AuthServer AuthSvcSocketTimeout # where # is the maximum number of minutes to wait for a response from a worker thread. by default. no additional configuration is necessary. a client cannot use it to access an Application Service or Network Shell Proxy Service. There are various options for modifying the standard behavior of an Application Service. By default the Authentication Service creates a session credential that only includes the service URL for the local Application Service. the maximum is 5. 8 Restart the Application Server (see “Restarting a specific Application Server” on page 111). a firewall) that requires address translations. the connection times out. the Authentication Service will. 140 BMC BladeLogic Server Automation Administration Guide . Overriding the defaults and specifying empty service URLs results in session credentials with no destination service URLs. include its service URL in the session credential it issues.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. 7 To specify a time-out for responses from Authentication Service worker threads. By default the maximum is 1. By default. Typically. Configuring the Application Service A default installation of BMC BladeLogic sets up an Application Service to support single sign-on. enter the following: set AuthServer MaxAuthSvcThreads # where # is the maximum number of threads that can process requests from clients. 6 To specify the maximum number of worker threads used for authentication. If the local Network Shell Proxy Service is enabled. When a session credential has no destination service URL. Once the maximum is exceeded.

■ false means the receiving service’s URL does not have to match the service URL to which the request is addressed. as described in “Starting the Application Server Administration console” on page 45. this option is set to true. this option is set to true. By default. Chapter 4 Administering security 141 . Setting AppSvcPort to 0 turns off the Application Service. ■ false means the IP address of the client does not have to match the client’s IP address included in the session credential. enter the following: set appserver AppSvcPort # where # is the number of the port. 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. Set this value to false only if you are using a network load balancer for your Application Servers or Network Shell Proxy Servers. the client is denied access. and a client can access any one of many Application Servers when establishing a session connection. 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. 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.Configuring the Application Service 1 Start the Application Server Administration console. By default. If the IP addresses do not match. 2 To specify a listening port other than 9841 for the Application Service. you are not using a load balancer for the Authentication Service.

See “Setting up a stand-alone Network Shell Proxy Server” on page 145. you may want to reduce overall traffic loads by setting up an Application Server that functions exclusively as a Network Shell Proxy Server. ■ ■ 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). 142 BMC BladeLogic Server Automation Administration Guide . Using this configuration. See “Setting Up a Network Shell Proxy Server” on page 142. 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. See “Setting Up a Network Shell Proxy Server” on page 142. 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. which means it only manages Network Shell traffic and performs no other Application Server functionality. This procedure is only necessary if you want to use Windows user mapping to run jobs that act on Windows target servers. Configuring the Network Shell Proxy Service Use this procedure to set up a Network Shell Proxy Server that manages traffic from Network Shell clients. Setting up an Application Server that serves as a stand-alone Network Shell Proxy Server. If an Application Server experiences high traffic loads that include Network Shell activity. Setting up an Application Server that functions exclusively as a Network Shell Proxy Server. A stand-alone Network Shell Proxy Server cannot access the BMC BladeLogic database. you have the following options: ■ Setting up an Application Server that performs many functions including that of Network Shell Proxy Server. a Network Shell Proxy Server can accommodate all authentication protocols that BMC BladeLogic supports. 5 Restart the Application Server (see “Restarting a specific Application Server” on page 111). It can relieve the overall workload by processing all Network Shell traffic. and a client can access any one of many Application Servers when establishing a session connection.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.

2 Start the Application Server Administration console.Configuring the Network Shell Proxy Service 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. 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. Increasing the maximum number of proxy threads can improve performance for Network Shell users. However. specify a maximum idle time for thread processing. enter the following: set appserver MaxNshProxyThreads # where # is the maximum number of threads. enter the following: set appserver NshProxyMaxThreadIdleTime # where # can be any of the following: Chapter 4 Administering security 143 . you do not have to set a value for ProxySvcPort. By default this value is set to 5. as described in “Starting the Application Server Administration console” on page 45. ■ For more information on application server profiles. If this value is acceptable. If a value is not set for ProxySvcPort. Each proxy thread can accommodate multiple Network Shell client connections by switching between connections when there is no traffic on a particular connection. 3 If necessary. 5 To adjust the performance of proxy threads processing Network Shell client connections. To accomplish this. see “Configuring multiple Application Servers on the same host” on page 93. the Application Server does not run a Network Shell proxy service. using an excessive number of threads can potentially degrade the performance of a Network Shell Proxy Server. 4 To specify the maximum number of threads that are available to process Network Shell client connections. By default the Network Shell Proxy Server listens for traffic on port equal to Base Port plus 42.

By default NshProxyMaxThreadIdleTime is set to 500 ms. 6 To specify the maximum idle time for a connection with a Network Shell client. While the thread is idle it continues to serve the current connection. 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 NSH proxy socket reads before the socket times out. in milliseconds. This value specifies the number of seconds for obtaining a NSH proxy socket connection to the Application Server. Each thread is dedicated to a single connection so the thread never switches connections. By default this value is set to 0. that a thread should remain idle. -1 – Provides the fastest performance for a particular connection. 144 BMC BladeLogic Server Automation Administration Guide . enter the following: set appserver IdleNshProxyPruneTime # where # is a value in minutes. A value greater than zero specifies a period. A thread is always available to serve another connection after traffic ends on the current connection. 9 Restart the Application Server (see “Restarting a specific Application Server” on page 111). >0 – Provides a compromise between the two settings described above. The longer you instruct a thread to be idle. By default this value is set to 60 seconds. the harder it is for that thread to process more than one connection. which means the connection is never closed.Configuring the Network Shell Proxy Service 0 – Provides the best thread switching performance. When there is no traffic over the connection between a Network Shell client and its proxy for this period of time. enter the following: set appserver NshProxySocketOperationTimeout # where # is a value in seconds. 8 To specify the timeout settings for NSH proxy socket reads. the connection is automatically closed. the thread can switch to another connection. By default this value is set to 7200 seconds. When the specified period expires.

keystore. 1 Install an Application Server on the machine where you want to create a standalone Network Shell Proxy Server. replace all occurrences of bladelogic. In this configuration. provide the same password for the Application Server’s certificate that you entered when installing the central Application Server. you must create a Network Shell Proxy Server deployment using the blasadmin utility.keystore on the Application Server where you are setting up a Network Shell Proxy Server. 11 Assign the NSH_PROXY. See “Setting up a Network Shell Client to run in proxy mode” on page 147. and you must perform some configuration on the central Application Server. search for all instances of bladelogic. Do not run the Post-Install Configuration wizard. such as the _template and _launcher directories. 3 On the Network Shell Proxy Server. a deployment of an Application Server is configured to function only as a Network Shell Proxy Server. On the central Application Server. use the Application Server Administration console (that is. 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 standalone Network Shell Proxy Server. you can find bladelogic. On the Network Shell Proxy Server.Configuring the Network Shell Proxy Service 10 Set up a client for Network Shell users.Connect authorization to any role that should be used to connect to a Network Shell Proxy Server. 2 Copy the bladelogic.keystore that may exist within installDirectory/br/deployments or any of its subdirectories. To accomplish this. Using the copied bladelogic. You must repeat this step for every Network Shell client that should communicate with the Network Shell Proxy Server.keystore at installDirectory/br/deployments/_template/bladelogic. Setting up a stand-alone Network Shell Proxy Server Use this procedure to configure a stand-alone Network Shell Proxy Server.keystore file from the central Application Server.keystore file. It cannot even access the BMC BladeLogic database. blasadmin) to create a new deployment of type NSH_PROXY and configure it as a stand-alone Network Shell Proxy Server. To perform this procedure. When installing. perform the following steps: A Start blasadmin for the _template deployment by entering the following: blasadmin -s _template Chapter 4 Administering security 145 . A stand-alone Network Shell Proxy Server can perform no other Application Server functionality.

C Switch to the newly created deployment by entering the following: switch new_proxy D If necessary. select the central Application Server.Configuring the Network Shell Proxy Service 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. B Expand Application Servers. For example. enter the following: 146 BMC BladeLogic Server Automation Administration Guide . If the base_port is 9500. right-click. the offset for the authentication port is 40 by default. For new deployments of an Application Server. configure the central Application Server by doing the following: A Select Configuration => Infrastructure Management. 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. you do not have to set a value for ProxySvcPort. See “Starting Application Servers” on page 41. If a value is not set for ProxySvcPort. 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. and select Edit. 5 Using the BMC BladeLogic Console. If this value is acceptable. the Network Shell Proxy Server listens for traffic on a port equal to Base Port plus 42. for ProxyServiceURLs. base_port is a number that is combined with offset values to determine Authentication and Application Server port numbers. the Application Server does not run a Network Shell Proxy Service. C On the Edit Application Server Profile. the authentication port would be 9540.

if you plan to run Network Shell and BLCLI scripts unattended on this client machine. NOTE To use the blcred utility.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). 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. 8 Assign the NSH_PROXY. Note that the BL_AUTH_PROFILE_NAME environment variable can override the value of this secure file setting. you must have the BMC BladeLogic Console installed. 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. Authentication profiles are defined in the authentication profiles file. You must repeat this step for every Network Shell client that communicates with the Network Shell Proxy Server. 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.Configuring the Network Shell Proxy Service service:proxysvc. 7 Set up a client for Network Shell users. See “Setting up a Network Shell Client to run in proxy mode” on page 147.Connect authorization to any role that should be used to connect to a Network Shell Proxy Server. 6 Restart the central Application Server (see “Restarting a specific Application Server” on page 111). Additionally. so it can communicate with servers via a Network Shell Proxy Server. see the blcred man page. Chapter 4 Administering security 147 . For a complete description of blcred. Primarily this procedure consists of some settings you must add to the secure file for a client installation. The value used for authProfile must match the name of an authentication profile included in that file.

or you can copy authenticationProfiles. such as /c/Program Files/BMC Software/BladeLogic/version/NSH/br/authenticationProfiles.Configuring the Network Shell Proxy Service ■ auth_profiles_file=fileName. do the following: A Provide an authentication profile name that can be used to generate an SSO session credential.xml. where fileName is the Network Shell-style path to the XML file containing authentication profile definitions.Connect authorization to any role that should be used to connect to a Network Shell Proxy Server. 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). 3 To run Network Shell and BLCLI scripts unattended from this client machine. 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. You can provide an authentication profile name using a command line option for blcred or by defining the BL_AUTH_PROFILE_NAME environment variable.xml: appserver_protocol=ssoproxy:tls_mode=encryption_only:encryption= tls To use the secadmin utility to generate the default entry shown above.xml from a machine where the console is installed and authentication profiles have already been created.xml file. 148 BMC BladeLogic Server Automation Administration Guide . the following is a default entry in the secure file on a client machine running Network Shell: default:protocol=5:auth_profile=QAProfile: auth_profiles_file=/c/Program Files/BMC Software/BladeLogic/ version/NSH/br/ authenticationProfiles. see “Secure file” on page 253. See the BMC BladeLogic Server Automation User Guide for information on using the BMC BladeLogic Console to set up authentication profiles. see “Using the secadmin utility” on page 258. ■ appserver_protocol=ssoproxy For example. Note that the BL_AUTH_PROFILES_FILE environment variable can override the value of the auth_profiles_file setting in the secure file. For more information on secadmin. To create the authenticationProfiles. You can create an authentication profile using blcred or you can create one beforehand using theBMC BladeLogic Console. 2 Assign the NSH_PROXY.

Chapter 4 Administering security 149 . — For SRP authentication. and other information required for the authentication mechanism. Setting up Network Shell Proxy Services for Windows user mapping If you are using automation principals to implement Windows user mapping. 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. Right-click the Application Server you want to modify and select Edit. password. or the job may not run at all. — Provide a BLCLI command line option that specifies the user’s role. which stores a user name. password. For information on setting up user_info. password. — Let the blcred utility prompt for a user name. — 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. make a role selection by doing one of the following: — Define the BL_RBAC_ROLE environment variable. jobs acting on target servers may not use Windows user mapping and instead may operate using user privilege mapping. provide a value for ProxyServiceURLs. select Configuration => Infrastructure Management. 1 Using the BMC BladeLogic Console.dat. If Application Servers are not correctly configured. your Application Server environment must meet certain criteria. and role. set up a keytab file called user_info. 2 Expand the Application Servers node. C If the user is authorized for multiple roles. see “Generating a user information file” on page 230. This procedure also requires you to modify the secure file on the Application Server. and other information required for the authentication mechanism. This procedure is only necessary for Application Servers that handle jobs and are defined as type ALL or JOB. 3 On the Edit Application Server Profile dialog.dat.Configuring the Network Shell Proxy Service 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.

By default. The value you provide should have the format service:proxysvc. see “Viewing and editing an Application Server’s profile” on page 100. 6 Restart the Application Server (see “Restarting a specific Application Server” on page 111). you can instruct a client application to use a file in a different location.Setting override locations for client SSO files This value should identify a Network Shell Proxy Service running in the Application Server’s environment. see “Secure file” on page 253. ProxySvcPort is set to Base Port plus 42. 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 150 BMC BladeLogic Server Automation Administration Guide . Setting override locations for client SSO files The BMC BladeLogic system of single sign-on stores SSO user information in the following files: Authentication profile file Session credential cache file Trusted keystore Each of these SSO files resides at a default location. provide values for other Application Server attributes. For more information. For more information. 7 Configure the secure file on the Application Server so the appserver_protocol option is set to ssoproxy.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. If necessary. portNumber is the value provided for ProxySvcPort on that Network Shell Proxy Server. 5 Click OK. 4 If necessary.

Setting override locations for client SSO files Authentication profile file Authentication profiles are collections of information that a BMC BladeLogic client application needs to log into the BMC BladeLogic Authentication Service. or you can copy the authenticationProfiles. that XML file resides at installDirectory/br/authenticationProfiles. as described below. Within that file each authentication profile must have a unique name. Session credential cache file When an Authentication Service authenticates a user. The user is asked to trust the certificate. the client establishes a TLS connection with that entity. which is known as a keystore. BMC BladeLogic Decision Support for Server Automation does not need an authentication profile to authenticate users. session credentials are automatically cached.bladelogic/bl_sesscc where userHomeDirectory is the home directory of the user running the client application C:\Documents and Settings\WindowsUserName\ Application Data\BladeLogic\bl_sesscc Trusted keystore When a BMC BladeLogic client first accesses a middle tier entity (by necessity. In the course of the TLS handshake. the client is presented with the Authentication Server’s self-signed X. Platform Solaris Linux AIX HP-UX Windows Default Location userHomeDirectory/. All authentication profiles are stored within a single XML file. BMC BladeLogic clients use session credentials to establish secure sessions with Application Servers and Network Shell Proxy Servers. as described below: Chapter 4 Administering security 151 . By default. If the user does. This list. it issues a session credential. A standard BMC BladeLogic installation uses a default location for caching session credentials. BMC BladeLogic Console users can choose to cache session credentials. resides in a default location.509 certificate. the certificate is added to the client’s list of trusted certificates. 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). When authenticating with the blcred utility.xml file.xml file from a client machine where the console is installed and authentication profiles have already been created. To create the authenticationProfiles.xml. the Authentication Service) to authenticate and obtain an SSO credential.

Mechanisms to Identify Location 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. A location provided in a command line option takes precedence over a location provided with an environment variable. A location provided in an environment variable takes precedence over a secure file setting.Setting override locations for client SSO files Platform Solaris Linux AIX.pkcs12.pkcs12. you can define environment variables or make settings in the client’s secure file. For more information on setting environment variables.pem Setting SSO file locations for BLCLI To specify alternative locations for SSO files used by the BLCLI.509 certificates command line option: -x certificateStore environment variable: BL_SSO_TRUSTED_CERT_KE YSTORE_FILE Takes precedence over environment variable Takes precedence over environment variable SSO File SSO session credentials Precedence Takes precedence over environment variable For more information on using command line options in BLCLI. see “Environment variables” on page 129. HP-UX Windows Default Location userHomeDirectory/. The following table identifies SSO file locations you can specify and the mechanisms available to provide that information. you can either provide command line arguments or define environment variables.pem where userHomeDirectory is the home directory of the user running the client application C:\Documents and Settings\WindowsUserName\ Application Data\BladeLogic\client_keystore. see the BLCLI Help. The following table identifies SSO file locations you can specify for BLCLI and the mechanisms available to provide that information. 152 BMC BladeLogic Server Automation Administration Guide .bladelogic/client_keystore. Setting SSO file locations for Network Shell To specify alternative locations for SSO files used by Network Shell operating in proxy mode.

there is no URL for the OCSP Responder. For almost all situations. If the certificate includes a valid URL for an OCSP Responder. it can also be used to further secure communication between components of the BMC BladeLogic system. Setting up certificate verification using OCSP The Online Certificate Status Protocol (OCSP) is an Internet standard used to verify the revocation status of X. For more information on setting environment variables. see “Secure file” on page 253. it sends a message over HTTP to an OCSP Responder. OCSP can determine the revocation status of customer-provisioned certificates for Application Servers (see “Securing communication with CA certificates” on page 224). Chapter 4 Administering security 153 ■ ■ .509 certificates. see “Environment variables” on page 129. In response. Not only is OCSP checking enabled by default for PKI authentication. You want failover capability that tries a second OCSP Responder in situations when the first OCSP Responder fails.Setting up certificate verification using OCSP SSO File SSO session credentials Authentication profile definitions Mechanisms to Identify Location environment variable: BL_SSO_CRED_CACHE_FILE environment variable: BL_AUTH_PROFILES_FILE secure file setting: auth_profiles_file Precedence Takes precedence over secure file setting Keystore for trusted X. You will need to perform additional configuration for OCSP if any of the following conditions are true: ■ In the smart card certificate. When a BMC BladeLogic Authentication Server uses this type of verification. the OCSP Responder sends back a signed message indicating the certificate’s revocation status. this default approach is sufficient and users do not have to perform any additional configuration for OCSP checking. For example.509 certificates environment variable: BL_SSO_TRUSTED_CERT_KE YSTORE_FILE For more information on defining settings in the secure file. BMC BladeLogic will contact that URL to verify the certificate. OCSP checking can be used to improve the security of the overall BMC BladeLogic system. You want to override the URL for the OCSP responder in the smart card certificate. an Authentication Server uses the information in a certificate to determine which OCSP Responder to access when verifying a certificate. Typically.

Setting up certificate verification using OCSP ■ Your OCSP Responder signs OCSP responses with a private key that is unrelated to the Certificate Authority that issued your smart card certificates. the Authentication Server may be contacting a trusted responder specified within the BMC BladeLogic system. The Authentication Server can first attempt to contact the OCSP Responder identified within a certificate. In such a situation. For more information on this capability. an organization can use the BMC BladeLogic system to designate another OCSP Responder (see “Configuring an additional OCSP responder” on page 155). If that attempt fails. The Authentication Server expects that same value will be returned in the response message from the OCSP Responder. In a typical configuration. 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). identified within the BMC BladeLogic system. When nonce is enabled. either because a certificate does not include a URL for an OSCP Responder or conditions prevent users from contacting that responder. In this situation. in some situations. you must create a trust store used specifically for validating communication with the trusted responder. see “Enabling or disabling nonce support” on page 154. 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. the Authentication Server can then contact a secondary responder. The response BMC BladeLogic receives is signed either by the CA that issued the certificate or a responder designated by the CA. the Authentication Server encloses a unique value in an OCSP request message. Using nonce helps to thwart replay attacks. you can set up a failover capability (see “Configuring failover to an OCSP responder” on page 155). the Authentication Server contacts the OCSP Responder identified within a certificate. However. 154 BMC BladeLogic Server Automation Administration Guide . When you use BMC BladeLogic to designate an OCSP Responder. Trusting the response from an OCSP responder If you have used the BMC BladeLogic system to designate an OCSP Responder. To enhance the security of communication with an OCSP Responder. Designating another OCSP responder In some circumstances an organization may want to designate an OSCP Responder. Enabling or disabling nonce support Use this procedure to enable or disable nonce support when contacting OCSP Responders. you may want to enable the OCSP “PKCS” extension. No additional configuration is needed to validate responses sent by the 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). a second OCSP Responder can be contacted in the event that the first fails for any reason. enter the following command: Chapter 4 Administering security 155 . 2 To enable failover between OCSP Responders. Configuring failover to an OCSP responder Use this procedure to set up failover capability between OCSP Responders. start the Application Server Administration console (that is. the only URL used to find an OCSP Responder is the URL obtained from the certificate. 1 On the Authentication Server. With failover. start the Application Server Administration console (that is. 2 To enable or disable nonce support. By default this value is set to an empty string. 3 Restart the Application Server. 3 Restart the Application Server.Setting up certificate verification using OCSP 1 On the Authentication Server. 1 On the Authentication Server. 2 Specify the additional responder by entering the following command: set OCSP ResponderUrl responderURL where responderURL is the URL of the additional responder. the blasadmin utility). start the Application Server Administration console (that is. If you set responderURL to an empty string (""). 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. the blasadmin utility). the blasadmin utility). Once you perform this procedure to define an OCSP Responder.

when the Authentication Server contacts an OCSP Responder. in some circumstances an OCSP trusted responder may sign its response with a key derived from some other entity. a trust store may be necessary in some unusual circumstances. enter the following command: set OCSP UseCustomResponder true|false In this command. 4 Restart the Application Server. Typically. To establish secure communication with an OCSP trusted responder. The trust store must contain a certificate that allows the Authentication Server to trust messages from the OCSP Responder. 2 Import the certificates into a trust store file on the Authentication Server. 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. 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). 3 To specify which OCSP Responder the Authentication Server should contact first. 156 BMC BladeLogic Server Automation Administration Guide . 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. However. the response is signed with the private key that was also used to sign the certificate being verified. No additional configuration is required.Setting up certificate verification using OCSP set OCSP IsFailoverEnabled true By default this value is set to false and failover is not enabled. In this situation. 1 Obtain certificates for all OCSP trusted responders from a certificate authority. If you change the certificate trust store. NOTE The Application Server only reads its certificate store when it starts up. you must set up a trust store used exclusively for validating communication with the OCSP trusted responder. Setting this value to false means the Authentication Server first contacts the OCSP Responder defined in the certificate. be sure to restart the Application Server.

which is available on any machine where the Authentication Server is installed. For example.Setting up certificate verification using OCSP There are many methods for importing a certificate. and -alias is the name you are assigning to the certificate you are adding to the trust store. 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. Currently. ■ 7 Restart the Application Server. pkcs12—Trust store uses the PKCS12 format. Chapter 4 Administering security 157 . you might enter a command like the following: installDirectory/jre/bin/keytool -import -keystore PkiOcspTruststore. 3 On the Authentication Server. OCSP verification is enabled by default for PKI authentication only. the blasadmin utility). 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. it is displayed in clear text.cer -alias ocspt where -keystore identifies the trust store you are setting up. if you are importing certificates with the Authentication Server’s version of keytool. it displays in encoded text. 5 Provide the password needed to decrypt the certificate by entering the following command: set OCSP TruststorePassword ****** When you enter the password. start the Application Server Administration console (that is. If you attempt to view this password later using the show command. -storepass provides the password for accessing the trust store.jks -storepass ****** -file DODOcspCert. Enabling or disabling OCSP Use this procedure to enable or disable OCSP support. -file identifies the certificate you are importing. One approach is to use Java’s keytool utility.

enter the following command: set OCSP IsEnabled true|false By default OCSP is enabled. 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 2 on page 161 in “Configuring LDAP authentication” on page 161. See “Configuring LDAP authentication” on page 161 for a step-by-step procedure describing how to set up LDAP authentication. 2 Provision the Authentication Server with trusted certificates for all LDAP servers. see “High availability configurations” on page 159. the Authentication Service issues a session credential with the user’s distinguished name. 1 Specify the LDAP servers. the Authentication Service uses the LDAP Service. For more information on high availability. For more information. 2 To enable or disable OCSP support. For details on how to specify LDAP servers to the Authentication Server. 158 BMC BladeLogic Server Automation Administration Guide . To accomplish this. the service uses that information to bind to an external LDAP server—that is. see step 3 on page 161 in “Configuring LDAP authentication” on page 161. If the bind is successful. the blasadmin utility). including any servers used for high availability purposes. When a user logs in and provides an LDAP distinguished name and password. 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. 3 Restart the Application Server. to connect to an LDAP server and authenticate a user.Implementing LDAP authentication 1 On the Authentication Server. 3 Define a distinguished name template. start the Application Server Administration console (that is. Implementing LDAP authentication The BMC BladeLogic Authentication Service can authenticate users defined in an LDAP registry.

509 certificates that LDAP servers provide during the TLS handshake. 5 Cross-register LDAP users with the users in the RBAC user database. see “Authentication profiles” on page 124 and the BMC BladeLogic Server Automation User Guide. When a list of multiple LDAP servers is available. You must repeat this procedure each time an LDAP server’s certificate is updated. see “Distinguished names” on page 160 and the BMC BladeLogic Server Automation User Guide. LDAP servers are authenticated via X. For more information. you must identify a file that contains trusted X. Certificate trust store The Authentication Service uses TLS to encrypt its connection to the LDAP Server. When provisioning X. Listing multiple servers helps to ensure high availability and failover capability. This file is the trust store.High availability configurations For more information. if necessary.509 certificates for the Authentication Server’s trust store. For more information. you may want to provide a list of LDAP servers that it can potentially contact.509 certificates. When configuring LDAP. High availability configurations When the Authentication Service needs to authenticate a user by connecting to an LDAP server. LDAP connects to the first functional LDAP server in the list. 4 On the BMC BladeLogic client: A Set up a distinguished name template. For more information. see “Cross-registering users in the BMC BladeLogic database” on page 160. For details on how to set up a distinguished name template for the Authentication Server. B Set up an authentication profile for LDAP authentication. see step 4 on page 162 in “Configuring LDAP authentication” on page 161. you can use one of the following approaches: ■ Install certificates for all LDAP servers. The Authentication Service sends the user’s credential to the LDAP Server only if it can validate the LDAP server’s certificate. Chapter 4 Administering security 159 . see “Distinguished names” on page 160.

For example. ou=dev. o=bladelogic. CN=Users. DC=bladelogic. Distinguished names LDAP users are uniquely identified by distinguished names (DN). DN templates can be defined in two places: the Authentication Service and LDAP authentication profiles (described in the BMC BladeLogic Server Automation User Guide). all current and future LDAP certificates are automatically trusted. the user’s DN becomes CN=qatest3. such as CN=admin. There it is transformed into CN=admin. which is replaced with the name the user provides when logging in. CN=Users. CN=Users. A DN template is a static string containing a {0} substring. the profile template transforms the name to CN=admin. Since all CA-issued certificates are trusted. If the user enters “admin” as a user name when logging in. When cross-registering users. with a DN template of CN={0}.509 certificates to the Authentication Server’s trust store. Rather than entering a full DN.Distinguished names ■ Install the certificate of the trusted Certificate Authority that issued certificates to the LDAP servers. DC=com. which replaces the {0} substring. To add X. be sure to also set IsHostValidationEnabled to True. For more information. the authentication profile DN template might be CN={0}. For information on adding users to RBAC. the Authentication Service requires a full DN and a corresponding password. To authenticate a user. ou=dev. DC=com before it is used to contact the LDAP server. o=bladelogic. Cross-registering users in the BMC BladeLogic database Users must be registered in both LDAP registries and BMC BladeLogic’s RBAC-based user database. CN=sub1 before sending it to the Authentication Service. and the Authentication Service DN template might be {0}. If the common names (CN) specified in the issued certificates are set to the directory server’s fully qualified domain names. For example. Cross-registration allows users to be authorized for RBAC roles. ou=dev. however. DC=bladelogic. users only have to enter the part of a DN that is unique to their accounts. Consequently. see the BMC BladeLogic Server Automation User Guide. the user only enters a string such as “qatest3”. 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. see the blcred man page. The name the user provides is transformed to a full DN by the use of a distinguished name template. 160 BMC BladeLogic Server Automation Administration Guide . be sure to enter the users full distinguished name in both RBAC and the LDAP registry. DC=sub1. use the blcred utility. DC=sub1. The two templates can be used together or by themselves. o=bladelogic.

Configuring LDAP authentication Configuring LDAP authentication Use this procedure to configure the Authentication Service so it can perform LDAP authentication. enter the following: set Ldap TrustStore certificateStore where certificateStore is the local path to a trust store. B To specify the amount of time to wait for an LDAP server to respond before terminating the connection. do the following: A Provision a trust store with X. enter the following: set Ldap LdapServerURLs serverList where serverList is a list of one or more URLs. including any servers used for high availability configurations. start the Application Server Administration console (that is. do the following: A To specify URLs of LDAP servers. In a high availability configuration. URLs must point to LDAPv3 servers that support the StartTLS extension. use the blcred utility. 3 To set up a trust store for X. either by adding certificates from individual LDAP servers or by importing a certificate from a PEM file. Separate URLs with commas or other delimiters (see “Specifying multiple values for a parameter” on page 50).509 certificates. enter the following: set Ldap IsHostValidationEnabled true Chapter 4 Administering security 161 . the blasadmin utility). enter the following: set Ldap ConnectionTimeoutMs # where # is the number of milliseconds to wait. For more information on high availability configurations in LDAP. 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. B To identify the trust store containing trusted certificates. C To check that the certificate’s common name matches the LDAP server’s fully qualified name. 1 On the Authentication Server. 2 To identify LDAP servers. see “High availability configurations” on page 159.509 certificates. To provision a trust store.

See “Certificate trust store” on page 159 for more information on using this option. be sure to restart the Application Server. 5 To enable LDAP authentication. NOTE The Application Server only reads its certificate store when it starts up. For more information on X.509 certificates and setting up trust stores. NOTE The blasadmin utility provides two additional commands for the Ldap component that are not documented here: DefaultUser and DefaultPassword. see “Certificate trust store” on page 159.Configuring LDAP authentication Setting this value to true causes the Authentication Server to reject X. 162 BMC BladeLogic Server Automation Administration Guide . If you change the certificate trust store. 7 Cross-register LDAP users with the users in the RBAC user database. See “Distinguished names” on page 160 for more information on using a distinguished name template. These commands are only used by BMC BladeLogic Decision Support for Server Automation. enter the following: set AuthServer LdapUserDnTemplate "text {0} text" where text represents any distinguished name objects that should be included in the template. See “Crossregistering users in the BMC BladeLogic database” on page 166. 4 To define an LDAP distinguished name template. 8 Set up authentication profiles using LDAP authentication on the BMC BladeLogic client. enter the following: set AuthServer IsLdapAuthEnabled true By default LDAP authentication is not turned on. 6 Restart the Application Server (see “Restarting a specific Application Server” on page 111). See “Authentication profiles” on page 124 and the BMC BladeLogic Server Automation User Guide.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).

2 Copy the sdconf. See “Authentication profiles” on page 124 and the BMC BladeLogic Server Automation User Guide for more information on authentication profiles. the BMC BladeLogic Authentication Service can share that agent’s configuration file. the Authentication Service issues a session credential to the user. BMC BladeLogic’s integration with SecurID requires the presence of a host configuration file called sdconf. BMC BladeLogic does not require one to be installed on the Application Server. Chapter 4 Administering security 163 . The following sections describe those requirements. Then generate a configuration file (sdconf.Implementing RSA SecurID authentication Implementing RSA SecurID authentication The BMC BladeLogic Application Server can authenticate users by means of RSA SecurID. If an RSA Authentication Agent is installed. This file provides the address of the RSA Authentication Manager Server and other parameters needed to contact it. If the information the user enters is valid. which consists of a PIN and the current token code displayed on an RSA SecurID Token. Users might choose to install an RSA Authentication Agent to help troubleshoot SecurID. Configuring SecurID authentication Use this procedure to configure the Authentication Server so it can perform SecurID authentication.rec. Configuring a BMC BladeLogic system to support SecurID authentication requires configuration beyond the default setup. you must configure a client to use an authentication profile set up for SecurID authentication. In that situation you do not have to perform the following procedure.rec file to the BMC BladeLogic Authentication Server. Configuring RSA Authentication Manager BMC BladeLogic assumes you have installed RSA Authentication Manager and are familiar with its functionality. In addition. If a user is registered in the RBAC system. RSA Authentication Agents are used to protect computers and other resources.rec) for the newly created agent. 1 Log in to RSA Authentication Manager and define an Authentication Agent Host using the Application Server’s name or IP address. In some situations the user may be prompted for a new PIN before authentication can occur. that user can authenticate by providing his or her user name and passcode.

if you change the SecurID configuration. 4 Provide the path to the RSA Authentication Manager’s configuration file (sdconf. enter the following: set SecurID ReadConfigInterval interval where interval is the interval in seconds for reloading the configuration file. enter the following: set SecurID AgentHost iPAddress ■ To specify the interval at which SecurID settings are read. enter the following: 164 BMC BladeLogic Server Automation Administration Guide . When set to false.Configuring SecurID authentication When you perform this procedure. enter the following: set AuthServer IsSecurIDAuthEnabled true By default SecurID authentication is not turned on. you must wait the amount of time specified by ReadConfigInterval (described below) until the new configuration values are read. enter the following: set SecurID StatusFilePath filePath where filePath is a local path to that file.rec) by entering the following: set SecurID ConfigFilePath filePath where filePath provides a local path to the sdconf. all SecurID login attempts are rejected. ■ To specify the path to the RSA Authentication Manager’s optional configuration file (sdopts. The default is 600 seconds. The valid range is 0-86400 (24 hours). 2 To enable SecurID authentication.1. ■ To specify the path to the RSA Authentication Manager’s server status file.rec). 1 On the Authentication Server.rec file. If you do not provide a path. the blasadmin utility). start the Application Server Administration console (that is. you do not have to restart the Authentication Server if you are making changes to SecurID configuration. The default file name is JAStatus. 3 Restart the Authentication Server. 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. However. a new file is created in BMC BladeLogic’s /br directory.

Configuring SecurID authentication set SecurID OptionsFilePath filePath> where filePath is a local path to that file. the RSA SecurID module creates log entries in the file specified by the LogFilePath option. the file is automatically created in BMC BladeLogic’s /br directory. This file is created automatically the first time the Authentication Service successfully connects to the RSA Authentication Manager. Chapter 4 Administering security 165 . you must ensure that the Application Server can access the node secret file by granting the appropriate operating system-level permissions to the file. This configuration file is used to configure a manual authentication load balancing policy. ■ To specify the path to the SecurID log file. enter the following: set SecurID LogToFile true | false If set to true. If multiple Application Servers are running on the same host. The default file name is securid. On UNIX. enter the following: set SecurID LogFilePath filePath where filePathis local path to the log file. enter the following: set SecurID LogLevel OFF | DEBUG | INFO | WARN | ERROR | FATAL By default this option is set to OFF. enter the following: set SecurID NodeSecretFilePath filePath where filePath is a local path to that file. If you are running other applications that also use RSA authentication. When multiple applications share a node secret file. on Windows you must grant permission to SYSTEM. ■ To set the logging level. If you do not define a path. ■ To specify the path to the RSA Authentication Manager’s node secret file. you must grant permission to the bladmin user. they may need to share the same node secret file that the Application Server is using. they should all use the same node secret file. ■ To turn on logging. Other applications may have similar access requirements. By default this option is set to false.

Refer to RSA’s product documentation for a more complete description of supported settings.Cross-registering users in the BMC BladeLogic database NOTE SecurID configuration settings are stored in installDirectory/br/deployments/ deploymentName/options/securid-options. a BMC BladeLogic client can access the appropriate certificate and private key on the smart card to authenticate the user. see “Setting up certificate verification using OCSP” on page 153. By default. For more information on setting up OCSP. You can manually edit this file to specify additional debug options. To verify whether a certificate is currently valid.properties. Cross-registering users in the BMC BladeLogic database Users must be registered in both the SecurID user registry and the BMC BladeLogic RBAC-based user database. 7 Set up authentication profiles using SecurID authentication on the BMC BladeLogic client. see the BMC BladeLogic Server Automation User Guide. BMC BladeLogic documentation assumes you know how to add users to the SecurID user registry. the user must insert a smart card into a card reader and enter a PIN. such as RSA_ENABLE_DEBUG=YES. Only users authorized to use BMC BladeLogic should be entered into the BMC BladeLogic database. the Authentication Server can access an OCSP Responder. See “Authentication profiles” on page 124 and the BMC BladeLogic Server Automation User Guide. 6 Cross-register users in both the SecurID user registry and the RBAC user data base. Through ActiveClient middleware. See “Cross-registering users in the BMC BladeLogic database” on page 166. Implementing PKI authentication The 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). While logging into a BMC BladeLogic client. If the information the user enters is valid and the OCSP Responder verifies the validity of the user’s certificate. Use RBAC to add users to the database. Cross-registration allows users to be authorized for RBAC roles. the Authentication Service issues the client a session credential. OCSP verification is enabled for PKI authentication. For information on adding users to RBAC. 166 BMC BladeLogic Server Automation Administration Guide .

users must be cross-registered according their full distinguished name (DN). PKI authentication is not supported for Windows 64-bit platforms. Configuring PKI authentication Use this procedure to configure the Authentication Server so it can perform PKIbased authentication. When set to false. For more information on registering users. See “Setting up a trust store for PKI authentication”. 2 To enable PKI authentication. If you choose to cross-register users by their common name. enter the following: set PkiAuth IsEnabled true By default PKI authentication is not turned on. NOTE In this release. the blasadmin utility).Configuring PKI authentication BMC BladeLogic does not provide a default set of trusted CA certificates for use with PKI authentication. 4 Set up a trust store for a PKI certificate. see “Cross-registering users in the BMC BladeLogic database” on page 166. 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. Chapter 4 Administering security 167 . Note that many steps in this procedure reference a sub-section that describes another procedure. 1 On the Authentication Server. all PKI-based login attempts are rejected. you cannot also crossregister users by their distinguished name. start the Application Server Administration console (that is. you must obtain certificates yourself from a CA. If you are implementing PKI. You must choose between the common name or the distinguished name approach.

obtain the certificate for the certificate authority that issued the certificates on the smart card. In most situations. 6 Cross-register users in both the user registry maintained for smart card holders and the RBAC user data base. if you are importing a certificate with the Authentication Server’s version of keytool. 2 Import the certificate into a trust store file on the Authentication Server. 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. OCSP verification is enabled for PKI authentication and no additional configuration is necessary.cer where -keystore identifies the trust store you are setting up.Configuring PKI authentication 5 To configure certificate verification using an OCSP Responder. 7 Set up authentication profiles using PKI authentication on the BMC BladeLogic client. be sure to restart the Application Server. and -file identifies the certificate you are importing. the blasadmin utility). 1 If you haven’t already done so. see “Setting up certificate verification using OCSP” on page 153. NOTE The Application Server only reads its certificate store when it starts up. which is available on any machine where the Authentication Server is installed. 4 Make the trust store available to the Authentication Server by entering the following command: set PkiAuth TruststorePathname certificateStore 168 BMC BladeLogic Server Automation Administration Guide . start the Application Server Administration console (that is. For example. One approach is to use Java’s keytool utility. There are many methods for importing a certificate. -storepass provides the password for accessing the trust store (needed later in step 5).jks -storepass ****** -file DODJITCCA_19. you might enter a command like the following: installDirectory/jre/bin/keytool -import -keystore PkiTruststore. See “Cross-registering users in the BMC BladeLogic database” on page 169. If you change the certificate trust store. 3 On the Authentication Server. See “Authentication profiles” on page 124 and the BMC BladeLogic Server Automation User Guide.

BMC BladeLogic documentation assumes you know how to add users to the registry of smart card holders. For information on adding users to RBAC. By default. Cross-registration allows users to be authorized for RBAC roles. 5 Provide the password needed to decrypt the certificate by entering the following command: set PkiAuth TruststorePassword ****** Enter the password using clear text. Only users authorized to use BMC BladeLogic should be entered into the BMC BladeLogic database. pkcs12—Trust store uses the PKCS12 format. Cross-registering users in the BMC BladeLogic database Users must be registered in both the registry maintained for smart card holders and the BMC BladeLogic RBAC-based user database. For details on this option. The Application Server Administration console encodes the password that is displayed. users are registered by their full distinguished name. ■ 7 Restart the Application Server. 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. Optionally. users can be registered by just the common name portion of the subject name within their certificate.Cross-registering users in the BMC BladeLogic database where certificateStore is the local path to the trust store. Use RBAC to add users to the database. Chapter 4 Administering security 169 . see the BMC BladeLogic Server Automation User Guide. see “Configuring PKI authentication” on page 167.

After you configure BMC BladeLogic for Domain Authentication. In Windows. use your existing Kerberos configuration files and modify as necessary based on the descriptions in this section. See “Authentication profiles” on page 124 and the BMC BladeLogic Server Automation User Guide for more information on authentication profiles. see “Configuring BMC BladeLogic for Domain Authentication” on page 171. 170 BMC BladeLogic Server Automation Administration Guide . Users provide a user name. The Authentication Service uses that information to authenticate the user to the Active Directory KDC. a Kerberos realm is an Active Directory domain. Configuring a BMC BladeLogic system to support Domain Authentication requires configuration beyond the default setup. and password. The following sections provide instructions for setting up Domain Authentication at installations where AD/Kerberos authentication is not already being used for BMC BladeLogic. which relies on the Active Directory registry to store the names and passwords of registered users within its Kerberos realm. you must configure a client to use an authentication profile set up for Domain Authentication. domain.Implementing Domain Authentication Implementing Domain Authentication The BMC BladeLogic Authentication Service can authenticate users via Windows Active Directory user credentials. For details on this process. If you have already set up AD/Kerberos authentication for BMC BladeLogic.

This is an example. The sample names shown in this example are used in many procedures that relate to the Domain Authentication and AD/Kerberos solutions.Sample domain structure Sample domain structure The following diagram shows a sample domain structure containing a parent domain and two child sub-domains. Chapter 4 Administering security 171 . The following is a master procedure. and password. Each of the steps in this procedure references a sub-section that describes another procedure. 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. you must use UPPER CASE LETTERS. NOTE When you specify a domain name in any of the following steps. Your domain structure may be simpler or more complex. 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. domain.

3 Create the blappserv_login. See “Locating Active Directory KDCs”.COM and SUB2.SUB2. 4 Configure the Authentication Service to support Domain Authentication. From a command line. If multiple realms are used.COM). you will need these host names. See “Logging on using default users and roles” on page 177._tcp.DEV. See “Defining Authentication Service settings for Domain Authentication” on page 175.com 172 BMC BladeLogic Server Automation Administration Guide . 5 Add user names based on Kerberos naming conventions to the RBAC user database.dev.COM The Active Directory KDC’s host name is reported as the value of service (UNIX) or svr hostname (Windows). See “Cross-registering users in the BMC BladeLogic database” on page 176.DEV.DEV.SUB1._tcp. 6 Add users to built-in roles.conf file.MYCOMPANY.DEV.MYCOMPANY.MYCOMPANY._tcp.COM nslookup -type=srv _kerberos. Look up the KDCs for each realm against which users authenticate.conf file.mycompany. 2 Create the blappserv_krb5. See “Creating the blappserv_login. See “Authentication profiles” on page 124 and the BMC BladeLogic Server Automation User Guide. See “Creating the blappserv_krb5.DEV. 7 Set up authentication profiles using Domain Authentication on the BMC BladeLogic client. For example: nslookup -type=srv _kerberos.MYCOMPANY. Later in the configuration process._tcp. enter the following: nslookup -type=srv _kerberos.MYCOMPANY. which defines Active Directory domains and servers.conf file” on page 173. Locating Active Directory KDCs Use this procedure to obtain the host names for Active Directory KDCs. For example: service = 0 100 88 kdc.MYCOMPANY. also look up the KDC for the parent realm (DEV.COM nslookup -type=srv _kerberos.REALM where REALM is a Windows domain name.COM.Configuring BMC BladeLogic for Domain Authentication 1 Obtain the host names for Active Directory KDCs.conf file” on page 174. such as SUB1.sub2. which provides necessary authentication information.

com = SUB1.DEV. 1 Create a text file and add the following content to it: [libdefaults] ticket_lifetime = 6000 default_realm = USERS_REALM [realms] USERS_REALM = { kdc = USERS_REALM_KDC:88 } [domain_realm] . use the nslookup command. they are authenticated as members of the default realm. In the “domain_realm” section.Configuring BMC BladeLogic for Domain Authentication Ignore the numbers before the host name. USERS_REALM_KDC is the host name for the KDC servicing that realm. This file configures Kerberos so it can communicate with the Active Directory server or servers. as described in “Locating Active Directory KDCs” on page 172. If multiple KDCs are running. USERS_DOMAIN provides DNS names. list all of those KDCs. If users are defined in multiple realms.COM To obtain host names for any of the KDCs listed in this file.COM .conf file. When you create a blappserv_krb5.MYCOMPANY.mycompany. you must define a default realm. The Application Server must be able to resolve DNS names of Active Directory servers.conf file Use this procedure to create a blappserv_krb5. create a separate stanza for each realm.MYCOMPANY.MYCOMPANY. 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.DEV.USERS_DOMAIN = USERS_REALM USERS_REALM is the realm where users are defined. For example: .conf.conf file. When Domain Authentication users log in and they do not provide a fully qualified user name. Creating the blappserv_krb5.mycompany.dev.com = SUB2. Chapter 4 Administering security 173 . do not use IP addresses.dev.sub2.dev.sub1.COM .mycompany.com = DEV. NOTE When identifying servers in the blappserv_krb5.

ADKerberosPasswordLogin { com.conf file.auth. For example. save the file to the InstallDirectory/NSH/br directory with the name blappserv_login. save the file to the InstallDirectory\NSH\br directory with the name: blappserv_krb5.conf.conf file You must create a blappserv_login. the file should be located as follows: /opt/bmc/BladeLogic/version/NSH/br/blappserv_krb5. 2 Do one of the following: ■ On a UNIX-style system.module.Krb5LoginModule required doNotPrompt=false useTicketCache=false debug=false. if the Authentication Server is installed in the default location. if BMC BladeLogic is installed in the default location.conf ■ On Windows.bladelogic.auth.service. }.conf For example. the file should be located as follows: C:\Program Files\BMC Software\BladeLogic\version\NSH\br\ blappserv_krb5. save the file to the InstallDirectory\NSH\br directory with the name blappserv_login. com. 1 Create a text file and add the text shown below to this file. the file should be located as follows: 174 BMC BladeLogic Server Automation Administration Guide .sun. save the file to the InstallDirectory/NSH/br directory with the name: blappserv_krb5.security. This files provides necessary Kerberos authentication information.conf Creating the blappserv_login.Configuring BMC BladeLogic for Domain Authentication 2 Do one of the following: ■ On a UNIX-style system.conf. if the Authentication Server is installed in the default location. if BMC BladeLogic is installed in the default location.conf ■ On Windows. the file should be located as follows: /opt/bmc/BladeLogic/version/NSH/br/blappserv_login. For example.conf For example.

conf file. from the directory where BMC BladeLogic is installed.conf file. This file is essential for supporting Kerberos. 2 To allow users to log in using Domain Authentication.Configuring BMC BladeLogic for Domain Authentication C:\Program Files\BMC Software\BladeLogic\version\NSH\br\ blappserv_login. enter the following: set AuthServer AuthSvcKrb5Config fileName where fileName is the name of the blappserv_krb5. enter the following: \bin\blasadmin. you must use the Application Server Administration console. enter the following: . 4 To enable the blappserv_login. To perform this procedure./bin/blasadmin ■ On Windows. select Programs => BMC Software => BladeLogic Server Automation Suite => Utilities => Application Server Administration.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. enter the following: set AuthServer AuthSvcKrb5LoginConfig fileName Chapter 4 Administering security 175 . You can skip this step unless you choose to use a different file name.conf file. By default AuthSvcKrb5Config is set to a value of blappserv_krb5. enter the following: set AuthServer isDomainAuthEnabled true By default this value is set to false. 3 To enable the blappserv_krb5.bat Both options run the same command.conf. 1 Start the Application Server Administration console by doing one of the following: ■ On a UNIX-style system. — From the directory where BMC BladeLogic is installed. do one of the following: — From the Start menu.

MYCOMPANY. Use RBAC to add users to the BMC BladeLogic database. Only users authorized to use BMC BladeLogic should be entered into the BMC BladeLogic database. see the BMC BladeLogic Server Automation User Guide.conf. Requirements for User Names When using AD/Kerberos to authenticate end users. Each BMC BladeLogic user name must be in the form: USER@DOMAIN where DOMAIN is the domain the user is registered in.COM. 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. The user’s BMC BladeLogic user name must match the user’s fully qualified Active Directory user name. Cross-registration allows users to be authorized for RBAC roles. Cross-registering users in the BMC BladeLogic database Users must be registered in both Active Directory and BMC BladeLogic’s RBACbased user database. 5 Restart the Application Server. 176 BMC BladeLogic Server Automation Administration Guide . By default AuthSvcKrb5LoginConfig is set to a value of blappserv_login.MYCOMPANY.COM is a different user name than than mary or mary@SUB3.MYCOMPANY.Configuring BMC BladeLogic for Domain Authentication where fileName is the name of the blappserv_login. you would fill in the name field with a value such as: mary@SUB1.conf file. BMC BladeLogic documentation assumes you know how to add users to Active Directory.DEV.DEV. For example. You can skip this step unless you choose to use a different file name. For information on adding users to RBAC.COM rather than filling in the name field with a value such as: mary Note that the user name mary@SUB1. if you are using RBAC or the bladduser utility to add a new BMC BladeLogic user.DEV. This file is essential for supporting Kerberos.

If the BMC BladeLogic administrator intends to support AD/Kerberos authentication exclusively and disable SRP user authentication. which has read access to all reports at all sites in a BMC BladeLogic installation. the RBACAdmins role has the authorizations necessary to manage users and roles. RBACAdmin_ADK@SUB2. Otherwise. the GlobalReportAdmins role.DEV.DEV. To allow a user to log into the GlobalReportViewers role. If you are using that default setup. In a default installation. The same issue applies to the BLAdmins role. you can simply assign a fully qualified domain user name (for example. Implementing Active Directory/Kerberos authentication The BMC BladeLogic Authentication Service can authenticate users via Windows Active Directory single sign-on credentials or. when SRP authentication is disabled.COM) to the RBACAdmins role. see the BLCLI help. BLAdmins. and the GlobalReportViewers role. Windows Server 2003/2008 implements a Kerberos Key Chapter 4 Administering security 177 . the user would also have to be registered in the Active Directory user registry for the domain SUB2. a Kerberos user’s ticket granting ticket (TGT). For more information on this command.COM. To allow a user to log into the GlobalReportAdmins role. the administrator should log in as a user authorized for the RBACAdmins role and ensure that each of the four built-in roles—RBACAdmins. RBACRole:syncUsers. and GlobalReportAdmins—has at least one registered domain user assigned to that role. you must use RBAC to add a fully qualified name to the GlobalReportViewers role.MYCOMPANY. then. respectively. In this example. you must use RBAC to add a fully qualified user name to the BLAdmins role. which has built-in authorizations to see data for all BMC Service Automation Reporting and Analytics sites. you must use RBAC to add a fully qualified user name to the GlobalReportAdmins role. no user will be able to access the built-in roles. Logging on using default users and roles The BMC BladeLogic user database comes pre-provisioned with two default SRP users: RBACAdmin and BLAdmin. Windows single sign-on is based on the Kerberos authentication protocol. These default users are assigned to the default roles RBACAdmins and BLAdmins.Implementing Active Directory/Kerberos authentication BMC BladeLogic provides a BLCLI command. which has built-in authorizations to change permissions for all system objects in BMC BladeLogic. To allow a user to log into the BLAdmins role.MYCOMPANY. equivalently. prior to disabling SRP. that you can use to synchronize group information in Active Directory with role information in RBAC. GlobalReportViewers.

The request carries encrypted material that allows the KDC to authenticate the request. which the client stores in a local credential cache. relies on the Active Directory registry to store the names and passwords of registered users within its Kerberos realm. B Export the blauthsvc. which BMC BladeLogic clients can use to establish secure sessions with the BMC BladeLogic Application Service or Network Shell Proxy Service. The keying material used to generate and verify the request is derived from the user’s password. 178 BMC BladeLogic Server Automation Administration Guide . the Active Directory KDC responds by sending the client a limited-lifetime (typically 10 hours) user credential. When a registered domain user logs into a client platform (Windows or UNIX). referred to as the Active Directory KDC. 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. Overview of AD/Kerberos 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.Overview of AD/Kerberos configuration tasks Distribution Center (KDC) as one of its default domain services. the login client sends a request to the Active Directory KDC for a Kerberos Ticket Granting Ticket (TGT). In this exchange. The following sections describe those configuration tasks. a Kerberos realm is an Active Directory domain. the Active Directory domain controller or Kerberos KDC mediates the authentication of the end user to the BMC BladeLogic Authentication Service. This credential consists of a service ticket to the ticket granting service (the Ticket Granting Ticket) and an associated ticket granting service session key. the Kerberos TGT is also referred to as the domain user credential. This Windows Server KDC. Upon successful Kerberos authentication of the end user. In Windows single sign-on.keytab file. In the context of Active Directory. Give this file and the SPN to the administrator of the Application Server hosting the BMC BladeLogic Authentication 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. After validating the request. the Authentication Service issues the authentication user interface a single sign-on credential. BMC BladeLogic end users can use their AD/Kerberos credentials to authenticate themselves to the BMC BladeLogic Authentication Service. it employs the end user's AD/Kerberos credentials to conduct a Kerberos protocol exchange with the Authentication Service.

conf file. C Locate the Active Directory KDC for the client’s realm. B Locate the Active Directory KDC for the service principal’s realm.keytab file in the correct directory.conf file. D Create a blclient_krb5. making sure each user name includes the user’s Active Directory domain (user@DOMAIN.COM).Overview of AD/Kerberos configuration tasks These tasks are described in detail in “Registering an Authentication Service in an Active Directory Domain” on page 180. C Create the blappserv_krb5.conf file. B Create the blclient_login. 3 On the BMC BladeLogic client: A Windows only: Update the Kerberos Registry Settings. These tasks are described in detail in “Configuring a BMC BladeLogic Client for AD/Kerberos authentication” on page 194. These tasks are described in detail in “Configuring an Authentication Service for AD/Kerberos authentication” on page 184. set up a Network Shell Proxy Server. F Add users to the BMC BladeLogic RBAC user database. G If you are using Network Shell to communicate directly with agents. 2 On the BMC BladeLogic Application Server: A Put the blauthsvc. G Create an authentication profile using AD/Kerberos authentication.conf file.properties file. E Update the config. F UNIX only: Obtain a ticket granting ticket (TGT) for the client. D Create the blappserv_login. Chapter 4 Administering security 179 . E Define Authentication Service settings to support AD/Kerberos.

Registering an Authentication Service in an Active Directory Domain

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

180

BMC BladeLogic Server Automation Administration Guide

Registering an Authentication Service in an Active Directory Domain

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.

Chapter 4

Administering security

181

Registering an Authentication Service in an Active Directory Domain

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/app4@SUB2.DEV.MYCOMPANY.COM -mapuser blauthsvc@SUB2.DEV.MYCOMPANY.COM +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

182

BMC BladeLogic Server Automation Administration Guide

Registering an Authentication Service in an Active Directory Domain

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 blauthsvc@SUB2.DEV.MYCOMPANY.COM -mapuser blauthsvc@SUB2.DEV.MYCOMPANY.COM +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.

Chapter 4

Administering security

183

Configuring an Authentication Service for AD/Kerberos authentication

The name of the domain (that is, the Kerberos realm) for the Application Server. For example:
SUB2.DEV.MYCOMPANY.COM

Configuring an Authentication Service for AD/Kerberos authentication
Use this procedure to configure a BMC BladeLogic Authentication Service so BMC BladeLogic users can authenticate using the AD/Kerberos user credentials. 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 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.

184

BMC BladeLogic Server Automation Administration Guide

Configuring an Authentication Service for AD/Kerberos authentication

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:
SUB2.DEV.MYCOMPANY.COM

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. 2 Do one of the following:

On a UNIX-style system, copy the file to the /NSH/br directory.

Chapter 4

Administering security

185

Configuring an Authentication Service for AD/Kerberos authentication

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. From a command line, enter the following:
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:
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 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.

186

BMC BladeLogic Server Automation Administration Guide

DEV.com = SUB2. For example: SUB2.MYCOMPANY.sub2.Configuring an Authentication Service for AD/Kerberos authentication 1 Create a text file like the following: [libdefaults] ticket_lifetime = 6000 default_realm = SERVICE_PRINCIPAL_REALM [realms] SERVICE_PRINCIPAL_REALM = { kdc = SERVICE_PRINCIPAL_REALM_KDC:88 } [domain_realm] .mycompany.conf Chapter 4 Administering security 187 .COM .dev.COM This is the value you got when you ran the nslookup command.sub1.COM SERVICE_PRINCIPAL_REALM_KDC is the host name for the Active Directory KDC for the realm where the keytab file was created.DEV.dev.DEV.dev.SERVICE_PRINCIPAL_DOMAIN = SERVICE_PRINCIPAL_REALM In this text file: SERVICE_PRINCIPAL_REALM is the realm where the keytab file was created.mycompany.COM .MYCOMPANY. In the “domain_realm” section.SUB2. save the file to the /NSH/br directory with the name: blappserv_krb5.mycompany. 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: . as described in “Locating the Active Directory KDC for the service principal’s domain” on page 186.MYCOMPANY. SERVICE_PRINCIPAL_DOMAIN provides DNS names.COM 2 Do one of the following: ■ On a UNIX-style system.com = SUB1.DEV.MYCOMPANY.com = DEV.MYCOMPANY. For example: kdc.

}. the file should be located as follows: /opt/bmc/BladeLogic/version/NSH/br/blappserv_krb5. The Application Server looks in the blappserv_login.module. if BMC BladeLogic is installed in the default location.conf Creating the blappserv_login.security.conf file to find the location of the keytab file.keytab" Be sure to use the double backslash syntax shown above.security. if BMC BladeLogic is installed in the default location.auth.keytab file on your system.jgss. the keyTab line would look like this: keyTab="C:\\Program Files\\BMC Software\\BladeLogic\\version\\NSH\\br\\ blauthsvc. the file should be located as follows: C:\Program Files\BMC Software\BladeLogic\version\NSH\br\ blappserv_krb5.conf ■ On Windows. assuming BMC BladeLogic is installed in the default location. 1 Create a text file and add the following content to it: com.conf For example. assuming BMC BladeLogic is installed in the default location. ■ On a UNIX-style system. In this text file.accept { com.conf file You must create a blappserv_login.sun. save the file to the \NSH\br directory with the name: blappserv_krb5. the keyTab line would look like this: keyTab="/opt/bmc/BladeLogic/version/NSH/br/blauthsvc. keyTab is the location of the blauthsvc.keytab" ■ On Windows. 188 BMC BladeLogic Server Automation Administration Guide .Configuring an Authentication Service for AD/Kerberos authentication For example.sun.Krb5LoginModule required useKeyTab=true keyTab="keytabFileLocation" storeKey=true principal="blauthsvc/instance@DOMAIN" doNotPrompt=true debug=false.conf file.

For example: principal="blauthsvc4@SUB2. You obtained the service principal name from the Active Directory administrator.DEV. principal is the service principal name for the Authentication Service.MYCOMPANY. the file should be located as follows: C:\Program Files\BMC Software\BladeLogic\version\NSH\br\ blappserv_login. you should enter a user principal name rather than a service principal name. use blauthsvc instead of blauthsvc/app4. enter the following: Chapter 4 Administering security 189 . you can use the klist utility to display them. For example: principal="blauthsvc/app4@SUB2. In other words. For example. save the file to the /NSH/br directory with the name: blappserv_login. if BMC BladeLogic is installed in the default location. the file should be located as follows: /opt/bmc/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. followed by the @ sign.conf.MYCOMPANY. followed by the Application Server’s domain. See “Using klist to read the keytab file” on page 189.DEV.Configuring an Authentication Service for AD/Kerberos authentication In the text file. if BMC BladeLogic is installed in the default location.COM" If you are using Windows 2008 without Service Pack 2. save the file to the \NSH\br directory with the name blappserv_login.conf. 1 Do one of the following: ■ On a UNIX-style system.COM" If you do not have the service principal name and the Application Server’s realm. 2 Do one of the following: ■ On a UNIX-style system.conf ■ On Windows. For example.

conf All UNIX platforms except Solaris: /etc/krb5. ■ On Windows.Configuring an Authentication Service for AD/Kerberos authentication utilityPath/klist -t -k /opt/bmc/BladeLogic/version/NSH/br/blauthsvc. There are many online sources for Kerberos utilities such as klist.conf file” on page 186.conf file. 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. assuming that BMC BladeLogic is installed in the default location.MYCOMPANY.COM The service principal name is blauthsvc/app4@SUB2.keytab" 2 The klist utility displays output similar to the following: Service principal: blauthsvc/app4@SUB2.COM. Verifying a keytab file Use this procedure to verify that the keytab file you have generated can be used to authenticate. 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 ■ 190 BMC BladeLogic Server Automation Administration Guide .DEV. This procedure is not essential.conf file you set up for the Authentication Server to one of the following locations: ■ Windows: %WINDIR%\krb5.MYCOMPANY. 1 Copy the blappserv_krb5.keytab In this command. you must first obtain it. utilityPath provides the path to the klist utility. see “Creating the blappserv_krb5.conf ■ ■ For more information on the blappserv_krb5.DEV. but BMC BladeLogic recommends performing this step to confirm that you have successfully set up authentication based on AD/Kerberos. If you do not have klist installed on a UNIX system.ini Solaris: /etc/krb5/krb5.

The variable keytabFile identifies the location of the keytab file you are generating. To perform this procedure. If this command runs successfully. For example. you must use the Application Server Administration console.MYCOMPANY. you should be able to authenticate with AD/ Kerberos. if you used the example names shown in “Sample domain structure” on page 171. from the directory where BMC BladeLogic is installed. If the command does not succeed. verify that the default_realm you have set up in blappserv_krb5. keytabFile is set to installDirectory/br. 1 Start the Application Server Administration console by doing one of the following: ■ On a UNIX-style system./bin/blasadmin Chapter 4 Administering security 191 . enter the following: .conf is correct.Configuring an Authentication Service for AD/Kerberos authentication In this command. you must first obtain it. There are many online sources for Kerberos utilities such as klist. For example. you must first obtain it. 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. Typically.COM. If you do not have kinit installed on a UNIX system. 3 Using the results of the previous step. utilityPath provides the path to the kinit utility. this command might identify a service principal called blauthsvc/ app4@SUB2. the keytab file for Windows would be C:\Program Files\BMC Software\BladeLogic\version\NSH\br\blauthsvc.DEV. The variable keytabFile identifies the location of the keytab file and servicePrincipal is the entity identified in 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. if BMC BladeLogic is installed in the default location. utilityPath provides the path to the klist utility. If you do not have klist installed on a UNIX system.keytab Running the klist command generates output that identifies the service principal.

By default AuthSvcKrb5Config is set to a value of blappserv_krb5.conf. — From the directory where BMC BladeLogic is installed. enter the following: set AuthServer AuthSvcKrb5Config fileName where fileName is the name of the blappserv_krb5. Cross-registration allows users to be authorized for RBAC roles. You can skip this step unless you choose to use a different file name. By default AuthSvcKrb5LoginConfig is set to a value of blappserv_login. This file is essential for supporting Kerberos.conf file. 192 BMC BladeLogic Server Automation Administration Guide .conf file. Cross-registering users in the BMC BladeLogic database Users must be registered in both Active Directory and BMC BladeLogic’s RBACbased user database. enter the following: set AuthServer AuthSvcKrb5LoginConfig fileName where fileName is the name of the blappserv_login.exe Both options run the same command. 5 Restart the Application Server (see “Restarting a specific Application Server” on page 111). select Programs => BMC Software => BladeLogic Server Automation Suite => Utilities => Application Server Administration.conf file.conf. enter the following: \bin\blasadmin. This file is essential for supporting Kerberos. 2 To enable Active Directory/Kerberos authentication.conf file.Configuring an Authentication Service for AD/Kerberos authentication ■ On Windows. You can skip this step unless you choose to use a different file name. 3 To enable the blappserv_krb5. do one of the following: — From the Start menu. enter the following: set AuthServer IsADKAuthEnabled true By default Active Directory/Kerberos authentication is not turned on. 4 To enable the blappserv_login.

For example. Chapter 4 Administering security 193 . For more information on this command.MYCOMPANY.MYCOMPANY. 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.COM).MYCOMPANY.COM.DEV. Each BMC BladeLogic user name must be in the form: USER@DOMAIN where DOMAIN is the domain the user is registered in. BMC BladeLogic documentation assumes you know how to add users to Active Directory. The user’s BMC BladeLogic user name must match the user’s fully qualified Active Directory user name. BMC BladeLogic provides a BLCLI command. Network Shell user names do not include domain information. RBACRole:syncUsers. that you can use to synchronize group information in Active Directory with role information in RBAC. Use RBAC to add users to the BMC BladeLogic database.DEV. For information on adding users to RBAC.COM rather than filling in the name field with a value such as: mary Note that the user name mary@SUB1.DEV.COM is a different user name than than mary or mary@SUB3. if you are using RBAC or the bladduser utility to add a new BMC BladeLogic user.DEV. 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 mary@SUB1. you would fill in the name field with a value such as: mary@SUB1.Configuring an Authentication Service for AD/Kerberos authentication Only users authorized to use BMC BladeLogic should be entered into the BMC BladeLogic database. see the BMC BladeLogic Server Automation User Guide.MYCOMPANY. see the BLCLI help. 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. Requirements for User Names When using AD/Kerberos to authenticate end users.

the user would also have to be registered in the Active Directory user registry for the domain SUB2. If the BMC BladeLogic administrator intends to support AD/Kerberos authentication exclusively and disable SRP user authentication.Configuring a BMC BladeLogic Client for AD/Kerberos authentication To avoid this problem and maintain communication with agents via Network Shell. the administrator should log in as a user authorized for the RBACAdmins role and ensure that each of the four built-in roles—RBACAdmins. you must use RBAC to add a fully qualified name to the GlobalReportViewers role. no user will be able to access the built-in roles. 194 BMC BladeLogic Server Automation Administration Guide . respectively.COM. To allow a user to log into the GlobalReportViewers role.DEV. prior to disabling SRP. Logging on using default users and roles The BMC BladeLogic user database comes pre-provisioned with two default SRP users: RBACAdmin and BLAdmin. which has built-in authorizations to see data for all BMC Service Automation Reporting and Analytics sites. then. In this example.MYCOMPANY. To allow a user to log into the GlobalReportAdmins role.COM) to the RBACAdmins role.DEV. the GlobalReportAdmins role. you must use RBAC to add a fully qualified user name to the BLAdmins role. when SRP authentication is disabled. you can simply assign a fully qualified domain user name (for example. set up a Network Shell Proxy Server. To allow a user to log into the BLAdmins role. The same issue applies to the BLAdmins role. RBACAdmin_ADK@SUB2. you must use RBAC to add a fully qualified user name to the GlobalReportAdmins role. and GlobalReportAdmins—has at least one registered domain user assigned to that role. Configuring a BMC BladeLogic Client for AD/Kerberos authentication 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. For more information. which has built-in authorizations to change permissions for all system objects in BMC BladeLogic. If you are using that default setup. GlobalReportViewers. and the GlobalReportViewers role. BLAdmins. Otherwise. see “Configuring the Network Shell Proxy Service” on page 142. which has read access to all reports at all sites in a BMC BladeLogic installation.MYCOMPANY. These default users are assigned to the default roles RBACAdmins and BLAdmins. the RBACAdmins role has the authorizations necessary to manage users and roles. In a default installation.

conf file” on page 196. 7 For UNIX clients. 8 Set up authentication profiles using AD/Kerberos authentication on the BMC BladeLogic client. For UNIX environments. See “Updating the config. The following is a master procedure.Configuring a BMC BladeLogic Client for AD/Kerberos authentication In addition to the procedures described here. 3 Create the blclient_login. skip this step. you must use UPPER CASE LETTERS. which provides essential Kerberos configuration information. See “Creating the blclient_krb5. See “Performing Windows-only client configuration tasks” on page 196. See “Locating the Active Directory KDC for the client’s domain” on page 197.properties file. each user must manually perform a kinit to obtain a ticketgranting ticket (TGT). Chapter 4 Administering security 195 .properties file” on page 200. For more information on defining authentication profiles. 6 Update the BMC BladeLogic config. 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.conf file” on page 198. the equivalent of a “kinit” is performed automatically. update registry settings and perform other configuration tasks. see the BMC BladeLogic Server Automation User Guide. 5 Create a blclient_krb5. See “Authentication profiles” on page 124 and the BMC BladeLogic Server Automation User Guide. a user must also define an authentication profile that calls for AD/Kerberos authentication. 4 Locate the Active Directory KDC for the client’s realm. This step provides information that is needed for subsequent steps in this procedure.conf file.conf file. which provides essential configuration data. Each of the steps in this procedure references a sub-section that describes another procedure. When a Windows user logs into the Active Directory. 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. See “Obtaining a TGT for a BMC BladeLogic client (UNIX only)” on page 201. NOTE When you specify a domain name in any of the following steps. 1 If you have not done so already. See “Creating the blclient_login.

It should be named allowtgtsessionkey and it should have a value of 1. Navigate to \HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\ Parameters. 4. 196 BMC BladeLogic Server Automation Administration Guide . Reboot the server. It should be named allowtgtsessionkey and it should have a value of 1. 2. 2. Windows XP 1. Open the Windows Registry Editor. This file provides necessary configuration information. It should be named allowtgtsessionkey and it should have a value of 1. Create a new registry value of type REG_DWORD. 4. Reboot the workstation. skip this section. This procedure is only necessary in Windows environments. Windows Vista 1. Do one of the following: Platform Windows 2003 and 2008 Actions 1. 3.conf file Use this procedure to create the blclient_login. Open the Windows Registry Editor.conf file. Open the Windows Registry Editor. 3. Create a new registry value of type REG_DWORD. Creating the blclient_login. Disable User Account Control (UAC). Navigate to \HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\ Parameters. 3. Create a new registry value of type REG_DWORD. Navigate to \HKLM\System\CurrentControlSet\Control\Lsa\Kerberos. 2. 5. If you are configuring a UNIX-style system.Configuring a BMC BladeLogic Client for AD/Kerberos authentication Performing Windows-only client configuration tasks Use this procedure to modify registry settings and perform other configuration tasks on Windows client machines.

the file should be located as follows: C:\Program Files\BMC Software\BladeLogic\version\NSH\br\ blclient_login. if BMC BladeLogic is installed in the default location. save the file to the \NSH\br directory with the name: blclient_login. From a command line.COM Chapter 4 Administering security 197 .conf ■ On Windows.module. }. For example. if BMC BladeLogic is installed in the default location. save the file to the /NSH/br directory with the name: blclient_login.initiate { com.DEV.conf. For example.SUB1.Configuring a BMC BladeLogic Client for AD/Kerberos authentication 1 Create a text file and add the following content to it: com. the file should be located as follows: /opt/bmc/BladeLogic/version/NSH/br/blclient_login.MYCOMPANY. For example: nslookup -type=srv _kerberos.conf._tcp.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. enter the following: nslookup -type=srv _kerberos.sun.security.CLIENT_DOMAIN where CLIENT_DOMAIN is the domain containing the user’s workstation where the client is running.jgss.security.Krb5LoginModule required doNotPrompt=true Debug=false useTicketCache=true. 2 Do one of the following: ■ On a UNIX-style system. You will need this host name later in the configuration process.auth._tcp.sun.

mycompany. For example: SUB1.SUB1.Configuring a BMC BladeLogic Client for AD/Kerberos authentication The Active Directory KDC’s host name is reported as the value of svr host name (Windows) or service (UNIX).DEV.sub1.conf file. This file provides necessary Kerberos configuration information.PARENT_DOMAIN = PARENT_REALM In this text file: CLIENT_DOMAIN is the realm containing the user’s workstation.DEV.MYCOMPANY. where the BMC BladeLogic client is running.conf file Use this procedure to create the blclient_krb5.com Ignore the numbers before the host name. Creating the blclient_krb5. For example: service = 0 100 88 kdc. 1 Create a text file like the following: [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 .dev.COM CLIENT_DOMAIN_KDC is the host name where the Active Directory server is running in your client’s realm.COM 198 BMC BladeLogic Server Automation Administration Guide . For example: kdc.MYCOMPANY.

save the file to the /NSH/br directory with the name: blclient_krb5. if BMC BladeLogic is installed in the default location. For example.COM 2 Do one of the following: ■ On a UNIX-style system.MYCOMPANY.dev.DEV.sub1. as described in “Locating the Active Directory KDC for the client’s domain” on page 197.conf ■ On Windows.DEV. 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.sub2.MYCOMPANY.COM SERVICE_PRINCIPAL_DOMAIN_KDC is the host name where the Active Directory server is running in the realm where the keytab file was created.mycompany.conf Chapter 4 Administering security 199 . save the file to the \NSH\br directory with the name blclient_krb5.MYCOMPANY.MYCOMPANY. the file should be located as follows: /opt/bmc/BladeLogic/version/NSH/br/blclient_krb5. In the “domain_realm” section. For example.COM .conf. as described in “Locating the Active Directory KDC for the service principal’s domain” on page 186.COM .dev.DEV. SERVICE_PRINCIPAL_DOMAIN is the realm where the keytab file was created.com = SUB2.mycompany. For example: SUB2.mycompany. For example: kdc.MYCOMPANY.SUB2.COM This is the value you obtained when you ran the nslookup command. if BMC BladeLogic is installed in the default location. SERVICE_PRINCIPAL_DOMAIN provides DNS names.conf. the file should be located as follows: C:\Program Files\BMC Software\BladeLogic\version\NSH\br\ blclient_krb5.DEV.Configuring a BMC BladeLogic Client for AD/Kerberos authentication This is the value you obtained when you ran the nslookup command.com = SUB1.dev.com = DEV. For example: .

Configuring a BMC BladeLogic Client for AD/Kerberos authentication NOTE If there is no direct trust between the two child domains.properties file on the BMC BladeLogic client.properties ■ Windows systems: C:\Program Files\BMC Software\BladeLogic\version\NSH\br\ config.COM.COM = { kdc = kdc. you must add additional DOMAINS to the [realms] section of the blclient_krb5. a copy of config.SUB1.DEV.properties When a user runs the console for the first time.COM = { kdc = kdc. 1 Open the config.DEV.conf file.COM:88 } Updating the config.MYCOMPANY.DEV. the [realms] section would look something like this: [realms] SUB1.MYCOMPANY. up the tree to the root domain and back down to the other child domain.MYCOMPANY.properties file. By default. In this case.COM:88 } DEV.MYCOMPANY.DEV.COM:88 } SUB2. using the examples in “Sample domain structure” on page 171.COM and SUB2.MYCOMPANY.DEV. These additional DOMAINS specify the explicit path you need to traverse from the first child domain.MYCOMPANY.properties file Use this procedure to modify the config.DEV.SUB2.MYCOMPANY.COM = { kdc = kdc. this file is initially stored in the following location: ■ UNIX-style systems: /opt/bmc/BladeLogic/version/NSH/br/config.properties is placed in the following user-specific location: ■ UNIX-style systems: userHomeDirectory /. assume that there is no direct trust between the child domains SUB1.properties 200 BMC BladeLogic Server Automation Administration Guide .bladelogic/config. For example.DEV.MYCOMPANY.

typically a TGT is valid for 10 hours. Entry java. Note that in either case you must use a backslash to escape the colon and backslash after the drive letter. C\:\\Program Files\\BMC Software\\BladeLogic\\version\\NSH\\br\\ blclient_krb5. you can use a backslash as a path separator but you must escape it with another backslash (such as. you should modify config. For Windows paths.properties in both locations—its initial location and in your own user-specific location. use forward slashes as path delimiters (such as.krb5. For Windows paths. Chapter 4 Administering security 201 . use forward slashes as path delimiters (such as.conf= javax.conf). The TGT is the AD/Kerberos user credential that domain users need to authenticate with the BMC BladeLogic Authentication Service. If an entry does not already exist in the config. Alternatively.conf).conf file. java. path is the full path to the blclient_krb5. Although the life span of a TGT is configurable. C\:\\Program Files/BMC Software/BladeLogic/ version/NSH/br/blclient_krb5.conf In this entry. a terminal server) and you have already run the BMC BladeLogic Console. 2 Set the following entries to the values shown below. this procedure is not necessary.properties If you are setting up an AD/Kerberos environment that many users are sharing (for example.conf file. C\:\\Program Files/BMC Software/BladeLogic/ version/NSH/br/blclient_login. you can use a backslash as a path separator but you must escape it with another backslash (such as.config= Value path/blclient_login. path is the full path to the blclient_login.security.security.security. Note that in either case you must use a backslash to escape the colon and backslash after the drive letter. path/blclient_krb5.Configuring a BMC BladeLogic Client for AD/Kerberos authentication ■ Windows systems: userHomeDirectory\Application Data\BladeLogic\config.auth.conf). add it at the end of the file. Alternatively.conf). If a user already has a valid TGT.useSubjectCredsOnly= false 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). C\:\\Program Files\\BMC Software\\BladeLogic\\version\\NSH\\br\\ blclient_login.auth.login.conf In this entry.properties file. This procedure must be performed every time a user needs a TGT on a UNIX client.

1 Copy blclient_krb5.conf. 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. If you are using a Windows client.conf. If your environment includes multiple Application Servers. and configure those agents or repeaters to authenticate incoming requests using client-side certificates.conf. skip this procedure. If you do not have kinit installed.conf to /etc/krb5. If you already use krb5. identified when you created the client’s blclient_krb5.conf with the contents of krb5. 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.Implementing security – Application Server to agents or repeaters This procedure is only necessary in UNIX-style environments. There are many online sources for Kerberos utilities such as kinit. you must first obtain it.conf.conf by renaming the copy of blclient_krb5. you should repeat this procedure for each Application Server.conf. 202 BMC BladeLogic Server Automation Administration Guide . then you must integrate the contents of blclient_krb5. run the following command: utilityPath/kinit userName In this command.conf file. If you are not already using krb5. 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. 2 To obtain a TGT. you can replace the existing version of krb5. utilityPath provides the path to the kinit utility.

Then add the passphrase for that certificate to the securecert file. If you want to stop using self-signed. WINDIR is typically winnt (on a Windows 2000 server) or windows.pem. client-side certificates. in BMC BladeLogic documentation a “client” refers to a host running the BMC BladeLogic Console or Network Shell. see “TLS with client-side certs – Discontinuing use of client-side certificates” on page 210. which contains the self-signed certificate for the Application Server and the private key associated with the certificate. See “Provisioning agents and repeaters with a SHA1 fingerprint of the Application Server’s self-signed certificate” on page 204.TLS with client-side certs – Securing a Windows Application Server Note that in the context of this section. See “Configuring agents or repeaters to authenticate incoming requests with client-side certificates” on page 206. 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. a “client” refers to an Application Server that is attempting to establish contact with the server hosting an agent. Each of the steps in this procedure references a sub-section that describes another procedure. Creating a self-signed client-side certificate on the Application Server Use this procedure to create a file called id. Generally. See “Creating a self-signed client-side certificate on the Application Server” on page 203. 3 Configure all targeted agents or repeaters to authenticate incoming requests using client-side certificates. The procedure for a Network Shell Proxy Server is identical to the procedure for an Application Server. 1 Create a self-signed. 3 Using a command line. generate a self-signed Application Server certificate by entering the following: Chapter 4 Administering security 203 . 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. client-side certificate on the Windows Application Server. In the path shown above. The following is a master procedure. 2 Provision all targeted agents or repeaters with an SHA1 fingerprint of the Application Server’s self-signed certificate. 2 Create a directory called C:\WINDIR\rsc\certs\SYSTEM.

To accomplish this. If you prematurely set the rscd entry in a secure file so that tls_mode=encrytion_and_auth.pem file is created in the C:\WINDIR\rsc\certs\SYSTEM directory. you can find the securecert file in the C:\WINDIR\rsc directory. use the command line to enter the following: secadmin -m default -cu SYSTEM -cp passPhrase After issuing this command. 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: 204 BMC BladeLogic Server Automation Administration Guide . you can find securecert in installDirectoryN\version\NSH\conf\securecert. on each managed server and repeater a file named SYSTEM. the default location for the second instance of BMC BladeLogic would be C:\Program Files\BMC Software\BladeLogic2\version\NSH. This passphrase is used to encrypt the private key in the id. you must ensure that the secure file on the agent or repeater is configured correctly. For example. The encoded passphrase will vary.TLS with client-side certs – Securing a Windows Application Server bl_gen_ssl -appcert After you enter the command. This file contains the SHA1 fingerprint of the Application Server’s self-signed certificate. The id. 1 Ensure that the secure file on all managed servers is configured so that tls_mode=encryption_only. 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. or update. the contents of the securecert file are updated to something like the following. Provisioning agents and repeaters with a SHA1 fingerprint of the Application Server’s self-signed certificate Use this procedure to create. 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. An agent or repeater uses this fingerprint to validate the selfsigned certificate received from the Application Server in the course of the TLS handshake. If necessary. [default] SYSTEM=FCUVOMLNGLVRZNOO For the initial installation of BMC BladeLogic. you are prompted to provide and then confirm a passphrase. 4 Update the securecert file to include an encoded copy of the passphrase. If additional instances of BMC BladeLogic are installed.pem file.

Chapter 4 Administering security 205 . you should provision each Application Server with its own self-signed certificate.pem file. To grant this privilege.TLS with client-side certs – Securing a Windows Application Server rscd:port=4750:protocol=5:tls_mode=encryption_only:encryption=tls This is the default setting after a fresh installation of an agent. all users accessing those agents will be mapped to root or Administrator. such as the IP address or host name of the Application Server. the fingerprint file for a Window Application Server is C:\Program Files\BMC Software\BladeLogic\version\RSCD\certs\ SYSTEM.agentN where agent1.. To provision an agent or repeater with the SHA1 fingerprint of an Application Server’s certificate. you should replace the host wildcard (“*”) with a more restrictive setting. On a Windows machine.. 4 Push the SHA1 fingerprint to managed servers by entering the following command: putcert SYSTEM id. you must have root or Administrator privileges on the server hosting the agent. on a UNIX machine. 5 Revert the setting in the exports file on managed servers back to a more restrictive user mapping. Otherwise.agentN is a space-delimited list of the host names or IP addresses of the managed servers hosting agents or repeaters.user=root To be safe. In environments where multiple Application Servers communicate with agents. This command creates or updates a fingerprint file on each targeted agent or repeater. 2 Set up root or Administrator privileges on each managed server hosting an agent. update the exports file on a Windows server by creating the following entry: * rw. update the exports file by creating the following entry: * rw.. Performing this procedure for each of those Application Servers generates multiple fingerprints in the SYSTEM file.user=Administrator On a UNIX server. cd to C:\WINDIR\rsc\certs\ SYSTEM. the fingerprint file for a Windows Application Server is /opt/bmc/BladeLogic/version/NSH/certs/SYSTEM. the directory containing the id. 3 Using a command line on the Application Server..pem agent1. so in most situations there is no need to perform this step.

The procedure for a Network Shell Proxy Server is identical to the procedure for an Application Server. in BMC BladeLogic documentation a “client” refers to a host running the BMC BladeLogic Console or Network Shell. This setting requires client authentication via clientside certificates. client-side certificate for a UNIX-based Application Server. client-side certificates. the secure files on those agents must be updated so tls_mode=encryption_and_auth. TLS with client-side certs – Securing a UNIX-based Application Server Use this procedure to generate a self-signed. To modify the rscd entry in the secure file on each targeted agent. Each of the steps in this procedure references a sub-section that describes another procedure. 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. a “client” refers to an Application Server that is attempting to establish contact with the server hosting an agent. provision all targeted agents or repeaters with an SHA1 fingerprint of the Application Server’s self-signed certificate.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. see “TLS with client-side certs – Discontinuing use of client-side certificates” on page 210. 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. This section is intended for administrators of BMC BladeLogic Application Servers. 206 BMC BladeLogic Server Automation Administration Guide . Generally. If you want to stop using self-signed. Note that in the context of this section. and configure those agents or repeaters to authenticate incoming requests using client-side certificates. The following is a master procedure.

2 Enter the following command: /opt/bmc/BladeLogic/version/NSH/bin/bl_gen_ssl After entering the command. which contains the self-signed certificate for the Application Server and the private key associated with the certificate.pem file or the .bladmin This command logs you in as the bladmin user.TLS with client-side certs – Securing a UNIX-based Application Server 1 Create a self-signed client-side certificate on the UNIX Application Server. In UNIX the Application Server runs as the bladmin user. and then enter the following command: su . The id.bladelogic directory. This passphrase is used to encrypt the private key in the id. 3 Configure all targeted agents or repeaters to authenticate incoming requests using client-side certificates. To accomplish this. you are prompted to provide and then confirm a passphrase. See “Configuring agents or repeaters to authenticate incoming requests with client-side certificates” on page 209.pem file is created in the bladminUserHome/. Then add the passphrase used to encrypt the private key to the securecert file on the Application Server. 2 Provision all targeted agents or repeaters with an SHA1 fingerprint of the Application Server’s self-signed certificate.pem file. See “Provisioning agents and repeaters with a SHA1 fingerprint of the Application Server’s self-signed certificate” on page 208. where the id. 3 Enter exit to revert back to the root user.bladelogic directory. Creating a self-signed client-side certificate on the Application Server Use this procedure to create a file called id. Then add the passphrase for that certificate to the securecert file.pem. use Network Shell to enter the following: secadmin -m default -cu bladmin -cp passPhrase Chapter 4 Administering security 207 . 4 Update the securecert file (contained in the /usr/lib/rsc directory) to contain an encoded copy of the passphrase.pem file is generated. See “Creating a selfsigned client-side certificate on the Application Server” on page 207. 1 Log into the UNIX system on the Application Server as root. BMC BladeLogic will not load the certificate if group or world permissions are set for the id.

the contents of the securecert file are updated to something like the following. on each managed server or repeater a file named bladmin. 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. This file contains the SHA1 fingerprint of the Application Server’s self-signed certificate.bladelogic chmod 600 /opt/bmc/BladeLogic/version/NSH/br/. [default] bladmin=FCUVOMLNGLVRZNOO 5 Ensure that access is restricted to the id.TLS with client-side certs – Securing a UNIX-based Application Server After issuing this command. you must ensure that the secure file on the agent or repeater is configured correctly.bladelogic/id. 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: rscd:port=4750:protocol=5:tls_mode=encryption_only:encryption=tls This is the default setting after a fresh installation of an agent. 2 Set up root or Administrator privileges on each managed server hosting an agent.pem Provisioning agents and repeaters with a SHA1 fingerprint of the Application Server’s self-signed certificate Use this procedure to create. or update. 208 BMC BladeLogic Server Automation Administration Guide . If you prematurely set the rscd entry in a secure file so that tls_mode=encrytion_and_auth. An agent or repeater uses this fingerprint to validate the selfsigned certificate received from the Application Server in the course of the TLS handshake.bladelogic directory by running the following commands: chmod 700 /opt/bmc/BladeLogic/version/NSH/br/. 1 Ensure that the secure file on all managed servers is configured so that tls_mode=encryption_only. The encoded passphrase will vary. 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. If necessary.pem file and the . so in most situations there is no need to perform this step.

you should provision each Application Server with its own self-signed certificate.bladelogic. the directory containing the id. On a Windows machine.user=root To be safe. 5 Revert the setting in the exports file on managed servers back to a more restrictive user mapping. update the exports file on a Windows server by creating the following entry: * rw. on a UNIX machine.TLS with client-side certs – Securing a UNIX-based Application Server To provision an agent or repeater with the SHA1 fingerprint of an Application Server’s certificate. This command creates or updates a fingerprint file on each targeted agent or repeater.user=Administrator On a UNIX server. update the exports file by creating the following entry: * rw.. the fingerprint file for a Window Application Server is C:\Program Files\BMC Software\BladeLogic\version\RSCD\certs\ bladmin. you must have root or Administrator privileges on the server hosting the agent. you should replace the host wildcard (“*”) with a more restrictive setting. In environments where multiple Application Servers communicate with agents. Otherwise. such as the IP address or host name of the Application Server. all users accessing those agents will be mapped to root or Administrator. To grant this privilege.pem file. 4 Push the SHA1 fingerprint to managed servers by entering the following command: /opt/bmc/BladeLogic/version/NSH/sbin/putcert bladmin id. cd to /opt/bmc/BladeLogic/version/ NSH/br/.. the fingerprint file for a Windows Application Server is /opt/bmc/BladeLogic/version/NSH/certs/bladmin. 3 Using a command line on the 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 Chapter 4 Administering security 209 .agentN is a space-separated list of the host names or IP addresses of the managed servers hosting agents or repeaters. Performing this procedure for each of those Application Servers generates multiple fingerprints in the bladmin file.agentN where agent1.pem agent1..

update the exports file by creating the following entry: * rw.user=root To be safe. 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. you must have root or Administrator privileges on any servers hosting agents or repeaters where you want to discontinue use of clientside certificates. 210 BMC BladeLogic Server Automation Administration Guide . To grant this privilege.agentN where SYSTEM|bladmin is SYSTEM for a Windows Application Server or bladmin for a UNIX Application Server and agent1. 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. This setting requires client authentication via clientside certificates. To perform this procedure... the secure files on those agents must be updated so tls_mode=encryption_and_auth. you may want to replace the host wildcard (“*”) with the IP address or host name of the Network Shell client.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.. To modify the rscd entry in the secure file on each targeted agent. 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.TLS with client-side certs – Discontinuing use of client-side certificates After agents are provisioned with the SHA1 fingerprint of an Application Server’s self-signed certificate.user=Administrator On a UNIX server. update the exports file on a Windows server by creating the following entry: * rw.. 1 Set up root or Administrator privileges on each managed server hosting an agent or repeater.

For more information on using the exports file. the SYSTEM directory can be found at C:\ WINDIR\rsc\certs\SYSTEM. Otherwise. Implementing security – Network Shell to agent This section provides procedures to secure access between Network Shell clients and servers hosting RSCD agents.bladelogic directory for UNIX Application Servers. 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.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: secadmin -m rscd -p 5 -T encryption_only -e tls Running this command generates an rscd entry in the secure file like the following: rscd:port=4750:protocol=5:tls_mode=encryption_only:encryption=tls 4 Revert the setting in the exports file on managed servers back to a more restrictive user mapping. 5 Remove certificates from Application Servers by deleting the SYSTEM directory for Windows Application Servers or the . the bladmin directory can be found at /opt/bmc/ BladeLogic/version/NSH/br/. see “Exports file” on page 240. For Windows Application Servers. all users accessing those agents will be mapped to root or Administrator. Chapter 4 Administering security 211 .bladelogic. For UNIX Application Servers. Typically administrators use the exports file to limit Network Shell client access to agents by restricting access to certain client IP addresses.

That file contains the client’s digital certificate and the corresponding private key. For more information. see “Discontinuing use of client-side certificates” on page 216. During the TLS handshake.pem file or the . which is encrypted using a password supplied when the self-signed certificate is created. NOTE The machine where you are creating a certificate must have the capability to generate random numbers.TLS with client-side certs – Securing a Network Shell client TLS with client-side certs – Securing a Network Shell client Use this procedure to generate a self-signed. This procedure creates a file on the client called id. Later in this procedure you will change the tls_mode setting. and configure those agents to authenticate incoming requests using client-side certificates. BMC BladeLogic will not load the certificate if group or world permissions are set for the id. 1 Ensure that the secure file is configured correctly on all agents where you want to set up secure access. provision all targeted agents with an SHA1 fingerprint of the self-signed certificate.pem file (certificate and corresponding private key) and the agents uses the SHA1 fingerprint. The installation program also allows you to install a daemon or create a random number seed that BMC BladeLogic uses for generating random numbers. On UNIX machines running Network Shell clients. At this point in the procedure the rscd entry in the secure file should be set to tls_mode=encryption_only.bladelogic directory. the client uses the contents of the id. The SHA1 fingerprint is written into fingerprint files on the agents. client-side certificate for a Windows Network Shell client.pem. Then this procedure calculates the SHA1 fingerprint of the client certificate and pushes it to targeted agents using the putcert utility. If you want to stop using self-signed. see the BMC BladeLogic Server Automation User Guide.pem file is generated. so in many situations there is no need to perform this step. The BMC BladeLogic installation program for the Application Server tests whether a machine has the capability to generate random numbers. where the id. generate this setting by running the following secadmin command on each agent: secadmin -m rscd -p 5 -T encryption_only -e tls This is the default setting after a fresh installation of an agent. If necessary. client-side certificates. 2 Set up root or Administrator privileges on each managed server hosting an agent. 212 BMC BladeLogic Server Automation Administration Guide .

pem is stored in /userHomeDirectory /. id. In UNIX.user=Administrator On a UNIX server. Then confirm the passphrase by entering it again. where userHomeDirectory is the user’s home directory.pem. you must have root or Administrator privileges on the server hosting the agent. To grant this privilege.pem file and the .pem is stored.pem agent1 .pem file.TLS with client-side certs – Securing a Network Shell client To provision an agent with the SHA1 fingerprint of a client’s certificate.bladelogic chmod 600 /home/userName/.. agentN is a space-delimited list of the names or IP addresses of the servers to which you want to push the certificate. generate a self-signed certificate by entering the following: bl_gen_ssl 4 Enter a passphrase. such as /home/userName. update the exports file on a Windows server by creating the following entry: * rw. 3 Using a command line on the Network Shell client. 6 For UNIX machines running Network Shell clients.pem 7 Push the SHA1 fingerprint of the self-signed certificate to managed servers by entering the following command: putcert userName id.. update the exports file by creating the following entry: * rw. id.. Chapter 4 Administering security 213 .. where userProfileDirectory specifies a path such as /Documents and Settings/userName. ensure that access is restricted to the id. BMC BladeLogic generates a self-signed certificate in a file named id. The passphrase is used to encrypt the private key in the id. 5 Cd to the directory where id.bladelogic. In Windows.user=root To be safe.pem is stored in /userProfileDirectory/Application Data /BladeLogic.bladelogic directory by running the following commands: chmod 700 /home/userName/. you should replace the host wildcard (“*”) with the IP address or host name of the Network Shell client. agentN where userName is the name of the user who created the certificate and agent1 .bladelogic/id.

Caching private keys A client certificate and its associated private key (that is. The procedure is the same as the procedure for Application Servers. You can also use these procedures to set up client-side certificates on Network Shell Proxy Servers. When an id. the contents of the id. This step sets tls_mode=encryption_and_auth on the targeted agents. On a UNIX agent. 214 BMC BladeLogic Server Automation Administration Guide . Network Shell decrypts and caches your private key. C:\Program Files\BMC Software\BladeLogic\version\RSCD\certs \userName is the fingerprint file. To keep private keys safe. 10 If you plan to use Network Shell to run non-interactive tools such as the BLCLI. 8 Modify the rscd entry in the secure file on each targeted agent by entering the following secadmin command: secadmin -m rscd -p 5 -T encryption_and_auth -e tls NOTE Performing this step could have implications for Application Servers or Network Shell Proxy Servers when they communicate with the same targeted agents. see “Caching private keys” on page 214. you should cache your private key for your client-side certificate. BMC BladeLogic provides a password mechanism. If the private key in the id. making it available to any command running under the shell. 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. 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.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. On a Windows agent. anyone gaining access to the file can assume the identity of the user named in the certificate.TLS with client-side certs – Securing a Network Shell client This command creates or updates a fingerprint file on each targeted agent. When you start Network Shell. Because each Network Shell session requires knowledge of the private key password.pem file is not password-protected. For more information. the private key is encrypted using the password you provide when you run the bl_gen_ssl utility. all users accessing those agents will be mapped to root or Administrator. Once you provide the password. For information on setting up client-side certificates on these entities.pem file is generated. the system prompts you for your private key password. 9 Revert the setting in the exports file on managed servers back to a more restrictive user mapping. which means these agents will require Application Servers or Network Shell Proxy Servers to also use client-side certificates. Otherwise. /opt/bmc/BladeLogic/version/ NSH/certs/userName is the fingerprint file.

right-click the BMC BladeLogic icon in the system tray and select Exit from the pop-up menu. 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. To avoid this. NOTE This command must be run in the foreground because it prompts for a password. enter the following command: bltray -blkey A dialog prompts for your private key password. The command will spawn a new process that will remain in the background to cache the password in a shared memory segment. 2 Enter the password. Activating the private key cache in UNIX 1 On the Network Shell client. Network Shell only prompts for the password when you start the new session. Activating the private key cache in Windows 1 From a Windows command line. bl_ssl_agent --background The system prompts for your private key password. 2 Enter the password and click OK. exit Network Shell. enter the following command. create the certificate. The BMC BladeLogic icon displays in the system tray on the task bar. Chapter 4 Administering security 215 . and then start Network Shell again. indicating the private key password is shared.TLS with client-side certs – Securing a Network Shell client 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. 3 To stop sharing the password.

user=root To be safe. To perform this procedure. you may want to replace the host wildcard (“*”) with the IP address or host name of the Network Shell client.... self-signed certificate from managed servers by entering the following command: nukecert userName agent1. 1 Set up root or Administrator privileges on each managed server hosting an agent.agentN where userName is the name of the user who created the certificate and agent1. 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. update the exports file on a Windows server by creating the following entry: * rw.user=Administrator On a UNIX server. 3 To reuse this shared memory segment with Network Shell. 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 grant this privilege.agentN is a space-delimited list of the names or IP addresses of the servers where you want to stop using certificates. This shared memory segment is only usable by the person who ran bl_ssl_agent. bl_ssl_agent runs in the background with the password cached in a shared memory segment. 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: 216 BMC BladeLogic Server Automation Administration Guide .TLS with client-side certs – Securing a Network Shell client After entering your password. update the exports file by creating the following entry: * rw.. you must have root or Administrator privileges on any servers hosting agents where you want to discontinue use of client-side certificates. 2 Remove the SHA1 fingerprint of a client-side.

you must perform this procedure for the BladeLogicRSCD user. Typically. client-side certificate for a repeater. you must perform this procedure for every user to whom connecting users are mapped.pem is stored in /userProfileDirectory/Application Data /BladeLogic. The following is a master procedure. On Windows. Each of the steps in this procedure references a sub-section that describes another procedure.bladelogic. such as /home/userName. see “Discontinuing use of client-side certificates” on page 222. client-side certificates. all users accessing those agents will be mapped to root or Administrator. In UNIX. 5 Remove certificates from clients by deleting the id. where userProfileDirectory specifies a path such as /Documents and Settings/userName. id.Implementing Security – Repeater to agent secadmin -m rscd -p 5 -T encryption_only -e tls Running this command generates an rscd entry in the secure file like the following: rscd:port=4750:protocol=5:tls_mode=encryption_only:encryption=tls NOTE Performing this step could have implications for Application Servers or Network Shell Proxy Servers when they communicate with the same targeted agents. users are mapped to root but mapping to other user names is possible. In Windows. which means these agents will not require Application Servers or Network Shell Proxy Servers to also use client-side certificates. Otherwise. and configure those agents to authenticate incoming requests using clientside certificates. If you want to stop using self-signed. provision all targeted agents with an SHA1 fingerprint of the repeater’s self-signed certificate. This step sets tls_mode=encryption_only on the targeted agents. Chapter 4 Administering security 217 . 4 Revert the setting in the exports file on managed servers back to a more restrictive user mapping. Implementing Security – Repeater to agent Use this procedure to generate a self-signed.pem is stored in /userHomeDirectory /.pem file. On UNIX repeaters. id. where userHomeDirectory> is the user’s home directory.

Create a directory called C:\WINDIR\rsc\certs\BladeLogicRSCD. 3 Configure all targeted agents to authenticate incoming requests using client-side certificates. In the path shown above. client-side certificate on the repeater. Log into the Application Server as Administrator. C. Then. See “Configuring agents to authenticate incoming requests with clientside certificates” on page 221.pem file or the .bladelogic directory. Then confirm the passphrase by entering it again. WINDIR is typically winnt (on a Windows 2000 server) or windows. and then add the passphrase for that certificate to the securecert file. where the id. 4 Using a command line. log into the repeater as a user to whom connecting users are mapped (typically root). issue the following command for generating a certificate: bl_gen_ssl ■ On Windows. 2 Provision all targeted agents with an SHA1 fingerprint of the repeater’s self-signed certificate. 218 BMC BladeLogic Server Automation Administration Guide . do the following: A.Creating a self-signed client-side certificate on the repeater 1 Create a self-signed. B. See “Creating a self-signed client-side certificate on the repeater” on page 218. 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.pem file is generated. On UNIX repeaters. See “Provisioning agents with an SHA1 fingerprint of the repeater’s self-signed certificate” on page 219. Enter the following command for generating a certificate: bl_gen_ssl -repeatcert 5 Enter a passphrase for the private key to the certificate. generate a self-signed certificate by doing one of the following: ■ On UNIX-style systems. BMC BladeLogic will not load the certificate if group or world permissions are set for the id.

bladelogic. such as root or BladeLogicRSCD. the file is created in WINDIR\rsc\certs\BladeLogicRSCD. ensure that access is restricted to the id. After issuing this command.bladelogic/id. On Windows.pem Provisioning agents with an SHA1 fingerprint of the repeater’s self-signed certificate Use this procedure to provision managed servers with the SHA1 fingerprint of the repeater’s self-signed certificate. For example. the file is created in userHomeDirectory /. The secadmin utility encrypts the password. Enter the password in clear text. On UNIX.pem.) [default] BladeLogicRSCD=FCUVOMLNGLVRZNOO 7 For UNIX repeaters. id.pem file and the .. if you are logged in as root. this command might create an entry like the following.pem is created in /root/. Using Network Shell. (The encoded passphrase will vary. Chapter 4 Administering security 219 . An agent uses this fingerprint to validate the selfsigned certificate received from the repeater in the course of the TLS handshake.Provisioning agents with an SHA1 fingerprint of the repeater’s self-signed certificate BMC BladeLogic generates a certificate in a file named id.bladelogic/id. the contents of the securecert file are updated to include an entry for your current user name.bladelogic directory by running the following commands: chmod 700 /opt/bmc/BladeLogic/version/NSH/br/. where WINDIR is typically windows or winnt. 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. For example. 6 Update the securecert file to contain an encoded copy of the passphrase.bladelogic chmod 600 /opt/bmc/BladeLogic/version/NSH/br/. where userHomeDirectory is the user’s home directory.pem.

you must ensure the secure file on the agent is configured correctly.user=Administrator On a UNIX server.bladelogic/id. you must have root or Administrator privileges on the server hosting the agent. you may want to replace the host wildcard (“*”) with the IP address or host name of the Application Server. To grant this privilege. update the exports file on a Windows server by creating the following entry: * rw.pem resides in userHomeDirectory/. If necessary. id. 220 BMC BladeLogic Server Automation Administration Guide .user=root To be safe. the agent will refuse the incoming connection because it will not have the SHA1 fingerprint of the repeater’s self-signed cert. On Windows. If you prematurely set the rscd entry in an agent's secure file so that tls_mode=encrytion_and_auth. so in most situations there is no need to perform this step. where userHomeDirectory is the user’s home directory. id. To provision an agent with the SHA1 fingerprint of an Application Server’s certificate.pem is created at /root/. 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 an agent with the fingerprint of the repeater’s certificate. id. 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: rscd:port=4750:protocol=5:tls_mode=encryption_only:encryption=tls This is the default setting after a fresh installation of an agent.pem is stored. update the exports file by creating the following entry: * rw..pem resides in WINDIR\rsc\certs\BladeLogicRSCD. 3 Cd to the directory on the repeater where id.pem. On UNIX-style servers. For example.bladelogic. 2 Set up root or Administrator privileges on each managed server hosting an agent.Provisioning agents with an SHA1 fingerprint of the repeater’s self-signed certificate 1 Ensure that the secure file on all managed servers is configured so that tls_mode=encryption_only. where WINDIR is typically windows or winnt. if you are logged in as root.

pem file for root in a file called root. When you issue the putcert command.pem agent1.pem file for BladeLogicRSCD in a file called BladeLogicRSCD..agentN is a space-separated list of the host names or IP addresses of the managed servers hosting agents. BMC BladeLogic places the SHA1 fingerprint of the id. Otherwise. 5 Revert the setting in the exports file on managed servers back to a more restrictive user mapping. agent1.agentN where. To modify the rscd entry in the secure file on each targeted agent. use Network Shell to enter the following: putcert user id. This setting requires client authentication via clientside certificates.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. the secure files on those agents must be updated so tls_mode=encryption_and_auth. Configuring agents 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. all users accessing those agents will be mapped to root or Administrator. use Network Shell to enter the following secadmin command: secadmin -m rscd -p 5 -T encryption_and_auth -e tls Chapter 4 Administering security 221 . 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... The file resides in the /nsh/certs directory on UNIX-style servers and in \rsc\certs on Windows. It places the SHA1 fingerprint of the id.

which means these agents will not require Application Servers or Network Shell Proxy Servers to also use client-side certificates. you must have root or Administrator privileges on any servers hosting agents where you want to discontinue use of client-side certificates. you should replace the host wildcard (“*”) with a more restrictive setting. update the exports file by creating the following entry: * rw. To grant this privilege. If other UNIX users have fingerprints on the agent. you must remove those user names as well.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. This step sets tls_mode=encryption_only on the targeted agents. 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: secadmin -m rscd -p 5 -T encryption_only -e tls Running this command generates an rscd entry in the secure file like the following: rscd:port=4750:protocol=5:tls_mode=encryption_only:encryption=tls NOTE Performing this step could have implications for Application Servers or Network Shell Proxy Servers when they communicate with the same targeted agents.Discontinuing use of client-side certificates Discontinuing use of client-side certificates Use this procedure to stop using client-side certificates that secure access between repeaters and agents. such as the IP address or host name of the Network Shell client. In the command shown above agent1..agentN where user is BladeLogicRSCD for a Windows repeater and typically root for a UNIX repeater.user=Administrator On a UNIX server. use Network Shell to enter the following: nukecert user agent1.. To accomplish this. update the exports file on a Windows server by creating the following entry: * rw.user=root To be safe. 1 Set up root or Administrator privileges on each managed server hosting an agent.. 222 BMC BladeLogic Server Automation Administration Guide . To perform this procedure. 2 Remove the SHA1 fingerprint of the repeater’s self-signed certificate from managed servers..

all users accessing those agents will be mapped to root or Administrator.Using certificates to secure communication between clients and Application Servers 4 Revert the setting in the exports file on managed servers back to a more restrictive user mapping. where userHomeDirectory is the user’s home directory. For example.bladelogic/id. However. 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. Otherwise. see “Generating a selfsigned certificate for an Application Server” on page 223. you may need to manually generate a self signed certificate for an Application Server. For more information on that procedure.bladelogic. In some situations. see “Securing communication with CA certificates” on page 224. the id. 5 Remove certificates from repeaters by deleting the id.pem file resides in WINDIR\rsc\certs\BladeLogicRSCD. On UNIX-style servers. if you are logged in as root..pem resides in /root/. For more information on that procedure. 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.pem.pem file storing the certificate. you may choose to provision Application Servers with a CA-issued certificate or certificate chain. The certificate will be valid for three years. and it will be stored under the “blade” alias. the id.pem file resides in userHomeDirectory/. 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. id. where WINDIR is typically windows or winnt. Chapter 4 Administering security 223 . On Windows.

keystore" ******** 2 If you are using a multi-Application Server environment. do not provision the Application Server with a certificate that includes an OCSP URL. When you perform this procedure. A trust store only contains certificates.Securing communication with CA certificates ■ jksFileName—The path to the keystore you are generating. 1 Obtain a certificate chain from a certificate authority. see “Importing CA-issued certificates into clients” on page 226. If a new password is needed. 224 BMC BladeLogic Server Automation Administration Guide . If you do not want clients to verify a certificate’s revocation status. For information on this process. After you provision Application Servers with CA-issued certificates. For more information on that procedure. password—A password used to encrypt the generated keystore file. Securing communication with CA certificates When you install an Application Server. you should import those certificates into client trust stores. the installation procedure provisions the Application Server with a self-signed certificate. ■ For example. some organizations may choose to use a CA-issued certificate or certificate chain rather than the default selfsigned certificate. copy the JKS file you generated in step 1 from this Application Server to all cooperating Application Servers. However. you set up a keystore that takes the place of the bladelogic. This file should be stored in the /deployments directory for the Application Server that is being updated. if you are generating a self-signed certificate on a Windows server called winappserver1.) If the certificate you are importing includes a URL for an OCSP Responder. update the password for each cooperating Application Server. see “Synchronizing keystore files of multiple Application Servers” on page 58. the client will attempt to verify the revocation status of the Application Server’s certificate. (A keystore contains certificates and a private key. 2 Import the certificate and its corresponding private key into a keystore file on the Application Server. such as installDirectory/br/deployments/_template.keystore created automatically when you install the Application Server. you might enter a command like the following: blmkcert CN=winappserver1 "C:\Program Files\BMC Software\BladeLogic\version\ NSH\br\deployments\_template\bladelogic.

such as installDirectory/br/deployments/_template. This is the password used to encrypt the keystore. see “Synchronizing keystore files of multiple Application Servers” on page 58. If your CA cannot create a JKS file and instead provides you with a PKCS12 file. 3 If you are using a multi-Application Server environment. the alias you use to identify the certificate must be blade and the format of the keystore must be jks. pkcs12Alias is the alias under which the certificate and private key are stored. you must convert your certificates and private keys into JKS. If you are importing a certificate with the Authentication Server’s version of keytool.p12 -destkeystore bladelogic. For example. update the password for each cooperating Application Server. you are prompted for a destination keystore password. The command shown above also prompts you for the source keystore password. This file should be stored in the /deployments directory for the Application Server that is being updated. bladelogic. which is the password originally used to create the PCKS12 file. which is available on any machine where the Authentication Server is installed. you might enter a command like the following: installDirectory/jre/bin/keytool -importkeystore -srckeystore bladelogic. If a new password is needed. When you enter the command shown above. copy the JKS file you generated in step 2 from this Application Server to all cooperating Application Servers.keystore -srcstoretype pkcs12 -deststoretype jks -srcalias pkcs12Alias -destalias blade In this command bladelogic.Securing communication with CA certificates Ideally. your certificate authority should create a certificates and private keys and output them using the JKS format. Chapter 4 Administering security 225 . When you use the blasadmin utility to set up keystores for cooperating Application Servers (described in the next step) you must provide this password.keystore is the name of the keystore file you are creating. There are various tools for performing this type of conversion.p12 is the file being imported. For information on this process. NOTE No matter what method you use to import the certificate. you can use Java’s keytool utility.

but performing it configures the client so it communicates more securely with the Application Server. 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. a user must provide an authentication profile. This functionality is equivalent to the default approach for BMC BladeLogic. This session credential can be stored in a credential cache file. user name. the certificate that you import into the client’s trust store should be the issuing certificate for the top of the certificate chain. you are prompted to trust the certificate. you should import a related certificate into the client’s trust store. you must install the BMC BladeLogic Console. which uses self-signed certificates. On Windows.bladelogic/ client_keystore. 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. To log into a BMC BladeLogic system. 226 BMC BladeLogic Server Automation Administration Guide . session credentials. this command imports the certificate to userHomeDirectory/. and password. or it could be a CA’s certificate that can be used to verify the validity of the Application Server’s certificate.PEM.PEM. Using the blcred utility The blcred utility manages authentication profiles. On UNIX.pkcs12. Once the Authentication Service validates a user. If you do not perform this procedure. The authentication profile specifies a BMC BladeLogic Authentication Service and the mechanism that should be employed to authenticate the user.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). If the Application Server is provisioned with a certificate chain. This procedure is not essential. The related certificate should be the issuing certificate for the Application Server’s certificate. This file could be the Application Server’s certificate file. and trusted certificates.pkcs12. when you establish a connection to the Application Server. This file must use the PEM or DER format. this command imports the certificate to C:\Documents and Settings\ user\Application Data\BladeLogic\client_keystore. To use blcred. the Authentication Service issues a session credential.

509 certificates are used when establishing a TLS connection to an LDAP server. — AD/Kerberos—The blcred utility retrieves the AD/Kerberos user credential from the host system's AD/Kerberos credential store. — Domain Authentication—User name (in the form user@KRBDOMAIN.509 certificates. — PKI—Insert a smart card into a smart card reader and provide the appropriate PIN for that smart card. an established client/ server session can continue even though the session credential used to establish that session has expired. BMC BladeLogic client applications can use a cached session credential when the owner of the credential cache file invokes the client application. ■ ■ Test whether a valid session credential already exists and determine the lifetime remaining for that credential. — LDAP—distinguished name and password. or Network Shell Proxy Server. add. — SecurID—user name and passcode (PIN plus token code). 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. X.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. After a session credential has expired. as described below: — SRP—user name and password. However. and delete trusted X. BMC BladeLogic users can log on and acquire session credentials using the BMC BladeLogic Console or blcred command line utility. On clients. Session credentials have a finite lifetime. You must insert the smart card before you can use blcred to run the acquire command to obtain a session credential. X. On Application Servers.COMPANY. add. import.509 certificates are used when establishing a TLS connection to an Authentication Service. and delete authentication profiles. When operating in a command line environment. Review. Application Server. ■ ■ Chapter 4 Administering security 227 . Review. it cannot be used to establish a client/server session.COM) and password. users do not explicitly use the command line interface to provide AD/Kerberos credentials.

refer to the man page for blcred. which means a valid session credential does exist for MyProfile. 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. 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. If this command is successful. run the following command: blcred cred -acquire 228 BMC BladeLogic Server Automation Administration Guide . enter a command like the following: blcred cred -test -profile MyProfile -time 500 where 500 is a remaining lifetime in minutes. it generates a return code of 0. Typical scenarios The following sections describe some typical scenarios for using blcred. 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. it generates a return code of 0.Options Options For a complete description of all available command line options. To determine whether a credential's remaining lifetime exceeds a specified number of minutes. If this command is successful.

$ blcred cred -acquire profile name: srpProfile username: BLAdmin password ****** Authentication succeeded: acquired session credential If you are using AD/Kerberos authentication. it retrieves the user’s Kerberos credential from the host operating system’s AD/Kerberos credential cache. Alternatively. you can direct blcred to obtain a session credential. (Alternatively. and you are using SRP authentication. blcred cred -acquire -profile srpProfile -username BLAdmin -password ****** Chapter 4 Administering security 229 .dat Obtaining a session credential using SRP authentication profile If you are running Network Shell or the BLCLI in batch mode. you must enter a profile name that calls for AD/Kerberos authentication. user name and password if the named profile specifies SRP authentication. as described in “Obtaining a TGT for a BMC BladeLogic client (UNIX only)” on page 201. The example below shows an authentication session that prompts the user for credential information. you can enter the same command. user name and password as command line options. Instead. you can specify the profile name as a command line option.Typical scenarios The blcred utility will prompt for an authentication profile name. blcred does not prompt the user for a name or password.) When employing AD/Kerberos authentication. you need to obtain a session credential non-interactively. Note that UNIX users must first manually run a kinit before attempting to authenticate. you can specify the profile name. using a command like the following blcred cred -acquire -profile srpProfile -i /home/user/user_info. $ blcred cred -acquire profile name: adkProfile Authentication succeeded: acquired session credential 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. but when prompted for an authentication profile name. you can direct blcred to retrieve an SRP user name and password from an SRP keytab file.

blcred cred -acquire -profile ldapProfile -username admin -password ****** If you are not using distinguished name templates.0.dat. 2 Name the file user_info. ■ The utility prompts you to create a file name. and role. you must provide a full distinguished name and a password. which caches your user ID.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. 230 BMC BladeLogic Server Automation Administration Guide .exe. If you are using a distinguished name template. Displaying the contents of a session credential Using a blcred command like the following. Username: Authentication: Issuing Service: Expiration Time: Maximum Lifetime: Client address: Authorized Roles: RBACAdmins RBACAdmin SRP service:authsvc.bladelogic:blsess://localhost:9842 Generating a user information file Use this procedure to generate a user information file. run the command bl_gen_blcli_user_info. you need to obtain a session credential non-interactively.bladelogic:blauth://localhost:9840 Fri Aug 17 20:57:29 EDT 2007 Sat Aug 18 06:57:29 EDT 2007 127.bladelogic:blsess://localhost:9841 service:proxysvc. On UNIX. do one of the following: ■ On Windows. you can direct blcred to obtain a session credential.0. and you are using LDAP authentication. password. run the command bl_gen_blcli_user_info.1 Destination URLs: service:appsvc. you can display the contents of your current session credential. 1 From installDirectory/bin. you only have to provide a partial distinguished name (in this case admin) and an LDAP password.

Generating a user information file 3 When prompted. password.dat ■ UNIX: userHomeDirectory/.user/user_info. 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 Chapter 4 Administering security 231 .dat 5 Make sure that only you have permission to access the directory where you have stored the user_info.bladelogic/. enter your user name. To determine the userHomeDirectory for LocalSystem. the user_info. NOTE When running a Network Shell Script Job based on a Network Shell script that contains CLI commands.dat file must be saved in the userHomeDirectory for the LocalSystem account on Windows or the bladmin user on UNIX. 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 file.

Generating a user information file 232 BMC BladeLogic Server Automation Administration Guide .

which clients and users have access to RSCD agents.local secure securecert log4crc. Introduction to the configuration files BMC BladeLogic provides the following configuration files: exports users users. 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. The chapter also provides an overview of logging in BMC BladeLogic. The secure files on both the client and server configure how clients communicate with servers. The secure.txt. users. users. The configuration files control how communication occurs between RSCD agents and their clients.local. each machine where an RSCD agent is installed).txt files are also installed for each client installation. secure. securecert. and discusses how logging is performed. Chapter 5 Setting up configuration files 233 . and log4crc. securecert. even if there are multiple client installations on the same machine. and log4crc.txt files reside on each server (that is.Chapter 5 5 Setting up configuration files This chapter describes how to modify BMC BladeLogic configuration files. The exports. When a client connects to a server.

even if you are using Windows user mapping.local configuration files. you should still push agent ACLs to servers when you add or modify user or role information in the BMC BladeLogic Console. users. see the man page for the chapw command. 234 BMC BladeLogic Server Automation Administration Guide . When you are using Windows user mapping to grant permissions to roles. For more information on configuring clients to use a Network Shell Proxy Server. For information on implementing Windows user mapping. Together. see the BMC BladeLogic Server Automation User Guide. or exports files. 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. Disabling user privilege mapping BMC BladeLogic provides a mechanism for disabling user privilege mapping on Windows servers. users. you must still create entries for the users. When a user is accessing a Windows server and the user’s role is not mapped to a Windows user through an automation principal. NOTE Only Windows servers running BMC BladeLogic 8.local. The alternative approach to user privilege mapping is to implement Windows user mapping. For more information. and users. This approach should always be used in the following situations: ■ ■ ■ ■ ■ When a user is accessing any UNIX server. The information in these entries defines whether users can access a server.Introduction to the configuration files In BMC BladeLogic. When a user runs a Network Shell client to connect directly to a server. the standard approach to granting user permission on managed servers is user privilege mapping. you can grant permissions to roles that are mapped to local or domain users who are authorized for a Windows server. see “Setting up a Network Shell Client to run in proxy mode” on page 147. Any user mapping information in these entries is ignored for roles that employ Windows user mapping through automation principals. When a user is using a Network Shell client to connect to servers via a stand-alone Network Shell Proxy Server. these files define what permissions apply during the connection. Consequently. It uses a combination of the exports. Using this technique.0 or later can recognize automation principals.

■ secure—Sets communication parameters that define how client and server machines communicate. With log4crc.local—Set access permissions for individual users that communicate with a server. Chapter 5 Setting up configuration files 235 . Although you can edit the secure file by hand.local files override any global user permissions defined in the exports file. A server’s secure file specifies how an agent communicates with clients. (On Windows. (For more information on RBAC. The secure file also determines whether a Network Shell client communicates with servers via a Network Shell Proxy Server. ■ log4crc. users and users.txt—Controls logging in BMC BladeLogic so that all events are logged using consistent formats.509 certificates. Permissions set in either the users and users.txt. Strong security for communication requires X. 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. so that a single log file cannot get excessively large. Application Servers. and client installations each have their own secure file. the values specified in the users file are ■ automatically generated to implement decisions made in RBAC. With the exports file you can also establish global user permissions. you can also control the rolling of log files.) A client’s secure file specifies how the client communicates with agents.509 certificates. a single machine can have multiple client installations.local file to override any permissions defined in the users file. A utility called secadmin allows you to configure the secure file on a particular machine. RSCD agents. Storing passphrases lets BMC BladeLogic access private keys without any need for user interaction. ■ securecert—Stores passphrases used to encrypt the private keys for X. BMC BladeLogic recommends that you always use secadmin. see the BMC BladeLogic Server Automation User Guide. Typically.) You can use the users.Configuration file functions Configuration file functions The configuration files function as follows: ■ exports—Sets access permissions for client machines that communicate with a server.

For example. provide the number of bits in the mask.Subnet designations The following graphic illustrates how the secure.10.000 @192.0 might look like the following: @192. an IP address.168. In the configuration files.0/24 The following are sample subnet mask definitions: 255.0/24 236 BMC BladeLogic Server Automation Administration Guide . you can use a resolvable host name. and users configuration files work together to control access to a server.255.255.100. A subnet represents a range of IP addresses. a subnet designation uses the following format: @<IP address or hostname>/mask The @ symbol indicates that a subnet is being defined.168. a subnet with a subnet mask of 255.255. Subnet designations When designating a host in the configuration files. After the IP address or host name. exports.255. or a subnet.

“Administering security. additional measures may be required before a connection can be successfully established between clients and servers.193/26 255. For a complete description of how to set up communication security for a BMC BladeLogic system.255.255.168.255. Then.100.255.255.255.100.241/28 255.255.168.240 @192.” For more information on using on the secure file. Depending on the type of authentication and encryption specified in the secure file.224 @192. If there is no entry for that client in the secure file of the server.128 @192.168. 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.100.248 @192.255. the client reads its secure file to determine whether it includes an entry for a particular server. see Chapter 4. see “Secure file” on page 253.129/25 255.How BMC BladeLogic grants access to RSCD agents 255.168.225/27 255. the client uses the information in the entry to establish a connection with the server.168.100.249/29 How BMC BladeLogic grants access to RSCD agents When a client contacts an RSCD agent.192 @192. a connection is established. Chapter 5 Setting up configuration files 237 . the RSCD agent on the server reads its secure file to determine if it has an entry for the incoming client. access to the agent is denied.100. If an entry for that server exists.255. First.255. 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.

On Windows domain controllers.0. entries in the users. 3 Once a connection is established between the client and server.00 or later. If a role is mapped to a Windows user through an automation principal. all users are domain users.local file is used for granting user permissions on a per-agent basis rather than granting system-wide user privileges. The users. For more on the exports file.How BMC BladeLogic grants access to RSCD agents 2 Assuming the conditions described below are satisfied. where the user= field can map users connecting from specified machines to a particular user on the server. 238 BMC BladeLogic Server Automation Administration Guide . Typically. To take advantage of Windows user mapping.local and users. the users. the algorithm continues to step 3 ■ ■ ■ ■ ■ The agent being contacted must be running on a Windows server. If a role is mapped to a Windows user through an automation principal. Network Shell cannot contact an agent directly or communicate through a stand-alone Network Shell Proxy Server. see “Exports file” on page 240. On domain controllers.local file take precedence. you can map users to root on UNIX-style systems or Administrator on Windows.local and users files produce no user mapping. If the same users have entries in both users. you can map a user on a client to a user on a server. The agent must be running BMC BladeLogic 8. 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 system checks the exports configuration file. If any of the following conditions are not satisfied. the incoming role is granted the permissions of a local or domain user on the server and the process if complete. The agent being contacted must be running on a server that has already been added to the BMC BladeLogic system. the exports file produces no user mapping.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. 4 The system checks the users. A Network Shell client must be communicating through a Network Shell Proxy Server. with the user= field. you can map a user to a domain user. 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. Note that on Windows. For example. if you are using Windows user mapping. incoming users can only be mapped to local users. however.

mapped to Anonymous unless a corresponding entry for the root= field is found. then that user is.local files. a mapping exists in the exports or users file.local. 5 If there is no user mapping defined in the exports. be aware that the validusers= option is treated the same as the allowed= option. Similarly. For example. on Windows.” Note that on UNIX. Similarly. If there is no user named WindowsUser.How BMC BladeLogic grants access to RSCD agents For more on the users and users.local files” on page 247. if the role is not mapped to an automation principal. the user is assigned that user’s permissions. mapped to nobody unless a corresponding entry for the root= field is found.” On Windows systems. 6 If none of the previous steps succeed. If a root= field is found. On UNIX-style systems. users coming in as root are. on Windows. by default. see “Users and users. users are granted the permissions of user “nobody. on Windows. the system maps the incoming user to a default user. including rejecting them with anon=-1. or users files. On Windows. access is denied. Chapter 5 Setting up configuration files 239 . Also. 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. The anon= field is not supported for 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. users. user “root” on a UNIX-style client is not allowed to map to its equivalent user “root” on a UNIX-style server. if an incoming user is not mapped to an automation principal and that user is a member of the Administrators group. you can use the anon= field to specify how to deal with anonymous users. by default. In UNIX-style systems. then root equivalence is allowed. by default. Note that. users are granted the permissions of user “Anonymous. If there is a match. 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. access to the agent is denied. if you are not using Windows user mapping. and the user that is being mapped to does not exist.

local files to specify individual users who are granted read/write permission on that server. Then you can use the users or users. you cannot establish a connection with an agent. For example. see the BMC BladeLogic Server Automation User Guide. When an rscd daemon starts on a server. as described in the following table. Only the user mapping information in the exports file is ignored. the daemon automatically re-reads it.local files to override those permissions for particular users. For information on Windows user mapping. If the exports file does not exist or it does not contain any configuration information. You do not have to restart the agent or otherwise instruct it to read the new exports file. WINDIR can be \windows or \winnt. 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. HP-UX Windows Location /usr/lib/rsc/exports WINDIR\rsc\exports (For example. If you are using Windows user mapping to grant permissions to roles. The exports file resides in different locations in Windows and UNIX-style systems. it automatically reads the exports file. Existing client connections are not affected by the changes. use the users or users. All subsequent client connections have the access permissions defined in the modified version of the exports file. when necessary. Often the exports file is used to set global permission that apply to users on all client machines. Linux. Access permissions are defined for each individual RSCD agent and must be configured separately on each host where the RSCD agent is running. you can use the exports file to limit all clients to readonly permission on the server. When changes are made to the exports file. the exports file may still include entries that apply to Windows servers. AIX. 240 BMC BladeLogic Server Automation Administration Guide . Platform Solaris.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.) The exports file does not grant permissions on Windows servers to roles that are set up for Windows user mapping.

Option allowed=username[:username] Description This option can be used to restrict access to specific users who do not have a local account. If possible. resolvable host names. The allowed= option is read before the validusers= option.optionN is a list of comma-separated fields. as in the following: validusers=user1:user2 Lines in the exports file that begin with # are considered to be comments. use the validusers option instead of the allowed= option..Configuring the exports file Configuring the exports file The exports file consists of multiple entries. Each option defines a type of access permission that applies to the hosts you have named in that entry. If a single option sets multiple values... you can apply any of the options listed below. option1.optionN hostNnames is a list of comma-separated IP addresses. see “Options for exports file” on page 241. When defining multiple options. or subnet designations.. Chapter 5 Setting up configuration files 241 . 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. For a complete list of available options. 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. Use the following format for each entry: hostNnames option1. separate each value with a colon. Options for exports file For each of the entries in the exports file. create entries that correlate the host names of clients with the permissions that should be granted to those clients. with each entry identifying client hosts and the access permissions granted to those hosts. Subnet designations are used to define a range of addresses (see “Subnet designations” on page 236). enter options in a comma-separated list. To configure the exports file.

Hosts not specified have read/write permissions if rw is defined or they are listed in the rw= option. The ro option takes precedence over the rw option if both are defined. (UNIX only. Root users (uid 0) are always considered “unknown” by the RSCD agent unless they are included in the root= option. commands=cmd1[:cmd2] By default.Options for exports file Option anon=uid Description (UNIX only. Specifying the nomknod option instructs the RSCD agent to prevent the client from making a mknod(2) call generating an EACCES (Permission denied) error. If the GID is not found. rw=hostname[:hostname] Hosts listed in this option are granted read/write permissions. If a request comes from an unknown user.) By default. the client is denied access. nomknod nosuid ro rw All clients have read-write access except those listed in the ro= option. ro=hostname[:hostname] Hosts listed in this option are granted read-only permissions. See “Restricting commands” on page 244 for more details on how to use this option. All clients have read-only access except those listed in the rw= option. clients are allowed to create files with the setuid or setgid bits enabled and to set setuid and setgid permission via chown(2). BMC BladeLogic clients are allowed to execute any command against an agent. The default is for no hosts to be granted root access. If you specify the nosuid option. If both the ro= and rw= options are defined. clients are allowed to create special files (character special and block special). the ro and rw options are ignored. 242 BMC BladeLogic Server Automation Administration Guide . the corresponding UID and GID are determined and set accordingly. If the user nobody does not exist. If both the ro= and rw= options are defined. the GID is set to the GID for the user nobody. the client is denied access. the value 65534 is used. The ro option takes precedence over the rw option if both are defined. If a UID is entered. described below. The value entered can be numeric or a user name. The default value for anon= is the UID of the user nobody. (UNIX only. The commands= option allows you to limit the commands a client can execute against an agent. Setting anon=-1 disables anonymous access. Hosts not specified have read-only permissions if ro is defined or they are listed in the ro= 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. If a user name is entered.) This option specifies how unknown users should be treated. If rw is not set or the host is not listed in the rw= option.) By default. If ro is not set or the host is not listed in the ro= option. root=hostname[:hostname] This option gives root access to root users from specified hosts. the ro and rw options are ignored. the user is treated as an anonymous user and the effective user ID is uid. a corresponding GID is searched for.

If an account is associated with a UID. Chapter 5 Setting up configuration files 243 . 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 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 user name entered is not known. The rsu= entry defines which users the client is allowed to rsu without challenging them for a password. no password challenge) and then tries to switch to a user not in the list. Group information can be provided in the form of group names or numeric GIDs. default user mapping applies. access is denied. the rscd server sets the “root” directory to dirname by making a call to or emulating chroot(2).Options for exports file Option rootdir=dirname Description By default. you can map a user to a domain user. By default the client is challenged for the user’s password. the connection is refused. the UID and GID for the user are determined and set accordingly. then the corresponding UID on the server is used even if no known user account is associated with that UID. For Windows systems. Numeric GIDs do not have to correspond to a local group name. access to the machine is denied. The user name you enter is validated against the domain users on the domain controller. the rscd server allows the client to “see” the complete directory tree from / on down. Use /etc/groups to define group names. but with the -p option no password is requested.) If a numeric UID is entered. if a user name is entered. if a user name or user account SID is entered. On Windows. Note that on Windows domain controllers. Clients can only see files and directories from dirname on down. On UNIX. The single entry you provide for username can be a user name or a numeric UID (UNIX only). If the GID is not in the list. By specifying the rootdir= option. Enter user groups in a colon (:) separated list. (For more details on user privilege mapping. it is validated against a list of local users on the machine. rsu=user[:user] user=username validgroups=groupname[:groupname] This option allows you to specify user groups that are allowed access. If the client tries to use the rsu command with the -p option (that is. For each group name and/or GID entered. This option forces all incoming client connections to run with the permissions of username. See “How BMC BladeLogic grants access to RSCD agents” on page 237 for more details. 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. The client command rsu allows a client to get alternate remote permissions on the agent. When setting rootdir= on Windows systems. If the user name that is entered is not known. you can use the native file naming convention rather than a Network Shellstyle path. then its corresponding GID is also set. see “How BMC BladeLogic grants access to RSCD agents” on page 237.

Access can be limited by host or subnet. that is. If no corresponding user account can be found. df. kill. you also inherently authorize the use of all nsh internal commands against the server. Once you use the commands= option to authorize the nsh command to run against a server. including cd. and midair. (The process is conceptually similar to doing an rsh. Remote commands do not include this safeguard.Restricting commands Option validusers=username[:username] Description This option allows you to specify users who are allowed access. The other type of command that a client can run is called a remote command (remote. The RSCD agent then matches the user name/UID combination to each attempted client connection. Restricting commands The RSCD agent reads entries in the exports file to determine what access permissions a calling client should have. ls. set. true. The order in which commands are entered and the format of the commands= field affect the way permissions are determined. you must 244 BMC BladeLogic Server Automation Administration Guide . hostname $ mkdir //athens/tmp/foo //rome/tmp/bar Besides launching external applications. Enter users in a colon (:) separated list. false. the connection is refused. You must first define the allowable distributed commands and then define the allowable remote commands. by user name. User names and UIDs must correspond to a locally known user account. For each user name and/or UID that is entered. from the client’s perspective). you cannot use the commands= option to explicitly restrict their use. In some circumstances you may want to restrict the commands a user can execute. remote commands include ps. the entry is ignored. which each have distributed capabilities. 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. This can be done using the commands= option in the exports or users files. the RSCD agent looks up the corresponding UID and user name to create a user name/UID combination. The first are Network Shell utilities. These commands do not have distributed capabilities and run remotely on the server host.) For example. and by the commands a user can run. To allow remote commands. echo. and netstat. A distinction exists between distributed commands and remote commands. pwd. the nsh utility provides access to many internal commands. The user information you provide for validusers= can be in the form of user names or numeric UIDs. Given that these commands are internal to nsh. To prevent individuals from renaming executables to trick the RSCD agent. and more. For example. such as nsh. each distributed utility contains an encrypted string that is used to hard code the name of the utility into the executable. BMC BladeLogic clients can run two types of commands.

you can leave out the list of distributed commands. This prevents users from trying to execute a different executable than the intended one. For example. all subsequent commands in the list are assumed to be remote commands. For example. 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. 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. In other words. the last of which should be the nexec command. 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 Chapter 5 Setting up configuration files 245 .Restricting commands also allow the distributed command nexec. For example. Then you define the remote commands. Once the nexec entry is found. 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. No remote commands such as ps or df are allowed. commands=nsh:mkdir:rmdir allows users to execute Network Shell’s internal commands as well as to create and remove directories. The decision to allow or disallow execution of a remote command is based on comparison of the effective (basename) of the command. first you define the distributed commands. In order to ensure that only the desired remote commands are executed. you can specify the full pathname of the remote executable.

host2. who typically work on Windows clients.user=Administrator NOTE On Windows.rootdir=/reports The following example is a configuration that could be assigned when administrators. When using the exports file to set up user privilege mapping on Domain Controllers. This entry would be added to the exports file on every remote server being managed by the two administrators. map users to Administrator or the administrator account for the domain. need to manage remote UNIX servers. The root directory for these users is set to /pubs.anon=-1 The following example maps incoming connections from machines called admin1 and admin2 to the local user called Administrator. on Windows Domain Controllers. * ro.rootdir=/pubs. This example grants read-only access to all clients and maps all incoming connections so that users have “guest” privileges. a configuration entry something like this example is important if administrators working on Windows clients want to modify the configuration of UNIX servers. The asterisk means permissions apply to all clients unless there are other entries that define different permissions for specific hosts.nosuid. * rw. the user name entered is validated against a list of local users on the machine. It grants two users (sysadmin1 and sysadmin2) read/write permission for all servers. The following example allows both read/write and read-only access for selected hosts.admin2 rw. granting them root access from only one host and changing the root directory to /reports: host1.Examples Examples The following example allows customers access to software updates from servers.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.host5 ro. all users are domain users.host3 rw. Because Windows machines have no inherent concept of root. * rw. and it also maps their user privileges to root.root=host1 host4.rootdir=/reports.user=root 246 BMC BladeLogic Server Automation Administration Guide .allowed=sysadmin1:sysadmin2. A configuration like this is typically necessary if you are deploying BLPackages to Windows machines because you need Administrator privileges to deploy packages. However. admin1.

Administrators may want to modify the users. entries in the users. The agent on a server enforces user permissions defined in an ACL by mapping incoming users to users defined on the server. If you want to have different access (ro/rw) permissions for various hosts within a subnet. host1.10.) With RBAC you define the characteristics of a role and assign users to that role. @192. but the users.168. (For more on RBAC.root=host1.1/24 rw=@192.168. she must operate with the privileges already assigned to user betty on that server.local files override any permissions defined on a per-client basis in the exports file.1-255 is split up so that the range from 1-127 has read/write privileges while the range 128-255 has readonly privileges.local file is used for granting permissions on a per-server basis rather than granting system-wide user privileges. Running an ACL Push Job automatically converts your role definitions and role assignments into entries in the users file on that server.168.ro=@192.192) has read-only privileges.129/25 Users and users.1/25.foo.10.local file is scanned before the users file. You can apply RBAC decisions to a server by running an ACL Push Job in the BMC BladeLogic Console.local file to override RBAC policy on a particular server.local files grant access permissions to specific users connecting to a server. a user cannot connect to a server unless a matching user name has been defined on a server.local files The following example demonstrates subnets.local and users. Chapter 5 Setting up configuration files 247 . Both the users and users.foo.local files The users and user.com/26 The following is an example where an address range of 192. The users file is primarily used to implement user permissions that are defined through RBAC. The permissions in the users and user.255.com has read/write privileges while everybody else in the subnet (subnet mask 255. In the example below the host host1. If the same users have entries in both users.local files are defined on a per-user basis.local file take precedence. In this scenario.10.local files have the same format. The agent accomplishes this by doing the following: ■ Incoming users are matched to a user name on the server.com ro @host1.foo. see the BMC BladeLogic Server Automation User Guide.10. Typically the users. In other words. you should first define the exception hosts and then define the default value for the remaining subnet.com rw. The permissions granted in the users and user.255.foo. when user betty attempts to connect to a server. Together these entries are called an access control list (ACL).168.Users and users.

You do not have to restart the agent or otherwise instruct it to read the new users or users. If command authorizations are specified on the server in BMC BladeLogic Console and command authorizations are specified for the role. Platform Solaris. HP-UX Windows Location /usr/lib/rsc/users /usr/lib/rsc/users. as described in the following table. This means the role has full authorization to use any Network Shell and nexec commands on that server. the RSCD agent automatically detects your new settings and uses them for all subsequent client connections.local WINDIR\rsc\users WINDIR\rsc\users. incoming users are automatically mapped to a user with downgraded permissions. 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. 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. AIX. For example. all users connecting to a UNIX system can be mapped to root.local files. This means the role is authorized to perform those commands on the agent.local files reside in different locations in Windows and UNIX-style systems. no command authorizations for that role are pushed to the agent. Linux. If command authorizations are specified on the server in BMC BladeLogic Console but no command authorizations are specified for a role. while users connecting to a Windows system can be mapped to Administrator. those command authorizations are pushed to the agent. If neither of the two previous techniques are possible.local files.) 248 BMC BladeLogic Server Automation Administration Guide . ■ An ACL Push Job generates users file entries that grant a variety of permissions. This means the role is authorized to perform only those commands on the agent.local files ■ Incoming users are mapped to a specified user name.Users and users. UNIX users are mapped to user nobody and Windows users are mapped to Anonymous.local (For example. including permissions for commands. the command authorizations common to both are pushed to the agent. WINDIR can be \windows or \winnt. ■ ■ ■ When you make changes to the users or users. The users and users. no command authorizations for that role are pushed to the agent.

the users or users.local files” on page 251. For example.Configuring the users or users. For example. However. For Network Shell users that are not communicating with servers through a Network Shell Proxy Server. even if you are using Windows user mapping. hosts=host1:host2. The format of each entry consists of two fields. separated by a colon. The second field is a commaseparated list of permissions that apply to the user defined in the first field. see “Options for users and users. Only the user mapping information in the users and users. If an option sets multiple values.local files is ignored for roles that employ Windows user mapping through automation principals. the first field in a users file entry provides only a user name. see the BMC BladeLogic Server Automation User Guide. For a complete list of available permissions.local files The users and users. For a complete list of available permissions.local files are a list of entries. separate each value with a colon. Each entry grants permissions to a user. The second field is a comma-separated list of permissions that apply to the user defined in the first field. hosts=host1:host2.local files Both the users and users. Chapter 5 Setting up configuration files 249 . Configuring the users or users. separate each value with a colon. Consequently. you should still push agent ACLs to servers when you add or modify user or role information in the BMC BladeLogic Console. 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.local files” on page 251. see “Options for users and users.local files should still include an entry for each role so that role can be granted access to a Windows server. No role is necessary because Network Shell does not recognize roles. such as BLAdmins:BLAdmin. For information on Windows user mapping. All other settings still apply. The first field provides a role and a user name. If an option sets multiple values.local files do not grant permissions on Windows servers to roles that are set up for Windows user mapping.

The users file can also include a nouser entry. This capability is unique to the users. Using wild cards in the users. All users in the role are mapped to root.map=root rw. The entries for DBAdmins:george and DBAdmins:betty would grant george and betty access to this server.local file allows you to use a wild card in place of user names when defining role:user combinations.map=root An entry like this grants read/write access to all users who have assumed the role of SecOpcs. When you use an ACL Push Job to push a users file to a server. 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.local file. Below these entries. you could create a users file entry such as: SecOps:* rw. DBAdmins is the role and george and betty are users.local files that begin with # are considered to be comments.map=root nouser If george and betty communicate with the server by means of a Network Shell Proxy Server. Lines in the users and user. two more entries grant george and betty access to this server using Network Shell.map=root # NSH-only ACLs entries for Network Shell users george betty rw. the Network Shell entries shown above would not be necessary. 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.Configuring the users or users. 250 BMC BladeLogic Server Automation Administration Guide . In these entries george and betty are not paired with any role # DBAdmins ACLs entries for DBAdmins role DBAdmins:george DBAdmins:betty rw.local file The users. For example. In this example.map=root rw.local files Below is a sample users file with entries for DBAdmins:george and DBAdmins:betty.

TIP BMC BladeLogic recommends adding an entry for RBACAdmins:RBACAdmin and BLAdmins:BLAdmin to the users. the corresponding entry in the exports file determines what commands the user can run.local file when users are added to or removed from a group. You do not have to update entries in the users. Chapter 5 Setting up configuration files 251 . Entries in the users.local file is a capability that should be used sparingly. Using a wild card like this also lets you authorize all members of a role to perform certain types of actions. Because these roles cannot be deleted.local file for every server. Thus an entry like the one shown above overrides any more restrictive settings defined for the role using RBAC.local files Identifying users with a wild card provides some benefits. If no hosts field is provided. 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. If you choose to rename the RBACAdmins or BLAdmins roles. Options for users and users. running an ACL Push Job may first require a lengthy change control process.local files The users and users.local file should reflect those naming decisions. the entries you make in the users.] This is a list of colon (:) separated commands that the user is allowed to execute on the local host. See “Restricting commands” on page 244 for more details on the use of this field.Options for users and users. By performing a modification like this.) This entry tells the RSCD agent that an account with the same user name must exist on this host. Using wild cards for user names in the users. 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. In some organizations..local file override entries in the users file. If no commands= option is given.local files provide the following options that you can use to assign access permissions to users: Option Description commands=cmd1[:cmd2 ..] (Unix only.. they provide a way to access a server in case you accidentally revoke everyone else’s permissions for that server. exists hosts=hosts1[:host2 . the entry applies to the user named in the first field regardless of what host that user is connecting from..

no password challenge) and then tries to switch to a user not in the list. generating an EACCES (Permission denied) error. server access is limited to users specifically included in the users or users. user1 and user2 can access this server from any other server. If you specify the nosuid option. chroot(2). For more information.local files. The named user has read/write access. clients are allowed to create special files (character special and block special).Examples Option map=username Description This entry forces incoming client connections to run with the permissions of username. By specifying the rootdir entry. The client command rsu allows a client to get alternate remote permissions on the agent. clients are allowed to create files with the setuid or setgid bits enabled and to set setuid and setgid permission via chown(2). (Unix only. the RSCD agent allows the client to “see” the complete directory tree from / on down. see “How BMC BladeLogic grants access to RSCD agents” on page 237. 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.. When the nouser name is included in the users or users. By default the client is challenged for the respective user’s password but with the -p option no password is requested. which are for user1 and user2.local files. the RSCD agent silently ignores any attempt to enable the setuid or setgid bits when creating a file or changing a file’s permissions. Clients can then see files and directories from dirname on down. the first and second entries in the users file grant read/ write access to user1 and user2. For Windows systems. If the client tries to use the rsu command with the -p option (that is. Specifying the nomknod option instructs the RSCD agent to prevent the client from making an mknod(2) call. who are associated with the role of SrAdmin. 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. the RSCD agent sets the “root” directory to dirname by making a call to. you can enter a Windows user account SID rather than a user name. The rsu= entry defines which users the client is allowed to rsu without challenging them for a password. (Unix only. access is denied. The third and fourth entries.. or emulating.) By default. Both users are mapped to Administrator on this server.) By default.] rw validuser Examples In the following example. nomknod nosuid nouser ro rootdir=dirname rsu=user1[:user2 .local file. do not associate those users with a role but do 252 BMC BladeLogic Server Automation Administration Guide . Because no hosts field is provided. By default. The named user has read-only access.

local files control user access to servers (see “Exports file” on page 240 and “Users and users.map=Administrator user1 rw. In this discussion. The last entry forbids access to all users who are not specified in the users file.map=Anonymous nouser The following example in the users. Chapter 5 Setting up configuration files 253 .rw. who is associated with the role of JrAdmin and is mapped to Anonymous on this server. a client application can be a Network Shell client.map=Administrator user2 rw. user2 is granted read-only permission.rw. The exports. The secure file on the server defines parameters that the RSCD agent uses to communicate with BMC BladeLogic applications on clients.map=Administrator JrAdmin:user3 ro. user1 user2 rw rw nouser 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. The secure file for a client application defines parameters that BMC BladeLogic applications use to communicate with the RSCD agent on a server. then user1 is only given access to the /data directory and granted the permissions of user3. If user1 is not connecting from host1 or host2. or Network Shell Proxy Server that communicates directly with an RSCD agent or repeater. BMC BladeLogic Application Server. These entries are used for granting permissions to Network Shell users.local files” on page 247).rootdir=/data. If user2 is not connecting from host1 or host2.local file grants read/write access to user1 and user2 and forbids access to all other users. and users. The fifth entry grants read-only access to user3.Secure file map them to user Administrator.map=Administrator SrAdmin:user2 rw. users.map=user3 ro The following example in the users. SrAdmin:user1 rw. user1 user2 user1 user2 hosts=host1:host2.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.validuser rw.validuser hosts=host1:host2.

Clients. The port number can be set with an entry in the Internet services databases (for example. WINDIR can be For example. each with their own secure file. On Windows. Name and location of secure file for first instance of BMC BladeLogic /usr/lib/rsc/secure Platform Solaris Linux AIX HP-UX Windows Name and location of secure file for additional instances Not applicable WINDIR\rsc\secure installDirectoryN\version\NSH\conf\secure For example. the default location for the second instance of BMC BladeLogic would be \windows or \winnt. you need only modify the secure file to establish how data is communicated between clients and servers. encrypted. If an entry for the target server exists in the secure file. servers. See Chapter 4. servers. C:\Program Files\BMC Software\ BladeLogic2\version\NSH. and the secure file By default. /etc/services). and the secure file When a BMC BladeLogic application on a client attempts to connect to an RSCD daemon on a server. The following table shows how the location of the secure file on Windows varies between the first instance and all subsequent instances. you can have multiple instances of BMC BladeLogic client applications. the application first checks the secure file for a client to see how the connection should be established. Always use the secadmin utility to modify the secure file. The secure file resides in different locations in Windows and UNIX-style systems. Using the secadmin utility ensures that the secure file is formatted correctly. see “Using the secadmin utility” on page 258. as described in the following table. Stronger security requires additional modifications to a system. For simpler security installations. “Administering security” for a full description of all the procedures needed to implement security in a BMC BladeLogic system. the application searches for an entry 254 BMC BladeLogic Server Automation Administration Guide . or sent as clear text. For more information. Clients. the application checks the secure file to see if and how the connection should be redirected and whether data should be encoded. If an entry for the remote host is not found. client and server processes communicate via TCP/IP port 4750 with the server process listening on all configured NIC (Network Interface Card) addresses.

the agent uses the connection parameters defined in that entry. The RSCD daemon cannot listen to a port on a list of specified NICs. protocol 5 uses Transport Layer Security (TLS). the RSCD daemon consults the secure file on the server. As such. Communication protocol Protocol 5. For a more detailed description of the capabilities of this suite. see “Configuring the secure file” on page 255. that connection is used to both send and receive data. BMC BladeLogic clients and RSCD agents use the TLS_RSA_WITH_AES_256_CBC_SHA cipher suite. as described in “Options for secure file” on page 258). the RSCD daemon again refers to the secure file to determine what data encoding/encryption it should expect from the client host. you can make three types of entries: ■ ■ default rscd Chapter 5 Setting up configuration files 255 . the daemon uses the default values from the rscd entry. (For more on configuring entries in the secure file. the attempt to establish a connection is aborted. TCP is a bi-directional virtual circuit protocol. Configuring the secure file When configuring the secure file. The rscd entry can specify which port and address to listen to for connection requests and it can specify default communication parameters. By default. the daemon listens by default to port 4750 (or as otherwise defined in the Internet services databases). the successor to SSL. The RSCD first checks for an entry for the connecting host.) The RSCD daemon can listen on a specified port on all available NICs or a particular NIC (specified using the host= field. it can only listen on one NIC or all NICs. If such an entry exists. If an rscd entry is found. In other words. If an entry is not found. establishes rules for communication between BMC BladeLogic clients and Application Servers and the RSCD agent. (For more on configuring the rscd entry. see “Configuring the secure file” on page 255. When a client establishes a connection. which automatically negotiates the strongest form of encryption that clients and servers can support. If no entry for the connecting host is found. the BMC BladeLogic default communication protocol.) If the secure file does not include an entry for the remote host or a default entry. see “Session layer security” on page 118. To determine where to listen for connection requests. the software treats it as a special entry used by the RSCD daemon. when a client establishes a connection to an RSCD daemon on a server.Communication protocol called default to determine how the connection to the remote host should be made. It looks for an entry for a host named rscd.

For a complete list of available options. The default entry also designates the default port as 4750. When you initially install Network Shell. An rscd entry in the secure file uses the following format: rscd:option1:option2:option3.. or the RSCD agent. a default entry is automatically created in the secure file. 256 BMC BladeLogic Server Automation Administration Guide . 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. see “Options for secure file” on page 258. where optionN is a list of colon-separated fields. Default entry The secure file allows for a special host name called default.. 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 more information. The default entry specifies that the client use protocol 5 and instructs clients and servers to communicate using the TLS protocol for secure communication.Configuring the secure file ■ host Always use the secadmin utility to configure the secure file. A default entry in the secure file uses the following format: default:option1:option2:option3. 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. 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. The secadmin utility encrypts any keys needed for data encryption and guarantees that the secure file is formatted correctly.. the BMC BladeLogic consoles.. It defines connection parameters for servers that otherwise do not have an entry in the secure file. see “Using the secadmin utility” on page 258.

see “Options for secure file” on page 258. hostName is the host with which the client or server is communicating. Each option in the list defines a parameter for communicating with all agents that do not have a host entry specifically defined for them. Each option defines a parameter for communicating with the host (or subnet) named in hostName. You must make corresponding entries in the secure file on both the client and server to establish a connection between client and server. optionN is a list of colon-separated fields. 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. Subnet designations are used to define a range of addresses (see “Subnet designations” on page 236). an rscd entry is automatically created in the secure file. IP address. or subnet designation. where.Configuring the secure file where optionN is a list of colon-separated fields. For a complete list of available options. To configure host entries in the secure file. Chapter 5 Setting up configuration files 257 . The rscd entry also designates the default port as 4750. 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.. When you initially install an RSCD agent on a server. see “Options for secure file” on page 258.. The rscd entry that is automatically generated in the secure file on a server reads as follows: rscd:port=4750:protocol=5:tls_mode=encryption_only:encryption=tls Host entries Host entries in the secure file on a server set connection parameters that define how that server communicates with individual clients. hostName can be a resolvable host name. Use the following format for each entry: hostName:option1:option2:option3. Host entries in the secure file on a client set connection parameters that define how that client communicates with individual servers. create entries that define parameters for a connection with a particular host. NOTE If you change the RSCD agent port number in the secure file. For a complete list of available options.

the secadmin utility lets you modify entries in the securecert file. see the man page for secadmin. You can also create. modify. you must include the full path to the secadmin utility when running a secadmin command. By default. you can create. you must use secadmin to modify the secure file on host2. modify. Additionally. 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.Options for secure file Using the secadmin utility With the secadmin utility. 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. 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 secadmin -a host3 -p 5 -T encryption_only -e tls secadmin -a host4 -p 5 -T encryption_only -e tls Next. and host4. or delete default or rscd entries in the secure file. host3. host3. 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. Options for secure file An entry in the secure file can include the following fields: 258 BMC BladeLogic Server Automation Administration Guide . or delete entries in a secure file.

Typically you should use compression when communicating through a thin pipe. This is the default value for appserver_protocol. The default value. 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. Be aware. This field specifies whether the agent should send TCP keepalive messages to the other side of a connection. If keep-alive messages are sent. You can set protocol to the following: ssoproxy Use the single sign-on functionality when communicating with the Network Shell Proxy Server. By default. This field is used differently. sessions may hang indefinitely leaving hung processes or threads on the agent. For more on Network Shell Proxy Servers. If you want to use data compression. encryption=type host=value keepalive=value Chapter 5 Setting up configuration files 259 . you do not have to set this field because the agent automatically listens on the default system NIC card (address). In a LAN environment the overhead required for compressing and uncompressing data is usually greater than the time saved transferring compressed data. that better compression is more CPU intensive. the host= field determines the address to which the agent should listen for client connections. the connecting system will notice the death of a connection or a machine crash. the host= field can be used to redirect data between hosts. set value to a number between 1 and 9. depending on whether a secure file entry defines the special host name rscd: ■ When applied to an rscd entry. where a higher number calls for better compression. which specifies that BMC BladeLogic should automatically negotiate an encryption method (usually AES). compression=value This field sets a data compression level. If the remote daemon to which the data is being sent is not another RSCD daemon. ■ When applied to a non-rscd entry.Options for secure file Option Description appserver_protocol=protocol This field specifies the authentication protocol used when communicating with a Network Shell Proxy Server. if unset. however. If TCP keep-alives are not sent. data is not compressed. 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. is yes. Set this field to tls. Possible values for this field are yes or no. If a system has a single NIC card. see “Configuring the Network Shell Proxy Service” on page 142. This field determines the type of data encryption that should be used.

Options for secure file

Option lock=value

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

port=value

protocol=value

auth_profile=profile

auth_profiles_file=filename

timeout=secs

260

BMC BladeLogic Server Automation Administration Guide

Examples

Option tls_mode=value

Description When using protocol 5, this field specifies one of the following values: encryption_only Use the TLS protocol to autonegotiate an encryption type (that is, a cipher) and then use that cipher to communicate. Client-side authentication or certificates are not required. Use TLS for encryption and clientside authentication. This option requires a certificate. For more on certificates, see “Implementing security – Application Server to agents or repeaters” on page 202.

encryption_and_auth

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. This field turns off X11 forwarding. By default this field is set to on and X11 forwarding is enabled for this agent. 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).

x11_fwd=on |off x11_port_offset=value

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

Chapter 5 Setting up configuration files

261

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 file
The 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 noninteractively 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.”.

262

BMC BladeLogic Server Automation Administration Guide

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.
Name and location of securecert file for first Name and location of securecert file for instance of BMC BladeLogic additional instances /usr/lib/rsc/securecert Not applicable

Platform Solaris Linux AIX HP-UX Windows

WINDIR\rsc\securecert For example, WINDIR can be \windows or \winnt.

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.

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:

Chapter 5 Setting up configuration files

263

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.

264

BMC BladeLogic Server Automation Administration Guide

Overview of BMC BladeLogic log files

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)
Description and default location 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 post_install.log Application Server configuration log installDirectory/br/post_install.log installDirectory/br/deployments/ deploymentName/log4j.properties installDirectory/br/deployments/ _template/log4j.properties Where to configure

Log file name

Chapter 5 Setting up configuration files

265

Overview of BMC BladeLogic log files

Table 1

Overview of BMC BladeLogic log files (part 2 of 3)
Description and default location Application Server Console log installDirectory/br/Console.log Where to configure Infrastructure Management => AppServer Launcher => Edit AppServer ConsoleLogfileName attribute installDirectory/deployments/ deploymentName/log4j.properties RSCD Agent (Windows)

Log file name Console.log

rscd.log*

Windows RSCD Agent log rscdInstallDirectory\rscd.log

rscdInstallDirectory\log4crc.txt

keystroke.log*

nexec session log rscdInstallDirectory\keystroke.log*

rscdInstallDirectory\log4crc.txt

rscdsvc.log*

RSCD agent service rscdInstallDirectory\rscdsvc.log

rscdInstallDirectory\log4crc.txt

*.log

Deploy Job log rscdInstallDirectory\Transactions\log\*.log RSCD Agent (UNIX)

rscdInstallDirectory\log4crc.txt

rscd.log*

UNIX RSCD Agent log rscdInstallDirectory/log/rscd.log

rscdInstallDirectory/log4crc.txt

keystroke.log*

nexec session log rscdInstallDirectory/log/keystroke.log*

rscdInstallDirectory/log4crc.txt

*.log

Deploy Job log rscdInstallDirectory/Transaction/log/*.log RCP Client (Windows)

rscdInstallDirectory/log4crc.txt

.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 RCP Client (UNIX) .log BMC BladeLogic Console log /root/.bladelogic/1_1_2/Workspacen/ .metadata/.log 266 BMC BladeLogic Server Automation Administration Guide

installDirectory\br\rcp.cf

installDirectory/br/rcp.cf

which is located in the Application Server installation directory for that deployment. By default.log* BLCLI (Windows) blcli.log* PXE Server log installDirectory/br/pxesrvr.log* TFTP Server log installDirectory/br/tftpsvr.cf Log file name BLWorkbenchPlugin. also located in the Application Server installation directory for the specific deployment.Application Server logging Table 1 Overview of BMC BladeLogic log files (part 3 of 3) Description and default location Where to configure installDirectory/br/rcp.properties file. Within the configuration files for each specific deployment. logging is controlled by the log4j.log PXE server pxesrvr. The following sections provide information on the log4j.log BLCLI UNIX log /.bladelogic/blcli-log.cf /.client.metadata/. Application Server logging output is written to the appserver. Chapter 5 Setting up configuration files 267 .cf C:\Documents and Settings\Administrator\Application Data\BladeLogic\blcli-log.properties configuration file.bladelogic/blcli.ui/ BLWorkbenchPlugin.log file.log BLCLI (UNIX) blcli.bladelogic/1_1_2/Workspacen/ .log BLCLI Windows log C:\Documents and Settings\Administrator\Application Data\BladeLogic\blcli.plugins/ com.bladelogic.log* tftpsvr.log BLWorkbenchPlugin log /root/.properties By default.cf Application Server logging Logging is controlled at the Application Server instance level. the file is located in installDirectory/br/deployments/deploymentName/log4j.properties installDirectory/br/tftpsvr.log installDirectory/br/deployments/ _pxe/log4j.

R. You can enable logging of performance-related information pertaining to the Application Server. 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.File option.appender.MaxBackupIndex option. Table 2 Attribute Log Files Location Modifying basic Application Server logging attributes Description You can set the log file location using the log4j. You can set the number of roll-over files using the log4j.R. you can modify one or more of the specified loggers in the file to set the log level to DEBUG.properties file can also control where the logging information is stored and how the log files are managed.appender.R. To do so. This section describes how to manipulate some of the basic properties of the configuration file. These loggers are initially configured with the log level INFO to prevent the log files from containing too much information. To do so.properties In addition to controlling the logging information. a backup file will be made and a new log file will be created.properties file. the maximum number of roll-over files is 5. You can set the maximum file size for the log file using the log4j.MaxFileSize option. You can enable logging of Content Authoring debug information. locate the Content Authoring related debug logs section in the file and uncomment the lines in that section. When a log file reaches its maximum size. By default.properties file contains a large list of loggers that can be configured to add useful debug information. This option instructs the log4j system to use the specified path for logging. When debugging specific issues with the system. To do so. locate the timing for deploy jobs section in the file and uncomment the lines in that section. There are comments within the file describing other options not defined here. 268 BMC BladeLogic Server Automation Administration Guide . the log4j. Maximum file size Number of roll-over files Performance logging Timing for Deploy Jobs Content Authoring Log configuration Additional debug logging The log4j. This value controls how many backup files will be retained. the maximum log file size is 5000KB.Application Server logging Modifying logging configuration using log4j. By default. locate the BlDeploy appserver performance logging section in the file and uncomment the lines in that section. specifying the relative or full path of the log file.appender. You can enable logging of timing information pertaining to the Deploy Jobs.

Chapter 5 Setting up configuration files 269 .DBServiceImpl – This logger controls messages generated by the database service.db. R. the application server will automatically detect the logging level modification after a short period of time and being logging data in debug mode. 2 Locate the following line: log4j.properties file. the following options in the log4j.mfw. 1 In the BMC BladeLogic Console.rootLogger=INFO.bladelogic. C Once saved.properties file for additional information on these logger options.logger. There are many logger options that give you the ability to enable debug logging for very specific tasks. 3 Right-click the Application Server you want to edit and select Edit.demux. See the comment lines in the log4j.app. R. select Infrastructure Management.com.logger. The Edit Application Server Profile dialog opens.rootLogger=DEBUG. 2 Expand the hierarchy of the Application Servers node.com.bladelogic.Demux – This logger controls messages generated by the networking layer.Application Server logging NOTE Debugging issues with the Application Server often require assistance by BMC BladeLogic Customer Support. from the Configuration menu. C 3 Modify the line to read: log4j. ■ log4j. 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. To enable basic debug logging 1 Open the log4j. For example.properties file control loggers that are useful for debugging: ■ log4j.

LogfileName The name of the log file for the Application Server. the console log files are configured to rollover. This convention avoids conflicts when there are multiple Application Servers on the same host. You can set the number of roll-over files for the console log file in the log4j. The console log file contains all information logged to the Application Server log. For example.log file contains the same information as the appserver. The console. add or change values for the following attributes.properties file accessed from the _template deployment directory (/br/ deployments/_template/log4j.log extension. but in addition it also captures any output that does not go through the log4j logging system. The console. plus any information logged to the console. click OK.Application Server logging 4 In the Edit Application Server Profile dialog.log file. This convention avoids conflicts when there are multiple Application Servers on the same host. BMC BladeLogic sets the log file’s name to the Application Server name plus the .log. specify a name that is unique on the host. 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. 7 Start or restart the Application Server to have changes take effect. When you create a new Application Server. BMC BladeLogic sets the console log file’s name to the Application Server name plus “_console”.properties). If you edit this attribute. set the ConsoleLogfileName to be empty. To disable console logging.log file. specify a name that is unique on the host.log file is useful for debugging when certain output is not captured by the regular log files. 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. Console logging is enabled by default. 270 BMC BladeLogic Server Automation Administration Guide . 6 Click OK on the warning that configuration changes do not take effect until you restart the Application Server. 5 When you are finished editing the profile. Enabling more detailed logging In addition to the appserver. Attribute ConsoleLogfileName Description The name of the console log file for the Application Server. When you create a new Application Server. If you edit this attribute.

BMC BladeLogic uses the following configuration files (all found in installDirectory/br) to control logging with log4j: ■ ui. how often logs are rotated. you can control which log files BMC BladeLogic generates.cf—Configures ui.Agent logging Agent logging The log4crc. 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. PXE Server logging The log file for the PXE Server is controlled with the log4j. see “About the Log4crc. which logs messages from the TFTP server.txt file is XML-based. ■ For more information on log4j. You access the tool from the BMC BladeLogic Console by selecting Configuration => Generate Support Data.log. which logs messages from the BMC BladeLogic Console.txt file” on page 272. For specific instructions. tftpsvr.cf—Configures tftpsvr. The log4crc. This data can be useful for diagnostic purposes when you contact Customer Support. and what sort of layout the contents of each log should use. 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.log. see http://jakarta. see “Generating data for support” on page 19.properties file located in the PXE server deployment (_pxe directory).org/log4j/docs/.txt. how much information is included in each file. where each log file is generated. By modifying XML tags in log4crc.txt file allows you to control Agent logging in BMC BladeLogic so that all Agent events are logged using consistent formats.apache. For detailed information. Chapter 5 Setting up configuration files 271 . Additional log files of interest Additionally.

where each log file is generated.txt For example. The log4crc. how often logs are rotated. how much information is included in each file. Name and location of log4crc.txt file is used to control Agent logging. you can control which log files BMC BladeLogic generates.txt file resides in different locations on Windows and UNIX-style systems. you can have multiple instances of BMC BladeLogic client applications. NOTE The log4crc. as described in the following table.properties file. each with their own log4crc.txt file.txt. The log4crc. The following table shows how the location of the log4crc.txt file is XML-based. For Application Server logging. logging level.txt Platform Solaris Linux AIX HP-UX Windows Name and location of log4crc.txt file for first instance of BMC BladeLogic /usr/lib/rsc/log4crc.txt file on Windows varies between the first instance and all subsequent instances.txt file for additional instances Not applicable WINDIR\rsc\log4crc. Syntax The syntax of the log4crc.txt file The log4crc. WINDIR can be \windows or \winnt. For more information.About the Log4crc. The log appender. On Windows. the default location for the second instance of BMC BladeLogic would be C:\Program Files\BMC Software\ BladeLogic2\version\NSH.txt For example. installDirectoryN\version\NSH\conf \log4crc. 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.txt file allows you to control Agent logging in BMC BladeLogic so that all Agent events are logged using consistent formats.txt file About the Log4crc. and logging format for Application Server logs are controlled using the log4j. By modifying XML tags in log4crc.txt file consists of three tags: <category> <appender> <layout> 272 BMC BladeLogic Server Automation Administration Guide . and what sort of layout the contents of each log should use. see “Application Server logging” on page 267.

Generates a keystroke log that records nexec sessions. Default values vary somewhat for UNIX-style installations. The <category> tag can include three options: name. Logs all warnings and errors. The following table identifies the possible priority levels: Priority fatal error warn info Description Logs only fatal errors. A category managed internally by Deploy Job executables.About the Log4crc.log" debugappender="stderr"/> <!-category name="keystroke" priority="info1" appender="C:/Program Files/BMC Software/BladeLogic/version/RSCD/keystroke. rscdsvc bldeploy bldeployConsole bldeployAppserver The priority= option specifies the amount of information included in a log. including fatal errors. Agitator managed internally by Deploy Job executables. The following table identifies all possible names: Name rscd keystroke Description Generates a log for the RSCD agent.txt file in a Windows installation. Do not modify this <category> tag.log"/--> <category name="rscdsvc" priority="info" appender="C:/Program Files/BMC Software/ BladeLogic/version/RSCD/rscdsvc. and appender.txt file category The <category> tag identifies the types of logging that BMC BladeLogic generates. This option only applies to Windows installations. priority. Logs only connection information. The following list shows the <category> tags included by default in the log4crc. which monitors the RSCD agent and restarts the agent if necessary. For more information. see “Enabling keystroke logging” on page 283.log" debugappender="stderr"/> <category name="bldeploy" priority="debug"/> <category name="bldeployConsole" priority="debug" appender="stdout"/> <categoryname="bldeployAppserver"priority="error"appender="blbasic"/> The name= option identifies the type of log file BMC BladeLogic generates. this is disabled (commented out). Uncomment it to enable keystroke logging. Do not modify this <category> tag. By default. Chapter 5 Setting up configuration files 273 . Agitator managed internally by Deploy Job executables. Do not modify this <category> tag. Generates a log for the RSCD agent server. Logs all errors. <category name="root" priority="info"/> <category name="rscd" priority="info1" appender="C:/Program Files/BMC Software/ BladeLogic/version/RSCD/rscd.

log. rscd. rscd. Logs connection information and user actions. For example. and all new information is recorded in rscd. STDERR. the <category> tag named rscd). Do not use a Network Shell-style path. This priority is only valid for the RSCD agent log (that is.log is renamed to rscd. You can specify that log files are rolled at specified intervals or when log files reach a particular size. appender The <appender> tag specifies whether logging information is stored as a stream in a file or periodically rolled over into a new file.log1. and STDOUT streams of the command being run by nexec. When a log file is rolled.log1. as well as all the system calls that an RSCD agent performs to execute user actions. the current log file is renamed to rscd. This priority corresponds to logging level 1 in older releases of BMC BladeLogic.txt file Priority info1 Description Logs connection information and user actions. This priority is only valid for the RSCD agent log (that is. When the log file is rolled again. All new information is then recorded in the rscd. The appender= tag provides a name and path for a log file. Logs all messages. Enter the path using a UNIX or Windows format. usually to prevent log files from getting excessively large. info2 debug Note that keystroke logs (where name is set to keystroke) support only the following options: Priority info info1 info2 Description Logs only the STDIN stream of the command being run by nexec.log2. 274 BMC BladeLogic Server Automation Administration Guide . the file is renamed with a number appended to its name. Logs the STDIN and STDERR streams of the command being run by nexec. Logs the STDIN. the <category> tag named rscd).log1 is renamed to rscd. This priority corresponds to logging level 2 in older releases of BMC BladeLogic. The <appender> tag also lets you specify secure agent logging and keystroke logging.log file.About the Log4crc.

log" type="rollfile" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="dated"/> The name= option must match the name (including its full path) assigned to an appender option in a <category> tag. For information about secure logging.pem" privatekeyfile="C:/WINDOWS/rsc/certificate. The following list shows the <appender> tags that are included by default in the log4crc.log" type="rollfile" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="dated"/> <!-appender name="C:/Program Files/BMC Software/BladeLogic/version/RSCD/ rscd. only one category can be output to a single log.log" type="digisign" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="dated" certfile="C:/WINDOWS/rsc/certificate. In other words. you cannot use type=rollfile to roll log files. see “Using secure agent logging” on page 277 and “Using keystroke log files” on page 281.pem"/--> <!-appender name="C:/Program Files/BMC Software/BladeLogic/version/RSCD/ keystroke.pem" privatekeyfile="C:/WINDOWS/rsc/certificate. Logging information is output to the UNIX syslog.log" type="encrypt" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="rawtime" certfile="C:/WINDOWS/rsc/certificate. Type stream syslog Description Logging information is output in a continuous stream to a file. Instead. If you are using this option for UNIX systems. you must set type=stream. If multiple sources are output to the same log. type.About the Log4crc. The type= option specifies what type of log file to generate. Chapter 5 Setting up configuration files 275 .pem"/--> <appender name="C:/Program Files/BMC Software/BladeLogic/version/RSCD/rscdsvc. you must configure the UNIX syslog daemon (see “Configuring the UNIX syslog” on page 284).txt file The <appender> tag can include three options: name. NOTE The two commented out entries (where type is set to digisign or encrypt) are used in secure logging. and layout. <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.txt file. The following table identifies the possible types: NOTE You can only roll log files when one source of logging data is being used to create a log file. a feature that is disabled by default.

As with rollfile. digisign needs the following additional parameters: certfile privatekeyfile Specifies the file containing the agent’s certificate.10. log files are rolled. the next time the log files roll over.10 is lost. 276 BMC BladeLogic Server Automation Administration Guide . The parameters rollsize. and rollmaxfiles mean the same as they do for 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. rolltimeinsec and rollmaxfiles mean the same as they do for rollfile. Specifies an interval in seconds for rolling log files. log entries and rolled log files are protected using the security mechanisms described in “Using secure agent logging” on page 277. Specifies the file containing the agent’s private key. For example. the information in file log. When the file reaches that maximum. rolltimeinsec. you can store log files named log. log entries and rolled log files are encrypted and protected using the security mechanisms described in “Using keystroke log files” on page 281. logging information is output to a file that is periodically rolled over into another file. The parameters rollsize. In addition to these parameters. if you have already generated ten log files. In this case. In addition to these parameters. If you set type=rollfile. if you set rollmaxfiles=10. Specifies the maximum number of files used for logging. rolltimeinsec rollmaxfiles digisign As with rollfile.1 to log. encrypt Used for keystroke log files. In addition. In addition. Specifies the file containing the agent’s private key. encrypt needs the following additional parameters: certfile privatekeyfile Specifies the file containing the agent’s certificate.txt file Type rollfile Description Logging information is output to a file that is periodically rolled over into another file. logging information is output to a file that is periodically rolled over into another file.About the Log4crc.

Except for the time stamp. Users should not modify the syntax of the <layout> tag. Protecting rolled log files with digital signatures. and recording the status of each verification. log entries use the same format as the data that is generated for the log message. This layout outputs minimal information in the log file—just the timestamp and the actual message. Verifying the integrity of log files. 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.txt file The layout= option specifies the type of layout used for logging information. It does not output the category name and log level that the basic and dated layouts do. Chapter 5 Setting up configuration files 277 . 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. To develop additional logging formats. contact BMC Software support. A time stamp precedes all log entries. The following table identifies all possible layouts: Type basic dated Description Log entries use the same format of the data that is generated for the log message. rawtime <layout> The <layout> tag defines the format of logging entries.About the Log4crc. Used only when type is set to encrypt. You can later check log file integrity by using the bllogman command. ■ ■ For additional information about secure agent logging.

the status field is set to Inconsistent. the status field is set to Consistent.About the Log4crc. the order) of each log entry. The following events take place at rollover: ■ MAC verification test and sequencing test. The agent will use this key to calculate a Message Authentication Code (MAC) for each entry in the log file.log. When this log file is rolled and it is time to start a new log file.222 23694 99/99 (Administrator): nexec: nexec engrhes40vm10 ifconfig -a 3. The RSCD agent starts writing its first log file—rscd. Before beginning to write its first log file. It also associates a sequence number with each entry. As it writes each log entry. The agent creates a corresponding digital signature file for the rolled log file rscd. rscd. ■ Digital signature file.269 INFO rscd . Note that this session key will be used only for the writing of this one log file. If the rolled log file failed the MAC test or the sequencing test. It also verifies the sequence number (or in other words. the agent will generate a new session key.log1. 278 BMC BladeLogic Server Automation Administration Guide .log1. it uses the session key to calculate a MAC and associate this MAC with each log entry.21. the RSCD agent generates a random session key. The agent verifies the integrity of each log entry in the rolled log file. 2. — The signature file has a status field. rscd. If the rolled log file passed the MAC test and the sequencing test. When it is time for a rollover.sig1.log is rolled to rscd. the corresponding signature file would be called rscd. MAC Sequence number 3d8591f27a805b0edac5 0000000012 07/28/07 02:45:16.log. 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.10. In this case. against each entry’s MAC.20.txt file 1.log1.

Example: engw2k3agt1% bllogman list --verify engrhes40vm10 Logfile(s) for host engrhes40vm10 with status: /opt/bmc/BladeLogic/version/NSH/log/rscd. the signature file will be rolled along with its associated log file. — At the next roll. the previous log file is automatically rolled and signed at agent startup.log3) is reported as Inconsistent. engrhes40vm10. 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. The cycle begins again. One file (rscd. with the creation of a new random session key for use in creating MACs for the next version of rscd. Verifying the integrity of log files You can verify the integrity of all agent log files by using the NSH command.About the Log4crc. — The MAC and sequence number fields are stripped as part of the process of signing the rolled log file. as described in “Verifying the integrity of log files” on page 279. as described the procedure below. The agent also does the MAC verification test and sequencing test on the rolled log file. Chapter 5 Setting up configuration files 279 . bllogman. NOTE If an agent is restarted.log1 () --> Consistent /opt/bmc/BladeLogic/version/NSH/log/rscd.log3 () --> Inconsistent /opt/bmc/BladeLogic/version/NSH/log/rscd. For additional information about bllogman.log () --> Consistent /opt/bmc/BladeLogic/version/NSH/log/rscd.log. see the bllogman man page. 4. which indicates that it has been tampered with.txt file You can use the information stored in the status field to verify the integrity of a rolled log file.log4 () --> Consistent engw2k3agt1% In the above example. there are five log files on the agent machine.log2 () --> Consistent /opt/bmc/BladeLogic/version/NSH/log/rscd.

log" type="digisign" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="dated" certfile="C:/WINDOWS/rsc/certificate. 3 Stop the RSCD agent.log1. These files have names like rscd.log2. rscd.txt configuration file: 280 BMC BladeLogic Server Automation Administration Guide . 4 Make the following changes to the log4crc.log1. NOTE On UNIX agents. 3 Delete all the agent log files.log" type="rollfile" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="dated"/--> Uncomment or add the following entry where type is set to digisign: <appender name="C:/Program Files/BMC Software/BladeLogic/version/RSCD/rscd. 2 Back up all your existing agent log files (if any). rscd. remove or comment out the rscd. and so on. See the BMC BladeLogic Server Automation Installation Guide for more information.log.txt configuration file: In the <appender> section. rscd. usual rolling logs will be generated. 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. Disabling secure agent logging If you have enabled secure agent logging and you now want to disable it: 1 Back up the certificate. Otherwise. These files have names like rscd. and so on. 5 Make the following changes to the log4crc.pem" privatekeyfile="C:/ WINDOWS/rsc/certificate. rscd.pem file and the signature files.pem"/> 5 Start the RSCD agent. 2 Stop the RSCD agent.About the Log4crc.log.log appender entry that has type set to rollfile: <!-appender name="C:/Program Files/BMC Software/BladeLogic/version/RSCD/ rscd.txt file 1 Back up all your existing agent log files (if any). 4 Delete all the agent log files.log2.

keystroke logs are encrypted and so are not readable. Similar to the secure agent logs.About the Log4crc. or a particular keystroke log file on an agent machine.pem" privatekeyfile="C:/WINDOWS/rsc/certificate. each keystroke log file is accompanied by a digital signature file.pem"/>--> ■ Start the RSCD agent. add or uncomment the rscd. Additionally.log" type="rollfile" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="dated" Comment out or delete the following entry where type is set to digisign: <!--<appender name="C:/Program Files/BMC Software/BladeLogic/version/RSCD/ rscd. STDOUT. Using keystroke log files You can configure the BMC BladeLogic RSCD agent to generate keystroke logs that record nexec sessions.log" type="digisign" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="dated" certfile="C:/WINDOWS/rsc/certificate.log appender entry that has type set to rollfile: appender name="C:/Program Files/BMC Software/BladeLogic/version/RSCD/rscd. which lets you verify the integrity of a keystroke log file. Whenever a remote user uses the NSH command nexec to execute a command on an agent machine.txt file In the <appender> section. you can verify the integrity of all the keystroke logs on an agent machine. 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. the keystroke log captures and stores the command’s STDIN. By using the NSH command blkeylogman. and STDERR streams. Chapter 5 Setting up configuration files 281 .

log6 () --> Consistent /opt/bmc/BladeLogic/version/NSH/log/keystroke. The active keystroke log file (/opt/bmc/BladeLogic/version/NSH/log/keystroke.log3 () --> Consistent /opt/bmc/BladeLogic/version/NSH/log/keystroke.log in the above example) is also protected by MAC codes and sequence numbers.txt file Example: engw2k3agt1% blkeylogman list --verify engrhes40vm10 Keystroke Logfile(s) for host engrhes40vm10 with status: \ /opt/bmc/BladeLogic/version/NSH/log/keystroke. the agent tests it for consistency using the MACs and the sequence numbers.log9 () --> Consistent /opt/bmc/BladeLogic/version/NSH/log/keystroke. View a list of various nexec sessions that have been recorded in the keystroke logs.log5 () --> Inconsistent /opt/bmc/BladeLogic/version/NSH/log/keystroke. One file (keystroke. If the log file was detected Inconsistent during this process. there are ten keystroke log files on the agent machine.log5) is reported as Inconsistent. The blkeylogman utility also lets you: ■ View the decrypted contents of keystroke log files. an event is raised (In the Eventlog on Windows and syslog on UNIXstyle systems).log4 () --> Consistent /opt/bmc/BladeLogic/version/NSH/log/keystroke. 282 BMC BladeLogic Server Automation Administration Guide .log7 () --> Consistent /opt/bmc/BladeLogic/version/NSH/log/keystroke.log8 () --> Consistent /opt/bmc/BladeLogic/version/NSH/log/keystroke.log1 () --> Consistent /opt/bmc/BladeLogic/version/NSH/log/keystroke. These two are then stripped off from the file and a digital signature is computed for it.log () --> Consistent /opt/bmc/BladeLogic/version/NSH/log/keystroke.log10 () --> Consistent engw2k3agt1% In the above example. ■ ■ For more details.log2 () --> Consistent /opt/bmc/BladeLogic/version/NSH/log/keystroke. which indicates that it has been tampered with. see the blkeylogman man page.About the Log4crc. Copy a (decrypted) keystroke log file from an agent to the client host. MAC Sequence number 967ff34b84f754c0774a 0000000011 Zl8abih3bvmLNHwTnE4iK5UqeYXWMk2ZQ4 2xdR3nNo8lE2/xUoVxPOd8CSlg7hAygMQgO7D6VmbB2QZVAG6ucg== When the active keystroke log file is rolled.

if the server on which the agent is running has either a working random number generator or PRNGD installed. keystroke logging is only enabled (even if you have followed these steps).About the Log4crc.txt configuration file: In the <category> section. as described in “Enabling keystroke logging” on page 283. 1 Stop the RSCD agent. Disabling keystroke logging If you have enabled keystroke logging and you now want to disable it: 1 Back up the certificate. uncomment or add the following entry. 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. To disable keystroke logging.pem" privatekeyfile="C:/WINDOWS/rsc/certificate. where type is set to encrypt: <appender name="C:/Program Files/BMC Software/BladeLogic/version/RSCD/ keystroke.pem"/> 3 Start the RSCD agent.log" type="encrypt" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="rawtime" certfile="C:/WINDOWS/rsc/certificate. See the BMC BladeLogic Server Automation Installation Guide for more information.txt file You can enable keystroke logs as part of your initial installation (see the BMC BladeLogic Server Automation Installation Guide) or later on.log"/> In the <appender> section.pem file.txt configuration file: Chapter 5 Setting up configuration files 283 . where name is set to keystroke: <categoryname="keystroke"priority="info1"appender="C:/ProgramFiles/BMC Software/BladeLogic/version/RSCD/keystroke. NOTE On UNIX agents. 2 Stop the RSCD agent. 2 Make the following changes to the log4crc. uncomment or add the following entry. see “Disabling keystroke logging” on page 283. 3 Make the following changes to the log4crc. as described in the procedure below.

debug /var/log/rscd-syslog BMC BladeLogic uses the local6 facility.pem" privatekeyfile="C:/WINDOWS/rsc/certificate. where type is set to encrypt: <!--<appender name="C:/Program Files/BMC Software/BladeLogic/version/RSCD/ keystroke.conf.log" type="encrypt" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="rawtime" certfile="C:/WINDOWS/rsc/certificate. configure a facility. you must configure the syslog daemon to accept output from BMC BladeLogic. and a location for the syslog by creating an entry like the following: local6.pem"/>--> ■ Start the RSCD agent. Configuring the UNIX syslog If you are logging output to the UNIX syslog. Within /etc/syslog. where name is set to keystroke: <!--<category name="keystroke" priority="info1" appender="C:/Program Files/BMC Software/BladeLogic/version/RSCD/keystroke.About the Log4crc.log"/>--> In the <appender> section. a priority level.txt file In the <category> section. comment out or delete the following entry. comment out or delete the following entry. 284 BMC BladeLogic Server Automation Administration Guide .

txt file Default default log4crc.0" encoding="ISO-8859-1"?> <!DOCTYPE log4c SYSTEM ""> <log4c version="1.log"/--> <category name="rscdsvc" priority="info" appender="C:/Program Files/BMC Software/BladeLogic/ version/RSCD/rscdsvc.log" type="encrypt" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="rawtime" certfile="C:/WINDOWS/rsc/certificate.1.default appenders ===================================== --> <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"/> <!-.log" type="rollfile" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="dated"/> <!-.0"> <!-.About the Log4crc.pem"/--> <appender name="C:/Program Files/BMC Software/BladeLogic/version/RSCD/rscdsvc.pem" privatekeyfile="C:/WINDOWS/rsc/certificate. <?xml version="1.root category ========================================= --> <category name="root" priority="info"/> <category name="rscd" priority="info1" appender="C:/Program Files/BMC Software/BladeLogic/ version/RSCD/rscd.txt file examples The following is an example of a default log4crc.pem"/--> <!-appender name="C:/Program Files/BMC Software/BladeLogic/version/RSCD/keystroke.default layouts ======================================= --> <layout name="basic" type="basic"/> <layout name="dated" type="dated"/> <layout name="rawtime" type="rawtime"/> </log4c> Chapter 5 Setting up configuration files 285 .log" debugappender="stderr"/> <category name="bldeploy" priority="debug"/> <category name="bldeployConsole" priority="debug" appender="stdout"/> <category name="bldeployAppserver" priority="error" appender="blbasic"/> <!-.pem" privatekeyfile="C:/WINDOWS/rsc/certificate.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.txt file for a Windows installation.log" debugappender="stderr"/> <!--categoryname="keystroke"priority="info1"appender="C:/ProgramFiles/BMCSoftware/ BladeLogic/version/RSCD/keystroke.

<?xml version="1.pem" privatekeyfile="/usr/lib/rsc/certificate.log"/--> <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"/> <!-.default appenders ===================================== --> <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="encrypt" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="rawtime" certfile="/usr/ lib/rsc/certificate.txt file The following is an example of a default log4crc.0" encoding="ISO-8859-1"?> <!DOCTYPE log4c SYSTEM ""> <log4c version="1.log" type="rollfile" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="dated"/> <!-.log" debugappender="stderr"/> <!--categoryname="keystroke"priority="info1"appender="/opt/bmc/BladeLogic/version/ NSH/log/keystroke.1.appender name="/opt/bmc/BladeLogic/version/NSH/log/rscd.About the Log4crc.pem"/--> <!--appendername="/opt/bmc/BladeLogic/version/NSH/log/keystroke.pem"/--> <appender name="/tmp/rscdsvc.default layouts ======================================= --> <layout name="basic" type="basic"/> <layout name="dated" type="dated"/> <layout name="rawtime" type="rawtime"/> </log4c> 286 BMC BladeLogic Server Automation Administration Guide .log" type="rollfile" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="dated"/> <!-.txt file for a UNIX-style installation.pem" privatekeyfile="/usr/lib/rsc/certificate.0"> <!-.root category ========================================= --> <category name="root" priority="info"/> <categoryname="rscd"priority="info1"appender="/opt/bmc/BladeLogic/version/NSH/log/ rscd.log" type="digisign" rollsize="10000000" rolltimeinsec="2419200" rollmaxfiles="10" layout="dated" certfile="/usr/lib/ rsc/certificate.

The database clean-up utility also deletes old audit trail entries. For information. This data consists of old files that are no longer accessed. and compliance results. or all accessible Application Servers. see “Cleaning up target servers (Agents)” on page 293. and auto-remediation. the objects are deleted from the database the next time the database clean-up utility is run. You can delete these files by using the repeater clean-up utility. The BMC BladeLogic Database. see “Cleaning the Application Server cache” on page 293. You can manage data in these areas: ■ The BMC BladeLogic Console. For information. You can reduce clutter in your workspace from objects created by job runs. For information. These tools let you delete unused data or data no longer needed for BMC BladeLogic operations. snapshot results. For information. You can reduce the amount of space taken up by unused data in the database by executing the database clean-up utility. you can use the target server clean-up utility to delete these files. For information. Repeater Servers. 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. see “Cleaning up repeater servers” on page 294. ■ ■ ■ ■ Chapter 6 Managing BMC BladeLogic data 287 . patch analysis. You can mark these objects for deletion. see “Marking data for deletion” on page 289. audit results.Chapter 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. You can delete data that has accumulated on target servers (BMC BladeLogic agents) from Deploy Jobs. Data from Deploy Jobs can also accumulate in the staging directory on repeater servers. the Application Server to which you are connected. This utility lets you delete old temporary files from a specific Application Server. Target Servers (Agents). 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. see “Cleaning up the BMC BladeLogic database” on page 288.

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’. the initial result displays until the cleanup completes. to avoid longrunning clean-up runs.Cleaning up the BMC BladeLogic database ■ The BMC BladeLogic File Server. see “Cleaning up the file server” on page 295. Objects marked as deleted with the retention policy utility. Cleaning up the BMC BladeLogic database BMC BladeLogic provides a database clean-up utility (cleanupDatabase) to minimize the amount of space taken up by unused data. You can delete unused files from the file server. if you query again. Before using the database clean-up utility. 288 BMC BladeLogic Server Automation Administration Guide . see the BLCLI Help. The result drops to 0 when the cleanup completes. This data includes: ■ Objects users have already deleted in the BMC BladeLogic Console. While the database clean-up utility is running. you must first start the Network Shell and then start the BMC BladeLogic command line interface (CLI). This clean-up utility deletes any data from the database that has been previously marked for deletion. For information. For more information on the CLI. For information on the retention policy utility. TIP BMC Software recommends that you run the clean-up utility once per week. see “Marking data for deletion” on page 289. 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. These objects include old job runs and job and depot objects automatically created during patching and auto-remediation. To run the database clean-up utility. see “Executing the database clean-up utility” on page 292. ■ About the clean-up utility The database clean-up utility works in conjunction with the retention policy utility. To execute the retention policy utility using the CLI or to run the database clean-up utility.

Once they are marked for deletion. Marking data for deletion BMC BladeLogic includes a retention policy utility that allows you to mark objects for deletion from the BMC BladeLogic database. see “Setting the retention period for automatically-generated objects” on page 291. see “Setting the retention period for job runs” on page 290. Enabling/disabling the retention policy utility The following procedure lets you enable or disable the retention policy. you can use the CLI to run the Delete:cleanupHistoricalData command. Once they are marked for deletion. By enabling the utility and setting the retention period. See “Enabling/disabling the retention policy utility” on page 289. By default. ■ For information on setting the retention period for job runs. (In addition. such as audit trail information and job run events. the objects are deleted from the database the next time the database clean-up utility is run. the objects are deleted from the database the next time the database clean-up utility is run.Marking data for deletion If you want to remove historical data. These objects include old job runs and job and depot objects automatically created during patching and auto-remediation. For more information on this command see the BLCLI Help. 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. ■ 3 Execute the retention policy utility. See “Executing the retention policy utility” on page 291. 2 Set the retention period for objects you want to mark for deletion. The following master procedure summarizes the steps for marking job runs for deletion: 1 Enable the retention policy utility. the retention policy utility is not enabled to avoid the possibility of deleting data unknowingly.) 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. For information on setting the retention period for automatically-generated objects. Chapter 6 Managing BMC BladeLogic data 289 . files associated with the objects are deleted from the File Server the next time the file server clean-up utility is run.

see the BMC BladeLogic Server Automation User Guide. set the RESULTS_RETENTION_TIME property for the Job property class in the Property Dictionary. which lets you mark objects for deletion from the BMC BladeLogic database. do any of the following: ■ To set the default retention period for all jobs. (See “Starting the Application Server Administration console” on page 45. For details on setting a property using the Property Dictionary. To set the number of days to retain job runs before marking them for deletion. ■ ■ 290 BMC BladeLogic Server Automation Administration Guide . enter the following: set Cleanup EnableRetentionPolicy true|false Where: true — Enables the retention policy utility. set the RESULTS_RETENTION_TIME property using the Properties tab for a specific job. see the BMC BladeLogic Server Automation User Guide.Marking data for deletion 1 Start the Application Server Administration console. 3 Restart the Application Server to have this change take effect. To set the default retention period for job runs of a specific job.) Setting the retention period for job runs You can set the number of days to retain job runs before marking them for deletion. 2 To enable or disable the retention policy utility. To set the default retention period for all jobs of a specific type. see the BMC BladeLogic Server Automation User Guide. set the RESULTS_RETENTION_TIME property for the specific job property class in the Property Dictionary (for example. as described in “Starting the Application Server Administration console” on page 45. In addition. For information on setting property values using the Properties tab for a system object (such as a job). (Objects are deleted from the database the next time the database clean-up utility is run. For details on setting a property using the Property Dictionary. You cannot mark objects for deletion during database cleanup. files associated with the objects are deleted from the file server the next time the file server clean-up utility is run. the SnapshotJob property class).) false — Disables the retention policy utility.

2 If you have not cached your session credentials. as described in “Starting the Application Server Administration console” on page 45. the CLI prompts you for a user name and password. see “Starting the Application Server Administration console” on page 45. 3 Restart the Application Server to have this change take effect. For example.Marking data for deletion NOTE The most specific retention value will be used when executing a retention policy. a specific job value overrides any value defined for the specific job type or for all job types. do the following: 1 Start the Application Server Administration console. Enter a user name and password that you use for accessing BMC BladeLogic. see the Delete name space of BLCLI Help. Executing the retention policy utility To execute the retention policy utility. Setting the retention period for automatically-generated objects To set the number of days to retain automatically-generated objects before marking them for deletion. For information. Chapter 6 Managing BMC BladeLogic data 291 . 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). do the following: 1 Start the Network Shell and then issue the CLI command that executes the retention policy utility by entering the following: #nsh Server1% blcli Delete executeRetentionPolicy For more information about this command.

the CLI prompts you for a user name and password. see “Marking data for deletion” on page 289. see the Delete name space of BLCLI Help. storing this information in the credentials cache. storing this information in the credentials cache. your role must be granted the BL_Administration. Executing the database clean-up utility Use this procedure to remove superfluous BMC BladeLogic data from Oracle and SQL Server databases. For information. TIP BMC Software recommends that you run the clean-up utility once per week.System_Cleanup authorization. For information. you can cache your authentication information for repeated use over a given time period. 292 BMC BladeLogic Server Automation Administration Guide . see “Single sign-on” on page 121. you can cache your authentication information for repeated use over a given time period. 1 Start the Network Shell and then issue the CLI command that executes the database clean-up utility by entering the following: #nsh Server1% blcli Delete cleanupDatabase For more information about this command. to avoid longrunning clean-up runs. Enter a user name and password that you use for accessing BMC BladeLogic.Executing the database clean-up utility NOTE If you are authenticating with SRP. For information on using the retention policy utility. For information. NOTE If you are authenticating with SRP. To execute a database clean-up operation. see “Single sign-on” on page 121. see the Delete name space of BLCLI Help. 2 If you have not cached your session credentials. NOTE BMC BladeLogic also provides the performFullCleanupJob CLI command for database cleanup.

To delete these objects from a target server. The utility lets you specify parameters for the cleanup.System_Cleanup authorization. the target server clean-up utility uses the value of the server’s TRANSACTIONS_DIR property to locate the transactions directory. These files are temporary files no longer needed after the operation. You can also use the utility to clean up caches of all accessible Application Servers. NOTE If you are authenticating with SRP. For information. see the Delete name space of BLCLI Help. storing this information in the credentials cache. Chapter 6 Managing BMC BladeLogic data 293 . such as Application Server name and the minimum elapsed time before files can be considered for deletion. your role must be granted the BL_Administration. see “Single sign-on” on page 121. transaction information and log files are created on the target servers and in certain cases are not deleted.Cleaning the Application Server cache Cleaning the Application Server cache Each Application Server has a file cache (directory) containing files that it uses for operations it performs. Cleaning up target servers (Agents) During Deploy Jobs. To execute a clean-up operation. see the BMC BladeLogic Server Automation User Guide. For information on configuring this property. the CLI prompts you for a user name and password. you can cache your authentication information for repeated use over a given time period. These files are temporary and will probably no longer be accessed. Enter a user name and password that you use for accessing BMC BladeLogic. objects such as BL packages. use the target server clean-up utility To clean up transactions. 2 If you have not cached your session credentials. 1 Start the Network Shell and then issue the CLI command that executes the Application Server cache clean-up utility by entering the following: #nsh Server1% blcli Delete cleanupAppServerCache <retention time> For more information about this command. you can use the Application Server cache clean-up utility to delete them from the cache.

Cleaning up repeater servers Old temporary files from Deploy Jobs can accumulate in the staging directory on 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: #nsh Server1% blcli Delete cleanupAgent For more information about this command.System_Cleanup authorization. use the command in a Network Shell Script Job. such as maximum size for the staging directory and the minimum elapsed time before files can be considered for deletion. You can use the repeater clean-up utility to delete these files. See “Scheduling the target server (Agent) cleanup” on page 300. To clean up a set of target servers. To execute a clean-up operation. For information. your role must be granted the BL_Administration. the CLI prompts you for a user name and password. Enter a user name and password that you use for accessing BMC BladeLogic. your role must be granted the BL_Administration. NOTE If you are authenticating with SRP. see the Delete name space of BLCLI Help. 1 Start the Network Shell and then issue the CLI command that executes the repeater server clean-up utility by entering the following: #nsh Server1% blcli Delete cleanupRepeater For more information about this command.System_Cleanup authorization. you can cache your authentication information for repeated use over a given time period. 294 BMC BladeLogic Server Automation Administration Guide . see the Delete name space of BLCLI Help.Cleaning up repeater servers To execute a clean-up operation. 2 If you have not cached your session credentials. The utility lets you specify parameters for the cleanup. storing this information in the credentials cache. see “Single sign-on” on page 121.

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. storing this information in the credentials cache. 2 If you have not cached your session credentials. see the Delete name space of BLCLI Help. you must run the Delete updateDeleteDependencies to remove these directories. For information. Neither the file server clean-up utility or database clean-up utility removes these directories. the CLI prompts you for a user name and password. it creates a subdirectory under the BLPackage directory for every iteration. Before you begin When a Custom Package Deploy Job runs. see “Single sign-on” on page 121. Enter a user name and password that you use for accessing BMC BladeLogic. 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: #nsh Server1% blcli Delete cleanupFileServer For more information about this command. Prior to running the Delete cleanupFileServer command. Chapter 6 Managing BMC BladeLogic data 295 . you can cache your authentication information for repeated use over a given time period. Even after the job run history is removed by the retention policy. these directories still exist. NOTE If you are authenticating with SRP. Cleaning up the file server When users delete objects from the BMC BladeLogic Console. the CLI prompts you for a user name and password. Enter a user name and password that you use for accessing BMC BladeLogic.Cleaning up the file server 2 If you have not cached your session credentials.

However. enter the command and specify a value for the objectName variable. you can delete all historical data or only one specific type of object. Enter a user name and password that you use for accessing BMC BladeLogic. 1 Start the Network Shell and then issue the CLI command that executes the historical data clean-up utility by entering the following: #nsh Server1% blcli Delete cleanupHistoricalData This command deletes all historical data. the database clean-up utility (cleanupDatabase) cleans up historical data from the database. storing this information in the credentials cache. The utility deletes the following objects: ■ ■ ■ ■ ■ ■ Old audit trail entries Audit results Job run events Compliance results Snapshot results Job schedules Using this utility. Cleaning up historical data As part of its operation. the CLI prompts you for a user name and password. 2 If you have not cached your session credentials. you can also clean up historical data by using the historical data clean-up utility. snapshot results. For information. To clean up one specific type of object. for example. see “Single sign-on” on page 121. see the Delete name space of BLCLI Help.Cleaning up historical data NOTE If you are authenticating with SRP.System_Cleanup authorization. For more information about this command. your role must be granted the BL_Administration. 296 BMC BladeLogic Server Automation Administration Guide . To execute a clean-up operation. you can cache your authentication information for repeated use over a given time period.

) 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. 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”.) Target server (agent) cleanup (See “Scheduling the target server (Agent) cleanup” on page 300. Scheduling the cleanup The clean-up utilities can be run as Network Shell Script Jobs. For information. The script should consist of the CLI command that invokes the utility: blcli Delete executeRetentionPolicy Chapter 6 Managing BMC BladeLogic data 297 . create a Network Shell script to run the retention policy utility. storing this information in the credentials cache. you can cache your authentication information for repeated use over a given time period. see “Single sign-on” on page 121. 1 In a text editor.) Repeater cleanup (See “Scheduling the repeater server cleanup” on page 300.Scheduling the cleanup NOTE If you are authenticating with SRP. Running a utility as a script job lets you schedule the job so it executes on a regular basis rather than running it interactively.) ■ ■ ■ ■ ■ 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 retention policy utility to mark data for deletion Use this procedure to run the retention policy utility as a Network Shell Script Job.) Database cleanup (See “Scheduling the database cleanup” on page 298.

create a Network Shell script to run the database clean-up utility. B Schedule the job to run at a frequency you prefer. 3 Create a Network Shell Script Job based on the script you added to the Depot in the previous step. TIP BMC Software recommends that you run the clean-up utility once per week.Scheduling the database cleanup 2 Using the BMC BladeLogic Console. specify the server functioning as the Application Server. For information. to avoid longrunning clean-up runs. choose the first option. B Schedule the job to run at a frequency you prefer. add the Network Shell script to the Depot. 1 In a text editor. specify the server functioning as the Application Server. A Assign any name to the script. see the BMC BladeLogic Server Automation User Guide. For information. Scheduling the database cleanup Use this procedure to run the database clean-up utility as a Network Shell Script Job. The script should consist of the CLI command that invokes the utility: blcli Delete cleanupDatabase 2 Using BMC BladeLogic Console. see the BMC BladeLogic Server Automation User Guide. add the Network Shell script to the Depot. For information. B When you specify the Script Type. choose the first option. 298 BMC BladeLogic Server Automation Administration Guide . see the BMC BladeLogic Server Automation User Guide. see the BMC BladeLogic Server Automation User Guide. 3 Create a Network Shell Script Job based on the script you added to the Depot in the previous step. A Assign any name to the script. A For the target server. A For the target server. B When you specify the Script Type. For information.

create a Network Shell script to run the Application Server cache clean-up utility. A Assign any name to the script. choose the first option. add the Network Shell script to the Depot. A Assign any name to the script. The script should consist of the CLI command that invokes the utility: blcli Delete cleanupFileServer 2 Using BMC BladeLogic Console. 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. B When you specify the Script Type. B Schedule the job to run at a frequency you prefer. A For the target server. 1 In a text editor. choose the first option. Chapter 6 Managing BMC BladeLogic data 299 . Scheduling the Application Server cache cleanup Use this procedure to run the Application Server cache clean-up utility as a Network Shell Script Job. For information. For information. add the Network Shell script to the Depot. see the BMC BladeLogic Server Automation User Guide. 1 In a text editor. create a Network Shell script to run the file server clean-up utility. B When you specify the Script Type. See “Cleaning up the file server” on page 295 for notes on pre-requisites for running the utility. For information. see the BMC BladeLogic Server Automation User Guide. specify the server functioning as the Application Server. The script should consist of the CLI command that invokes the utility: blcli Delete cleanupAppServerCache <retention time> 2 Using the BMC BladeLogic Console. 3 Create a Network Shell Script Job based on the script you added to the Depot in the previous step.

The script should consist of the CLI command that invokes the utility: blcli Delete cleanupRepeater 2 Using the BMC BladeLogic Console. see the BMC BladeLogic Server Automation User Guide. B Schedule the job to run at a frequency you prefer. B When you specify the Script Type. The script should consist of the CLI command that invokes the utility: blcli Delete cleanupAgent 300 BMC BladeLogic Server Automation Administration Guide . choose the first option. add the Network Shell script to the Depot. B Schedule the job to run at a frequency you prefer.Scheduling the repeater server cleanup 3 Create a Network Shell Script Job based on the script you added to the Depot in the previous step. Scheduling the repeater server cleanup Use this procedure to run the repeater server clean-up utility as a Network Shell Script Job. For information. Scheduling the target server (Agent) cleanup Use this procedure to run the target server clean-up utility as a Network Shell Script Job. see the BMC BladeLogic Server Automation User Guide. see the BMC BladeLogic Server Automation User Guide. For information. specify the repeater servers you want to clean up. A For the target server. specify the server functioning as the Application Server. A Assign any name to the script. For information. create a Network Shell script to run the repeater server clean-up utility. A For the target server. create a Network Shell script to run the target server (agent) cleanup utility. 3 Create a Network Shell Script Job based on the script you added to the Depot in the previous step. 1 In a text editor. 1 In a text editor.

add the Network Shell script to the Depot.Scheduling the target server (Agent) cleanup 2 Using the BMC BladeLogic Console. A Assign any name to the script. specify the target servers (agents) you want to clean up. 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. see the BMC BladeLogic Server Automation User Guide. A For the target server. Chapter 6 Managing BMC BladeLogic data 301 . B Schedule the job to run at a frequency you prefer. B When you specify the Script Type. For information. choose the first option.

Scheduling the target server (Agent) cleanup 302 BMC BladeLogic Server Automation Administration Guide .

You can also configure bandwidth throttling on links between the Advanced File Server and the Advanced Repeater. With the standard BMC BladeLogic Server Automation file server and repeater. Overview Using advanced file servers and Advanced Repeater servers can help you improve the bandwidth utilization between the central file server and the repeaters.Chapter 7 Configuring Advanced File Servers and Advanced Repeaters 7 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. 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. Figure 1 shows a sample configuration. Chapter 7 Configuring Advanced File Servers and Advanced Repeaters 303 .

Both the Advanced Repeater and Advanced File Server are built on BMC BladeLogic Server Automation Client Automation technology. the Transmitter (used by the Advanced File Server). 304 BMC BladeLogic Server Automation Administration Guide . and the BMC BladeLogic Server Automation Client Automation Proxy (used by the Advanced Repeater server).Key terms Figure 1 Sample configuration Key terms The BMC BladeLogic Advanced Repeater is the combination of Advanced File Server and Advanced Repeater server. The three key components are the Content Replicator. It uses the BMC BladeLogic Server Automation Client Automation master transmitter component to hold a second copy of the depot content in a compressed. ■ Advanced File Server .an enhanced Java application server running on an existing File Server. proprietary format that is well suited to providing bandwidth efficient transfer of data. The following list defines some of these key terms.

NOTE For instructions on installing the BMC BladeLogic Advanced Repeater.used to publish the content from the existing file server to the Transmitter on the Advanced File Server. Ability to manage the use of network resources by the Advanced File Server and Advanced Repeater server.What is the BMC BladeLogic Advanced Repeater? ■ Advanced Repeater . Content Replicator . Advanced Repeater installer . ■ ■ What is the BMC BladeLogic Advanced Repeater? The BMC BladeLogic Advanced Repeater provides scalable transport of data over wide-area networks. using the BMC BladeLogic Server Automation Client Automation proxy. Any targets which are not configured to use a repeater stage the data directly on the target. ■ If the BMC BladeLogic Advanced Repeater components have been installed. any targets which have been configured through Routing Rules to use an Advanced Repeater will make use of the BMC BladeLogic Advanced Repeater. which use the BMC BladeLogic Advanced Repeater. Chapter 7 Configuring Advanced File Servers and Advanced Repeaters 305 . See “Best practice information” on page 306. consider setting up Advanced File Servers and using Advanced Repeater servers. An RSCD agent must be installed on the servers hosting both the Advanced Repeater and Advanced File Server components.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. you can configure an Advanced File Server and one or more Advanced Repeaters. Using BMC BladeLogic Advanced Repeater technology enables file servers and repeater servers to store and share deploy data efficiently.the Advanced Repeater and Advanced File Server are both installed from the same installation file. If you are using deploy jobs in a large-scale environment. and is an alternate option when configuring file servers or repeater servers. Any targets which have been configured to use a standard repeater continue to do so. see “Installing the BMC BladeLogic Server Automation Advanced Repeater” on page 307. It is also used to pull the content down to the file system on the Advanced Repeater. When a Deploy Job is run and is set for indirect staging. Using the BMC BladeLogic Advanced Repeater technology for deploying data offers several key benefits: ■ Improved performance of staging data for deploy jobs.

such as diffing. CPU utilization The advanced file server does not make intensive usage of the CPU. BMC BladeLogic recommends that the file server have 200 GB or more of available RAID 5 disk space. it runs in limited disk space mode. An Advanced File Server cannot be disabled if there are existing Advanced Repeater servers. In limited disk space mode. 306 BMC BladeLogic Server Automation Administration Guide . disk space. but the CPU usage will spike when new content is published as this needs to be compressed. When the BMC BladeLogic Advanced Repeater has enough disk space.Best practice information 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. and attempts to maintain at least 10% free disk space. In addition. It is possible to run the transmitter with less than optimal disk space. and starts maintaining free disk space instead. and compressing. caching. 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. The Advanced Repeater transmitter component uses the additional space for optimizations that improve the efficiency of data replication. Memory utilization The default Java heap size is configured for a maximum of 512MB in the advanced file server. by removing cache files to reduce the amount of storage. the transmitter stops maintaining storage size ratio. If the transmitter does not have enough disk space to maintain the optimal storage size ratio. but efficiency degrades. it maintains three times the size of the data as cache. This setting means that about 1GB RAM should be allowed to run the advanced file server. using SSL also increases the CPU usage by about 40% due to the encryption and decryption of the content. non-redundant.

copy the installation file to a directory on the server you want to configure as an Advanced File Server or Advanced Repeater Server. Chapter 7 Configuring Advanced File Servers and Advanced Repeaters 307 . In Linux Environments. 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.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. 5 On the Welcome screen. click OK. click Next. The installer files applicable to the Advanced Repeater are labeled BMC BladeLogic Advanced Repeater for hostPlatform on the EPD site. upload the installer bin to the file server or repeater server. ■ 3 Start the BMC BladeLogic installation program for your platform. 4 On the BMC BladeLogic Server Automation Advanced Repeater Installation screen. Different installers are provided for 32-bit and 64-bit Windows. 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. 2 Do one of the following: ■ In Microsoft Windows environments. 6 Accept the license agreement and click Next.

— Click Next. Click Next. NOTE The default installation folder (AdvancedRepeater) is the same for both Advanced File Server and Advanced Repeater Server.Installing using the installation program 7 Specify the destination directory. NOTE You must use the RPC port number that was set during installation. 308 BMC BladeLogic Server Automation Administration Guide . 12 When the installation completes. Specify an integer between 0 and 65535. The Advanced Repeater Credentials window opens. The default port is 7717. The default port is 8081. Specify an integer between 0 and 65535. or accept the default. or accept the default credentials by selecting Use default tuner credential settings. Specify this TCP port if you are installing the BMC BladeLogic Advanced Repeater behind a firewall. Click Next to upgrade the installation. The default port is 5282. 9 Specify the credentials for the Advanced Repeater administrator. 11 Review the current settings to confirm that you have specified the correct installation configuration. or accept the default. 8 Specify the workspace directory (where the Advanced Repeater stores its channels). The Advanced Repeater Service Port window opens. — Transmitter Listener Port: Specify the TCP port for the Transmitter service listener. The Workspace Directory window opens. A notification panel window appears if the installation program detects an existing installation. — Proxy Listener Port: Specify the TCP port for the Proxy Service listener. click Finish.port number to be used by the BMC BladeLogic Advanced Repeater. Click Next. and then click Install. You can use any port. 10 Specify the following: — Transmitter RPC Port: If the server is using remote procedure calls (RPC). as long as the port number is not already in use. Click Next. enter the port number used to establish a new connection for each RPC client connecting to the RPC server.

On Linux. create an options file and add the options for the installation that you want to run. Performing an unattended (silent) installation Install the Advanced Repeater using silent mode You can perform an unattended (silent) installation of the BMC BladeLogic Server Automation Advanced Repeater. select Start => All Programs => BMC BladeLogic Server Automation Suite => Uninstall Advanced Repeater and follow the prompts on the uninstall wizard. For example: -A -P -J -J -J -J -J -J featureAdvancedRepeater installLocation=installationDirectory WORKSPACE_DIRECTORY=pathToWorkspace TUNER_ADMINISTRATION_USER_NAME=admin TUNER_ADMINISTRATION_PASSWORD=password TUNER_ADMINISTRATION_PORT_NUMBER=7177 PROXY_PORT_NUMBER=8081 XMITTER_PORT_NUMBER=5282 Chapter 7 Configuring Advanced File Servers and Advanced Repeaters 309 . Before you begin Certain Terminal Server configuration options that pertain to temporary folders must be turned off. enter the following command and follow the prompts on the uninstall wizard: ■ :/opt/adv/rptr/version/AdvancedRepeater/UninstallAdvancedRepeater # . To install the Advanced Repeater in silent mode 1 In a text editor.1)./uninstall where version is the version number for BMC BladeLogic Server Automation (for example. 8. to enable running the installation wizard through a Terminal Services connection or a remote desktop session.Performing an unattended (silent) installation To uninstall the BMC BladeLogic Advanced Repeater Do one of the following: ■ On Microsoft Windows.

Specify this TCP port if you are installing the BMC BladeLogic Server Automation Advanced Repeater behind a firewall.0\AdvancedRepeater On UNIX: -P installLocation= opt/bmc/BladeLogic/8.Performing an unattended (silent) installation Where: Option -P installLocation= installationDirectory Description Sets the installation directory for the product.0/AdvancedR epeater/tuner The user name and password for Advanced Repeater administrator.0/AdvancedRepeater -A featureAdvancedRepeater Specifies installation of the Advanced Repeater. on Windows: -P installLocation=C:\Program Files\BMC Software\BladeLogic\8. Specify an integer between 0 and 65535. Values for options may contain spaces. on Windows: -J WORKSPACE_DIRECTORY=C:\Program Files\BMC Software\BladeLogic\8. -J PROXY_PORT_NUMBER= The TCP port for the Proxy Service listener. -J WORKSPACE_DIRECTORY= pathToWorkspace Specifies the workspace directory (where the Advanced Repeater stores its channels). -J XMITTER_PORT_NUMBER= Guidelines ■ Each option must be on a single line. For example. For example. The default is 8081. Specify an integer between 0 and 65535. You can use any port. -J TUNER_ADMINISTRATION_USER_ NAME= -J TUNER_ADMINISTRATION_ PASSWORD= -J The TCP port to be used by the BMC BladeLogic Server Automation TUNER_ADMINISTRATION_PORT_ Advanced Repeater.0\AdvancedRepeater\tuner On UNIX: -J WORKSPACE_DIRECTORY=/opt/bmc/BladeLogic/8. The default is 5282. The NUMBER= default is 7717. as long as the port number is not already in use. ■ 310 BMC BladeLogic Server Automation Administration Guide . Specify an integer between 0 and 65535. The TCP port for the Transmitter service listener.

exe -i silent DOPTIONS_FILE=/opt/bmc/BladeLogic/8. AdvancedRepeaterInstallerName -i silent DOPTIONS_FILE=silentOptionsFilePath You must use an absolute path to the options file. 2 Change directory to the location where the installer resides. 3 Run the installation program with the -i silent option. 3 Run the installation program with the -i silent option.txt Chapter 7 Configuring Advanced File Servers and Advanced Repeaters 311 .0\silent_upgrade.0/silent_install.Performing an unattended (silent) installation ■ All Java properties have default values if not specified in the options file. Windows: AdvancedRepeater_8_1_win32. 1 In a text editor.txt Upgrade the Advanced Repeater using silent mode You can perform an unattended (silent) upgrade of the BMC BladeLogic Server Automation Advanced Repeater. you should specify TUNER_ADMINISTRATION_USER_NAME and PASSWORD. AdvancedRepeaterInstallerName -i silent -DOPTIONS_FILE=silentOptionsFilePath You must use an absolute path to the options file. However. Windows example AdvancedRepeater_8_1_win32.exe -i silent -DOPTIONS_FILE=C:\Program Files\BMC Software\BladeLogic\8. create an options file that contains this option: -A featureAdvancedRepeater 2 Change directory to the location where the installer resides.bin -i silent DOPTIONS_FILE=/opt/bmc/BladeLogic/8.0/silent_install.txt UNIX example sh AdvancedRepeater_8_1_win32.

see the following: ■ Configuring Advanced File Servers Configuring Advanced Repeater servers Changing the administrator user and password for Advanced Repeater Servers ■ ■ Before you begin NOTE Configuring an Advanced Repeater server behind a SOCKS proxy server is not supported. Set up credentials If you have not already done so. 312 BMC BladeLogic Server Automation Administration Guide .0/silent_upgrade. See the BMC BladeLogic Server Automation User Guide for information on creating automation principals. create an automation principal which contains the user-defined Administrator credential used to configure the Advanced File Server.Configuring Advanced File Servers and Advanced Repeater servers UNIX: sh AdvancedRepeater_8_1_win32.bin -i silent DOPTIONS_FILE=/opt/bmc/BladeLogic/8. An automation principal defines a user credential that can be used for accessing external systems.txt Configuring Advanced File Servers and Advanced Repeater servers To adjust the configuration settings for the an Advanced File Server or Advanced Repeater server.

If you do not specify the install directory. 2 Install the BMC BladeLogic Advanced Repeater on the file server. NOTE The Advanced File Server Root Directory path is different than the File Server Root Path.Configuring Advanced File Servers Configuring Advanced File Servers Use this procedure to modify a file server to be used as an Advanced File Server. The Advanced File Server Root Directory points to the BMC BladeLogic Advanced Repeater installation directory. as described in “Installing the BMC BladeLogic Server Automation Advanced Repeater” on page 307. 1 Create a file server as described in “Setting up the file server” on page 75. the Transmitter and Performance tabs are not accessible. Chapter 7 Configuring Advanced File Servers and Advanced Repeaters 313 . which uses the BMC BladeLogic Advanced Repeater. 4 Right-click the file server and select Properties to open the Modify File Server dialog. 3 On the BMC BladeLogic Server Automation Console. change the Advanced File Server root directory path to point to the BMC BladeLogic Advanced Repeater installation directory. 5 On the General tab. If necessary. while the File Server Root Path points to the directory on the file server where data is stored. click Enable Advanced File Server. select Configuration => Infrastructure Management.

The automation principal is used to access and configure the Advanced File Server. Advanced File Server Administrator Select an Automation Principal from the drop-down list. select the automation principal that was created for that user/password combination. select "Default".Configuring Advanced File Servers 6 On the Security tab. However. This default automation principal matches the built-in administrator credential. ■ If you have not changed any credential during the installation or post-installation procedures. If you have configured secure communication for the file server. If you specified a custom user/password combination during installation or in the post-install procedure. check SSL Enabled. you can use SSL if your environment requires encryption. ■ 314 BMC BladeLogic Server Automation Administration Guide . See “Securing communication between Advanced File Servers and Advanced Repeater servers (optional)” on page 319. This credential is needed by BMC BladeLogic Server Automation to access and configure the Advanced File Server. specify the following: Option SSL Settings Description By default the traffic between the advanced file server and advanced repeater is not encrypted.

as long as the port number is not already in use. the transmitter is located on the same host as the File Server. ■ Install Copy A on an existing file server host.Configuring Advanced File Servers 7 On the Transmitter tab. In some cases. Chapter 7 Configuring Advanced File Servers and Advanced Repeaters 315 . you only need to install one copy of the Advanced Repeater on the file server host. if there is not sufficient disk space on the file server host. The value Advanced File Server Root Directory on the General tab reflects the installation directory for Copy A. you may want the transmitter to be on a different host than file server. By default. For example. In this case. the value for the Transmitter Root Directory field reflects the installation directory for Copy B. Enter the RPC port number that was set during installation. Install Copy B on a separate transmitter host. you must install two copies of the Advanced Repeater. In this case. You can use any port as the listener port. The RPC port is used to administer the Advanced Repeater components. Select the BMC BladeLogic Advanced Repeater installation directory. 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. the transmitter (in the Advanced File Server) is located on the same host as the existing file server. however. specify the following: Option Transmitter Host Name Transmitter Root Directory Description By default. ■ In this case. Transmitter Listener Port RPC Port Enter the port on which the Advanced Repeater listens for requests.

Instead of transferring entire files when updating payloads. specify the following: Option Disk resources Description Enter the minimum amount of disk space (as a percentage) that the transmitter should keep free.specify the number of kilobits per second that the Advanced File Server can use as throughput.enter the maximum amount of available bandwidth (as a percentage) that the transmitter can use. Specify the following: Option Network connections Network bandwidth Description Enter the number of clients (Advanced Repeaters) allowed to connect to the Advanced File Server at one time.specifies whether the transmitter should use byte-level differencing. 10 Click OK.specifies whether the Advanced File Server should compress the files it sends.balances time and size. across all parallel connections. To keep the specified amount of disk space free. A bandwidth setting of “0” (zero) sets specifies maximum bandwidth speed (unlimited). Specify the following: ■ ■ File transfer efficiency ■ Compression enabled .Configuring Advanced File Servers 8 On the Performance tab. — medium . the transmitter automatically deletes optional files. If you select the Enable bandwidth management option. Maximum throughput .the compression is fast but the file size isn't reduced as much as on high (however the byte-savings difference is minimal). Set the amount of memory to allocate for differencing. Differencing enabled . — high . the transmitter uses byte-level differencing to send only the changed bytes. Compression level . specify the following: ■ ■ Percentage of bandwidth . you can specify options that help you control the amount of network resources used during deployment. 9 On the Network tab.the file is compressed as much as possible. — low . which allows the transmitter to send faster payload updates and to use less bandwidth. 316 BMC BladeLogic Server Automation Administration Guide . but for large files the process can take a long time and can use many CPU resources. This setting limits the total traffic leaving the transmitter.specifies the level of compression the transmitter should use for the files it sends. such as files in the index cache.

See “Configuring Advanced File Servers and Advanced Repeater servers” on page 312. as described in “Installing the BMC BladeLogic Server Automation Advanced Repeater” on page 307. 2 On the BMC BladeLogic Server Automation Console. 3 Do one of the following: — Right-click Repeater Servers and select New Repeater Server to start the New Repeater Wizard. 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. 4 On the General panel. Chapter 7 Configuring Advanced File Servers and Advanced Repeaters 317 . 1 Install the BMC BladeLogic Advanced Repeater on the system that you will use as an Advanced Repeater server. see the Exports File section in the BMC BladeLogic Server Automation Administration Guide. click Enable Advanced Repeater.Configuring Advanced Repeater servers Configuring Advanced Repeater servers Use this procedure to create or modify a server to be used as an Advanced Repeater server. For more information. select Configuration => Infrastructure Management. which uses the BMC BladeLogic Advanced Repeater. NOTE You must have first configured an Advanced File Server before you can configure an Advanced Repeater server. If necessary. — Right-click an existing repeater server select Properties to open the Modify Repeater Server dialog. change the Advanced Repeater root directory path.

Enter a percentage that represents the lower limit (cache low watermark) for the Advanced Repeater cache size. 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). specify the following: Option Cache maximum size Description Cache management options Enter the total size (in MB) for the Advanced Repeater cache. select "Default". Advanced Repeater Server Administrator Select an Automation Principal from the drop-down list. ■ If you have not changed any credential during the installation or post-installation procedures.Configuring Advanced Repeater servers 5 On the Security tab. ■ 6 On the Cache and Port panel. you can use SSL if your environment requires encryption. If you have configured secure communication. This default automation principal matches the built-in administrator credential. See “Securing communication between Advanced File Servers and Advanced Repeater servers (optional)” on page 319. specify the following: Option SSL Settings Description By default the traffic between the advanced file server and advanced repeater is not encrypted. However. select the automation principal that was created for that user/password combination. 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. The automation principal is used to access and configure the Advanced File Server. the Advanced Repeater starts garbage collection to delete older channel files from the cache. Cache low watermark 318 BMC BladeLogic Server Automation Administration Guide . The cache does not exceed this disk-space limit. Once the cache reaches the maximum cache size. This credential is needed by BMC BladeLogic Server Automation to access and configure the Advanced Repeater. check SSL Enabled. If you specified a custom user/password combination during installation or in the post-install procedure.

you can change it using a Runchannel command.Changing the administrator user and password for Advanced Repeater Servers Option Listener port Description Port management options Enter the port on which the Advanced Repeater listens for requests. 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. the default directory is C:\Program Files\BMC Software\Bladelogic\8. This setting applies for each repeater to file server connection. Specify the following: Option Network connections Network bandwidth Description Enter the number of concurrent connections to the Advanced Repeater. specify the following: ■ ■ Percentage of bandwidth . Enter the RPC port number that was set during installation. Maximum throughput . when running the installation program. RPC port 7 On the Network panel. If enabled.0\AdvancedRepeater\tuner\).specify the number of kilobits per second that the Advanced Repeater can use as throughput.enter the maximum amount of available bandwidth (as a percentage) that the Advanced Repeater can use. you can specify options that help you control the amount of network resources used during deployment. The RPC port is used to administer the Advanced Repeater components. A bandwidth setting of “0” (zero) sets specifies maximum bandwidth speed (unlimited). 8 Click OK. — From a command prompt. (On Windows. You can use any port as the listener port. as long as the port number is not already in use. — Navigate to the Advanced Repeater Server installation directory. If you know the administrator user/password combination. execute the following command: ■ Chapter 7 Configuring Advanced File Servers and Advanced Repeaters 319 .

— From a command prompt.exe -admin "newAdminUser. (Note that the Tuner program can only be run locally. the default directory is C:\Program Files\BMC Software\Bladelogic\8.plain:newAdminPwd" Securing communication between Advanced File Servers and Advanced Repeater servers (optional) Optionally. You can secure the link between the Advanced Repeater server and the transmitter located on the Advanced File Server.d/advancedrepeater start 320 BMC BladeLogic Server Automation Administration Guide . All other traffic is all local and does not require encryption.) — Navigate to the Advanced Repeater Server installation directory. for example) that is able to issue credentials used for PKI authentication.0\AdvancedRepeater\tuner\).Securing communication between Advanced File Servers and Advanced Repeater servers (optional) runchannel http://localhost:5282/Marimba/Current/TunerAdministrator -tuner localhost:7717 -username oldAdminUser -password oldAdminPwd set -property "marimba. Set up the Advanced File Server for secure communication 1 Start the Advanced Repeater. all communication between the Advanced File Server and Advanced Repeater servers using the BMC BladeLogic Advanced Repeater can be encrypted using SSL. you can use the Tuner program to override the current user/password combination. NOTE The following instructions assume you have a valid certificate authority (using OpenSSL. use the following command: /etc/init.admin" -value "newAdminUser. if you are using the built-in default user/password). execute the following command: tuner.tuner. using one of the following methods: ■ On UNIX and Linux.plain:newAdminPwd" ■ If you do not know the administrator user/password combination (for example. (On Windows.

7 On the Root Certificates dialog. The root certificate is now configured on the Advanced File Server. Chapter 7 Configuring Advanced File Servers and Advanced Repeaters 321 . 2 Click Request. TIP When specifying Host name. select Root. Generate the SSL certificate 1 In the Certificate Manager dialog. 4 Click Import to display the Import Certificate dialog. 3 In the left pane. Do not enter localhost. 5 Browse to the location of the root certificate and select it. select Channel => Show internal channels to populate the list. select the root certificate you just imported and select SSL from the Trust Type group box. 4 On the Class 3 Digital ID Information panel.Generate the SSL certificate ■ On Windows. leave the entry field blank. 3 Click Next. 2 Right-click the Certificate Manager option and select Start. TIP If you do not see any channels listed in the Channels list. from the Start menu. use the actual name of the Advanced File Server host system. The SSL Certificate Request dialog is displayed. complete the fields and click Next. 5 Specify a password. and click Next. click Programs => BMC Software => BladeLogic Server Automation Suite => Advanced Repeater. The Certificate Manager dialog is displayed. 6 When prompted for a password or nickname. select SSL in the left pane.

secure true where ■ uniqueID is the ID you obtained in step 3. 11 On the SSL Certificates dialog. 10 Once you have received the signed certificate. 3 Click View. paste the contents of the signed certificate and click Next.http. 7 Click Copy CSR to paste buffer. Enable SSL on Advanced File Servers and Advanced Repeaters To configure the BMC BladeLogic Advanced Repeater for secure communication. 1 In the Certificate Manager dialog.http. 322 BMC BladeLogic Server Automation Administration Guide . complete the following steps on the Advanced File Server.http. The certificate request is generated. copy the contents of the file.pw hostname property -setProperty transmitter. 13 Click Done to complete the SSL certificate. The Unique ID is displayed on the Certificate Information dialog. 9 Forward the file to your Certificate Authority. 12 On the Install SSL Certificate dialog. 8 Copy the certificate request and paste it into a text file.certID uniqueID hostname property -setProperty transmitter.http.savepw true hostname property -setProperty transmitter.Enable SSL on Advanced File Servers and Advanced Repeaters 6 Click inside the text box and enter characters until the counter reaches zero. select SSL in the left pane. click Install. 4 Using the Unique ID displayed in the certificate. 2 Select the certificate you just created. enter the following commands to configure the transmitter to use the certificate and only accept https traffic: runchannel transmitterURL runchannel transmitterURL runchannel transmitterURL plain:password runchannel transmitterURL hostname property -setProperty transmitter.

click Programs => BMC Software => BladeLogic Server Automation Suite => Advanced Repeater. 2 Right-click the Certificate Manager option and select Start.d/advancedrepeater start ■ On Windows. For example. use the following command: /etc/init. http://localhost:5282/Marimba/Current/TransmitterAdministrator. 5 Browse to the location of the root certificate and select it. 3 In the left pane. 5 Validate that the communication type is enabled. Chapter 7 Configuring Advanced File Servers and Advanced Repeaters 323 . For example. 6 Restart the BMC BladeLogic Advanced Repeater on the Advanced File Server. The browser should display the status information for the Advanced Repeater.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. Configure the Advanced Repeater server for secure communication 1 Copy the root certificate you created to the Advanced Repeater server. from the Start menu. https://localhost:5282/Marimba/Current/TransmitterAdministrator. 4 Click Import to display the Import Certificate dialog. start the Advanced Repeater using one of the following methods: ■ On UNIX and Linux. select Root. by entering the following string in any browser address field: https://transmitterURL/?status transmitterURL is the URL to the Transmitter Administrator of the BMC BladeLogic Advanced Repeater. The Certificate Manager dialog is displayed. 1 On the Advanced Repeater server.

1 Select Configuration => Infrastructure Management. NOTE To disable SSL communication. For more information on using the Certificate Manager.secure false 2 Restart the BMC BladeLogic Server Automation Advanced Repeater. Disabling SSL communication 1 Enter the following command to disable secure communication between the Advanced File Server and the Advanced Repeater server: runchannel transmitterURL hostName property –setProperty transmitter.http. 4 Click OK. 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. 3 Select Enable SSL. Do not enter a password or a nickname. clear the Enable SSL check box.Configure the Advanced File Server to use secure communication 6 Click OK to bypass the Enter Password and Enter Nickname dialogs. 2 Right-click the Advanced File Server and choose Properties. select the root certificate you just imported and select SSL from the Trust Type group box. 7 On the Root Certificates dialog. by entering the following string in any browser address field: 324 BMC BladeLogic Server Automation Administration Guide . 3 Validate that the secure communication type has been disabled. see BMC Configuration Automation CMS and Tuner Guide.

The browser displays the status information for the Advanced Repeater. http://localhost:5282/Marimba/Current/TransmitterAdministrator. Chapter 7 Configuring Advanced File Servers and Advanced Repeaters 325 . For example. 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. where data is being pushed out to a large number of servers. The options are particularly useful in large scale environments. 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. 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. ■ 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.Troubleshooting advanced file servers and advanced repeaters http://transmitterURL:portNumber/?status transmitterURL is the URL to the Transmitter Administrator of the BMC BladeLogic Advanced Repeater. as well as the number of kilobits per second that the Advanced File Server or repeater can use as throughput.

marimba/ws3/ Proxy log files access-y<yyyy>-w<w>.Location of log files NOTE The bandwidth setting on an Advanced File Server is different from the bandwidth setting on an Advanced Repeater server. Table 3 Log file history-<n>. Location of log files Log files specific to the Advanced Repeater are listed in Table 3 on page 325.marimba\proxyroot\lo gs\ UNIX /opt/bmc/BladeLogic/8.marimba\BCAC\ UNIX /opt/bmc/BladeLogic/8.marimba/proxyroot/logs/ 326 BMC BladeLogic Server Automation Administration Guide .log The proxy access log is located in: Windows C:\Program Files\BMC Software\Bladelogic\8. across all parallel connections.0\AdvancedRepeater\tuner\.0/AdvancedRepeater/tuner/.log Log files for Advanced Repeater Default location Tuner log files The tuner log file is located in: Windows C:\Program Files\BMC Software\BladeLogic\8. The bandwidth setting on Advanced File Server limits the total traffic leaving the transmitter. These options are described in detail in the procedures for Configuring Advanced File Servers and Advanced Repeater servers and Configuring Advanced Repeater servers. while the bandwidth setting in Advanced Repeater server is a per connection setting (for each repeater to file server link).0/AdvancedRepeater/tuner/.0\AdvancedRepeater\tuner\.

if you are experiencing problems on Linux or UNIX systems that are not running X-Windows.txt file (see Table 4 for location of file): marimba.marimba\proxyroot\lo gs\ UNIX /opt/bmc/BladeLogic/8. However.log The proxy admin log is located in: Windows C:\Program Files\BMC Software\Bladelogic\8. perform the following steps: 1 Add the following property to the properties.0\AdvancedRepeater\tuner\lib\tuner\properties. In general these configuration files should not be modified.marimba/proxyroot/logs/ Location of configuration files Configuration files specific to the Advanced Repeater are listed in Table 4.0/AdvancedRepeater/tuner/.0/AdvancedRepeater/tuner/lib/tuner/properties.Location of configuration files Table 3 Log file Log files for Advanced Repeater Default location admin-y<yyyy>-w<w>.txt Configuration file Chapter 7 Configuring Advanced File Servers and Advanced Repeaters 327 .0\AdvancedRepeater\tuner\.nodisplay=true 2 Restart the advanced file server. Table 4 Configuration files for Advanced Repeater Default location Properties file properties.txt UNIX /opt/bmc/BladeLogic/8.txt The main configuration file for the tuner is located in: Windows C:\Program Files\BMC Software\BladeLogic\8.tuner.display.

txt UNIX /opt/bmc/BladeLogic/8. 328 BMC BladeLogic Server Automation Administration Guide . use the following command: /etc/init.txt Starting and stopping the Advanced Repeater Use the following procedures to start and stop the BMC BladeLogic Advanced Repeater: ■ On UNIX.0\AdvancedRepeater\tuner\. use one of the following procedures: — From the Start menu. — From the Services dialog.d/advancedrepeater {start|stop} ■ On Windows.txt Configuration file prefs. click Programs => BMC Software => BladeLogic Server Automation Suite => Advanced Repeater. start or stop the BMC BladeLogic Advanced Repeater Service.marimba\BCAC\prefs.Starting and stopping the Advanced Repeater Table 4 Configuration files for Advanced Repeater Default location Preferences file The preferences file is located in: Windows C:\Program Files\BMC Software\BladeLogic\8.marimba/ws3/prefs.0/AdvancedRepeater/tuner/.

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. enabling you to track infrastructure change actions. and describe how to enable that integration within BMC BladeLogic. Levels of integration The following sections provide an overview of the integration points. NOTE BMC BladeLogic supports integration with BMC Remedy ITSM Change Management. The following topics provide an overview of integrating BMC BladeLogic with the BMC Remedy ITSM change management solution.Chapter 8 Integrating BMC BladeLogic and Change Management 8 You can integrate BMC BladeLogic with your Change Management processes. ■ The BMC Continuous Compliance for Servers solution Requirements for integration ■ Chapter 8 Integrating BMC BladeLogic and Change Management 329 . and describe the configuration tasks in BMC BladeLogic that are required to communicate with BMC Remedy ITSM. Once configured and enabled.

See “Facilitating BMC BladeLogic operator-initiated change” on page 331. ensure continuous compliance for servers. The solution reduces the risk of unauthorized and unplanned changes through enforced change tracking and automated documentation of all changes. The integration of BMC BladeLogic with BMC Remedy ITSM is accomplished through standard application interfaces (APIs). If you implement the solution. 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. but also reduces errors commonly associated with the manual coordination of change and configuration management. see BMC Continuous Compliance for Server Automation Solution Getting Started Guide. you can ■ ■ ■ facilitate the tracking of infrastructure change actions initiated by a BMC BladeLogic operator. For more information on the BMC Continuous Compliance for Servers solution. See “Enriching BMC Remedy ITSM incidents with server configuration information” on page 331. enrich BMC Remedy ITSM incidents with server configuration information. For an overview of these tasks. see “Requirements for integration” on page 332. contact your BMC Software sales representative. auditing. There are several configuration tasks you need to perform to enable the integration of BMC BladeLogic and BMC Remedy ITSM. This automation not only saves organizations time. and remediation processes with IT management systems such as BMC Remedy ITSM. See “Ensuring continuous compliance for servers” on page 331. For complete details on installing and configuring BMC Atrium Orchestrator and setting up the BMC Remedy ITSM templates and filters. compliance. The BMC Continuous Compliance for Servers solution automates the integration of BMC BladeLogic monitoring. 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. enabling an automated coordination of configuration management processes with other ITIL® processes. such as incident management and change management. 330 BMC BladeLogic Server Automation Administration Guide .The BMC Continuous Compliance for Servers solution 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.

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 Chapter 8 Integrating BMC BladeLogic and Change Management 331 . 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. the BMC Remedy ITSM change task is closed with an associated completion status and any changed configuration items (CIs). Ensuring continuous compliance for servers This integration involves automatically creating incidents and change requests if noncompliant servers are detected. operators need to document these changes in BMC Remedy ITSM Change Management. The main benefit of this integration is to enforce continuous compliance to the change process without introducing labor intensive activities. or if deviations from a master server configuration are detected. Once the change is approved in BMC Remedy ITSM. security. After the job has run. 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. the job is scheduled for execution in BMC BladeLogic.The BMC Continuous Compliance for Servers solution Facilitating BMC BladeLogic operator-initiated change When operations changes are implemented. 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. The BMC Remedy ITSM user can launch the job details report from the task to verify the change actions. The integration reduces the risk of unauthorized and unplanned changes through enforced change tracking. 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. To automate this change tracking process.

Requirements for integration Requirements for integration To integrate BMC BladeLogic with BMC Remedy ITSM. see “Enabling BMC Remedy ITSM integration for job approval”. see BMC Continuous Compliance for Server Automation Solution Getting Started Guide. 332 BMC BladeLogic Server Automation Administration Guide . — Review default BMC Remedy templates . To complete the integration tasks associated with BMC BladeLogic. and tasks using BMC Remedy ITSM templates. 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. change tickets.The BMC Atrium Orchestrator workflows create incidents. 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. ■ 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.

you can track these infrastructure changes when the change is initiated by the BMC BladeLogic operator. For more information about Workflow Jobs. Use this procedure to enable or disable the BMC Remedy ITSM job approval capability at the job type level.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). if integration with BMC Remedy ITSM for job approval is desired. 2 On the Job Approval Required Configuration dialog. Chapter 8 Integrating BMC BladeLogic and Change Management 333 . To fully enable the integration. select Configuration => Approval Configuration. 3 Click OK. By default. the approval for each supported job type is turned off. see the BMC BladeLogic Server Automation User Guide. 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 ■ ■ ■ 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. set the Approval Required option for each available job type. 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. To configure job approval for job types 1 From the BMC BladeLogic Console.

Assigning job approval permissions Use this procedure to assign permissions to different BMC BladeLogic users for integrating job execution with BMC Remedy ITSM. When that user logs on. 5 Click OK to save the updates. the BLAdmins Role has permissions to all approval permissions. NOTE By default. To assign job approval permissions 1 In the RBAC Manager workspace of the BMC BladeLogic Console. you may create a role for junior operators that has only Manual permission. only the job approval type assigned for the user role is listed when running the job wizard. 334 BMC BladeLogic Server Automation Administration Guide . 3 Click the Systems tab. ensuring that any jobs they initiate would be reviewed and approved by a BMC Remedy ITSM prior to execution. Assign the appropriate approval type to each user role. 4 Add any of the following RBAC controls to enable specific BMC Remedy ITSM job approval permissions ■ ■ ■ ■ Automatic Manual Emergency NoApproval For example.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. select Roles. 6 Click OK to exit the Update Permissions panel. 2 Right-click a role and select Open.

3 On the Add new AO configuration dialog box. For any additional CDP connection (see step 4).* authorizations.Setting up the connection to BMC Atrium Orchestrator Setting up the connection to BMC Atrium Orchestrator Through the BMC BladeLogic Console. The BMC Atrium Orchestrator password for the specified user. in seconds. Password Time-out Chapter 8 Integrating BMC BladeLogic and Change Management 335 . click Add. Parameter Host Port Grid Name Description The IP address or fully-qualified host name of the BMC Atrium Orchestrator CDP server. 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).* and the AutomationPrincipal. The default is 300 seconds (five minutes). The amount of time. before a BMC BladeLogic job that connects to BMC Atrium Orchestrator times out. as all defined connections must be on the same grid. and then click OK. This user must be associated with the ADMIN role in BMC Atrium Orchestrator. you must add the configuration information required to connect to BMC Atrium Orchestrator. To configure the connection with BMC Atrium Orchestrator 1 Select Configuration => AO Configuration. 2 On the AO Configuration dialog box. Specify the name of a grid only if this is the first defined CDP connection. enter the configuration information required to connect to BMC Atrium Orchestrator. this field is read-only. The port number used to connect to the BMC Atrium Orchestrator CDP. Other types of peers are not supported. The name defined for the BMC Atrium Orchestrator grid. User Name The name of the BMC Atrium Orchestrator user used to log on to the CDP. ensure that your role is granted the AOConfig. Before you begin From the BMC BladeLogic Console.

In this example. In a high-availability environment with multiple CDP instances. If you define multiple BMC Atrium Orchestrator CDP instances. create the keystore file by entering a command such as the following example: keytool -genkey -alias w2k3-sp-vm5 -dname "cn=w2k3-sp-vm5" -keyalg RSA -keystore C:\. to ensure high availability. Enabling HTTPS support for the BMC Atrium Orchestrator connection If you want to secure the communication of data between BMC BladeLogic Server Automation and BMC Atrium Orchestrator. ensure that you select the correct CDP. To enable HTTPS support on BMC Atrium Orchestrator 1 On the system where the BMC Atrium Orchestrator CDP is installed. port. click Check Connection. If you want to test whether or not you can connect to the CDP with the host. you must enable an HTTPS connection on both products. 336 BMC BladeLogic Server Automation Administration Guide .keystore -storepass changeit The value entered for the -dname option must match the host name where the BMC Atrium Orchestrator CDP is installed. grid name. 5 Click Close on the AO Configuration dialog box. user name. the value is w2k3-sp-vm5. and password details that you specified.Enabling HTTPS support for the BMC Atrium Orchestrator connection Parameter Primary AO Description Whether to specify this CDP as the primary instance. 4 If you want to add additional CDP connections to BMC Atrium Orchestrator. repeat step 2 and step 3 for every additional CDP instance of the same grid. as defined in BMC Atrium Orchestrator. ensure that only one of your CDPs is set as the primary instance (using the Primary AO check box). 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”). 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.

3 Restart the BMC Atrium Orchestrator CDP. 2 On the system where the BMC BladeLogic application server is installed. copy the C:\. <Connector port="8443" protocol="HTTP/1.csr -keystore C:\.5.keystore storepass changeit In the command shown above. 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: keytool -export -alias w2k3-sp-vm5 -file C:\cert. keystore is the keystore file name and location that you created for BMC Atrium Orchestrator. note the following: ■ file is the name and location of the certificate file that is going to be created from this command.Enabling HTTPS support for the BMC Atrium Orchestrator connection 2 Enable HTTPS on Tomcat by completing the following steps: A Open the server.xml file.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="C:\.keystore file from the BMC Atrium Orchestrator CDP system to the system where the BMC BladeLogic application server is installed. To enable HTTPS support for BMC Atrium Orchestrator on BMC BladeLogic 1 If BMC Atrium Orchestrator is installed on a different machine. B Uncomment the following block of configuration information and add two attributes.keystore" truststoreFile="C:\Program Files\Java\jdk1. ■ ■ 3 Add the public certificate from the temporary file to the trusted certificate file by entering a command such as the following example: Chapter 8 Integrating BMC BladeLogic and Change Management 337 .0_13\jre\lib\security\cacerts" /> 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. alias is the name used to distinguish certificates.

338 BMC BladeLogic Server Automation Administration Guide .Enabling HTTPS support for the BMC Atrium Orchestrator connection 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 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: keytool -list -keystore C:\Program Files\BMC Software\BladeLogic\version\NSH\jre\lib\security\cacerts 5 Restart the BMC BladeLogic application server.

is used to decrypt the data. A Active Directory Microsoft's directory service. and the private key. which provides a centralized system for automating management of networked entities. printers. known to everyone.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. an authentication service is implemented within the BMC BladeLogic Application Server. Authentication Service A service implemented within the BMC BladeLogic Application Server that is responsible for authenticating a user and issuing a session credential. the authentication service stands alone. authentication profile A collection of information that a BMC BladeLogic client (BMC BladeLogic Console. Network Shell. but for BMC BladeLogic Decision Support for Server Automation. which integrates BMC BladeLogic with a key distribution center (KDC) to utilize the Kerberos v5 protocol for authenticating client-tier users. is used to encrypt data. and users. AES The Advanced Encryption Standard (AES) is an encryption algorithm that has become the encryption standard used in most commercial transactions. asymmetric encryption A method of encryption that uses public and private keys. C certificate authority (CA) Security Glossary 339 . known only to the recipient of the data. The public key. AD/Kerberos authentication The Active Directory/Kerberos (AD/Kerberos) approach to authentication. 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. such as applications. files. Typically.

DC=com. D Data Encryption Standard (DES) A common method of data encryption using a secret key that is shared by the sender and receiver. 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). certificate management protocol (CMP) A definition of the online interactions between end entities. For example. registration authority (RA). Certificates can be thought of as analogous to passports that guarantee the identity of their bearers. 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. distinguished name An PKCS entry that identifies a user for an LDAP server. certificates Digital documents used for secure authentication of communicating parties. DC=bladelogic. The highest trusted CA in the tree is called a root CA.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 The trusted party issuing digital certificates (especially X. A certificate is digitally signed by a trusted third party who has verified that the key pair actually belongs to the entity. DC=sub1. If allowed by the certificate policy of the CA. CAs can also issue certificates to other sub-CAs. 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. CN=Users. This leads to a tree-like certification hierarchy. The CA usually issues new CRLs at frequent intervals. Those objects are listed from bottom to top. DN 340 BMC BladeLogic Server Automation Administration Guide . A certification request contains at least the public key and some identity information about the entity making the request.509 public-key certificates) to an identified end entity and vouching for the binding between the data items in a certificate. a distinguished name might be CN=admin. and the certificate authority (CA) in a public key infrastructure (PKI). generated by end entities or registration authority (RA) and sent to the certificate authority (CA). A certificate is signed with the private key of the entity. A certificate binds identity information about an entity to the entity's public key for a certain validity period. DC=kerbtest. 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. certification request A request for a certificate. a certificate can be issued based on the request.

IPSec can be used for protecting the data transmitted by any service or application that is based on IP. After a client and server have used Kerberos to prove their identity. In Windows NT. for protecting IP traffic at the packet level. The IPSec protocols are defined in RFC 2401. Security Glossary 341 . J JKS Java keystore. A type of keystore file used for holding certificates. defined by the Internet Engineering Task Force (IETF). I Internet Protocol Security (IPSec) A protocol suite. A user can access network resources by logging into the domain. Domain Authentication only requires a user to provide a name. which delegates user authentication to the Active Directory domain controller. K keystore A file used to store a list of certificates along with their private keys. they can encrypt all of their communications to assure privacy and data integrity. domains are used to manage access to network resources. The primary domain controller periodically sends copies of its database to the backup domain controllers. One server on the network functions as the primary domain controller by managing a master database of users for the domain. Kerberos A cross-platform mechanism for mutual authentication between a client and server or between two servers before a network connection is opened between the two. Domain Authentication An approach to authentication that is based on AD/Kerberos authentication. The protocol uses strong cryptography so a client can prove its identity to a server (and vice versa) across an insecure network connection. F failover A mode of operating in which a secondary component takes over the functions of a primary component when the primary component cannot function. and password when logging in. Additional servers can function as backup domain controllers.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 An LDAP distinguished name. The BMC BladeLogic implementation of Kerberos is based on MIT’s Kerberos v5. domain controller A role assigned to a server in a network of computers running the Windows NT operating system. This information is passed to the Authentication Service. domain.

Public key infrastructure consists of a certificate authority (CA). PKI See public key infrastructure (PKI). public key cryptography A method for authenticating a sender or encrypting a message sent over a network. Lightweight Directory Access Protocol (LDAP) A directory access protocol for accessing directories supporting the X. 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.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 L LDAP Lightweight Directory Access Protocol (LDAP). 342 BMC BladeLogic Server Automation Administration Guide . In public key cryptography. tree-like structure. public key infrastructure (PKI) A collection of mechanisms that together allow network users to exchange data securely over a network. N nonce A random number used for cryptographic processes. proxy mode A 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. and decrypt communication using public key cryptography. The number is used only once to ensure that any communication used for authentication cannot be reused. P PKCS A group of public key cryptography standards devised and published by RSA Security. the encryption and decryption of messages is done with different keys. R RC4 An encryption algorithm. Many companies are using LDAP-based solutions as directories and user management systems.500 models. The protocol for querying and modifying directory entries that are arranged in a hierarchical. BMC BladeLogic provides an approach to user authentication based on PKI. and other mechanisms needed to authenticate. which requires a secure exchange of a shared key. certificate repositories (directories). encrypt.

SRP is the default approach to user authentication in BMC BladeLogic. In this way you can define a set of permissions that might be used by an entire class of users. Session keys are symmetric. After the session key is decrypted. RSA SecurID See SecurID. This output is sometimes called a digital fingerprint. 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. single sign-on Security Glossary 343 .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 RBAC The BMC BladeLogic system of role-based access control (RBAC). SHA1 The most commonly used function in the Secure Hash Algorithm (SHA) family of cryptographic hash functions. The RBAC Manager workspace in the BMC BladeLogic Console lets you define roles. session credential A credential issued to a BMC BladeLogic client application after a successful user login. it is used for symmetric encryption of all subsequent communication during a session. BMC BladeLogic clients use session credentials to establish secure sessions with BMC BladeLogic Application Servers and Network Shell Proxy Servers. A hash function like SHA1 takes a long string as input and produces a fixed-length string as output. session key A key used for encrypting and decrypting traffic during a communication session. such as expert administrators or help desk personnel. service URL The identity and address of a BMC BladeLogic Application Service or Network Shell Proxy Service that can be accessed using a session credential. SHA1 is used for many security application and protocols. see the BMC BladeLogic Server Automation User Guide. S secure remote password (SRP) A protocol for integrating secure password authentication into networked applications. Because symmetric encryption is very fast and asymmetric encryption is very slow. asymmetric encryption is used only to encrypt a session key. SecurID RSA’s authentication protocol based on two-factor authentication. meaning the same key is used to encrypt and decrypt data. including TLS. For more information on RBAC.

authentication.509 A standard for defining digital certificates. X X.509 recommendation defines the formats for X. As long as the session credential is valid. 344 BMC BladeLogic Server Automation Administration Guide .509 certificates and the X. The ITU-T X. the user does not have to authenticate again. trust store A file used to store a list of trusted certificates. TLS is typically used to secure HTTP connections. and integrity for stream-like connections.509 certificate revocation list (CRL). TLS is the successor to the Secure Socket Layer (SSL) protocol. T Transport Layer Security (TLS) A protocol providing confidentiality.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 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.

conf file 198 creating blclient_login.txt file 274 <category> tag for log4crc. 237 provisioning with SHA1 fingerprints 204.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 Index Symbols <appender> tag for log4crc. 235 cleanup of 293 configuring to authenticate using client-side certs 206. 185.conf file 188 creating blclient_krb5. 208 scheduling cleanup of 300 secure file 253 users file 247 users.conf file 186 creating blappserv_login. 191 console to Application Server 194 copying keytab file to Application Server 185 creating blappserv_krb5.txt file 273 <layout> tag for log4crc.txt file 277 network throttling options 315 advanced repeater configuring 316 disk space recommendations 306 installing 307 network throttling options 318 overview 305 securing communication 319 using network throttling 324 AES defined 339 agent logs disabling secure logging 280 enabling secure logging 279 security overview 277 verifying integrity of 279 agents and configuration files 233.properties file for clients 200 updating Kerberos registry settings 196 verifying a keytab file 190 advanced file server configuring 312 Index 345 .local file 247 anonymous user on Windows 17 Application Server information about 106 reporting information about 108 Application Server Administration console 44 binding to an IP address 67 canceling jobs 60 configuring Application Server 52 configuring database server 78 configuring file server 74 configuring mail server 76 configuring Network Shell Proxy Server 68 configuring Perl 77 configuring process spawner 79 configuring remote execution objects 68 configuring SNMP server 77 configuring the PXE Server 89 A access to RSCD agents 233. 209 exports file 240 granting access 233. 237 accounts locking out 88 Active Directory defined 339 Active Directory/Kerberos 123 AD/Kerberos setting up Network Shell Proxy Servers 193 user names 192 AD/Kerberos authentication configuring Authentication Service 184.conf file 196 creating user accounts 181 default users and roles 194 defined 339 exporting keytab file 181 implementing 177 locating KDC for client’s domain 197 locating KDC for service principal 186 overview 178 registering Authentication Service 180 requirements for Active Directory server 180 running kinit to get a TGT 201 sample domain structure 171 updating config.

206 security for 133 setting up to cooperate 58 shutting down gracefully 43 starting 41. 152 profiles 124. 100 provisioning agents with SHA1 fingerprints 204. 208 restarting 111 restricting size of configuration objects 83 restricting size of extended objects 83 scaling 52 securing with certificates 223 securing with client-side certs 202. 111 terminating process for 111 tier 13 time-out behavior 61 types of 96 undeploying 110 understanding 30 work item threads 31 Application Service 135 configuring 140 architecture of BMC BladeLogic system 13 asymmetric encryption defined 339 asynchronous execution enabling 92 audience intended 11 authentication AD/Kerberos 123 Application Server framework 33 described 117 domain 124 for BMC Service Automation Reporting and Analytics 132 LDAP 122. 191 configuring for Domain Authentication 171 registering in Active Directory domain 180 authorization described 120 automatically-generated objects setting retention time for 291 346 BMC BladeLogic Server Automation Administration Guide . 166 single sign-on 121. 64 deleting the deployment of 110 deployment directories for 95 deployments 94 discontinuing client-side certs 210 introduced 15 job distribution 32 job execution thread 31 managing 44 maximum client idle time 60 multiple 93. 70 configuration wizard 34 configuring 29. 70 setting connection types 65 setting database connections 64 setting login requirements 88 setting past due job behavior 63 setting retention time for automatically-generated objects 291 setting time-out behavior 61 showing no access nodes 84 specifying update group location 87 starting 45 Application Server cache scheduling cleanup of 299 Application Server Launchers editing access list for 113 Application Servers attributes for 100 attributes of 96 authentication framework 33 canceling jobs 60 changing access to 113 changing configuration of 100 cleanup of caches for 293 communication ports 65 compliance results maximum 62. 163. 128. 151. 96 past due job behavior 63 pausing 43 profiles 93 profiles for 96. 135 SRP 122 Authentication Service 135 configuring 137 configuring for AD/Kerberos 184. 126. 93 creating client-side certs 203. 125 SecurID 123. 129.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 controlling user interface settings 84 crossing mount points 82 default permissions 86 deleting group 84 enabling asynchronous execution 92 enabling import/export of property classes 87 enabling import/export of Property Dictionary 87 enabling/disabling the retention policy utility 289 evaluating SOCKS Proxy Server rules 73 job distribution 55 limiting smart live browse results 85 preparing HTTP proxy server support 66 restricting size of configuration objects 83 restricting size of extended objects 83 scaling Application Server 52 setting client idle time 60 setting communication ports 65 setting compliance results maximum 62. 109. 109 stopping 42. 42. 158 managing profiles with blcred 226 PKI 123 profile files 150. 207 creating multiple 97 database connections 33.

194 illustrated 116 Network Shell to agent 133. 15 configuration files 233.properties file for clients 200 configuration for Domain Authentication 172. 206. 13–19 Perl support 17 security 115. 174. 221. 212 Network Shell to Network Shell Proxy Server 131 repeater to agent 134. 216. 115–231 security glossary 339 BMC BladeLogic Console and secure file 253 job parts 31 jobs and Application Server 31 security 130 BMC Service Automation Reporting and Analytics authentication 132 security for 132 server-side certificates 132 BMC Software. 233–264. 221. 218. contacting 2 browsing limiting number of results 85 C caching user information 230 certificate authority 339 management protocol 340 revocation list 340 certificate trust store for LDAP 159 certificates defined 340 for BMC Service Automation Reporting and Analytics 132 for secure communication 258 importing to clients 226 managing with blcred 226 setting up 223. 203. 222 used by agents to authenticate 206. 14. 219.conf file creating for consoles 198 blclient_login.conf file creating for consoles 196 blcred configuring for AD/Kerberos 194 utility 125. 224 verifying with OCSP 153 certification request 340 service provider 340 chrole command 128 cleanup of agents on servers 293 of BMC BladeLogic database 288 of repeater servers 294 of the Application Server cache 293 of the file server 295 scheduling of 297 cleanupDatabase command 292 client connections maximum idle time 60 client tier 13 of BMC BladeLogic 14 clients connections to database 64 secure file 253 use of term 11 client-side certs 119 discontinuing use 210. 206. 216 for repeaters 218. 226 bltray 215 BMC Atrium Orchestrator integration 333 BMC BladeLogic architecture 13. 211. 217. 70 config. 210 BLCLI to Application Server 130 console to Application Server 130.conf file 173 creating for Application Server 186 blappserv_login. 271 configuring Application Server 29 default permissions 16 default security configuration 16 introduced 11. 222 reports client to reports server 132 security for 130 communication ports setting 65 Compliance Job results setting maximum number displayed 62.conf file 174 creating for Application Server 188 blasadmin utility 44 starting 45 BLCLI security 130 settings for 84 blclient_krb5. 11–12 overview 13. 202. 219. 173. 207 for Network Shell client 212. 175 configuration files exports file 240 Index 347 .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 B BladeLogic integration configure job approval for job types 333 blappserv_krb5. 222 for Application Server 202. 209 commands restricting access with exports file 244 communication legs Application Server to agent or repeater 133.

local file 247. 192 customer support 3 user names 176 domain controller defined 341 E encryption described 118 for secure communication 258 environment variables 129 exports file 240. 176. 169. 233–264. 271 subnet designations 236 users file 247. 175 default users and roles 177 implementing 170 G groups deleting in console 84 H high availability 159 host entries in secure file 257 HTTP proxy server 66 I impersonation 119 described 119 import and update process specifying temporary group location 87 indirect deployments and certificates 262 Infrastructure Management window Application Server information 106 installing the BMC BladeLogic Advanced Repeater 307 integration and configuration checklist 332 Internet Protocol Security defined 341 348 BMC BladeLogic Server Automation Administration Guide . 235 options for configuring 241 restricting access to commands 244 extended objects restricting size 83 F file servers cleanup of 295 configuring 37. 74 configuring advanced file servers 312 scheduling cleanup of 299 D Data Encryption Standard defined 340 database cleanup 288. 240–247 configuring 241 examples 246 introduced 233. 166. 247–253 users.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 log4crc. 172. 174. 235 secure file 253. 247–253 configuration objects restricting size 83 configuration wizard for Application Server 34 connection types for Application Server 65 console settings for 84 conventions used in documentation 12 copying objects default permissions 86 cross-registering users in RBAC database 160.txt 272–285 logging 272. 253–262 securecert file 262 setting up 233. 272–285 overview 233. 64 databases configuring 78 connecting to Application Server 15 connections to 64 default entry in secure file 256 deployments 95 deleting for an Application Server 110 of Application Servers 94 DES defined 340 distinguished names for LDAP 160 documentation conventions 12 for Network Shell 12 Domain Authentication 124 configuring 171. 173. 289 scheduling 298 utility for 292 database configuration for Application Server 36 database connections for Application Server 33.

conf file 196 creating user accounts 181 default users and roles 194 exporting keytab file 181 implementing 177 locating KDC for client’s domain 197 locating KDC for service principal 186 registering Authentication Service 180 requirements for Active Directory server 180 running kinit to get a TGT 201 sample domain structure 171 updating config. 55 past due 63 setting maximum for Application Server 52 L LDAP defined 342 user names 160 LDAP authentication 122 certificate trust store 159 configuring 161 distinguished names 160 high availability 159 implementing 158 overview 158 listening ports on Application Server 65 log4crc. 11–12 IP address binding Application Server to 67 IPSec defined 341 disabling 283 enabling 283 keytab files 128 copying to Application Server 185 exporting 181 verifying 190 klist displaying SPN for Application Server 189 J job execution thread for Application Server 31 job parts for BMC BladeLogic Console jobs 31 job runs setting retention time for 290 jobs canceling 60 defining time-outs 60 distributing between Application Servers 32.properties file for clients 200 updating Kerberos registry settings 196 verifying a keytab file 190 keystore file for cooperating Application Servers 58 keystroke logs 281 M mail server configuring 76 man pages 12 middle tier communication 118 of BladeLogic 13 of BMC BladeLogic 15 mount points setting up in Application Server 82 N Network Shell and secure file 253 caching private keys 214 discontinuing use of client-side certs 216 Index 349 . 191 configuring blcred 194 copying keytab file to Application Server 185 creating blappserv_krb5. 178 client to Application Server 194 configuring Application Server 185 configuring Authentication Service 184.txt file 272.conf file 198 creating blclient_login. 272–285 <appender> tag 274 <category> tag 273 <layout> tag 277 configuring syslog 284 default values 285 syntax 272 logging configuration file 272 configuring syslog 284 default values 285 login setting requirements 88 K KDC locating for client’s domain 197 locating for service principal’s domain 186 Kerberos defined 341 Kerberos authentication 123.conf file 188 creating blclient_krb5.conf file 186 creating blappserv_login.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 introduction to BMC BladeLogic administration 11.

192 defined 343 RC4 defined 342 remote execution objects configuring ports 68 repeater servers cleanup of 294 scheduling cleanup of 300 repeaters and certificates 262 configuring advanced repeaters 316 discontinuing use of client-side certs 222 provisioning with SHA1 fingerprints 204. 221 security for 134 using advanced repeater servers 305 RESULTS_RETENTION_TIME property 290 retention policy utility P passwords requiring periodic changes 88 setting minimum length 88 setting through configuration wizard 38 past due jobs 63 Perl 17 configuring 77 permissions default 16 for copied objects 86 PKCS# 12 defined 342 PKI 350 BMC BladeLogic Server Automation Administration Guide . 176. 149 Network Shell Script Jobs for Application Server cache cleanup 299 for cleanup 297 for database cleanup 298 for file server cleanup 299 for repeater server cleanup 300 for retention policy utility 297 for target server (agent) cleanup 300 network throttling for advanced file servers 315 for advanced repeater 318 overview 324 no access nodes showing in console 84 nobody user on UNIX 17 notifications setting through configuration wizard 38 defined 342 PKI authentication 123 ports Application Server 65 for remote execution objects 68 Post-Install Configuration wizard 34 database configuration 36 file server configuration 37 notification configuration 38 password configuration 38 private keys caching in UNIX 215 caching in Windows 215 managing 214 privilege mapping described 119 process spawner configuring 79 product support 3 profiles 100 property classes enabling import/export 87 Property Dictionary enabling import/export 87 protocol levels defined in secure file 255 for secure communication 258 public key cryptography defined 342 public key infrastructure defined 342 PXE Server configuring 89 O OCSP 153 overview BMC BladeLogic 13. 219. 169. 208 securing with client-side certs 218. 166. 13–19 of Application Server 30 of configuration files 233. 235 R RBAC 128 cross-registering users 160.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 documentation 12 man pages 12 managing private keys 214 securing with client-side certs 212 security 131. 133 Network Shell Proxy Servers 68 configuring 142 configuring clients for 147 configuring stand-alone 145 setting up for AD/Kerberos 193 user information for scripts 147 Network Shell Proxy Service 135 configuring 142.

166 security administering 115. 216 secure remote password defined 343 securecert file 262 configuring 263 SecurID user names 166. 237 secure file 253 users file 247 users. 135 using blcred 226 self-signed certificates 119 server tier communication 119 of BladeLogic 13 of BMC BladeLogic 15 servers use of term 11 server-side certificates for BMC Service Automation Reporting and Analytics 132 service principal name displaying with klist 189 service URLs 117 session credential cache file 150. 217 reports client to reports server 132 session layer 118 single sign-on 121. 253–262 certificates 258 client and server interaction 254 communication protocols 255 configuring 255 configuring for agents 210. 235 exports file 240 granting access 233. 167. 125 certificate verification using OCSP 153 client file locations 152 client files 150.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 description of 289 enabling/disabling 289 executing 291 scheduling for execution 297 retention time for automatically-generated objects 291 for job runs 290 roles selecting 128 RSA SecurID 123 RSCD agents and configuration files 233. 211 Network Shell to Network Shell Proxy Server 131 privilege mapping 119 repeater to agent 134.local file 247 rscd entry in secure file 256 SecurID authentication 123 configuring 163. 137. 142 importing CA certs to clients 226 keytab files 128 LDAP authentication 122 S scripts user information for 147 secadmin utility 258 introduced 233. 152 session credentials 121. 122. 222 configuring for Network Shell Proxy Servers 147 default entry 256 encryption method 258 examples 261 host entries 257 introduced 233. 115–231 Application Server to agent or repeater 133. 168 configuring RSA Authentication Manager 163 implementing 163. 123. 126 managing with blcred 226 session key defined 343 session layer security described 118 single sign-on 117 AD/Kerberos authentication 123 authentication profiles 124. 151. 140. 202 authentication using client-side certs 117 authorization 120 BLCLI to Application Server 130 console to Application Server 130 default configuration 16 for different communication legs 130 fundamentals 117 glossary 339 impersonation 119 Network Shell to agent 133. 151 described 121 Domain Authentication 124 environment variables 129 implementing 135. 169 Index 351 . 235 secure agent logging 277 disabling 280 enabling 279 secure agent logs security overview 277 secure file 253. 235 options for configuring 258 protocol levels 258 rscd entry 256 setting defaults for clients 256 setting defaults for servers 256 setting parameters for a client 257 setting up for NSH clients 212. 124.

52. customer 3 syntax for log4crc.509 certificates 118 U update process 352 BMC BladeLogic Server Automation Administration Guide . 192 users file 247. 206. 176. 192 requirements for names 160.local 250 Windows client configuration for Kerberos 196 Windows user mapping 149 work item threads for Application Server 31.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 overrides for client SSO files 150 PKI authentication 123 SecurID authentication 123 selecting roles 128 session credentials 126 SRP authentication 122 smart card authentication 123 SNMP server configuring 77 SOCKS Proxy Servers 73 SPN displaying with klist 189 SRP defined 343 SRP authentication 122 standard terminology 11 subnet designations 236 support. 247–253 configuring 249. 235 options for configuring 251 users. 210 Network Shell to agent 212 repeater to agent 218. 151. 235 options for configuring 251 T target server scheduling cleanup of 300 target servers cleanup of 293 technical support 3 terminology BMC BladeLogic 11 TGT running kinit to get 201 three-tier architecture 13 ticket-gathering ticket running kinit to get 201 time-outs defining for job parts 60 defining for jobs 60 TLS communication protocol 118 middle tier communication 118 server tier communication 119 TLS with client-side certs Application Server to agent or repeater 202. 152 W wild cards using in users. 166. 169. 250 examples 252 introduced 233. 247–253 configuring 249 examples 252 introduced 233. 176. 61 Workflow Jobs 333 X X.dat 128 users cross-registering 160.txt file 272 syslog configuring for logging 284 system architecture overview 13 specifying temporary group location 87 user accounts adding default for AD/Kerberos 194 adding default for Domain Authentication 177 creating in Application Server’s domain 181 locking out 88 user information for Network Shell scripts 147 generating 230 user interfaces settings for 84 user privilege mapping 17. 119 user_info.local file 247. 221. 222 trusted keystore 150. 166. 169. 219.

.

*363391* *363391* *363391* *363391* *193363* .

Sign up to vote on this title
UsefulNot useful