IBM Tivoli Remote Control User Manual

Download

Front cover

Implementing IBM Tivoli Remote Control Across Firewalls

Achieve Remote Control without sacrificing security

Guide for TCP/IP ports used and troubleshooting

Set up a secure Remote Control environment based on realistic scenarios

ibm.com/redbooks

Edson Manoel

Francesca Balzi

Sebastien Fardel

Venkata R Reddy

International Technical Support Organization

Implementing IBM Tivoli Remote Control Across Firewalls

April 2003

SG24-6944-00

Note: Before using this information and the product it supports, read the information in “Notices” on page xiii.

First Edition (April 2003)

This edition applies to the following products: IBM Tivoli Remote Control 3.8, IBM Tivoli Management Framework 4.1, and Tivoli Firewall Security Toolbox 1.3.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Tabl es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix

Examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiv

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi

Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Part 1. Concepts and planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1. Remote Control sessions overview . . . . . . . . . . . . . . . . . . . . . . 3

1.1 IBM Tivoli Remote Control overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.1 IBM Tivoli Management Framework components . . . . . . . . . . . . . . . . 4

1.1.2 IBM Tivoli Remote Control components . . . . . . . . . . . . . . . . . . . . . . . 7

1.1.3 Tivoli components and communication symbols . . . . . . . . . . . . . . . . . 8

1.1.4 Parent-Child concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.1.5 Proxy connection types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2 IBM Tivoli Remote Control sessions overview . . . . . . . . . . . . . . . . . . . . . 12

1.2.1 Session in a single-TMR environment . . . . . . . . . . . . . . . . . . . . . . . 14

1.2.2 Session in a multi-TMR environment . . . . . . . . . . . . . . . . . . . . . . . . 21

1.2.3 Session using a Remote Control Gateway . . . . . . . . . . . . . . . . . . . . 31

1.2.4 Session using Remote Control Proxies Standalone . . . . . . . . . . . . . 35

1.2.5 Session using Remote Control Proxies in a TFST environment . . . . 45

Chapter 2. Implementation planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

2.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

2.1.1 Logical design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

2.1.2 Physical design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

2.1.3 Network considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

2.2 Planning for IBM Tivoli Remote Control Proxy . . . . . . . . . . . . . . . . . . . . . 73

2.3 Implementation planning case study scenario . . . . . . . . . . . . . . . . . . . . . 80

Part 2. Implementation scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Chapter 3. Implementation scenario: Standalone Proxies . . . . . . . . . . . . 93

3.1 Scenario overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

3.2 Environment description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

3.2.1 Technical infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

3.2.2 Data flow description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

3.3 Scenario installation and configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 101

3.3.1 Remote Control Proxy installation. . . . . . . . . . . . . . . . . . . . . . . . . . 101

3.3.2 Remote Control Proxy configuration . . . . . . . . . . . . . . . . . . . . . . . . 104

3.3.3 Firewall configuration table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

3.3.4 Remote Control Proxy startup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Chapter 4. Implementation scenario: Tivoli Firewall Security Toolbox . 115

4.1 Scenario overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

4.2 Environment description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

4.2.1 Technical infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

4.2.2 Data flow description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

4.2.3 Firewall configuration tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

4.3 Scenario installation and configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 125

4.3.1 Remote Control Proxy installation. . . . . . . . . . . . . . . . . . . . . . . . . . 125

4.3.2 Remote Control Proxy configuration . . . . . . . . . . . . . . . . . . . . . . . . 129

4.3.3 Remote Control Proxy startup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Part 3. Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Chapter 5. Troubleshooting techniques . . . . . . . . . . . . . . . . . . . . . . . . . . 141

5.1 Generic problem determination outline . . . . . . . . . . . . . . . . . . . . . . . . . . 142

5.1.1 Session startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

5.1.2 Session management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

5.2 Troubleshooting the Remote Control Proxy . . . . . . . . . . . . . . . . . . . . . . 155

5.2.1 The rcproxy.log file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

5.2.2 The remcon.trc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

5.3 Troubleshooting examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

5.3.1 Case 1: Controller not connecting to Target Proxy . . . . . . . . . . . . . 160

5.3.2 Case 2: Target Proxy service is not active . . . . . . . . . . . . . . . . . . . 163

5.3.3 Case 3: Wrong Proxy configuration . . . . . . . . . . . . . . . . . . . . . . . . 167

5.4 Troubleshooting the firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Part 4. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Appendix A. Tivoli Firewall Security Toolbox overview. . . . . . . . . . . . . . 175

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Components of TFST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Endpoint Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Gateway Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

iv IBM Tivoli Remote Control Across Firewalls

Relay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Event Sink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Tivoli environments with single firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Tivoli environments with multiple firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Sending events across firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Installation and configuration of TFST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Installation of TFST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Configuration of TFST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

TFST components and operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Port range configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Appendix B. Introducing firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Functionality of a firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Firewall tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Packet filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Proxy servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Socks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

DNS and mail gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Network address translation (NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Virtual Private Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Log management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Firewalls in the market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

Contents v

vi IBM Tivoli Remote Control Across Firewalls

Figures

1-1 Parent-Child hierarchy in RC Proxy-TFST architecture . . . . . . . . . . . . . 11

1-2 RC session data flow in a single-TMR environment . . . . . . . . . . . . . . . 14

1-3 RC session data flow in a multi-TMR environment . . . . . . . . . . . . . . . . 22

1-4 RC session data flow in an RC Gateway/single-TMR environment. . . . 32

1-5 RC session data flow in an RC Gateway/multi-TMR environment. . . . . 34

1-6 RC session data flow in an RC Proxy Standalone/single-TMR . . . . . . . 36

1-7 RC session data flow in an RC Proxy Standalone/multi-TMR . . . . . . . . 40

1-8 RC session data flow in an RC Proxy-TFST/single-TMR environment . 46 1-9 RC session data flow in an RC Proxy-TFST/multi-TMR environment . . 51

2-1 Planning overview for RC Proxy in a Standalone environment . . . . . . . 74

2-2 Planning overview for Remote Control Proxy in a TFST environment. . 75

2-3 Case study scenario without RC Proxy architecture . . . . . . . . . . . . . . . 82

2-4 Case study scenario with RC Proxy architecture - Solution A . . . . . . . . 84

2-5 Case study scenario with RC Proxy architecture - Solution B . . . . . . . . 88

3-1 General testing scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

3-2 RC Proxy Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

3-3 Remote Control Data Flow Overview. . . . . . . . . . . . . . . . . . . . . . . . . . 100

3-4 Remote Control Data Flow Overview. . . . . . . . . . . . . . . . . . . . . . . . . . 108

3-5 Startup of Remote Control Proxy using Service Applet . . . . . . . . . . . . 110

4-1 General TFST testing scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

4-2 Remote Control Proxy Implementation in a TFST environment . . . . . 120

4-3 Data flow overview: Non-Standalone scenario . . . . . . . . . . . . . . . . . . 122

5-1 Endpoint problem determination flow. . . . . . . . . . . . . . . . . . . . . . . . . . 144

5-2 TFST problem determination flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

5-3 RC Proxy problem determination flow . . . . . . . . . . . . . . . . . . . . . . . . . 152

5-4 Error message displayed on Controller when attempt a session. . . . . 160

5-5 Error message displayed on the Controller at session startup . . . . . . 163

5-6 Error message at session startup: Proxy configuration problem . . . . . 167

A-1 Tivoli Endpoint and Gateway proxies communication through firewall 177 A-2 Relay connecting Endpoint and Gateway proxies through a DMZ . . . 178

A-3 Event Sink collecting non-TME events . . . . . . . . . . . . . . . . . . . . . . . . 179

viii IBM Tivoli Remote Control Across Firewalls

Tables

2-1 RC ports for unidirectional communication - Parent/initiator . . . . . . . . . 63

2-2 RC ports for unidirectional communication - Parent/listener . . . . . . . . . 64

2-3 RC ports for unidirectional communication - Relay - Parents/initiators . 65 2-4 RC ports for unidirectional communication - Relay - Parents/listeners . 67

2-5 RC ports for bidirectional communication . . . . . . . . . . . . . . . . . . . . . . . 69

2-6 RC ports for bidirectional communication with Relay. . . . . . . . . . . . . . . 71

2-7 Hardware requirements for IBM Tivoli Remote Control Proxy . . . . . . . 76

2-8 Software requirements for IBM Tivoli Remote Control Proxy. . . . . . . . . 77

2-9 RC Proxy network ports for firewall 1 - Solution A. . . . . . . . . . . . . . . . . 86

2-10 RC Proxy network ports for firewall 2 - Solution A . . . . . . . . . . . . . . . . . 87

2-11 RC Proxy network ports for firewall 3 - Solution A . . . . . . . . . . . . . . . . . 87

2-12 RC Proxy network ports for firewall 1 - Solution B . . . . . . . . . . . . . . . . . 90

2-13 RC Proxy network ports for firewall 2 - Solution B . . . . . . . . . . . . . . . . . 90

2-14 RC Proxy network ports for firewall 3 - Solution B . . . . . . . . . . . . . . . . . 90

3-1 RC Target Proxy settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

3-2 RC Controller Proxy settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

3-3 Scenario firewall configuration table . . . . . . . . . . . . . . . . . . . . . . . . . . 108

4-1 Summary of Framework and Remote Control resources . . . . . . . . . . 121

4-2 Summary of port configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

4-3 Firewall 1 configuration table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

4-4 Firewall 2 configuration table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

4-5 RC Target Proxy installation settings . . . . . . . . . . . . . . . . . . . . . . . . . . 126

4-6 Relay instance installation settings . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

4-7 RC Controller Proxy installation settings . . . . . . . . . . . . . . . . . . . . . . . 128

x IBM Tivoli Remote Control Across Firewalls

Examples

1-1 RC session trace in a single-TMR environment. . . . . . . . . . . . . . . . . . . 16

1-2 The remote_control method from a single-TMR environment . . . . . . . . 19

1-3 The is_proxied_ep method from a single-TMR environment . . . . . . . . . 20

1-4 The nd_start_target method from a single-TMR environment . . . . . . . . 20

1-5 The nd_start_controller method from a single-TMR environment . . . . . 20

1-6 RC session trace from the HUB TMR in a multi-TMR environment . . . . 25

1-7 RC session trace from the Spoke TMR in a multi-TMR environment . . 25

1-8 The remote_control method from a Spoke TMR . . . . . . . . . . . . . . . . . . 28

1-9 The is_proxied_ep method from a Spoke TMR . . . . . . . . . . . . . . . . . . . 29

1-10 The nd_start_target method from a Spoke TMR . . . . . . . . . . . . . . . . . . 29

1-11 The nd_start_controller method from a Spoke TMR . . . . . . . . . . . . . . . 29

1-12 The nd_start_controller method from a HUB TMR . . . . . . . . . . . . . . . . 30

1-13 The rc_def_gw default policy method for Remote Control . . . . . . . . . . . 33

1-14 The rc_def_proxy default policy method for Remote Control. . . . . . . . . 38

1-15 The is_proxied_ep method for an RC Proxy Standalone architecture . . 43 1-16 The nd_start_target method for an RC Proxy Standalone architecture . 43 1-17 The nd_start_controller method for RC Proxy Standalone architecture 44

1-18 The rc_def_proxy default policy method for Remote Control. . . . . . . . . 49

1-19 The is_proxied_ep method for an RC Proxy-TFST architecture . . . . . . 54

1-20 The nd_start_target method for an RC Proxy-TFST architecture . . . . . 55

1-21 The nd_start_controller method for an RC Proxy-TFST architecture. . . 55

3-1 Hub TMR region. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

3-2 Spoke TMR region. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

3-3 Hub TMR Endpoint Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

3-4 Spoke TMR Endpoint Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

3-5 Remote Control Target Proxy configuration file. . . . . . . . . . . . . . . . . . 104

3-6 Remote Control Controller Proxy configuration file . . . . . . . . . . . . . . . 105

3-7 Target Proxy local-port-rage definition. . . . . . . . . . . . . . . . . . . . . . . . . 105

3-8 Remote Control Proxy routing table configuration file . . . . . . . . . . . . . 106

3-9 The rc_def_proxy policy method contents . . . . . . . . . . . . . . . . . . . . . . 107

3-10 How to modify the rc_def_proxy policy method . . . . . . . . . . . . . . . . . . 107

3-11 Startup of Remote Control Proxy on AIX operating system. . . . . . . . . 109

3-12 The rcproxy.log: RC Target Proxy log file . . . . . . . . . . . . . . . . . . . . . . 110

3-13 The rcproxy.log: RC Controller Proxy log file . . . . . . . . . . . . . . . . . . . . 111

3-14 The netstat output collected on the RC Target Proxy . . . . . . . . . . . . . 111

3-15 The netstat output collected on the Controller Proxy . . . . . . . . . . . . . . 112

3-16 The output of the rcproxy -list command . . . . . . . . . . . . . . . . . . . . . . . 113

4-1 RC Controller Proxy configuration file . . . . . . . . . . . . . . . . . . . . . . . . . 129

4-2 RC Target Proxy configuration file example . . . . . . . . . . . . . . . . . . . . 130

4-3 Modification settings example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

4-4 The Relay.cfg after the installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

4-5 The Relay.cfg file after the changes . . . . . . . . . . . . . . . . . . . . . . . . . . 132

4-6 The rc_def_proxy policy method contents . . . . . . . . . . . . . . . . . . . . . . 132

4-7 The rcproxy.log: RC Target Proxy log file . . . . . . . . . . . . . . . . . . . . . . 133

4-8 The Relay.log: Relay log file contents . . . . . . . . . . . . . . . . . . . . . . . . . 134

4-9 The rcproxy.log: RC Controller Proxy log file . . . . . . . . . . . . . . . . . . . . 134

4-10 The netstat output collected on the RC Target Proxy . . . . . . . . . . . . . 135

4-11 The netstat output collected on the Relay . . . . . . . . . . . . . . . . . . . . . . 135

4-12 The netstat output collected on the Controller Proxy . . . . . . . . . . . . . . 136

4-13 The output of the rcproxy -list command . . . . . . . . . . . . . . . . . . . . . . . 137

5-1 The rcproxy.log file settings in the rcproxy.cfg file . . . . . . . . . . . . . . . . 155

5-2 The Target Proxy log file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

5-3 The Controller Proxy log file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

5-4 The remcon.trc file for the Controller machine. . . . . . . . . . . . . . . . . . . 158

5-5 The Target Proxy log file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

5-6 The Controller Proxy log file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

5-7 The remcon.trc file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

5-8 The rc_def_proxy policy method changes in order to fix the problem . 162

5-9 The Endpoint Proxy log file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

5-10 The Relay log file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

5-11 The Gateway Proxy log file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

5-12 The Target Proxy log file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

5-13 The Relay log file (instance used by remote control proxies) . . . . . . . 166

5-14 The Controller Proxy log file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

5-15 The remote control Target Proxy log file . . . . . . . . . . . . . . . . . . . . . . . 167

5-16 The remote control Relay log file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

5-17 The remote control Controller log file. . . . . . . . . . . . . . . . . . . . . . . . . . 169

5-18 The Relay configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

5-19 Wrong Target Proxy configuration file . . . . . . . . . . . . . . . . . . . . . . . . . 170

xii IBM Tivoli Remote Control Across Firewalls

Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law

THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.

COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces.

Trademarks

The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:

AIX® CT™

™

Illustra™ IBM® ibm.com®

The following terms are trademarks of other companies:

ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States, other countries, or both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

C-bus is a trademark of Corollary, Inc. in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC.

Other company, product, and service names may be trademarks or service marks of others.

pSeries™ Redbooks™ Redbooks (logo) ™ SecureWay® SP™ SP1®

Tivoli Enterprise™ Tivoli Enterprise Console® Tivoli® TME 10™ TME®

xiv IBM Tivoli Remote Control Across Firewalls

Preface

System administrators and help desk personnel sometimes need access to remote PCs in order to resolve problems and assist users with important business applications. Most organizations will, at some point, need to expand their management of systems from their regular systems management environment to those that exist on the other side of firewalls. Tivoli® Remote Control allows a system administrator to control the keyboard and mouse input and monitor the display output of a remote machine, independently of the firewall architecture.

This book presents a concise documentation of known requirements for implementing the IBM Tivoli Remote Control 3.8 across firewalls.

This IBM® Redbook will prove invaluable for Tivoli system administrators and Tivoli designers and firewall administrators planning, designing, implementing, and operating a Remote Control environment that involves firewalls. The results from a variety of test scenarios are presented along with tabulated firewall configuration requirements for the various components involved in such solution.

The team that wrote this redbook

This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Austin Center.

Edson Manoel is a Software Engineer at the IBM Corporation, International Technical Support Organization (ITSO), Austin Center, working as an IT Specialist in the Systems Management area. Prior to joining the ITSO, Edson worked in the IBM Software Group as a Tivoli Technology Ambassador and in IBM Brasil Professional Services Organization as a Certified IT Specialist. He was involved in numerous projects, designing and implementing systems management solutions for IBM customers and Business Partners. Edson holds a BSc degree in Applied Mathematics from Universidade de Sao Paulo, Brazil.

Francesca Balzi is a Tivoli Software Engineer at the IBM Tivoli Software Laboratory, in Italy. She has 7 years of experience in Customer Support. Her areas of expertise include problem determination and source identification in the client-server environment. She is currently performing Level 2 support for the EMEA Geo on IBM Tivoli Remote Control and IBM Tivoli Configuration Manager.

Sebastien Fardel is an Advisory IT Specialist at IBM Corporation, Global Services, Switzerland, acting as a Tivoli Architect in the Performance and Availability and Configurations and Operations areas. He has been in the IT industry since 1996 and has experience in IT infrastructure management, programming, and Systems Management area. His e-mail is sfa@ch.ibm.com.

Venkata Reddy is a software Engineer working for IBM Software Labs in Bangalore, India. He has three years of IT experience and is working as part of networking software group. He leads the firewall India team for providing Level3 support and Enhancements for IBM SecureWay® firewall. His areas of expertise include network security and firewalls.

Thanks to the following people for their contributions to this project:

Joanne Luedtke, Lupe Brown, Wade Wallace, and Chris Blatchley International Technical Support Organization, Austin Center

Yvonne Lyon International Technical Support Organization, San Jose Center

Silvia Giacone, Nicola Milanese, and Ugo Madama Remote Control Development and Verification Team, IBM Rome

Alan Hsu Market Manager - Remote Control, IBM Software Group Austin

Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll team with IBM technical professionals, Business Partners and/or customers.

Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability.

Find out more about the residency program, browse the residency index, and apply online at:

ibm.com/redbooks/residencies.html

xvi IBM Tivoli Remote Control Across Firewalls

Comments welcome

Your comments are important to us!

We want our Redbooks™ to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways:

򐂰 Use the online Contact us review redbook form found at:

ibm.com/redbooks

򐂰 Send your comments in an Internet note to:

redbook@us.ibm.com

򐂰 Mail your comments to:

IBM Corporation, International Technical Support Organization Dept. JN9B Building 003 Internal Zip 2834 11400 Burnet Road Austin, Texas 78758-3493

Preface xvii

xviii IBM Tivoli Remote Control Across Firewalls

Part 1

Part 1 Concepts and

planning

2 IBM Tivoli Remote Control Across Firewalls

Chapter 1. Remote Control sessions

overview

System administrators often need to manage servers or workstations in distant secure locations — for example, in an outsourcing project. If a problem on one of these machines requires attention, the administrator traditionally has two options: try to resolve the problem over the telephone with an authorized person (with a high chance of miscommunication); or relocate to the user’s location for problem determination (which is often impractical). IBM Tivoli Remote Control allows an administrator to control the keyboard and mouse input and monitor the display output of a remote machine even in zones protected by any kind of network controlling process like firewalls. In addition, the administrator can just monitor, reboot the PC, or transfer files in a really simple way.

In this chapter we cover the following topics: 򐂰 Business perspectives for a solution using IBM Tivoli Remote Control across

firewalls

򐂰 An overview of the IBM Tivoli Remote Control functionality 򐂰 A detailed description of the IBM Tivoli Remote Control components that will

help to manage machines inside secure areas 򐂰 A detailed description of each type of communication used to exchange

information between the different zones

1.1 IBM Tivoli Remote Control overview

The purpose of this chapter is not only to explain how IBM Tivoli Remote Control works in general, but to emphasize its architecture and functionality in a firewall environment. Even though the architecture and implementation of IBM Tivoli Remote Control may differ when firewalls are involved from implementation to implementation, the IBM Tivoli Remote Control functionality will remain the same. Therefore, in order to fully understand how remote control sessions work across firewalls, it is important to understand how this works in a non-secure environment.

IBM Tivoli Remote Control (ITRC) provides a complete real-time solution for remote controlling the target systems. For all intents and purposes, the technician or administrator’s keyboard and mouse become the primary keyboard and mouse for the target system for the duration of a remote control session. Functionalities such as chat, reboot, and file transfer are available to the administrator.

IBM Tivoli Remote Control runs on top of the IBM Tivoli Management Framework. However, in the context of a firewalls environment, some other components must be installed in order to simplify and secure the way that communications are exchanged between the different components of IBM Tivoli Remote Control. Before continuing and defining the complete Remote Control process across firewalls, it is important to first know and understand the utility and functionality of each component of IBM Tivoli Remote Control and of IBM Tivoli Management Framework.

1.1.1 IBM Tivoli Management Framework components

The IBM Tivoli Management Framework enables you to install and create several management components (services) that allow you to manage the resources in your network. You can install any or all of these services, depending on your organizational needs. As a minimum, one TMR server must be installed. The following is a list of the management services provided by the Tivoli Management Framework and a brief description of each:

TMR Server The Tivoli Management Region (TMR) Server includes

the libraries, binaries, data files, and graphical user interface (GUI) needed to install and manage your Tivoli environment. The TMR Server maintains the Object DataBase and coordinates all communications with Tivoli managed systems, like Managed Nodes and Endpoints (through Tivoli Endpoint Gateways). The server also performs the authentication and verification necessary to ensure the security of Tivoli Enterprise™ data.

4 IBM Tivoli Remote Control Across Firewalls

Managed Node A Tivoli Managed Node runs the same software that runs

on a TMR Server. Managed Nodes maintain their own Object DataBases, which can be accessed by the TMR Server. When Managed Nodes communicate directly with other Managed Nodes, they perform the same communication or security operations as they would perform with the TMR Server. Although there is no clear distinction between managed systems and managing systems, the introduction of the Endpoints architecture leads to a paradigm shift. Managed Nodes are considered to be managing systems (hosting the desktop or running as a gateway), whereas endpoints are the managed systems.

Endpoint Manager The Endpoint Manager establishes and maintains the

relationship between an Endpoint and its assigned Gateway. It is involved in taking the Endpoint in charge when its assigned Gateway is no longer responding. It is also involved in identifying the Gateways that an Endpoint is assigned to when applications are trying to contact the Endpoint. The Endpoint Manager runs on top of the TMR Server and is automatically created during the TMR Server installation process.

Endpoint Gateway The Endpoint Gateway provides access to the Endpoint

methods and provides the communications with the TMR Server that the Endpoints occasionally require. A single Gateway can support communications with thousands of Endpoints and can launch methods on an Endpoint or run methods on the Endpoint’s behalf. A Gateway is created on an existing managed node.

Endpoint Proxy An Endpoint Proxy is an optional component that

emulates Endpoints to the Gateway to simplify the Tivoli communications in a firewall environment through a common port. The Endpoint Proxy funnels requests for specific Endpoints through a single TCP/IP port and passes it down to a Relay or a Gateway Proxy. This component is part of the Tivoli Firewall Security Toolbox and must be installed on the same network zone as the Tivoli Endpoint Gateway on which it is connected.

Chapter 1. Remote Control sessions overview 5

Relay The Relay component’s purpose is to pass information

sent to it up or down the chain to an Endpoint Proxy, Gateway Proxy, or other Relays. This component is optional and is part of the Tivoli Firewall Security Toolbox. It must be installed in the network zone between the Endpoint Proxy and the Gateway Proxy. Multiple Relays could be chained to allow this connection if Endpoint Proxy and Gateway Proxy are separated by multiple network zones. There can be multiple instances of the Relay running on the same machine.

Gateway proxy A Gateway Proxy is an optional component that

emulates a Gateway to the Endpoints to simplify the Tivoli communications in a firewall environment through a common port. The Endpoints are not explicitly aware of the fact that this destination is not truly a Gateway. This component is part of the Tivoli Firewall Security Toolbox and must be installed on the same network zone as the distant Endpoints.

Endpoint A Tivoli Management Agent (TMA) is any system that

runs an Endpoint service (or daemon). Typically, an Endpoint is installed on a machine that is not used for daily management operations. Endpoints run a very small amount of software and do not maintain a database. The majority of systems in most Tivoli Enterprise installations will be Endpoints.

Policy Region A Policy Region is a collection of Tivoli resources that are

governed by a common set of policies. A Policy Region is often created to represent a management domain or area of influence for one or more system administrators.

Administrator Tivoli Administrators are persons who will be responsible

for managing various aspects of enterprise wide systems management. Tivoli functionality allows administrative functions that may be performed at many levels and locations of the organization. Administrators may be individuals or groups of persons with different logins.

Collection The Collection is a container that groups objects on a

Tivoli Desktop, thus providing the Tivoli Administrator with as single view of related resources. Such Collections are defined when an Administrator has the need to centralize miscellaneous resources stored in different Policy Regions. A Collection provides a “shortcut” for using resources.

6 IBM Tivoli Remote Control Across Firewalls

For more information about TMR Server, Managed Node, Endpoint Gateway, Endpoint and Policy Region, refer to

Deployment Guide

For more information about Endpoint Proxy, Gateway Proxy and Relay, refer to Firewall Security Toolbox User ’s Guide, GC23-4826 and to Tivoli Enterprise Management Across Firewalls, SG24-5510.

, GC32-0803.

Tivoli Management Framework Planning for

1.1.2 IBM Tivoli Remote Control components

As already mentioned, the IBM Tivoli Remote Control is a client-server application that helps you take control over workstations on a network using a specific remote control technology. It could serve as a central location for monitoring and controlling machines at local or remote locations. The following is a definition list of the Remote Control components. Their installation is mandatory except for the Remote Control Proxies and the Remote Control Gateway, which are only used in environments where components of a Tivoli Management Region are separated by firewalls:

RC Server The Remote Control Server (RC Server) component is

installed on the TMR Server and on each Managed Node that will act as an Endpoint Gateway. It manages the Remote Control session request from a Remote Control Controller to a Remote Control Target until the connection between the two machines is successfully initiated.

RC Tool The Remote Control Tool (RC Tool) is the Remote

Control managed resource in the Tivoli Management Region and is associated with a Policy Region. This tool enables remote operations such as remote controlling or rebooting of a workstation, transferring files and chatting. Customizing the default Remote Control policies allows you to change the set of rules that will apply to the RC Tool within a Policy Region.

RC Policies The Remote Control Policies consist of a set of rules, the

so-called policy methods, that allows to change the default behavior and graphical appearance of Remote Control Tools.

RC Controller The Remote Control Controller component is

automatically installed on each Endpoint that initiates a Remote Control session. It will enable a Tivoli Administrator to take control of a remote target workstation to which it is linked over a network. This component is also known as Controller.

Chapter 1. Remote Control sessions overview 7

RC Target The Remote Control Target component is automatically

installed on each Endpoint when a session from a Remote Control Controller is initiated. This component is also known as Target.

RC Controller Proxy The Remote Control Controller Proxy is an optional

component which could be used to simplify the communication between Controllers and Targets in a firewall environment through a common port. In fact, this component simulates a Remote Control Controller to the Targets that are separated from the Controllers by firewalls. This component must be installed in the same network zone as the Targets. Nevertheless, this component could be either installed on top of a Endpoint/Gateway Proxy or as a Standalone component.

RC Target Proxy The Remote Control Target Proxy is an optional

component which could be used to simplify the communication between Controllers and Targets in a firewall environment through a common port. In fact, this component simulates Remote Control Targets to the Controllers that are separated from the Targets by firewalls. This component must be installed in the same network zone as Controllers. Nevertheless, this component could be either installed on top of a Endpoint/Gateway Proxy or as a Standalone component.

RC Gateway The Remote Control Gateway is an optional component

which could be used when direct link from the Controller to the Target is not authorized. Thus, in this case, a Remote Control Gateway needs to be installed on top of a Tivoli Endpoint Gateway.

1.1.3 Tivoli components and communication symbols

In the figures and scenarios that follow, we use the following set of symbols to denote the various components and type of communication for easy recognition:

Tivoli Management Region Server (blue line)

Endpoint Gateway, Remote Control Server, Endpoint Manager or Instance of the Tivoli Firewall Security Toolbox Relay

8 IBM Tivoli Remote Control Across Firewalls

Endpoint, Remote Control Controller or Remote Control Target

Policy Region (blue line)

Collection (blue line)

Remote Control Tool

Endpoint Proxy or Gateway Proxy (black line)

Remote Control Target Proxy or Remote Control Controller Proxy

Instance 1 of the Tivoli Firewall Security Toolbox Relay (black line)

Firewall

Network zone secured by a firewall (red line)

Tivoli Framework communication (black line)

Tivoli Remote Control session communication (blue line)

Tivoli proprietary protocol encapsulated in HTTP (green line)

Chapter 1. Remote Control sessions overview 9

1.1.4 Parent-Child concept

The hierarchy of the components of either the Tivoli Firewall Security Toolbox or the Remote Control Proxies (either RC Target Proxy or RC Controller Proxy) is presented in terms of a Parent-Child relationship. Such hierarchy is a subset of the whole Tivoli Top-Down hierarchy. It means that the starting point is the TMR Server and the ending point is the Endpoint. The components close to the TMR Server will be Parents and the ones close to the Endpoints will be Children. However, some components could, at the same time, be a Child and a Parent, as they are just in between the Parent-Child hierarchy. You must also notice that a Parent could have more than one Child but that a Child could only have one Parent.

As the Endpoint Proxy, which simulates Endpoints, is the closest element from the TMR Server, it is a Parent and, as it is directly connected to a Tivoli Gateway, it could not have any Parent. As the Gateway Proxy, which simulates a Tivoli Gateway, is the closest element from the Endpoints, it is a Child and as it the most closest component from the bottom of the hierarchy, it could not have any Child. A Relay could be either a Parent or a Child. When it is connected to an Endpoint Proxy or to another Relay, it becomes a Child of those components. In another way, when a Gateway Proxy or another Relay connects to a Relay, this one also becomes a Parent for these components.

In the case of Remote Control Proxies being installed on top of the Tivoli Firewall Security Toolbox components, the RC Proxy (either Target or Controller Proxy) installed on the Endpoint Proxy is a Parent of Relays or other RC Proxies. The RC Proxy installed on the Gateway Proxy is a Child of an RC Proxy installed on an Endpoint Proxy or a Relay. As no Remote Control components could be installed on the Relay, an RC Proxy could only be either a Parent or a Child, but not both at the same time.

If the Remote Control Proxies are installed as Standalone components, you have to decide on the Parent-Child role for each of the Proxies (Target and Controller Proxies). For configuration improvement, it is advised to configure the Target Proxy as the Parent and the Controller Proxy as the Child. This is because connection requests to the Target Proxy are done by the RC Controller. So, this request is always forwarded by the RC Target Proxy to the RC Controller Proxy. In this case, to logically respect a Top-Down hierarchy and to improve performance for the request, the RC Target should be the Parent.

Figure 1-1 depicts the Top-Down Proxy hierarchy when Remote Control Proxy components are installed on top of the Tivoli Firewall Security Toolbox.

10 IBM Tivoli Remote Control Across Firewalls

TMR Server

Endpoint GW

Parent

RC Target Proxy

Endpoint Proxy

Parent

Firewall

DMZ

Firewall

Gateway Proxy

Child

RC Contr. Proxy

Child

Parent

Relay

Child

Figure 1-1 Parent-Child hierarchy in RC Proxy-TFST architecture

Note: Understanding this hierarchy is important when you install and configure the components.

1.1.5 Proxy connection types

In some secure environments, the firewall’s constraints are so high that only communications from the more secure environment to the less secure environments are allowed. Either the Tivoli Firewall Security Toolbox or the Remote Control Proxies communications are designed to support those constraints. Even though we explain the proxy connection types in this section using the Tivoli Firewall Security Toolbox components, the same is valid for the Remote Control Proxies.

Endpoint

External

Firewall

Child

Gateway Proxy

RC Contr. Proxy

Endpoint

Child

DMZ

Different types of communications are available. The key point is which component initiates the communication:

Chapter 1. Remote Control sessions overview 11

򐂰 Bidirectional communication: In simple secure environments,

communications could be initiated either by a component on the less secure

zone or by the one located on the more secure zone. For example, an

Endpoint initiates an upcall that is intercepted by the Gateway Proxy and

further sent to the Endpoint Proxy, which in turn will forward it to the Tivoli

Endpoint Gateway. In reverse, the Endpoint Proxy could initiate a downcall to

the Endpoint without any restrictions. 򐂰 Unidirectional communication: In more secure environments,

communications could only be initiated by components located in one of the

zones. For example, if an Endpoint needs to initiate an upcall, this one is

intercepted by the Gateway Proxy and held until the Endpoint Proxy polls

their Gateway Proxies, at configurable intervals, to check if any of them have

data to be sent. In this case, the Endpoint Gateway is called the

will be responsible to poll their Child. The Gateway Proxy is called the

Initiator, as it

Listener, as it will wait for a send request before being able to transfer any

information. The poll interval is set to 2 seconds by default and could be

configured by changing the polling-interval parameter in the epproxy.cfg,

gwproxy.cfg, and/or rcproxy.cfg configuration files. For more information

about the Endpoint and Gateway proxies configuration files, refer to Firewall

Security Toolbox User ’s Guide, GC23-4826. The

User’s Guide

Proxies configuration files.

, SC23-4842, provides information for the Remote Control

IBM Tivoli Remote Control

1.2 IBM Tivoli Remote Control sessions overview

In this section we describe in detail the data flow of Remote Control sessions used in different implementations. This is meant to help you to fully understand how the communications of Remote Control work and what you have to consider in your design in order to respect the firewall restrictions.

The example scenarios used in this section are based on commonly found Remote Control architecture implementations in which the RC Controller is installed on the most secure side of the firewall and the Targets on the less secure zone. These scenarios should provide you enough information to master others more complicated situations. Furthermore, only the Remote Control action is discussed, but the process is basically the same for the File Transfer action. More information for these actions can be found in the

User’s Guide

Attention: Only the Remote Control and the File Transfer actions can use the Remote Control Proxy technology to cross firewalls.

12 IBM Tivoli Remote Control Across Firewalls

, SC23-4842.

IBM Tivoli Remote Control

The Remote Control session scenarios could be divided into the following categories.

򐂰 Sessions in a single-TMR environment with no firewall restrictions. It is

important to understand how these kinds of sessions work, because the basic

concepts remain valid for all others scenarios. 򐂰 Sessions in a multi-TMR environment with no firewall restrictions. At first it

seems similar to the way Remote Control works in a single-TMR environment.

However, the HUB-Spoke concept introduces new constraints that need to be

discussed. For more information about HUB-Spoke concept, refer to the

Management Framework Planning for Deployment Guide

򐂰 Sessions with firewall restrictions using the Remote Control Gateway

component. We will describe how sessions are established for both

single-TMR and multi-TMR environments when using the Remote Control

Gateway component. 򐂰 Sessions with firewall restrictions using StandAlone Remote Control Proxies.

We will show how sessions can be established for both single-TMR and

multi-TMR environments when using the Remote Control Proxies. This type

of sessions are commonly known as Remote Control Proxies in

mode

򐂰 Sessions with firewall restrictions using the Remote Control Proxies in

conjunction with the TFST components. We will show how sessions can be

established for both single-TMR and multi-TMR environments, as well as for

multi-firewall environments when using the Remote Control Proxies installed

on top of the TFST components.

, GC32-0803.

standalone

Tivoli

Note: There are three different ways to start a Remote Control session:

򐂰 Using the Tivoli Desktop 򐂰 Via the Tivoli WEB interface 򐂰 Using the Tivoli command line

In the following sections, only the Tivoli Desktop process will be discussed. However, the Remote Control data flow for any of the above methods remains the same. The advantage to use the Tivoli WEB interface is that even if you are on a secure site, the process will use the HTTP protocol, which is firewall friendly, to get the Targets list.

Nevertheless, as the following sections do not describe the best way to start a session, but only how the session works, for illustrative purposes only, we decided to use the Tivoli Desktop interface. For more information on how to start a Remote Control session, refer to the

Guide

, SC23-4842.

Chapter 1. Remote Control sessions overview 13

IBM Tivoli Remote Control User’s

1.2.1 Session in a single-TMR environment

In order to fully understand how a Remote Control session works, it is important to know in detail the entire data flow between the different elements of IBM Tivoli Remote Control, starting with the most simple scenario.

Data flow for single-TMR session

Figure 1-2 shows in detail how a Remote Control session works in a single-TMR environment without firewall restrictions.

TMR Server

RC Tool

RC Server

Endpoint Mgr Endpoint GW

Endpoint GW

Figure 1-2 RC session data flow in a single-TMR environment

Based on Figure 1-2, here we provide a description of each step, from the time the Tivoli Administrator opens the Remote Control Tool (RC Tool) until the connection is established between the Controller and the Target.

The legend used in this diagram is explained as follows: A The Tivoli Administrator must first open an RC Tool to be able to

select a Target from a list. As the RC Tool is located in a Policy Region, it needs to be opened as well.

Controller

Target

14 IBM Tivoli Remote Control Across Firewalls

B As soon as the RC Tool is opened, the Remote Control Server needs

to validate the Controller by checking:

– If the Controller is an Endpoint – If the label of the Endpoint is the same as of the hostname of the

Controller

– If the interpreter of the Controller is supported and able to start a

Remote Control session

In order to get this information, the Remote Control Server needs to contact the Endpoint Manager.

C If the Controller is validated, the Remote Control Server loads a

subset of the Remote Control policies from the Policy Region where the RC Tool is located. For our examples, we will call these policies. These opened. No more are loaded for the time the Tool is active.

D At this point, the Tivoli Administrator can start a Remote Control

session by clicking the Run button of the RC Tool after selecting a Ta r ge t .

E The Remote Control Server needs to load the rest of the Remote

Control policies. These policies are more network related and, for example, specifies if a Remote Control Proxy or a Remote Control Gateway should be used and which port are defined to start the session. Unlike the basis policies, these Remote Control policies are loaded every time a new session is started from this RC Tool. Example 1-1 shows which policies are read when the session starts, and which are read when the RC Tool is opened.

basis policies are only accessed when the RC Tool is

basis

F As soon as all Remote Control policies are loaded, the Remote

Control Server needs to obtain additional information for both the Controller and the Target, such as their IP addresses. In order to get this information, the Remote Control Server must contact the Endpoint Manager.

G Before initiating the connection, the Remote Control Server needs to

know if the Target needs to be reached using an Endpoint Proxy/Gateway proxy infrastructure or not. If the Target is a proxied Endpoint, the Remote Control Server should send the request through an Endpoint Proxy instead of using the standard Tivoli Endpoint Gateway communication process.

H As soon as the Remote Control Server knows how it should contact

the Target, it sends the nd_start_target method down to the Target and waits for the process to start. The local process started on the Target machine is named EQNRCMAI.EXE.

Chapter 1. Remote Control sessions overview 15

I As soon as the Target is started, the Remote Control Server sends

the nd_start_controller method to the Controller and waits for the process to start. The local process started on the Controller machine is named EQNRSMAI.EXE.

J The Remote Control session is now established. It is important to

notice that once the session established, the Controller talks directly with the Target; this is a peer-to-peer communication. The Target is listening on port 2501 (port 2502 for File Transfer and port 2503 for chat) by default. On the Controller side, by default, the port is assigned by the communication stack. However, these ports could be easily changed by configuring the rc_def_ports Remote Control Policy.

Tracing for single-TMR session

Example 1-1 is a subset of the output from a IBM Tivoli Management Framework odstat command. It shows each method used to start a Remote Control session in a single-TMR environment as described above. This trace was captured from the time when a Tivoli Administrator opened an RC Tool until the session was established after the Administrator clicked the Run button of this RC Tool. This trace helps to fully depict the data flow shown in Figure 1-2 on page 14.

From the trace file, we can see what basis Remote Control policies are loaded when the Tivoli Administrator opens the RC Tool, and all the network related Remote Control policies that are loaded each time a Target request is started from a Controller. We can also see that the session is first started on the Target and then on the Controller before the peer-to-peer connection is established.

Example 1-1 RC session trace in a single-TMR environment

******************************************************************************* Remote Control Tool is opened and RC Controller is checked. *******************************************************************************

0.0.0 get_name_registry

1562174364.1.26 lookup

1562174364.1.1418#PcController::controller# _get_info

1562174364.1.26 lookup

1562174364.1.4 lookup_id

1562174364.1.4##6@LCFData::ep_tnr_info_s describe

1562174364.1.26 lookup

1562174364.1.531#TMF_LCF::EpMgr# get_endpoint_key_value

1562174364.1.1413#PcRC::RemoteControl# get_policy_region

1562174364.1.1413#PcRC::RemoteControl# get_policy_region_name

1562174364.1.1413#PcRC::RemoteControl# _get_label

16 IBM Tivoli Remote Control Across Firewalls

******************************************************************************* “Basis” Remote Control Policies are loaded. *******************************************************************************

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_define

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_uncheckedlist

0.0.0 get_name_registry

1562174364.1.26 lookup

1562174364.1.14#TMF_SysAdmin::Library# find_members

1562174364.1.184#TMF_SysAdmin::InstanceManager# find_members

1562174364.1.26 lookup

1562174364.1.4 lookup_id

1562174364.1.4##2@TMF_PolicyRegion::GUI describe

1562174364.1.4##2@TMF_PolicyRegion::GUI _get_type

1562174364.1.1139#TMF_PolicyRegion::GUI# find_members

0.0.0 get_name_registry

1562174364.1.26 lookup

1562174364.1.14#TMF_SysAdmin::Library# find_members

1562174364.1.184#TMF_SysAdmin::InstanceManager# find_members

1562174364.1.26 lookup

1562174364.1.4 lookup_id

1562174364.1.4##2@TMF_PolicyRegion::GUI describe

1562174364.1.4##2@TMF_PolicyRegion::GUI _get_type

1562174364.1.1141#TMF_PolicyRegion::GUI# find_members

1562174364.1.1413#PcRC::RemoteControl# _get_pres_object

1562174364.1.635#TMF_UI::Presentation# _get_dialogs

1562174364.1.635#TMF_UI::Presentation# _get_bitmaps

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_command

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_gw

1562174364.1.178#TMF_Administrator::Configuration_GUI# _get_label

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_rcmode

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_ftmode

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_grace_time

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_timeout_op

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_optimize

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_initstate

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_alt_t

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_backgrnd

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_rate

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_color

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_inactivity

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_gw

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_comp

******************************************************************************* Remote Control session is initiated by pressing the Run button of the RC Tool *******************************************************************************

Chapter 1. Remote Control sessions overview 17

1562174364.1.1413#PcRC::RemoteControl# remote_control

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_gw

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_ports

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_encryption

1562174364.1.1127#TMF_PolicyRegion::GUI# rc_def_proxy

1562174364.1.26 lookup

1562174364.1.531#TMF_LCF::EpMgr# get_endpoint_key_value

1562174364.21.517+#TMF_Endpoint::Endpoint# _get_label

1562174364.17.517+#TMF_Endpoint::Endpoint# _get_label

1562174364.1.26 lookup

1562174364.1.531#TMF_LCF::EpMgr# get_endpoint_key_value

1562174364.21.517+#TMF_Endpoint::Endpoint# is_proxied_ep

1562174364.21.517+#TMF_Endpoint::Endpoint# nd_start_target

1562174364.1.26 lookup

1562174364.1.531#TMF_LCF::EpMgr# get_endpoint_key_value

1562174364.17.517+#TMF_Endpoint::Endpoint# nd_start_controller

1562174364.1.26 lookup

1562174364.1.531#TMF_LCF::EpMgr# get_endpoint_key_value

In order to further explain the Remote Control session process, it is necessary to understand how the Remote Control Server knows which Controller the session is initiated from, and which Target the session should be started to. This information can be found in the IBM Tivoli Management Framework wtrace command output (wtrace -jHk $DBDIR). This trace was captured at the same time as the odstat command trace. The following examples show the detailed information from the wtrace output about the most important lines of the IBM Tivoli Management Framework odstat trace file shown in Example 1-1 on page 16.

As a reference, the following information is important to understand the content of the examples:

򐂰 The object ID of the Target is 1562174364.21.517+#TMF_Endpoint::Endpoint# 򐂰 The object ID of the Controller is

1562174364.17.517+#TMF_Endpoint::Endpoint#

򐂰 The Object ID of the Remote Control Tool

1562174364.1.1413#PcRC::RemoteControl#

򐂰 The Tivoli Administrator who initiates this session is

Root_ITSO-region(ITSO\Administrator@ITSO)

Example 1-2 details the remote_control method which could also be named the Target request. It refers to the following line in Example 1-1 on page 16:

1562174364.1.1413#PcRC::RemoteControl# remote_control

18 IBM Tivoli Remote Control Across Firewalls

Example 1-2 The remote_control method from a single-TMR environment

loc-ic 687 M-hdoq 1-426 776 Time run: [Mon 27-Jan 17:11:33]

Object ID: 1562174364.1.1413#PcRC::RemoteControl# Method: remote_control Principal: ITSO\Administrator@ITSO (8731208/0) Path: /w32-ix86/TME/PCREMOTE/pcremote Trans Id: { 1562174364:1,1562174364:1,220:135 } #4 Input Data: (encoded):

{ 251658240 [ "WD_DIALOG_OWNER=1562174364.1.1413#PcRC::RemoteControl#" "WD_GADGET_PATH=" "WD_SOURCE_PATH=btn_run" "WD_DIALOG_NAME =pcremote" "WD_DIALOG_INSTANCE=3668:0" "WD_DESKTOP_OID=1562

174364.1.549#TMF_UI::Extd_Desktop#" "WD_DESKTOP_PID=3436" "WD_DESKTOP_HOST=ITSO" "WD_DESKTOP_FQ_HOST=ITSO" "WD_DISPLAY =ITSO:0" "WD_OCO_OID=1562174364.1.178#TMF_Administrator: :Configuration_GUI#" "WD_VERSION=1" "WD_TYPE=Windows" "LANG=en" "LC_ALL=EN_US" ]

} "1562174364.21.517+#TMF_Endpoint::Endpoint#" "1562174364.17.517 +#TMF_Endpoint::Endpoint#" 67109120 "controla" " /R50 /B /C8" "" "Root_ITSO-region(ITSO\Administrator@ITSO)

Example 1-3 details the is_proxied_ep method. It refers to the following line in Example 1-1 on page 16:

1562174364.21.517+#TMF_Endpoint::Endpoint# is_proxied_ep

This method checks if the Target is behind an Endpoint Proxy/Gateway Proxy architecture. If the result is true, Remote Control knows that an Endpoint Proxy must be used to contact the Target. We can see that the result of this method is false; this means that the Target is not an Endpoint connected to a Gateway Proxy.

Chapter 1. Remote Control sessions overview 19

Example 1-3 The is_proxied_ep method from a single-TMR environment

loc-oc 699 9 Results: (encoded): false

Example 1-4 details the nd_start_target method. It refers to the following line in Example 1-1 on page 16:

1562174364.21.517+#TMF_Endpoint::Endpoint# nd_start_target

This method is used to start the local Remote Control process on the Target. The wtrace command output doesn’t show much information about this method in this type of architecture. However, it is important to know which method is used to start the session on the Target because, in some different situations, more information will be available for this method.

The return code of this method is 0; this means that the session starts without an error.

Example 1-4 The nd_start_target method from a single-TMR environment

loc-oc 700 23 Results: (encoded): "" 0

Example 1-4 detailed the nd_start_controller method. The odstat line is:

1562174364.17.517+#TMF_Endpoint::Endpoint# nd_start_controller

This method is used to start the local Remote Control process on the Controller. The wtrace process doesn’t show much information about this method in this type of architecture. However, it is important to know which method is used to start the session on the Controller because, in some different situations, more information will be available for this method.

The return code of this method is 0; this means that the session starts without error.

Example 1-5 The nd_start_controller method from a single-TMR environment

loc-oc 703 12 Results: (encoded): 0

20 IBM Tivoli Remote Control Across Firewalls

1.2.2 Session in a multi-TMR environment

In order to continue to master the Remote Control session processes, it is also important to know in detail the whole data flow between the different elements of IBM Tivoli Remote Control in a multi-TMR environment. In a HUB-Spoke architecture, all managed resources should be placed in the Spoke TMR, and all profiles dedicated for the management should be created in the HUB TMR. As RC Tools are managed resources, we assume that they are created in the Spoke TMR. We also assume that the Targets are all managed by the Spoke TMR.

However, in order to let the Tivoli Administrator manage the Spoke TMR’s resources from the HUB TMR, the Controller has to be declared in the HUB TMR. This is because the resources of one Spoke TMR should never be able to directly access resources of another Spoke TMR; only the HUB TMR resources could manage all others. Furthermore, some resources, such as Endpoints, Policy Region, and RemoteControl, need to be exchanged between the HUB and Spoke TMRs. For more information about resources exchange between TMRs, refer to the GC32-0803.

Data flow for a multi-TMR session

Figure 1-3 shows in detail how a Remote Control session is working in a HUB-Spoke TMR environment without firewall restrictions.

Tivoli Management Framework Planning for Deployment Guide

Chapter 1. Remote Control sessions overview 21

HUB TMR Server

HUB RCL

Collection

Endpoint GW

Spoke RC

Tool

HUB RC

Server

HUB Endpoint Mgr

Spoke TMR Server

Spoke

Spoke RC

Tool

Spoke RC

Server

Spoke Endpoint Mgr Spoke

Figure 1-3 RC session data flow in a multi-TMR environment

HUB

Controller

Target

Endpoint GW

Based on Figure 1-3, here we detail each step from the time when the Tivoli Administrator opens an RC Tool from a Collection located in the HUB TMR until the connection is established between the Controller and the Target.

The legend used in Figure 1-3 is explained as follows: A The Tivoli Administrator must first open an RC Tool to be able to

select a Target from a list. As the RC Tool is located in a Policy Region of the Spoke TMR, a Collection containing the Spoke RC Tool is available in the HUB TMR.

B As soon as the RC Tool on the Spoke is opened, the Spoke Remote

Control Server needs to validate the Controller by checking:

– If the Controller is an Endpoint.

22 IBM Tivoli Remote Control Across Firewalls

– If the label of the Endpoint is the same as of the hostname of the

Controller

– If the interpreter of the Controller is supported and able to start a

Remote Control session.

In order to get this information, the Spoke Remote Control Server needs to contact the Spoke Endpoint Manager.

C As the Controller is not an Endpoint of the Spoke TMR, thus not

known by the Spoke Endpoint Manager, the Spoke Endpoint Manager must get the Region ID from the Controller Object ID and must find a way to contact the Endpoint Manager of this other TMR known by the Region ID. As soon as the Spoke Endpoint Manager find the way to contact the HUB Endpoint Manager, it transfers the request it receives from the Spoke Remote Control Server and waits for the return.

D If the Controller, based on the information received from the HUB

Endpoint Manager, is authorized to be a Controller, the Spoke Remote Control server loads a subset of the Remote Control policies. For our examples, we will call these policies These policies are not loaded not from the Spoke RC Tool but from the Spoke Policy Region where the Tool is located. These policies are only accessed when the RC Tool is opened and no more loaded for the time the Tool is active.

basis policies.

basis

E At this point, the Tivoli Administrator could decide to start a session

by clicking the Run button of the Spoke Remote Control Tool after selecting a Target.

F The Spoke Remote Control Server needs to load the rest of the

Remote Control policies. These policies are more network related and, for example, specify if a Remote Control Proxy or a Remote Control Gateway should be used and which ports are defined to start the session. Unlike the basis policies, these Remote Control policies are loaded every time a new session is started from this Spoke RC Tool. Example 1-7 on page 25 shows which policies are read when the session starts and which are read when the RC Tool is opened.

G As soon as all Remote Control policies are loaded, the Spoke

Remote Control Server needs to obtain additional information for both the Controller and the Target, such as their IP addresses. In order to get this information, the Remote Control Server must contact the Spoke Endpoint Manager.

Chapter 1. Remote Control sessions overview 23

H The Spoke Endpoint Manager is able to provide information for the

Target machine as this Endpoint is part of the same TMR. However, for the Controller, once again, it could not find any information for it inside its Endpoint Database. The Spoke Endpoint Manager needs to extract the Region ID of the Controller Object ID and must find a way to contact the HUB Endpoint Manager. As soon the Spoke Endpoint Manager find the way to contact the HUB Endpoint Manager, it transfers the request it receives from the Spoke Remote Control Server and waits for the return.

I Before initiating the connection, the Spoke Remote Control Server

needs to know if the Target needs to be reached using an Endpoint Proxy/Gateway proxy infrastructure or not. If the Target is a proxied Endpoint, the Spoke Remote Control Server should send the request through an Endpoint Proxy instead of using the standard Tivoli Endpoint Gateway communication process.

J As soon as the Spoke Remote Control Server knows how to contact

the Target, it sends the nd_start_target method down to the Target and waits for the process to starts. The local process started on the machine is named EQNRCMAI.EXE.

K As soon as the Target is started, the Spoke Remote Control Server

sends an nd_start_controller method to the Controller, but as it knows that the Controller is not part of the Spoke TMR, it forwards the request to the HUB TMR. The HUB Remote Control Server is sending the nd_start_controller method to the Controller and waits for the process to start. The local process started on the machine is named EQNRSMAI.EXE.

L The Remote Control session is now established. Notice that once the

session established, the Controller talks directly with the Target; this is a peer-to-peer communication. The Target is listening on port 2501 (port 2502 for File Transfer and port 2503 for chat) by default. On the Controller side, by default, the port is assigned by the communication stack. However, these ports could be easily changed by configuring the rc_def_ports Remote Control Policy.

Tracing for a multi-TMR session

Example 1-6 and Example 1-7 show subsets of IBM Tivoli Management Framework odstat command output from the HUB TMR and the Spoke TMR respectively. They show each method used to start a Remote Control session in a multi-TMR environment described above. This trace was captured from the time the Tivoli Administrator opened an RC Tool until the session was established after the Administrator clicked the Run button of this RC Tool. This trace helps to fully depict the data flow that was shown in Figure 1-3 on page 22.

24 IBM Tivoli Remote Control Across Firewalls

From Example 1-7, we could analyze that all methods needed to get information from the HUB TMR are initiated on the Spoke TMR. Furthermore, all of these methods will be found again in the HUB TMR trace file. Even if these methods are initiated by the Spoke TMR, they are nevertheless managed by the HUB TMR. In the Spoke TMR trace file (Example 1-7), we could also see that all

basis

Remote Control policies are loaded when the Tivoli Administrator opens the RC Tool, and that all network related Remote Control policies are loaded each time a Target request is started from a Controller. In addition to that, we could also remark that the session is first started on the Target and then on the Controller before the peer-to-peer connection between them is established.

In order to understand the information shown in the trace files, the Region IDs of the HUB and Spoke TMRs in our environment are:

򐂰 HUB TMR:

1380596993

򐂰 Spoke TMR: 1519322503

Example 1-6 is the trace file from the HUB TMR Server.

Example 1-6 RC session trace from the HUB TMR in a multi-TMR environment

1380596993.1.536#TMF_LCF::EpMgr# get_endpoint_key_value

1380596993.1.179#TMF_Administrator::Configuration_GUI# _get_label

1380596993.1.631#TMF_UI::Extd_Desktop# connect

1380596993.7.522+#TMF_Endpoint::Endpoint# _get_label

1380596993.1.536#TMF_LCF::EpMgr# get_endpoint_key_value

1380596993.7.522+#TMF_Endpoint::Endpoint# nd_start_controller

1380596993.1.536#TMF_LCF::EpMgr# get_endpoint_key_value

Example 1-7 is the trace file from the Spoke TMR Server.

Example 1-7 RC session trace from the Spoke TMR in a multi-TMR environment

0.0.0 get_name_registry

1519322503.1.26 lookup

1519322503.1.4 lookup_id

1519322503.1.4##6@LCFData::ep_tnr_info_s describe

1519322503.1.26 lookup

1519322503.1.536#TMF_LCF::EpMgr# get_endpoint_key_value

Chapter 1. Remote Control sessions overview 25

1380596993.1.536#TMF_LCF::EpMgr# get_endpoint_key_value

1519322503.1.26 lookup

1519322503.1.536#TMF_LCF::EpMgr# get_endpoint_key_value

1380596993.1.536#TMF_LCF::EpMgr# get_endpoint_key_value

1519322503.1.707#PcRC::RemoteControl# get_policy_region

1519322503.1.707#PcRC::RemoteControl# get_policy_region_name

1519322503.1.707#PcRC::RemoteControl# _get_label

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_define

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_uncheckedlist

0.0.0 get_name_registry

1519322503.1.26 lookup

1519322503.1.14#TMF_SysAdmin::Library# lookup_object

1519322503.1.521#TMF_SysAdmin::InstanceManager# get_instances_interface

1519322503.1.14#TMF_SysAdmin::Library# select_instance_managers

1519322503.1.26 get_all

1519322503.1.26 lookup

1519322503.1.4 lookup_id

1519322503.1.4##6@LCFData::ep_tnr_info_s describe

1519322503.1.707#PcRC::RemoteControl# _get_pres_object

1519322503.1.679#TMF_UI::Presentation# _get_dialogs

1519322503.1.679#TMF_UI::Presentation# _get_bitmaps

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_command

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_gw

1380596993.1.179#TMF_Administrator::Configuration_GUI# _get_label

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_rcmode

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_ftmode

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_grace_time

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_timeout_op

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_optimize

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_initstate

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_alt_t

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_backgrnd

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_rate

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_color

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_inactivity

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_gw

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_comp

1380596993.1.631#TMF_UI::Extd_Desktop# connect

1519322503.1.26 lookup

26 IBM Tivoli Remote Control Across Firewalls

1519322503.1.707#PcRC::RemoteControl# remote_control

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_gw

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_ports

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_encryption

1519322503.1.705#TMF_PolicyRegion::GUI# rc_def_proxy

1519322503.1.26 lookup

1519322503.1.536#TMF_LCF::EpMgr# get_endpoint_key_value

1519322503.18.522+#TMF_Endpoint::Endpoint# _get_label

1380596993.7.522+#TMF_Endpoint::Endpoint# _get_label

1519322503.1.26 lookup

1519322503.1.536#TMF_LCF::EpMgr# get_endpoint_key_value

1519322503.18.522+#TMF_Endpoint::Endpoint# is_proxied_ep

1519322503.18.522+#TMF_Endpoint::Endpoint# nd_start_target

1519322503.1.26 lookup

1519322503.1.536#TMF_LCF::EpMgr# get_endpoint_key_value

1380596993.1.536#TMF_LCF::EpMgr# get_endpoint_key_value

1380596993.7.522+#TMF_Endpoint::Endpoint# nd_start_controller

1519322503.1.26 lookup

1519322503.1.536#TMF_LCF::EpMgr# get_endpoint_key_value

1380596993.1.536#TMF_LCF::EpMgr# get_endpoint_key_value

1519322503.1.26 lookup

1519322503.1.88#TMF_SysAdmin::InstanceManager# connect

In order to explain how the Spoke Remote Control Server knows which Controller the session is initiated from and which Target the session should be started to, we need to analyze the output of the wtrace command from the Spoke TMR Server. This trace was captured at the same time as the odstat command trace.

The following examples will show the detailed information from the wtrace command output about the most important lines of the IBM Tivoli Management Framework odstat trace file shown in Example 1-6 on page 25 and in Example 1-7 on page 25.

As a reference, the following information is important to understand the content of the examples:

򐂰 The Object ID of the Target is

1519322503.18.522+#TMF_Endpoint::Endpoint#

򐂰 The Object ID of the Controller is

1380596993.7.522+#TMF_Endpoint::Endpoint#

򐂰 The Object ID of the RC Tool is 1519322503.1.707#PcRC::RemoteControl# 򐂰 The Tivoli Administrator who initiates the section is

root@lpar07.itsc.austin.ibm.com

Chapter 1. Remote Control sessions overview 27

Example 1-8 details the remote_control method started from the Spoke TMR Server which could also be named the Target request. It refers to the following line in Example 1-7 on page 25:

1519322503.1.707#PcRC::RemoteControl# remote_control

Example 1-8 The remote_control method from a Spoke TMR

loc-ic 4778 M-hdoq 1-4728 782 Time run: [Tue 28-Jan 17:47:15]

Object ID: 1519322503.1.707#PcRC::RemoteControl# Method: remote_control Principal: root@lpar07.itsc.austin.ibm.com (-2/-2) Path: /aix4-r1/TME/PCREMOTE/pcremote Trans Id: { 1519322503:1,1519322503:1,7:1207 } #4 Input Data: (encoded):

{ 14 [ "WD_DIALOG_OWNER=1519322503.1.707#PcRC::RemoteControl#" "WD_GADGET_PATH=" "WD_SOURCE_PATH=btn_run" "WD_DIALOG_NAME =pcremote" "WD_DIALOG_INSTANCE=30278:0" "WD_DESKTOP_OID=138

0596993.1.631#TMF_UI::Extd_Desktop#" "WD_DESKTOP_PID=1360" "WD_DESKTOP_HOST=TIC01008" "WD_DESKTOP_FQ_HOST=TIC01008" "WD_DISPLAY=TIC01008:0" "WD_OCO_OID=1380596993.1.179#TMF_A dministrator::Configuration_GUI#" "WD_VERSION=1" "WD_TYPE=Wi ndows" "LANG=en" ]

} "1519322503.18.522+#TMF_Endpoint::Endpoint#" "1380596993.7.522+ #TMF_Endpoint::Endpoint#" 65540 "controla" " /R50 /B /C8" ""

"Root_tic01010-region(root@lpar07.itsc.austin.ibm.com)"

Example 1-9 details the is_proxied_ep method started from the Spoke TMR Server. It refers to the following line in Example 1-7 on page 25:

1519322503.18.522+#TMF_Endpoint::Endpoint# is_proxied_ep

This method checks if the Target is behind an Endpoint Proxy/Gateway Proxy architecture. If the result is true, Remote Control knows that an Endpoint Proxy must be used to contact the Target. We see that the result of this method is false; this means that the Target is not an Endpoint connected to a Gateway Proxy.

28 IBM Tivoli Remote Control Across Firewalls

Example 1-9 The is_proxied_ep method from a Spoke TMR

loc-oc 4695 9 Results: (encoded): false

Example 1-10 details the nd_start_target method started from the Spoke TMR Server. It refers to the following line in Example 1-7 on page 25:

1519322503.18.522+#TMF_Endpoint::Endpoint# nd_start_target

This method is used to start the local Remote Control process on the Target. The return code of this method is 0; this means that the session starts without error.

Example 1-10 The nd_start_target method from a Spoke TMR

loc-oc 4791 23 Results: (encoded): "" 0

Example 1-11 details the nd_start_controller method started from the Spoke TMR Server. It refers to the following line in Example 1-7 on page 25:

1380596993.7.522+#TMF_Endpoint::Endpoint# nd_start_controller

This method is used to start the local Remote Control process on the Controller. However, this method is first started from the Spoke TMR, and as the Endpoint Manager of this TMR doesn’t know the Controller Endpoint, the method must be transferred to the HUB TMR with all needed information.

As a reference, the Target IP address is 9.3.4.247 and the Controller IP address is 9.3.4.244.

The return code of this method is 0; this means that the session starts without error.

Example 1-11 The nd_start_controller method from a Spoke TMR

rem-ic 4795 M-H 1-4778 236 Time run: [Tue 28-Jan 17:47:22]

Object ID: 1380596993.7.522+#TMF_Endpoint::Endpoint# Method: nd_start_controller Principal: root@lpar07.itsc.austin.ibm.com (0/0) Path: Input Data: (encoded): "\tivoli\pcremote\eqnrsmai.exe" { 1

Chapter 1. Remote Control sessions overview 29

[ "/I9.3.4.247 / ], ,((!?+; ] /Ntic01006 / ], ,((!?+; ] /B18 /A /T / ] ;+?!((,, ] /HRoot_tic01010-region(root@lpar07.itsc.austin.ibm.com) / ] ;+?!((,, ] " ]

} 65540 "9.3.4.244"

rem-oc 4795 12 Results: (encoded): 0

Example 1-12 details the nd_start_controller method started from the HUB TMR Server. It refers to the following line in Example 1-6 on page 25:

1380596993.7.522+#TMF_Endpoint::Endpoint# nd_start_controller

As soon as the Spoke TMR asked the HUB TMR Server to start the Controller, the same nd_start_controller method is started on the HUB TMR Server. The return code of this method is 0; this means that the session starts without error.

Example 1-12 The nd_start_controller method from a HUB TMR

loc-oc 6483 12 Results: (encoded): 0

30 IBM Tivoli Remote Control Across Firewalls

1.2.3 Session using a Remote Control Gateway

In the following sections we describe how Remote Control sessions are established in a firewall environment using the Remote Control Gateway component for both single-TMR and multi-TMR environments. As this technology had been previously developed to allow Remote Control sessions in a firewall environment before the Remote Control Proxy technology was announced, we won’t go into details on this process, and no trace will be discussed. Nevertheless, it could be interesting to have an idea of how it works to compare and understand the two different technologies.

The Remote Control Gateway must be installed on top of a Tivoli Endpoint Gateway. If you match the Remote Control Gateway port to your firewall configurations, you enable all Controllers to access all the Targets that reside on the other side of the firewall, through the same Remote Control Gateway. Furthermore, the Remote Control Gateway can’t be used to bridge two different LAN.

Data flow for RC Gateway/single-TMR session

Figure 1-4 shows in detail how a Remote Control session works using a Remote Control Gateway in a single-TMR environment with firewall restrictions.

Chapter 1. Remote Control sessions overview 31

TMR Server

Endpoint Mgr

RC Tool

RC Server

Firewall

Endpoint GW

RC Gateway

Figure 1-4 RC session data flow in an RC Gateway/single-TMR environment

Based on Figure 1-4, here we detail each step from the time the Tivoli Administrator opens a Remote Control Tool until the connection is established between the Controller and the Target.

Controller

Target

DMZ

The legend used in Figure 1-4 is explained as follows:

Steps A, B,C, D, E, F, G, H and I remain the same as for a Remote Control session in single-TMR environment without firewall restriction. Refer to “Data flow for single-TMR session” on page 14 for detailed information about these steps.

The remaining step is different and is defined as follows: J The rc_def_gw policy has been configured to force the usage of the

Remote Control Gateway, and the Remote Control Server has been informed of that on step E. The Remote Control server then has

32 IBM Tivoli Remote Control Across Firewalls

informed the Controller (step I) to use the Remote Control Gateway in order to contact the Target. As the Controller knows on which Managed Node the Remote Control Gateway is installed and which port has to be used, it starts to communicate with the Target using this specific network path. The Remote Control session is now established. It is important to notice that once the session established, the Controller talks directly with the Target, but it’s

not a

peer-to-peer communication (Controller-Target) anymore, as the communication flow must always go through the Remote Control Gateway. The Target is listening on the port defined in the rc_def_gw policy. If 0 is specified as the parameter, the port is assigned by the communication stack. On the Controller side, by default, the port is assigned by the communication stack. However, this port could be easily fixed by configuring the rc_def_ports Remote Control Policy.

In order to force the Remote Control session to use a Remote Control Gateway, the rc_def_gw default policy method needs to be configured as shown in Example 1-13.

Example 1-13 The rc_def_gw default policy method for Remote Control

#!/bin/sh # # Default policy method for Remote Control gateway # # This policy method determines whether or not to # use the Remote Control gateway. # # Possible values: # NO Do not use the Remote Control gateway. # YES <ManagedNode-label> <GatewayPort> <MaxSessions> IP:<IP-Port> # Use the specified Remote Control gateway, # where: # <ManagedNode-label> is the name of the managed node # to be used as Remote Control gateway. # <GatewayPort> is the TCP/IP port used by the Remote # Control gateway to listen for connection request from # controllers. # <MaxSessions> is the number of Tivoli Remote Control # sessions between a controller and target that the Remote # Control gateway can handle on the same incoming port. # The maximum value is 64. # <IP-Port> is the local TCP/IP port used by the Remote # Control gateway to communicate with TCP/IP targets. # If it has the value 0, the Remote Control gateway uses # a port generated by the communication stack. # # Default value: NO

Chapter 1. Remote Control sessions overview 33

HUB TMR Server

echo "YES tic01002 8877 64 IP:0"

exit 0

Data flow for an RC Gateway/multi-TMR session

Figure 1-5 shows in detail how a Remote Control session works using a Remote Control Gateway in a multi-TMR environment with firewall restrictions.

HUB RCL

Collection

Spoke RC

HUB RC

Server

HUB Endpoint Mgr

Tool

HUB

Endpoint GW

Spoke TMR Server

Spoke

Spoke RC

Tool

Spoke RC

Server

Spoke Endpoint Mgr

Firewall

Figure 1-5 RC session data flow in an RC Gateway/multi-TMR environment

Controller

L L

J J

Endpoint GW

RC Gateway

Target

DMZ

Based on Figure 1-5, here we detail each step from the time when the Tivoli Administrator opens a Remote Control Tool until the connection is established between the Controller and the Target.

34 IBM Tivoli Remote Control Across Firewalls

The legend used in Figure 1-5 is explained as follows:

Steps A, B,C, D, E, F, G, H, I, J, and K remain the same as for a Remote Control session in a multi-TMR environment without the firewall restriction. Refer to “Data flow for a multi-TMR session” on page 21 for detailed information about these steps.

The remaining step is different and is defined as follows: L The rc_def_gw policy has been configured to force the usage of the

Remote Control Gateway and the Remote Control Server has been informed of that on step F. The Remote Control server then has informed the Controller (step K) to use the Remote Control Gateway in order to contact the Target. As the Controller knows on which Managed Node the Remote Control Gateway is installed and which port has to be used, it could start to communicate with the Target using this specific network path. The Remote Control session is now established. It is important to notice that once the session established, the Controller talks directly with the Target, but it’s peer-to-peer communication (Controller-Target) anymore, as the communication flow must always go through the Remote Control Gateway. The Target is listening on port defined in the rc_def_gw policy. If 0 is specified as parameter, the port is assigned by the communication stack. On the Controller side, by default, the port is assigned by the communication stack. However, this port could be easily fixed by configuring the rc_def_ports Remote Control Policy.

not a

In order to force the Remote Control session to use a Remote Control Gateway, the rc_def_gw default policy method needs to be configured as shown in Example 1-13 on page 33. This has to be done in the Spoke TMR where the Remote Control Object is located.

1.2.4 Session using Remote Control Proxies Standalone

In the following sections we describe the Remote Control Proxy Standalone architecture for both single-TMR and multi-TMR environments.

The Remote Control Proxy components enable machines on a side of a firewall to communicate, through a common definable port, to machines on the other side of the firewall. Thus, the Controller is able to start a session with a Target by minimizing the impact on the security infrastructure.

However, the Remote Control Proxy Standalone solution could only be used if a standard Tivoli Endpoint Gateway is installed in the same network zone as the Targets. Otherwise, the Remote Control Proxy on top of the Tivoli Firewall Security Toolbox solution needs to be deployed.

Chapter 1. Remote Control sessions overview 35

The RC Target Proxy emulates the Target located in another network zone to the Controller. The Target Proxy must be able to communicate with the Controller without any firewall constraints, and thus must be located in the same network zone as the Controller.

On the other side, the RC Controller Proxy emulates the Controller located in another zone to the Target. The Controller Proxy must be able to communicate with the Target without any firewall constraints, and thus must be located in the same network zone as the Target.

Data flow for RC Proxy Standalone/single-TMR session

Figure 1-6 shows in detail how a Remote Control session works using a Remote Control Proxy Standalone architecture in a single-TMR environment with firewall restrictions.

TMR Server

Endpoint Mgr

RC Tool

RC Server

Endpoint GW

RC Target Proxy

Controller

Firewall

Figure 1-6 RC session data flow in an RC Proxy Standalone/single-TMR

RC Controller Proxy

Endpoint GW

Target

DMZ

36 IBM Tivoli Remote Control Across Firewalls

Based on Figure 1-6, here we detail each step from the time the Tivoli Administrator opens a Remote Control Tool until the connection is established between the Controller and the Target using the Remote Control Proxies.

The legend used in Figure 1-6 is explained as follows:

Steps A, B,C, D, E, F, G, H and I are similar to a Remote Control session in single-TMR environment without firewall restriction. Refer to “Data flow for single-TMR session” on page 14 for detailed information about these steps.

The remaining step is different and defined as follows: J Both sessions on the Target and on the Controller are now started.

At this step, the Controller needs to establish the link to control the Target. The rc_def_proxy policy has been configured to force the usage of the Remote Control Proxies and the Remote Control Server has been informed of that on step E. The Remote Control server then has informed the Controller (step I) to use the RC Target Proxy in order to contact the Target. The Controller is able now to transfer the connection request to the RC Target Proxy as it got its IP address.

When the RC Target Proxy receives the request containing the IP address of the requested Target, it can start searching in the rcproxy.route file for the RC Controller Proxy the Target is connected to. In fact, this file contains a list of all distant Endpoints and their assigned RC Controller Proxy and needs to be manually customized. For more information about how to configure this file, refer to 3.3.2, “Remote Control Proxy configuration” on page 104. The RC Target Proxy then contacts the correspondent RC Controller Proxy to forward the Target connection request. The RC Controller Proxy uses the Target information stored in the first request to start a session with the Target.

The Remote Control session is now established. It is important to notice that once the session established, the Controller talks directly with the Target, but it’s

not a peer-to-peer communication

(Controller-Target) anymore, as the communication flow must always go through the Remote Control Proxies.

The Target is listening on port defined in the rc_def_ports policy. On the Controller side, by default, the port is assigned by the communication stack. However, these ports could be easily changed by configuring the rc_def_ports Remote Control Policies. The RC Target Proxy and the RC Controller Proxy are listening on the port defined during the installation process. The port specified in the rc_def_proxy policy must be the same as defined during the installation process of the RC Target Proxy. The configuration of these RC Proxies ports could be reviewed by editing the rcproxy.cfg

Chapter 1. Remote Control sessions overview 37

configuration file. However, if you decided to change this port, you need to also review the rc_def_proxy policy. For more information about the RC Proxies configuration files, refer to

Control User’s Guide

, SC23-4842.

IBM Tivoli Remote

Sometimes, the Controller could be in a secure zone and managed by a local Tivoli Endpoint Gateway and the Target could be in another secure zone and also be managed by a local Tivoli Endpoint Gateway. In this case, two firewalls separate the Controller and its RC Target Proxy from the Target and its RC Controller Proxy. The TFST Relay could be installed in the zone between the two secure zones and used to pass the information between the RC Target Proxy and the RC Controller Proxy.

In order to implement the Remote Control session to use Remote Control Proxies, the rc_def_proxy default policy method needs to be configured as shown in Example 1-14.

Example 1-14 The rc_def_proxy default policy method for Remote Control

38 IBM Tivoli Remote Control Across Firewalls

# the machine where the target # proxy runs. # # <rc proxy ip address> # Identifies the machine where the target proxy # runs. You must use this parameter only with # the manual configuration type. # # <rc proxy port> # Identifies the port that the target proxy uses to # communicate with the controller or the controller # proxy. # # Default value: NO # # # Examples follow. # # First example: # YES manual 192.168.100.50 3501 # # Second example: # YES auto 3501 # # Third example: # NO #

echo "YES manual 9.3.4.169 8888"

exit 0

Data flow for an RC Proxy Standalone/multi-TMR session

Figure 1-7 shows in detail how a Remote Control session works using a Remote Control Proxy Standalone architecture in a multi-TMR environment with firewall restrictions.

Chapter 1. Remote Control sessions overview 39

HUB TMR Server

HUB RCL

Collection

Spoke RC

HUB RC

Server

HUB Endpoint Mgr

Tool

HUB

Endpoint GW

Spoke TMR Server

Spoke

Spoke RC

Tool

Spoke RC

Server

Spoke Endpoint Mgr

Firewal l

Figure 1-7 RC session data flow in an RC Proxy Standalone/multi-TMR

Controller

RC Target Proxy

RC Controller Proxy

Endpoint GW

Target

DMZ

Based on Figure 1-7, here we detail each step from the time the Tivoli Administrator opens a Remote Control Tool until the connection is established between the Controller and the Target using the Remote Control Proxies.

The legend used in Figure 1-7 is explained as follows:

Steps A, B,C, D, E, F, G, H, I, J and K are similar to a Remote Control session in multi-TMR environment without firewall restriction. Refer to “Data flow for a multi-TMR session” on page 21 for detailed information about these steps.

The remaining step is different and defined as follows: L Both sessions on the Target and on the Controller are now started.

40 IBM Tivoli Remote Control Across Firewalls

has been informed of that on step F. The Remote Control server then has informed the Controller (step K) to use the RC Target Proxy in order to contact the Target. The Controller is able now to transfer the connection request to the RC Target Proxy as it got its IP address.

The Remote Control session is now established. It is important to notice that once the session established, the Controller talks directly with the Target, but it’s (Controller-Target) anymore, as the communication flow must always go through the Remote Control Proxies.

Control User’s Guide

not a peer-to-peer communication

IBM Tivoli Remote

, SC23-4842

Sometimes, the Controller could be in a secure zone and managed by a local Tivoli Endpoint Gateway and the Target could be in another secure zone and also managed by a local Tivoli Endpoint Gateway. In this case, two firewalls separate the Controller and RC Target Proxy from the Target and RC Controller Proxy. The TFST Relay could be installed in the zone between the two secure zones and used to pass the information from the RC Target Proxy to the RC Controller Proxy

Chapter 1. Remote Control sessions overview 41

In order to implement the Remote Control session to use Remote Control Proxies, the rc_def_proxy default policy method needs to be configured as shown in Example 1-14 on page 38. This has to be done in the Spoke TMR where the Remote Control Object is located.

Tracing for RC Proxy Standalone

The Tivoli methods used to start a session in a Remote Control Proxy Standalone architecture are the same used to start a session in a non-secure environment. Refer to Example 1-1 on page 16 for a subset of an IBM Tivoli Management Framework odstat output trace file for a single-TMR architecture and to the Example 1-6 on page 25 and Example 1-7 on page 25 for multi-TMR architecture.

Sections “Tracing for single-TMR session” on page 16 and “Tracing for a multi-TMR session” on page 24 provided the details of the most important methods used to start a Remote Control session both in a single-TMR and multi-TMR architecture. As mentioned, the methods are almost the same to start a Remote Control session in a secure environment. Thus, we only provide in this section the main differences for the most important methods.

The Target request, managed by the remote_control method, remains the same in a secure environment. For more information about this method, refer to Example 1-2 on page 19 for a single-TMR architecture and to Example 1-8 on page 28 for a multi-TMR architecture.

Example 1-15 details the is_proxied_ep method started from either the TMR Server in a single-TMR architecture or from the Spoke TMR Server in a multi-TMR architecture. It refers to the following line in Example 1-7 on page 25:

1519322503.29.522+#TMF_Endpoint::Endpoint# is_proxied_ep

This method checks if the Target is behind an Endpoint Proxy/Gateway Proxy architecture. If the result is true, Remote Control knows that an Endpoint Proxy must be used to contact the Target. We see that the result of this method is false; this means that the Target is not an Endpoint connected to a Gateway Proxy.

As a reference, the following information is important to understand the content of the examples:

򐂰 The Target IP address is 10.10.10.7 򐂰 The RC Target Proxy IP address is 9.3.4.169 and it is defined in the

rc_def_proxy policy file 򐂰 The Controller IP address is 9.3.4.244

42 IBM Tivoli Remote Control Across Firewalls

Example 1-15 The is_proxied_ep method for an RC Proxy Standalone architecture

rem-ic 695 M-H 1-683 21 Time run: [Thu 30-Jan 11:42:46]

Object ID: 1519322503.29.522+#TMF_Endpoint::Endpoint# Method: is_proxied_ep Principal: root@tic01002 (0/0) Path: Input Data: (encoded): "10.10.10.7"

rem-oc 695 9 Results: (encoded): false

Example 1-16 details the nd_start_target method started from either the TMR Server in a single-TMR architecture or from the Spoke TMR Server in a multi-TMR architecture. It refers to the following line in Example 1-7 on page 25:

1519322503.18.522+#TMF_Endpoint::Endpoint# nd_start_target

This method is used to start the local Remote Control process on the Target. The return code of this method is 0; this means that the session starts without error.

Example 1-16 The nd_start_target method for an RC Proxy Standalone architecture

rem-ic 1517 M-H 1-1504 199 Time run: [Thu 30-Jan 13:10:39]

Object ID: 1519322503.29.522+#TMF_Endpoint::Endpoint# Method: nd_start_target Principal: root@tic01002 (0/0) Path: Input Data: (encoded): "\tivoli\pcremote\eqnrcmai.exe" { 3 [ "10.10.10.7" "/HRoot_tic01002-region(root@tic01002)" " /R50 /B /C8 /V1519322503.1.702#PcRC::RemoteControl# /I"

]

} 65540

rem-oc 1517 23 Results: (encoded):

Chapter 1. Remote Control sessions overview 43

"" 0

Example 1-17 details the nd_start_controller method started from the Spoke TMR Server in a multi-TMR architecture because it shows more useful information to understand how the information about the Target Proxy is passed to the Controller. It refers to the following line in Example 1-7 on page 25:

1380596993.7.522+#TMF_Endpoint::Endpoint# nd_start_controller

This method is used to start the local Remote Control process on the Controller. The 8888 number, in fact, is the port number on which the Target Proxy is listening. This port is configurable and defined in the rc_def_proxy Policy. The return code of this method is 0; this means that the session starts without error.

Example 1-17 The nd_start_controller method for RC Proxy Standalone architecture

rem-ic 972 M-H 1-955 256 Time run: [Thu 30-Jan 11:49:00]

Object ID: 1380596993.7.522+#TMF_Endpoint::Endpoint# Method: nd_start_controller Principal: root@lpar07.itsc.austin.ibm.com (0/0) Path: Input Data: (encoded): "\tivoli\pcremote\eqnrsmai.exe" { 1 [ "/I10.10.10.7 / ], ,((!?+; ] /Ntic01007 / ], ,((!?+; ] /C8888 /F9.3.4.169 /B29 /A /T / ] ;+?!((,, ] /HRoot_tic01010-region(root@lpar07.itsc.austin.ibm.com) / ] ;+?!((,, ] " ]

} 65540 "9.3.4.244"

44 IBM Tivoli Remote Control Across Firewalls

rem-oc 972 12 Results: (encoded): 0

1.2.5 Session using Remote Control Proxies in a TFST environment

In the following sections we describe the Remote Control Proxy architecture running on top of Tivoli Firewall Security Toolbox for both single-TMR and multi-TMR environments.

The Remote Control Proxy components enable machines on one side of a firewall to communicate, through a common definable port, with machines on the other side of the firewall. The Controller is able to start a Target session by minimizing the impact on the security infrastructure.

The Remote Control Proxy-TFST solution can only be used if a Tivoli Firewall Security Toolbox environment is already deployed.

The Endpoint Proxy emulates the Endpoints located in another network zone to the standard Tivoli Gateway located in the same network zone as the TMR Server. Thus, the Endpoint Proxy is able to find the path to contact all distant Endpoints. In this context, the RC Target Proxy, which emulates the Target located in another network zone, could take the advantage of the Endpoint Proxy to find the way to contact the Targets. However, the Target Proxy must be able to communicate with the Controller without any firewall constraints, and thus must be located in the same network zone as the Controller.

On the other side, the RC Controller Proxy emulates the Controller located in another zone to the Target. The RC Controller Proxy must be able to communicate with the Target without any firewall constraints, and thus must be located in the same network zone as the Target. Furthermore, as the RC Target Proxy is installed on top of the Endpoint Proxy, the RC Controller Proxy must be installed on the top of the Gateway Proxy, which emulates a standard Tivoli Gateway to the distant Endpoints.

Data flow for RC Proxy-TFST/single-TMR session

Figure 1-8 shows in detail how a Remote Control session works using a Remote Control Proxy - TFST architecture in a single-TMR environment with firewall restrictions:

Chapter 1. Remote Control sessions overview 45

TMR Server

Endpoint Mgr

RC Tool

RC Server

Endpoint GW

Firewall

DMZ

Controller

RC Target Proxy

Endpoint Proxy

RC Contr. Proxy

Firewall

Gateway Proxy

Target

External

Relay 2 TFST

Relay 1 TFST

Figure 1-8 RC session data flow in an RC Proxy-TFST/single-TMR environment

Based on Figure 1-8, here we detail each step from the time the Tivoli Administrator opens a Remote Control Tool until the connection is established between the Controller and the Target through the Remote Control Proxies.

The legend used in Figure 1-8 is explained as follows:

Steps A, B,C, D, E, F, G and I remain the same as for a Remote Control session in single-TMR environment without firewall restriction. Refer to “Data flow for single-TMR session” on page 14 for detailed information about these steps.

The remaining steps are different and are defined as follows: H This step remains almost the same as for a standard session in a

non-secure environment. However, in a standard process the nd_start_target method is sent to the Target using the standard

46 IBM Tivoli Remote Control Across Firewalls

Endpoint Communication Protocol packets. In a TFST environment, these packets are encapsulated by the Endpoint Proxy inside common HTTP packets. HTTP protocol has been chosen, as it is “firewall friendly” protocol. The packets are then rebuilt into Tivoli proprietary communication protocol by the Gateway proxy to let the distant Targets understand the order to start an RC session.

When the request arrives from the standard Tivoli environment, it contains the label of the distant Endpoint, which is the Target in this case. The Endpoint Proxy owns its proper Endpoint Database where key information about each distant Endpoint is stored and notably its Gateway Proxy. Using this information, the Endpoint Proxy is able to forward the request to the correct Gateway Proxy, which will forward it at the end to the Endpoint.

In the situation depicted in Figure 1-8 on page 46, there are two firewalls separating the standard Tivoli environment from the distant Endpoints. To let the Endpoint Proxy, which needs to be on the same network zone that the Tivoli Endpoint Gateway, communicate with the Gateway Proxy, which needs to be close to the distant Endpoints, a second instance of the Relay is needed in the zone between the firewalls. Its role it just to forward the packets to the final destination between the different network zones. Multiple Relays could be chained to cross multiple secure zones.

J Both sessions on the Target and on the Controller are now started.

At this step, the Controller need to establish the link to control the Target. The rc_def_proxy policy has been configured to force the usage of the Remote Control Proxies and the Remote Control Server has been informed of that on step E. The Remote Control server then has informed the Controller (step I) to use the RC Target Proxy in order to contact the Target. The Controller is able now to transfer the connection request to the RC Target Proxy.

As only the RC Target Proxy port is defined in the rc_def_proxy policy in an auto mode, the Controller only receives the address of the Endpoint Proxy. As the RC Target Proxy must be installed on the same machine as the Endpoint Proxy, the Controller can forward the Target request to the RC Target Proxy using the address of the Endpoint Proxy.

When the Target Proxy receives the request, it needs to find which RC Controller Proxy the Endpoint is attached to. In a Tivoli Firewall Security Toolbox environment, the Endpoint Proxy is in charge to manage the key information of the Endpoint. To know the right path to contact the Target, the RC Target Proxy needs to ask the Endpoint Proxy for this information. The Endpoint Proxy provides the host

Chapter 1. Remote Control sessions overview 47

name of the Gateway Proxy which the Target is connected to. As the RC Controller Proxy must be installed on the same machine as the Gateway Proxy, the RC Target proxy is able to connect to this RC Controller Proxy and forward the Target request using the Gateway Proxy IP Address provided by the Endpoint Proxy. The RC Controller Proxy then uses the Target information stored in the first request to start a session with the Target.

Control User’s Guide

not a peer-to-peer communication

IBM Tivoli Remote

, SC23-4842.

In the scenario depicted in Figure 1-8 on page 46, there are two firewalls separating the standard Tivoli environment from the distant Endpoints. To let the RC Target Proxy, which needs to be on the same network zone that the Controller, communicate with the RC Controller Proxy, which needs to be close to the Target, a second instance of a Relay is needed. Its role it just to forward the packet to the final destination between the different network zones. Multiple Relays could be chained to cross all multiple secure zones. The Relay is not a Remote Control Component, it is a Tivoli Firewall Security Toolbox one. In fact, one instance of the Relay is needed to manage network flow between the Endpoint Proxy and Gateway Proxy and another instance of the same Relay need to be installed on the same machine as the first Relay instance to manage the network flow between the Remote Control Proxies.

In order to implement the Remote Control session to use Remote Control Proxies, the rc_def_proxy default policy method needs to be configured, for instance, as shown in Example 1-18.

48 IBM Tivoli Remote Control Across Firewalls

Example 1-18 The rc_def_proxy default policy method for Remote Control

#!/bin/sh # # Default policy method for Remote Control Proxy # # This policy method determines whether to use Remote Control Proxies. # If you use Remote Control Proxies, rc_def_proxy defines how the controller # uses the Remote Control Proxies to start a session with a target across a # firewall. # # Possible values: # # NO Do not use the Remote Control Proxies. # # YES <configuration type> <rc proxy ip address> <rc proxy port> # Use the Remote Control Proxies, where: # # <configuration type> # Identifies the following scenarios: # # auto # The controller and Remote Control Proxies # search the route to the target using the # information stored by # Tivoli Firewall Security Toolbox. # # manual # The Remote Control Proxies run as standalone. # The controller uses the network address that # you specify in this method to reach # the machine where the target # proxy runs. # # <rc proxy ip address> # Identifies the machine where the target proxy # runs. You must use this parameter only with # the manual configuration type. # # <rc proxy port> # Identifies the port that the target proxy uses to # communicate with the controller or the controller # proxy. # # Default value: NO # # # Examples follow. #

Chapter 1. Remote Control sessions overview 49

# First example: # YES manual 192.168.100.50 3501 # # Second example: # YES auto 3501 # # Third example: # NO #

echo "YES auto 5020"

exit 0

Data flow for RC Proxy-TFST/multi-TMR session

Figure 1-9 shows in detail how a Remote Control session works using a Remote Control Proxy - TFST architecture in a multi-TMR environment with firewall restrictions:

50 IBM Tivoli Remote Control Across Firewalls

HUB TMR Server

HUB RCL

Collection

HUB RC

Server

HUB Endpoint Mgr

Spoke RC

Tool

Endpoint GW

Spoke TMR Server

Spoke

Spoke RC

Server

Spoke Endpoint Mgr

HUB

Spoke RC

Tool

Controller

Spoke

Endpoint GW

Firewall

RC Target Proxy

Endpoint Proxy

DMZ

Gateway Proxy

Relay 2 TFST

Relay 1 TFST

Firewall

Target

External

RC Contr. Proxy

Figure 1-9 RC session data flow in an RC Proxy-TFST/multi-TMR environment

Based on Figure 1-9, here we detail each step from the time the Tivoli Administrator opens a Remote Control Tool until the connection is established between the Controller and the Target through the Remote Control Proxies.

The legend used in Figure 1-9 is explained as follows:

Steps A, B,C, D, E, F, G, H, I and K remain the same as for a Remote Control session in a multi-TMR environment without firewall restriction. Refer to “Data flow for a multi-TMR session” on page 21 for detailed information about these steps.

The remaining steps are different and are defined as follows: J This step remains almost the same as for a standard session in a

non-secure environment. However, in a standard process, the

Chapter 1. Remote Control sessions overview 51

nd_start_target method is sent to the Target using the standard Endpoint Communication Protocol packets. In a TFST environment, these packets are encapsulated by the Endpoint Proxy inside common HTTP packets. HTTP protocol has been chosen, as it is considered a “firewall friendly” protocol. The packets are then rebuilt into Tivoli proprietary protocol by the Gateway proxy to let the distant Targets understand the order to start an RC session.

When the request arrives from the standard Tivoli environment, it contains the label of the distant Endpoint, which is the Target in this case. The Endpoint Proxy owns its proper Endpoint Database where key information about each distant Endpoint is stored and notably its Gateway Proxy. Using this information, the Endpoint Proxy is able to forward the request to the right Gateway Proxy which will forward it at the end to the Endpoint.

In the situation depicted in Figure 1-9 on page 51, there are two firewalls separating the standard Tivoli environment from the distant Endpoints. To let the Endpoint Proxy (which needs to be on the same network zone as the Tivoli Endpoint Gateway) communicate with the Gateway Proxy (which needs to be close to the distant Endpoints), a second instance of the Relay is needed in the zone between the firewalls. Its role is just to forward the packets to the final destination between the different network zones. Multiple Relays could be chained to cross multiple secure zones.

L Both sessions on the Target and on the Controller are now started.

At this step, the Controller need to establish the link to control the Target. The rc_def_proxy policy has been configured to force the usage of the Remote Control Proxies and the Remote Control Server has been informed of that on step I. The Remote Control server then has informed the Controller (step K) to use the RC Target Proxy in order to contact the Target. The Controller is able now to transfer the connection request to the RC Target Proxy.

When the Target Proxy receives the request, it needs to find on which RC Controller Proxy the Endpoint is attached to. In a TFST environment, the Endpoint Proxy is in charge to manage the key information of the Endpoint. To know the right path to contact the Target, the RC Target Proxy needs to ask the Endpoint Proxy for this information. The Endpoint Proxy provides the host name of the

52 IBM Tivoli Remote Control Across Firewalls

Gateway Proxy on which the Target is connected to. As the RC Controller Proxy must be installed on the same machine as the Gateway Proxy, the RC Target proxy is able to connect to this RC Controller Proxy and forward the Target request using the Gateway Proxy Address provided by the Endpoint Proxy. The RC Controller Proxy uses the Target information stored in the first request to start a session with the Target.

The Remote Control session is now established. It is important to notice that once the session established, the Controller talks directly with the Target, but it’s NOT a peer-to-peer communication (Controller-Target) anymore, as the communication flow must always go through the Remote Control Proxies.

The Target is listening on port define in the rc_def_port policy. On the Controller side, by default, the port is assigned by the communication stack. However, these ports could be easily changed by configuring the rc_def_ports Remote Control Policies. The RC Target Proxy and the RC Controller proxy are listening on the port defined during the installation process. The port specified in the rc_def_proxy policy must be the same as defined during the installation process of the RC Target Proxy. The configuration of these RC Proxies port could be reviewed by editing the rcproxy.cfg configuration file. However, if you decided to change this port, you need to also review the rc_def_proxy policy. For more information about the RC Proxies configuration files, refer to

Control User’s Guide

, SC23-4842.

IBM Tivoli Remote

In the situation depicted in Figure 1-9 on page 51, there are two firewalls separating the standard Tivoli environment from the distant Endpoints. To let the RC Target Proxy (which needs to be on the same network zone as the Controller) communicate with the RC Controller Proxy (which needs to be close to the Target), a second instance of the Relay is needed. Its role is just to forward the packet to the final destination between the different network zones. Multiple Relays could be chained to cross all multiple secure zones. The Relay is not a Remote Control Component, it is a Tivoli Firewall Security Toolbox one. In fact, one instance of the Relay is needed to manage network flow between the Endpoint Proxy and Gateway Proxy and another instance of the same Relay need to be installed on the same machine as the first Relay instance to manage the network flow between the Remote Control Proxies.

In order to implement the Remote Control session to use Remote Control Proxies, the rc_def_proxy default policy method needs to be configured as shown in Example 1-18 on page 49. This has to be done in the Spoke TMR where the Remote Control Object is located.

Chapter 1. Remote Control sessions overview 53

Tracing for RC Proxy-TFST

The methods used to start a session in a Remote Control Proxy-TFST architecture are the same that are used to start a session in a non-secure environment. Refer to Example 1-1 on page 16 for a subset of an IBM Tivoli Management Framework odstat command output for a single-TMR architecture; and to Example 1-6 on page 25 and Example 1-7 on page 25 for multi-TMR architecture.

In “Tracing for single-TMR session” on page 16 and “Tracing for a multi-TMR session” on page 24, we provided the detail of the most important methods used to start a Remote Control session both in a single-TMR and multi-TMR architecture. As mentioned, the methods are almost the same to start a Remote Control session in a secure environment. Thus, we only provide in this section the main differences for the most important methods.

The Example 1-19 details the is_proxied_ep method started from either the TMR Server in a single-TMR architecture or from the Spoke TMR Server in a multi-TMR architecture. It refers to the following line in Example 1-7 on page 25:

1380596993.12.522+#TMF_Endpoint::Endpoint# is_proxied_ep

This method checks if the Target is behind an Endpoint Proxy/Gateway Proxy architecture. If the result is true, Remote Control knows that an Endpoint Proxy must be used to contact the Target. We see that the result of this method is true; this means that the Target is an Endpoint connected to a Gateway Proxy.

Example 1-19 The is_proxied_ep method for an RC Proxy-TFST architecture

loc-oc 11620 9 Results: (encoded): true

Example 1-20 details the nd_start_target method started from either the TMR Server in a single-TMR architecture or from the Spoke TMR Server in a multi-TMR architecture. It refers to the following line in Example 1-7 on page 25:

1380596993.12.522+#TMF_Endpoint::Endpoint# nd_start_target

This method is used to start the local Remote Control process on the Target. A return code of 0; this means that the session starts without error.

54 IBM Tivoli Remote Control Across Firewalls

Example 1-20 The nd_start_target method for an RC Proxy-TFST architecture

loc-oc 11621 23 Results: (encoded): "" 0

Example 1-21 details the nd_start_controller method started from the Spoke TMR Server in a multi-TMR architecture and it shows more useful information to understand how the information about the Target Proxy is passed to the Controller. It refers to the following line in Example 1-7 on page 25:

1380596993.7.522+#TMF_Endpoint::Endpoint# nd_start_controller

This method is used to start the local Remote Control process on the Controller.

As a reference, the following information is needed to interpret Example 1-21.

򐂰 The Target IP address is 9.3.5.29 򐂰 The Controller IP address is 9.3.4.244 򐂰 As the Target Proxy is installed on the same machine as the Endpoint Proxy,

the Controller doesn’t need this to know the Target Proxy IP address.

The 5020 number, in fact, is the port number on which the Target Proxy is listening. This port is defined in the rc_def_proxy Policy. The return code of this method is 0; this means that the session starts without error.

Example 1-21 The nd_start_controller method for an RC Proxy-TFST architecture

rem-ic 11625 M-H 1-11608 227 Time run: [Thu 30-Jan 18:34:04]

Object ID: 1519322503.35.522+#TMF_Endpoint::Endpoint# Method: nd_start_controller Principal: root@tic01002 (0/0) Path: Input Data: (encoded): "\tivoli\pcremote\eqnrsmai.exe" { 1 [ "/I9.3.5.29 / ], ,((!?+; ] /Ntic01007 / ], ,((!?+; ] /C5020 /E /B12 /M /T /

Chapter 1. Remote Control sessions overview 55

] ;+?!((,, ] /HRoot_tic01002-region(root@tic01002) / ] ;+?!((,, ] " ]

} 65540 "9.3.4.244"

rem-oc 11625 12 Results: (encoded): 0

56 IBM Tivoli Remote Control Across Firewalls

Chapter 2. Implementation planning

In this chapter we provide considerations to ensure an effective implementation of IBM Tivoli Remote Control (ITRC) within environments across an enterprise protected by firewalls.

IBM Tivoli Remote Control is dependent on a number of requirements and supporting applications as the network constraints, the enterprise IT security policies, the Tivoli Management Framework design and, in some situations, the Tivoli Firewall Security Toolbox configuration, which make planning an essential task in order to ensure a successful deployment.

Before implementing IBM Tivoli Remote Control in secured areas, you need to consider the design of your network topology and analyze all technical, network, and security requirements. This should include a Remote Control physical design in order to place all IBM Tivoli Remote Control components efficiently, and a Remote Control Logical design in order to configure all required Remote Control policies and roles. You should also consider the hardware and software requirements and their dependencies on the various functional pieces of the other applications that support the IBM Tivoli Remote Control solution.

The main topics concerning planning discussions in this chapter are:

򐂰 Considerations regarding the Remote Control design 򐂰 Planning for IBM Tivoli Remote Control 򐂰 Case study scenarios of IBM Tivoli Remote Control implementation planning

2.1 Design

In this section we address design considerations for the implementation of IBM Tivoli Remote Control in a secure environment. In fact, we assume that the Tivoli environment is already deployed within the enterprise. Thus, no information on planning for the IBM Tivoli Management Framework and the Tivoli Firewall Security Toolbox is provided in this section. For more information about the IBM Tivoli Management Framework architecture, refer to the

Framework Planning for Deployment Guide

information about the Tivoli Firewall Security Toolbox architecture, refer to the

Firewall Security Toolbox User ’s Guide

Furthermore, as the main topic of this book is to describe IBM Tivoli Remote Control in a firewall environment, this section focuses more on the IBM Tivoli Remote Control Proxy planning considerations than on the whole picture of IBM Tivoli Remote Control planning. You can get more information about architecture considerations and configuration for a standard IBM Tivoli Remote Control environment in the

We should also point out that we will not cover planning for the Remote Control component, as the Remote Control Proxies provide a better technology and are more flexible in responding to all security constraints an enterprise may have.

2.1.1 Logical design

Tivoli Management

, GC32-0803, and for more

, GC23-4826.

IBM Tivoli Remote Control User’s Guide

, SC23-4842.

In order to force the RC Controller to use an RC Target Proxy, some specific Remote Control policies need to be configured. This means that a new Logical structure must be defined for each secure environment served by a different RC Target-Controller Proxy architecture.

In order to satisfy this requirement, and because the Remote Control object is a Tivoli managed resource, a new Policy Region must be created to host the new Remote Control Tool (RC Tool) object. This RC Tool will manage the list of Targets for a specific secure zone served by the same RC Target Proxy. All RC Tools created in this Policy Region will respond to the same set of RC policies as they apply to a Policy Region and not to a specific RC Object. You should create as many Policy Regions as RC Target-Controller Proxy architectures you plan to have.

The main RC policies that need be reviewed for a secure environment are:

򐂰 rc_def_proxy: Defines whether to use Remote Control Proxies or not. 򐂰 rc_def_ports: Defines the ports to use for Controller-Target communications. 򐂰 rc_def_encryption: Defines data encryption using DES method.

58 IBM Tivoli Remote Control Across Firewalls

The remaining RC Policies should follow the same rules defined for all other RC Objects. They don’t have a direct impact on the way IBM Tivoli Remote Control works across firewalls. However, they could also be reviewed in order to fulfill some new requirements concerning the type of actions (for example, Remote Control, File Transfer, or Chat) that a Tivoli Administrator is able to use in a secure environment.

For more information about how to configure the Remote Control policies, refer to the

IBM Tivoli Remote Control User’s Guide

If you have defined the Administrator Roles at the Resource level rather than at the TMR level, you need to assign the Remote Control roles for the new Policy Regions hosting the new Remote Control Objects to the Administrator.

2.1.2 Physical design

This section addresses the Physical design for the implementation of IBM Tivoli Remote Control across firewalls. The Physical design develops the underlying physical infrastructure on which the solution will operate. Sufficient time needs to be allocated to ensure that the correct design has been developed because when deployed and operational, the Physical design may be difficult to change without a disruption of the IBM Tivoli Remote Control environment or, at worst, a disruption of the entire Tivoli infrastructure.

Before defining where the different components of the IBM Tivoli Remote Control Proxy — and, if necessary, the TFST components — should be installed, you first need to identify and determine the existing firewall environment as well as the architecture and all the restrictions that these firewalls impose on your IBM Tivoli Remote Control environment. In addition, the placement of all the other IBM Tivoli Remote Control components (such as RC Controllers and Targets) needs to be identified, especially which network zone they are located in.

, SC23-4842.

As explained in 1.2, “IBM Tivoli Remote Control sessions overview” on page 12, the scenarios supported by IBM Tivoli Remote Control can be divided into two categories corresponding to the firewall placement:

1. Scenarios where a Tivoli Endpoint Gateway is installed in the same secure

network zone as the Targets, and the Controllers are located in another

network zone managed by another Tivoli Endpoint Gateway. In this case, the

IBM Tivoli Remote Control Proxy could be installed as a Standalone solution,

as the Tivoli Firewall Security Toolbox does not need to be deployed.

However, this means that Targets and/or Controllers are separated from their

TMR Server by one firewall.

Chapter 2. Implementation planning 59

2. Scenarios where the Targets and/or Controllers are separated from their

standard Tivoli Endpoint Gateway by a firewall. In this case, a Tivoli Firewall

Security Toolbox is needed to manage these Endpoints. IBM Tivoli Remote

Control must be installed on top of the Tivoli Firewall Security Toolbox

architecture in order for it to be able to contact the Endpoint separated from

their TMR Server by, at least, one firewall or more. Such a solution is often

referred to as a Non-Standalone or RCProxy-TFST solution.

At this point, you should know if an IBM Tivoli Remote Control Proxy Standalone solution or a Non-Standalone solution has to be deployed.

In a case of a Non-Standalone solution, you need to identify the placement of both the Endpoint Proxy and Gateway Proxy. If the RC Controller is in the same network zone as the Endpoint Proxy, the RC Target Proxy must be installed on top of the Endpoint Proxy (same physical machine). Similarly, the RC Controller Proxy must be installed on top of the Gateway Proxy. Otherwise, if the RC Controller is in the same network zone as the Gateway Proxy, the RC Target Proxy must installed on top of the Gateway Proxy, and the RC Controller Proxy on top of the Endpoint Proxy.

However, if the intention is to have RC Controllers and RC Targets in both network zones (more secure and less secure), an RC Target Proxy and an RC Controller could be installed at the same time on top of the Endpoint Proxy and also on top of the Gateway Proxy. If one or many Relays are already installed to let the Endpoint Proxy communicate with the Gateway Proxy through more than one firewall, a new instance of the Relay needs to be installed on top of all Relays already installed (same physical machine) in order to permit the RC Proxies to communicate together through a dedicated channel.

In a case of a Standalone solution, if the RC Controller is in the same network zone as the TMR Server, the RC Target Proxy must be installed inside the more secure zone and the RC Controller Proxy in the less secure zone. Otherwise, if the RC Controller is in the less secure network zone, the RC Target Proxy must be installed in the less secure zone, and the RC Controller Proxy in the more secure zone. However, if you plan to have RC Controllers and RC Targets in both network zones (more secure and less secure), an RC Target Proxy and an RC Controller Proxy could be installed at the same time in the less secure and also in the more secure network zone.

In some situations, the RC Target Proxy needs to cross more than one firewall to contact the RC Controller Proxy. In this case, you must plan to use a Tivoli Firewall Security Toolbox Relay. This component is also able to transfer the RC Target Proxy information to the RC Controller Proxy information even in a Standalone solution.

60 IBM Tivoli Remote Control Across Firewalls

Having decided where to place the different components, you need now to decide on the Parent-Child relationship. In other words, to define which one of the RC Target Proxy or the RC Controller Proxy must be the Parent and which one must the Child. For more information about the Parent-Child concept, refer to the 1.1.4, “Parent-Child concept” on page 10.

Furthermore, in both Standalone and Non-Standalone solutions, you must get the security rules defined to manage these secure network zones from your enterprise Security Officer. These rules define which type of communication you will be able to use to cross the firewalls (bidirectional or unidirectional), and which network zone the communication could be initiated from. For more information about the different type of communication, refer to the 1.1.5, “Proxy connection types” on page 11.

As soon as you know which type of communication you are able to use, you need to define the Source and the Destination of the communication and, of course, the network ports that will be used to communicate. The following section provides a list of communication ports for either a bidirectional or unidirectional communications. This information should be discussed with the Security Officer and documented as new firewall policies within your enterprise standard Security documentation.

Note: The terms bidirectional and unidirectional communication can be misleading sometimes. In the context of this redbook, they refer to the communication initiation step. Unidirectional communication between two components means that the communication can only be initiated by one of the components. Bidirectional communication between two components means that the communication can be initiated by either one of the components.

2.1.3 Network considerations

IBM Tivoli Remote Control Proxies encapsulate the Tivoli proprietary protocol using the Hyper Text Transfer Protocol (HTTP) for communication.

When planning your IBM Tivoli Remote Control Proxy solution, you should take the following as considerations in order to improve RC Target Proxy and RC Controller Proxy networking performance:

򐂰 Introduce high-speed network adapters on all IBM Tivoli Remote Control

Proxies.

򐂰 Use local file system storage for binaries, libraries and data. 򐂰 Place the RC Target Proxy and RC Controller Proxy in a high-speed segment

so that it could faster serves the different requests.

Chapter 2. Implementation planning 61

Regarding the network communication for IBM Tivoli Remote Control, it is important to notice that the communication pipe between the RC Proxies is always opened and started as soon as the local RC Proxies services are started. If a Relay is part of the architecture, the communication pipes between the RC Proxies and the Relay are also always opened and started at the service startup time. The communication channels between the RC Controller and the RC Target Proxy and between the RC Target and the RC Controller Proxy are opened only when the remote session is started.

Note: The information provided in the following tables could be used to configure the filtering rules of the firewall.

Note: The following sections mainly provide information about the Remote Control Proxies network communication. These communications are the same even if the Remote Control Proxy is a Standalone or a Non-Standalone solution. However, the information provided could also help you to understand the network communication between an Endpoint Proxy and a Gateway Proxy, as the Proxy concept is almost the same for the both products. Furthermore, as the Proxy configuration files are the same, you could replace the RC Target Proxy by the Endpoint Proxy and the RC Controller Proxy by the Gateway Proxy in the sections below. However, you will find more information about the Endpoint Proxy/Gateway Proxy communication in the redbook,

Tivoli Enterprise Management Across Firewalls

, SG24-5510 .

Note: In order to better explain the different ports used by IBM Tivoli Remote Control, we assume that the RC Target Proxy is the Parent Proxy and that the RC Controller Proxy is the Child Proxy. However, the communications ports concept will work the same if the RC Target Proxy is installed on the Child Proxy and the RC Controller Proxy on the Parent Proxy.

Unidirectional communication without Relay

Table 2-1 provides an exhaustive list of communication ports required to allow the RC Controller to communicate with the RC Target located in another network zone using a unidirectional communication type between the RC Proxies. In this situation, the Parent Proxy, which is the RC Target Proxy, is the comments following the table refer to the numbered notes inside the table.

62 IBM Tivoli Remote Control Across Firewalls

initiator

. The

Table 2-1 RC ports for unidirectional communication - Parent/initiator

Source Destination Protocol Description

Type (Service)

Controller (eqnrsmai)

Target Proxy (rcproxy)

Controller Proxy (rcproxy)

Port (Single / Range)

random or

defined (single)

random or

defined (single or range)

random (single)

Type (Service)

Target Proxy (rcproxy)

Controller Proxy (rcproxy)

Target (eqnrcmai)

Port (Single / Range)

9494 (single)

defined (single)

2501 (single)

TCP Started at request.

Communication in the same network zone. No firewall rule needed.

TCP Started at service time.

Communication between two network zones.

Firewall rule needed.

Default polling interval is 2 seconds

TCP Started at request.

Communication in the same network zone. No firewall rule needed.

Comments:

1. This port can be fixed in the rc_def_ports RC Policy.

2. This default port could be changed using the proxy-port parameter in the

[rcproxy] section of the Parent rcproxy.cfg file, that in this case is the RC

Target Proxy configuration file. This port must match with the port defined in

the rc_def_proxy RC Policy.

3. This port or port range could be fixed by configuring the local-port-range

parameter in the [children-cm-info] section of the Parent rcproxy.cfg file,

in this case the RC Target Proxy configuration file.

4. This port must be configured using the parent-local-port parameter in the

[communication-layer] section of the Child rcproxy.cfg file, in this case the

RC Controller Proxy configuration file. This port must match with the port

specified in the children-remote-list parameter in the

[communication-layer] section of the Parent rcproxy.cfg file, in this case

the RC Target Proxy configuration file.

5. The default polling interval could be changed by configuring the

polling-interval parameter in the [children-cm-info] section of the

Parent rcproxy.cfg file, in this case the RC Target Proxy configuration file, as

it is the initiator.

Chapter 2. Implementation planning 63

6. This default port is for a Remote Control session and could be changed in the

rc_def_ports RC Policy. The default port for a File Transfer session is 2502

and could also be changed in the rc_def_ports RC Policy.

For more information about how to configure the RC Policies or the Proxy configuration files, refer to the

IBM Tivoli Remote Control User’s Guide

SC23-4842.

Table 2-2 provides the same information as provided in Table 2-1 on page 63, but in this situation, the Parent Proxy, which is the RC Target Proxy, is the The comments following the table refer to the numbered notes inside the table.

Table 2-2 RC ports for unidirectional communication - Parent/listener

Source Destination Protocol Description

listener

Type (Service)

Controller (eqnrsmai)

Controller Proxy (rcproxy)

Port (Single / Range)

random or

defined (single)

random or

defined (single or range)

random (single)

Type (Service)

Target Proxy (rcproxy)

Target (eqnrcmai)

Port (Single / Range)

9494 (single)

defined (single)

2501 (single)

TCP Started at request.

Communication in the same network zone. No firewall rule needed.

TCP Started at service time.

Communication between two network zones.

Firewall rule needed.

Default polling interval is 2 seconds

TCP Started at request.

Communication in the same network zone. No firewall rule needed.

Comments:

1. This port could be fixed in the rc_def_ports RC Policy.

2. This default port could be changed using the proxy-port parameter in the

[rcproxy] section of the Parent rcproxy.cfg file, in this case the RC Target

Proxy configuration file. This port must be the same as defined in the

rc_def_proxy RC Policy.

3. This port or port range could be fixed by configuring the local-port-range

parameter in the [parent-cm-info] section of the Child rcproxy.cfg file, in

this case the RC Controller Proxy configuration file.

64 IBM Tivoli Remote Control Across Firewalls

4. This port must be configured using the children-local-port parameter in the

[communication-layer] section of the Parent rcproxy.cfg file, in this case

the RC Target Proxy configuration file. This port must be the same as

specified in the parent-remote-port parameter in the [communication-layer]

section of the Child rcproxy.cfg file, in this case the RC Controller Proxy

configuration file.

5. The default polling interval could be changed by configuring the

polling-interval parameter in the [parent-cm-info] section of the Child

rcproxy.cfg file, in this case the RC Controller Proxy configuration file, as it is

the initiator.

6. This default port is for a Remote Control session and could be changed in the

rc_def_ports RC Policy. The default port for a File Transfer session is 2502

and could also be changed in the rc_def_ports RC Policy.

For more information about how to configure the RC Policies or the Proxy configuration files, refer to the

IBM Tivoli Remote Control User’s Guide

SC23-4842.

Unidirectional communication with Relay

Table 2-3 describes the same type of communication as detailed in Table 2-1 on page 63, but a new element, a Relay, has been introduced between the two RC Proxies. In this situation, the Parent Proxies, which are the RC Target Proxy and the Relay towards the RC Controller Proxy, are the following the table refer to the numbered notes inside the table.

initiator

s. The comments

Table 2-3 RC ports for unidirectional communication - Relay - Parents/initiators

Source Destination Protocol Description

Type (Service)

Controller (eqnrsmai)

Target Proxy (rcproxy)

Port (Single / Range)

random or

defined (single)

random or

defined (single or range)

Type (Service)

Target Pr oxy (rcproxy)

Relay (Relay)

Port (Single / Range)

9494 (single)

defined (single)

TCP Started at request.

TCP Started at service time.

Chapter 2. Implementation planning 65

Communication in the same network zone. No firewall rule needed.

Communication between two network zones.

Firewall rule needed.

Default polling interval is 2 seconds

Source Destination Protocol Description

Type (Service)

Relay (Relay)

Controller Proxy (rcproxy)

Port (Single / Range)

random or

defined (single or range)

random (single or range)

Type (Service)

Controller Proxy (rcproxy)

Targ et (eqnrcmai)

Port (Single / Range)

defined (single)

2501 (single)

TCP Started at service time.

Communication between two network zones.

Firewall rule needed.

Default polling interval is 2 seconds

TCP Started at request.

Communication in the same network zone. No firewall rule needed.

Comments:

1. This port could be fixed in the rc_def_ports RC Policy.

2. This default port could be changed using the proxy-port parameter in the

[rcproxy] section of the Parent rcproxy.cfg file, in this case the RC Target

Proxy configuration file. This port must be the same as defined in the

rc_def_proxy RC Policy.

3. This port or port range could be fixed by configuring the local-port-range

parameter in the [children-cm-info] section of the Parent rcproxy.cfg file,

in this case the RC Target Proxy configuration file.

4. This port must be configured using the parent-local-port parameter in the

[communication-layer] section of the Relay Relay.cfg file. This port must be

the same as specified in the children-remote-list parameter in the

[communication-layer] section of the Parent rcproxy.cfg file, in this case

the RC Target Proxy configuration file.

5. The default polling interval could be changed by configuring the

polling-interval parameter in the [children-cm-info] section of the

Parent rcproxy.cfg file, in this case the RC Target Proxy configuration file, as

it is the initiator.

6. This port or port range could be fixed by configuring the local-port-range

parameter in the [children-cm-info] section of the Relay Relay.cfg file.

7. This port must be configured in the parent-local-port parameter in the

[communication-layer] section of the Child rcproxy.cfg file, in this case the

RC Controller Proxy configuration file. This port must be the same as

specified in the children-remote-list parameter in the

[communication-layer] section of the Parent rcproxy.cfg file, in this case

the RC Target Proxy configuration file.

66 IBM Tivoli Remote Control Across Firewalls

8. The default polling interval could be changed by configuring the

polling-interval parameter in the [children-cm-info] section of the Relay

Relay.cfg file, as it is the initiator.

9. This default port is for a Remote Control session and could be changed in the

rc_def_ports RC Policy. The default port for a File Transfer session is 2502

and could also be changed in the rc_def_ports RC Policy.

For more information about how to configure the RC Policies or the Proxy configuration files, refer to the

IBM Tivoli Remote Control User’s Guide

SC23-4842.

Table 2-4 provides the same information as given in Table 2-3 on page 65, but in this situation, the Parent Proxies, which are the RC Target Proxy and the Relay towards the RC Controller Proxy, are the

listeners

. The comments following the

table refer to the numbered notes inside the table.

Table 2-4 RC ports for unidirectional communication - Relay - Parents/listeners

Source Destination Protocol Description

Type (Service)

Controller (eqnrsmai)

Relay (Relay)

Controller Proxy (rcproxy)

Port (Single / Range)

random or

defined (single)

random or

defined (single or range)

random or

defined (single or range)

random (single or range)

Type (Service)

Target Proxy (rcproxy)

Relay (Relay)

Target (eqnrcmai)

Port (Single / Range)

9494 (single)

defined (single)

2501 (single)

TCP Started at request.

Communication in the same network zone. No firewall rule needed.

TCP Started at service time.

Communication between two network zones.

Firewall rule needed.

Default polling interval is 2 seconds

TCP Started at service time.

Communication between two network zones.

Firewall rule needed.

Default polling interval is 2 seconds

TCP Started at request.

Communication in the same network zone. No firewall rule needed.

Chapter 2. Implementation planning 67

Comments:

1. This port could be fixed in the rc_def_ports RC Policy

2. This default port could be changed using the proxy-port parameter in the

[rcproxy] section of the Parent rcproxy.cfg file, in this case the RC Target

Proxy configuration file. This port must be the same as defined in the

rc_def_proxy RC Policy.

3. This port or port range could be fixed by configuring the local-port-range

parameter in the [parent-cm-info] section of the Relay Relay.cfg file.

4. This port must be configured using the children-local-port parameter in the

[communication-layer] section of the Parent rcproxy.cfg file, in this case

the RC Target Proxy configuration file. This port must be the same as

specified in the parent-remote-port parameter in the [communication-layer]

section of the Child rcproxy.cfg file, in this case the Relay configuration file.

5. The default polling interval could be changed by configuring the

polling-interval parameter in the [parent-cm-info] section of the Relay

Relay.cfg file, as it is the initiator.

6. This port or port range could be fixed by configuring the local-port-range

parameter in the [parent-cm-info] section of the Child rcproxy.cfg file, in

this case the RC Controller Proxy configuration file.

7. This port must be configured using the children-local-port parameter in the

[communication-layer] section of the Relay Relay.cfg file. This port must be

the same as specified in the parent-remote-port parameter in the

[communication-layer] section of the Child rcproxy.cfg file, in this case the

RC Controller Proxy configuration file.

8. The default polling interval could be changed by configuring the

polling-interval parameter in the [parent-cm-info] section of the Child

rcproxy.cfg file, in this case the RC Controller Proxy configuration file, as it is

the initiator.

9. This default port is for a Remote Control session and could be changed in the

rc_def_ports RC Policy. The default port for a File Transfer session is 2502

and could also be changed in the rc_def_ports RC Policy.

For more information about how to configure the RC Policies or the Proxy configuration files, refer to the SC23-4842.

68 IBM Tivoli Remote Control Across Firewalls

IBM Tivoli Remote Control User’s Guide

Note: A Relay could, at the same time, be an initiator and a listener, as it is a Child towards the RC Target Proxy and a Parent towards the RC Controller Proxy in our scenario. The information provided in the Table 2-3 on page 65 and Table 2-4 on page 67 can help you to understand all scenarios.

If the Relay is a Child listener and a Parent listener, get the Child listener communication ports in Table 2-3 on page 65 and the Parent listener ports in Table 2-4 on page 67. Conversely, if the Relay is a Child initiator and a Parent initiator, get the Child initiator communication ports in Table 2-4 on page 67 and the Parent initiator communication ports in Table 2-3 on page 65.

Bidirectional communication without Relay

Table 2-5 provides an exhaustive list of communication ports required to allow the RC Controller to communicate with the RC Target located in another network zone using a bidirectional communication type between the RC Proxies. The comments following the table refer to the numbered notes inside the table.

Table 2-5 RC ports for bidirectional communication

Source Destination Protocol Description

Type (Service)

Controller (eqnrsmai)

Target Proxy (rcproxy)

Controller Proxy (rcproxy)

Port (Single / Range)

random or

defined (single)

random or

defined (single or range)

random or

defined (single or range)

random (single)

Type (Service)

Tar g e t Pr ox y (rcproxy)

Controller Proxy (rcproxy)

Tar g e t Pr ox y (rcproxy)

Ta r g et (eqnrcmai)

Port (Single / Range)

9494 (single)

defined (single)

2501 (single)

TCP Started at request.

Communication in the same network zone. No firewall rule needed.

TCP Started at service time.

Communication between two network zones.

Firewall rule needed.

TCP Started at service time.

Communication between two network zones.

Firewall rule needed.

TCP Started at request.

Communication in the same network zone. No firewall rule needed.

Chapter 2. Implementation planning 69

Comments:

1. This port could be fixed in the rc_def_ports RC Policy

2. This default port could be changed using the proxy-port parameter in the

[rcproxy] section of the Parent rcproxy.cfg file, in this case the RC Target

Proxy configuration file. This port must be the same as defined in the

rc_def_proxy RC Policy.

3. This port or port range could be fixed by configuring the local-port-range

parameter in the [children-cm-info] section of the Parent rcproxy.cfg file,

in this case the RC Target Proxy configuration file.

4. This port must be configured using the parent-local-port parameter in the

[communication-layer] section of the Child rcproxy.cfg file, in this case the

RC Controller Proxy configuration file. This port must be the same as

specified in the children-remote-list parameter in the

[communication-layer] section of the Parent rcproxy.cfg file, in this case

the RC Target Proxy configuration file.

5. This port or port range could be fixed by configuring the local-port-range

parameter in the [parent-cm-info] section of the Child rcproxy.cfg file, in

this case the RC Controller Proxy configuration file.

6. This port must be configured using the children-local-port parameter in the

[communication-layer] section of the Parent rcproxy.cfg file, in this case

the RC Target Proxy configuration file. This port must be the same as

specified in the parent-remote-port parameter in the [communication-layer]

section of the Child rcproxy.cfg file, in this case the RC Controller Proxy

configuration file.

7. This default port is for a Remote Control session and could be changed in the

rc_def_ports RC Policy. The default port for a File Transfer session is 2502

and could also be changed in the rc_def_ports RC Policy.

For more information about how to configure the RC Policies or the Proxy configuration files, refer to the SC23-4842.

Bidirectional communication with Relay

Table 2-6 describes the same type of communication as detailed in Table 2-5 on page 69, but a new element, a Relay, has been introduced between the two RC Proxies. The comments following the table refer to the numbered notes inside the table.

70 IBM Tivoli Remote Control Across Firewalls

IBM Tivoli Remote Control User’s Guide

Table 2-6 RC ports for bidirectional communication with Relay

Source Destination Protocol Description

Type (Service)

Controller (eqnrsmai)

Target Proxy (rcproxy)

Relay (Relay)

Controller Proxy (rcproxy)

Port (Single / Range)

random or

defined (single)

random or

defined (single or range)

random or

defined (single or range)

random or

defined (single or range)

random or

defined (single or range)

random (single)

Type (Service)

Target Pr oxy (rcproxy)

Relay (Relay)

Target Pr oxy (rcproxy)

Controller Proxy (rcproxy)

Relay (Relay)

Targ et (eqnrcmai)

Port (Single / Range)

9494 (single)

defined (single)

2501 (single)

TCP Started at request.

Communication in the same network zone. No firewall rule needed.

TCP Started at service time.

Communication between two network zones.

Firewall rule needed.

TCP Started at service time.

Communication between two network zones.

Firewall rule needed.

TCP Started at service time.

Communication between two network zones.

Firewall rule needed.

TCP Started at service time.

Communication between two network zones.

Firewall rule needed.

TCP Started at request.

Communication in the same network zone. No firewall rule needed.

Comments:

1. This port could be fixed in the rc_def_ports RC Policy

2. This default port could be changed using the proxy_port parameter in the

[rcproxy] section of the Parent rcproxy.cfg file, in this case the RC Target

Proxy configuration file. This port must be the same as defined in the

rc_def_proxy RC Policy.

3. This port or port range could be fixed by configuring the local-port-range

parameter in the [children-cm-info] section of the Parent rcproxy.cfg file,

in this case the RC Target Proxy configuration file.

Chapter 2. Implementation planning 71

4. This port must be configured using the parent-local-port parameter in the

[communication-layer] section of the Relay Relay.cfg file. This port must be

the same as specified in the children-remote-list parameter in the

[communication-layer] section of the Parent rcproxy.cfg file, in this case

the RC Target Proxy configuration file.

5. This port or port range could be fixed by configuring the local-port-range

parameter in the [parent-cm-info] section of the Relay Relay.cfg file.

6. This port must be configured using the children-local-port parameter in the

[communication-layer] section of the Parent rcproxy.cfg file, in this case

the RC Target Proxy configuration file. This port must be the same as

specified in the parent-remote-port parameter in the [communication-layer]

section of the Child rcproxy.cfg file, in this case the Relay configuration file.

7. This port or port range could be fixed by configuring the local-port-range

parameter in the [children-cm-info] section of the Relay Relay.cfg file.

8. This port must be configured in the parent-local-port parameter in the

[communication-layer] section of the Child rcproxy.cfg file, in this case the

RC Controller Proxy configuration file. This port must be the same as

specified in the children-remote-list parameter in the

[communication-layer] section of the Parent rcproxy.cfg file, in this case

the RC Target Proxy configuration file.

9. This port or port range could be fixed by configuring the local-port-range

parameter in the [parent-cm-info] section of the Child rcproxy.cfg file, in

this case the RC Controller Proxy configuration file.

10.This port must be configured using the children-local-port parameter in the

[communication-layer] section of the Relay Relay.cfg file. This port must be

the same as specified in the parent-remote-port parameter in the

[communication-layer] section of the Child rcproxy.cfg file, in this case the

RC Controller Proxy configuration file.

11.This default port is for a Remote Control session and could be changed in the

rc_def_ports RC Policy. The default port for a File Transfer session is 2502

and could also be changed in the rc_def_ports RC Policy.

For more information about how to configure the RC Policies or the Proxy configuration files, refer to the SC23-4842.

72 IBM Tivoli Remote Control Across Firewalls

IBM Tivoli Remote Control User’s Guide

Note: A Relay could, at the same time, be a Parent of the RC Controller Proxy and Child of the RC Target Proxy in our scenario. This means that the communication between the Relay and the RC Target Proxy could be unidirectional and bidirectional between the Relay and the RC Controller Proxy. The tables provided in 2.1.3, “Network considerations” on page 61 can help you to understand all of the scenarios.

If the communication between the Relay and the RC Target or Controller Proxy is unidirectional, refer to “Unidirectional communication with Relay” on page 65. If the communication between the Relay and the RC Controller or Target Proxy is bidirectional, refer to “Bidirectional communication with Relay” on page 70.

2.2 Planning for IBM Tivoli Remote Control Proxy

As IBM Tivoli Remote Control Proxies require additional supporting applications, such as the Tivoli Management Framework and, optionally, the Tivoli Firewall Security Toolbox in an RC Proxy Non-Standalone environment, the entire installation process, including Tivoli installation and firewall configuration phases, is depicted in Figure 2-1 on page 74 and Figure 2-2 on page 75. However, in this section, we do not discuss the installation process for each of the pre-requisite application; instead we focus on the installation process for the IBM Tivoli Remote Control Proxies.

Figure 2-1 shows the entire installation process, which includes the supporting application and the required firewall configurations phases for an IBM Tivoli Remote Control Proxy Standalone environment.

Chapter 2. Implementation planning 73

Phase 1

1. Install a TRM Server

2. Define the IOM Range port and configure your Firewall

3. Install Endpoint Gateways in the more and less secure zone.

4. Deploy the Endpoints in the more and less secure zone

TMR Server

Firew all

Endpoint GW

Endpoint

Phase 2

5. Install a Remote Control Server

6. Create a new Policy Region with the RemoteControl managed resource

7. Create a new Remote Control Tool and configure the Remote Control policies to force the usage of the Remote Control Proxy.

Phase 3a

8. Define the communication ports between the RC Proxies and the type of communication (uni or bidirectional) and configure the Firewall

9. Install the Target Proxy and define if it will be the Parent or the Child

10. Install the Cont. Proxy and define if it will be the Child or the Parent

Phase 3b

8. Define the communication ports between the RC Proxies and the type of communication (uni or bidirectional) and configure the multiple Firewalls

9. Install the Target Proxy and define if it will be the Parent or the Child

10. Install the TFST Relay(s)

11. Install the Cont. Proxy and define if it will be the Child or the Parent

RC Server

Firewall

Target Proxy

Figure 2-1 Planning overview for RC Proxy in a Standalone environment

Figure 2-2 shows the entire installation process, which includes the supporting application and the required firewall configurations phases for a IBM Tivoli Remote Control Proxy RCProxy-TFST environment.

RC Tool

Controller Proxy

Relay TF ST

Controller Proxy

74 IBM Tivoli Remote Control Across Firewalls

Phase 1

1. Install a TRM Server

2. Install Endpoint Gateways in the more secure zone.

3. Deploy the Endpoints in the more secure zone

TMR Server1Endpoint GW

Endpoint

Phase 2

4. Install a Remote Control Server

5. Create a new Policy Region with the RemoteControl managed resource

6. Create a new Remote Control Tool and configure the Remote Control policies to force the usage of the Remote Control Proxy.

Phase 3a

7. Define the communication ports between the Endpoint/Gateway Proxy and the type of communication (uni or bidirectional) and configure the Firewall

8. Install the Endpoint Proxy and define it as the Parent

9. Install the Gateway Proxy and define it as the Child

10. Deploy the Endpoints in the less secure zone

Phase 3b

7. Define the communication ports between the Endpoint/Gateway Proxy and the type of communication (uni or bidirectional) and configure the Firewall

8. Install the Endpoint Proxy and define it as the Parent

9. Install the TFST Relay(s) and define it as the Child and as the Parent

10. Install the Gateway Proxy and define it as the Child

11. Deploy the Endpoints in the less secure zone

Phase 4a

11. Define the ports between the RC Proxies and the type of communication (uni or bidirectional) and configure the Firewall

12. Install the RC Target Proxy on top of the Endpoint or Gateway Proxy and define it as the Parent or the Child

13. Install the RC Controller Proxy on top of the Endpoint or Gateway Proxy and define it as the Child or the Parent

RC Server

Firewall

Endpoint Proxy

8 10

Endpoint

Proxy

Target Proxy

Gateway Proxy

Relay TFST

Controller Proxy

RC Tool

Gateway

Proxy

Endpoint

Phase 4b

12. Define the ports between the RC Proxies and the type of communication (uni or bidirectional) and configure the Firewall

13. Install the RC Target Proxy on top of the Endpoint or Gateway Proxy and define it as the Parent or the Child

14. Install a second instance of the TFST Relay and define it as the Child and as the Parent

15. Install the RC Controller Proxy on top of the Endpoint or Gateway Proxy and define it as the Child or the Parent

Firewall

Target Proxy

Figure 2-2 Planning overview for Remote Control Proxy in a TFST environment

Chapter 2. Implementation planning 75

Relay TFST

Controller Pr oxy

Supporting applications requirements

Before installing any IBM Tivoli Remote Control Proxy, you must have the following software components installed, up and running:

򐂰 IBM Tivoli Management Framework 3.7.1 or higher. 򐂰 IBM Tivoli Remote Control 3.8 or higher. 򐂰 Tivoli Firewall Security Toolbox 1.3 or higher for an RC Proxy

Non-Standalone architecture.

In addition, you must install: 򐂰 IBM Tivoli Management Framework Agent of the IBM Tivoli Management

Framework 3.7.1 or higher (lcf version 91 or higher) on the workstations that

should work as Controllers and Targets. 򐂰 IBM Tivoli Management Framework desktop on the workstations where you

want to use the Tivoli Remote Control graphical user interface.

You need to have one of the following Web browsers on the workstations where you want to use the IBM Tivoli Remote Control Web interface:

򐂰 Netscape 4.6 or later 򐂰 Internet Explorer 5.0 or 5.5+SP1®

Hardware requirements

Table 2-7 lists the minimum hardware requirements. These requirements are only for the IBM Tivoli Remote Control Proxies. If you plan to use a Non-Standalone solution, you should also take in consideration the hardware requirements for the Tivoli Firewall Security Toolbox.

Table 2-7 Hardware requirements for IBM Tivoli Remote Control Proxy

HW Intel platforms AIX® platforms SUN platforms

Processor Any Pentium systems Any pSeries™ systems Any SPARC systems

RAM 64 MB minimum

128 MB recommended

Hard disk 28.3 MB for Windows

35.7 MB for Linux

64 MB RAM minimum 128 MB recommended

32.1MB 57.8 MB

64 MB RAM minimum 128 MB recommended

Always refer to the IBM Tivoli Remote Control Release Notes, SC23-4844, for up-to-date hardware requirements for IBM Tivoli Remote Control Proxies.

76 IBM Tivoli Remote Control Across Firewalls

Software requirements

Before starting the installation of the IBM Tivoli Remote Control Proxy, you should have installed the minimum product levels listed in the Table 2-8. These requirements are only for the IBM Tivoli Remote Control Proxies. If you plan to use a Non-Standalone solution, you should also take in consideration the software requirements for the Tivoli Firewall Security Toolbox. Please always refer to the IBM Tivoli Remote Control Release Notes, SC23-4844 for up-to-date software requirements for IBM Tivoli Remote Control Proxies.

Table 2-8 Software requirements for IBM Tivoli Remote Control Proxy

Operating system

AIX ® 4.3.3 (4330-02 ML) / 5.1

Solaris Operating Environment

Red Hat Linux Server

SuSE Linux 7.3

TurboLinux 6.5

Windows 2000 Server / Advanced Server

Required version

7 / 8 (All JRE 1.3 and Java 2 SDK, Standard Edition, v1.3.1 patches can be located at:

http://java.sun.com/j2se/1.3/install-solaris-patches.html)

7.1 / 7.2

For the UNIX platform, you need to have 48 MB of available space in the /tmp file system.

Information you will need for the installation

The IBM Tivoli Remote Control Proxy Standalone installation process will require you to fill in the following information, and will offer advice about the values you can use during the installation process:

򐂰 Common parts for all installation types, Standalone and Non-Standalone:

You will be asked for the following information:

– Licence acceptance:

You must accept the licence agreement.

– The destination directory for the installation:

By default, the Directory is as follows: On Windows: C:\Program Files\Tivoli Sytems\Remote Control Proxy On UNIX: /opt/Tivoli Systems/Remote Control Proxy

Chapter 2. Implementation planning 77

This file system will contain the binaries and configuration files for the application. It is recommended to install such applications in another Logical Partition than the Operating System. Furthermore, a directory structure with no spaces in the name could be easier to manage — just in case the directory name might be used in a script, for example.

– Type of installation:

If you choose to add a label to this Proxy, then this Proxy will become a Child. Otherwise, the Proxy will become a Parent.

Note: This step only concerns an RC Proxy Standalone installation process. In a Non-Standalone process, the setup application discovers if either an Endpoint or Gateway Proxy is installed on the local machine. Then, it defines the RC Proxy as the Parent if it discovers an Endpoint Proxy, and the RC Proxy as the Child if it discovers a Gateway Proxy.

򐂰 If the installation refers to a Standalone mode with a Parent proxy, or an

installation on top of an existing Endpoint Proxy, the process will ask for the

following information:

– A listening port for the Parent from which it listens for Child connections:

This information will be saved in the children_local_port parameter in the [communication-layer] section of the rcproxy.cfg configuration file.

– An IP Address of the Child (or DNS name) and on which port this Child will

be listening for the Parent connections. Repeat this step for all Children you need to define for this Parent.

This information will be saved in the children_remote_list parameter in the [communication-layer] section of the rcproxy.cfg configuration file.

– A type of connection:

This choice must be in accordance with the security rules defined by your Security Officer regarding how communication must be exchanged between different network zones. Refer to 1.1.5, “Proxy connection types” on page 11 for more information about the different types of communications.

This information will be saved in the children_cm_type parameter in the [communication-layer] section of the rcproxy.cfg configuration file. If the connection type selected is unidirectional, the Parent role is saved in the

connection-mode parameter in the [children-cm-info] section of the rcproxy.cfg configuration file.

78 IBM Tivoli Remote Control Across Firewalls

– A list of Tivoli Endpoints that will act as Targets with their dedicated

Remote Control Proxy: This list will be used to find the route to contact the RC Target. This

information will be saved in the rcproxy.route definition file.

Note: This step only concerns an RC Proxy Standalone installation process. In a Non-Standalone process, this information is managed by the Endpoint Proxy and the RC Proxy does not need to maintain a local route file.

– A Proxy role:

You have to define if the Parent proxy will act as an RC Target or an RC Controller Proxy.

For the RC Target Proxy, the process will ask you for the following information:

• A port from which it listens for RC Controller connections:

This port must be the same as registered in the rc_def_proxy Policy. This information will be saved in the proxy-port parameter in the [rcproxy] section of the rcproxy.cfg configuration file.

– A listening port for commands of a command line:

This information will be saved in the cmdline-port parameter in the [rcproxy] section of the rcproxy.cfg configuration file.

򐂰 If the installation concerns a Standalone Child installation or an installation on

top of a Gateway Proxy, the process will ask you for the following information:

– A Proxy label:

This information is used to identify the Child Proxy to its Parent Proxy. It will be saved in the proxy-label parameter in the [rcproxy] section of the rcproxy.cfg configuration file.

Note: This step only concerns an RC Proxy Standalone installation process. In a Non-Standalone process, the Proxy label will be the same name defined for the Gateway Proxy.

– A port to be used to listen to Parent connections:

This information will be saved in the parent_local_port parameter in the [communication-layer] section of the rcproxy.cfg configuration file.

Chapter 2. Implementation planning 79

– The IP Address (or DNS name) of the Parent:

This information will be saved in the parent-remote-host parameter in the [communication-layer] section of the rcproxy.cfg configuration file.

– The listening port of the Parent:

This information will be saved in the parent-remote-port parameter in the [communication-layer] section of the rcproxy.cfg configuration file.

– The type of connection:

This information will be saved in the parent_cm_type parameter in the [communication-layer] section of the rcproxy.cfg configuration file. If the connection type selected is unidirectional, the Child role is saved in the

connection-mode parameter in the [parent-cm-info] section of the rcproxy.cfg configuration file.

– A Proxy role:

You have to define if this Child will be an RC Target Proxy or an RC Controller Proxy.

For the RC Target Proxy, the process will ask you for the following information:

• A port from which it listens for RC Controller connections.

This port must be the same as registered in the rc_def_proxy Policy. This information will be saved in the proxy-port parameter in the [rcproxy] section of the rcproxy.cfg configuration file.

– A listening port for commands of a command line:

This information will be saved in the cmdline-port parameter in the [rcproxy] section of the rcproxy.cfg configuration file.

2.3 Implementation planning case study scenario

Next, we provide a case study scenario which will help you to understand where to place the different components of the IBM Tivoli Remote Control Proxy, and in which situation an RC Proxy Standalone or an RC Proxy Non-Standalone solution should be selected.

80 IBM Tivoli Remote Control Across Firewalls

IBM Tivoli Remote Control User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

Front cover

Contents

Figures

Tables

Examples

Notices

Trademarks

Preface

The team that wrote this redbook

Become a published author

Comments welcome

1.1 IBM Tivoli Remote Control overview

1.1.1 IBM Tivoli Management Framework components

1.1.2 IBM Tivoli Remote Control components

1.1.3 Tivoli components and communication symbols

1.1.4 Parent-Child concept

1.1.5 Proxy connection types

1.2 IBM Tivoli Remote Control sessions overview

1.2.1 Session in a single-TMR environment

1.2.2 Session in a multi-TMR environment

1.2.3 Session using a Remote Control Gateway

1.2.4 Session using Remote Control Proxies Standalone

1.2.5 Session using Remote Control Proxies in a TFST environment

Chapter 2. Implementation planning

2.1 Design

2.1.1 Logical design

2.1.2 Physical design

2.1.3 Network considerations

2.2 Planning for IBM Tivoli Remote Control Proxy

2.3 Implementation planning case study scenario