Professional Documents
Culture Documents
Enterprises
Harley Allkins, Shreedhar Atre, Donal Fallon, Fred Plassman, Clifford Vaughan
SG24-5125-00
SG24-5125-00
Take Note!
Before using this information and the product it supports, be sure to read the general information in
Appendix C, Special Notices on page 127.
Contents
Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi
The Team That Wrote This Redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Comments Welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Chapter 1. Tivoli Remote Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 How Remote Control Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Security Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Authorization Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Default Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.6 Securing the Remote Control Controller Defaults. . . . . . . . . . . . . . . . . 2
1.6.1 Remote Control Policy Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6.2 Security Conscious Environment Modifications . . . . . . . . . . . . . . . 6
Chapter 2. Check Point Software Firewall Technologies, Inc. .
2.1 FireWall-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 VPN-1 SecuRemote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 FloodGate-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .9
. .9
. 10
. 11
iii
.
.
.
.
.
.
..
..
..
..
..
..
.
.
.
.
.
.
. 89
. 90
. 93
. 94
. 94
. 97
vi
Figures
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
vii
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
viii
Tables
1. Summary of TME Network Port Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2. Services Used Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
ix
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. Tivoli Remote Control allows a system administrator to
control the keyboard and mouse input and monitor the display output of a remote
PC running Windows NT, Windows 95, Windows 3.1, or OS/2. The administrator
can also monitor a PC and allow a user to maintain control of the system. Tivoli
Remote Control can even reboot a remote PC.
This redbook describes the functions of the Tivoli Remote Control, how these
functions provide benefits for customers, and practical suggestions for planning,
creating, and managing Tivoli Remote Control in a large enterprise environment.
xi
Comments Welcome
Your comments are important to us!
We want our redbooks to be as helpful as possible. Please send us your
comments about this or other redbooks in one of the following ways:
Fax the evaluation form found in ITSO Redbook Evaluation on page 149
to the fax number shown on the form.
Use the electronic evaluation form found on the Redbooks Web sites:
For Internet users
For IBM Intranet users
http://www.redbooks.ibm.com
http://w3.itso.ibm.com
xii
control or reboot a system without prompting the end user (which is useful if
the end user is absent), or only if the end user allows it.
1.5 Notices
Remote Control generates a notice in the TME 10 Remote Control notice
group for each operation attempted. The notice indicates what action was
taken and the outcome of the operation. Actions performed during a remote
control session are not logged, but the fact that a session was successfully
initiated is, as well as the administrator responsible for the session.
user presses Start Session, the user is prompted with the Start Session
dialogue box as shown in Figure 1 on page 3.
Here, the Remote Control user has the option of selecting which mode of
control to implement, how much warning time (Grace Period) to give the user
at the target, and whether to allow the user at the target to break the session
(State Change on Target).
In some environments, such as an out-sourced help desk, it is not advisable
for personnel to be able to take control of a target and not allow the user at
the target to override this action. In a banking environment, for example, it
might be necessary for the user at the target to first give permission to the
controller to connect before allowing them to do so. Alternatively, it is
sometimes more practical to alter the defaults that appear on this panel to
settings that would better suit a production environment, instead of expecting
Remote Control users to continuously change the settings each time they
start a session.
This can be done by modifying the Remote Control policy methods.
The default policy method that is installed when Remote Control is installed is
called RemoteControl_PDO. You can obtain a list of all the default Remote
Control policy objects that are defined by executing the following command:
wlspol -d RemoteControl.
To confirm the current default policy object for a particular Remote Control
tool (icon) in a particular policy region, open the policy region where that
Remote Control tool was defined. Select the Remote Control tool (one left
mouse click), select Properties on the Action Bar, then select Managed
Resource Policies... in the drop down menu. On the Managed Resource
Policies panel, select RemoteControl in the Managed Resources list. The
default policy object for this instance of the Remote Control tool is in the
Default Policy drop down box entry field. Click on the Close button to exit
this panel.
It is good practice to leave the RemoteControl_PDO policy object unchanged,
and only make modifications to policies which have been copied from this
default. To copy a policy object, execute the following command:
wcrtpol -d RemoteControl Restricted RemoteControl_PDO
We elected to call our new policy Restricted. Executing wlspol again will
show the new policy in the class for Remote Control, as shown in Figure 4.
c:\>wlspol RemoteControl
RemoteControl_PDO
Restricted.
Just as one would use the wgetpolm command to view the contents of a policy
method, the command wputpolm replaces the current content. The simplest
method of using these commands to make changes is to follow the process
listed below. To illustrate this point, we are modifying the rc_def_command
policy method.
Execute:
wgetpolm -d RemoteControl Restricted rc_def_command >
c:\temp\AFileName
Confirm that the change has taken place as required by viewing the
output of wgetpolm again.
the user, but give the Remote Control user the opportunity to take control
once the session has been established.
We wanted to give our users more time to respond to the initialization of
the Remote Control session and cancel it if they were busy with a
confidential document. At the same time, however, if no one was at the
workstation to cancel the session, the Remote Control user would then
automatically have access. This would allow support personnel to control
a machine after hours. To do this, we altered rc_def_grace_time to be
15-locked and rc_def_timeout_op to be ENABLED. The Remote Control
User is not able to modify the default timeout as we have specified it to be
locked.
One can improve on this by writing a script which gives different output
depending on the time of day that this command is run. For instance,
during office hours, rc_def_grace_time could be set to 15-locked, and the
rc_def_timeout_op could be DISABLED-locked. After hours, the user
could be given the option to modify these settings on the Start Session
dialogue.
Finally, we modified rc_def_alt_t. This is by default DISABLED, and we
changed it to read ENABLED-locked. Any user at a Remote Control
target can then terminate a Remote Control session, and this setting
cannot be overridden by the user at the Remote Control controller.
Once the policy methods have been modified, the policy object must be
activated and this is done using the command
wsetpr -d Restricted RemoteControl ostmr-region.
The new start session dialogue box is shown in Figure 5 on page 8. Notice
that the Grace Period drop-down-list and the State Change on Target
check-box are both lowlighted, or grayed out, and cannot be modified.
2.1 FireWall-1
Internet technology has changed not only the way organizations do business,
but also the way they approach network security. The dynamic nature of
todays corporate networks means that they are no longer defined by physical
boundaries, but instead by enterprise-wide security policies. To be effective,
these policies must include a broad range of security services that govern
access to network resources while protecting these same resources from
both internal and external threats.
A complete enterprise security solution must provide the ability to:
Grant selective network access to authorized remote and corporate users
Authenticate network users with strong authentication techniques before
granting access to sensitive corporate data
Ensure the privacy and integrity of communications over untrusted public
networks like the Internet
Provide content security at the gateway to screen malicious content such
as viruses and malevolent Java/ActiveX applets
Detect network attacks and misuse in real time and respond automatically
to defeat an attack
Protect internal network addressing schemes and conserve IP addresses
Ensure high availability to network resources and applications
Deliver detailed logging and accounting information on all communication
attempts
With its Enterprise Security Management product family, Check Point
Software Technologies offers a comprehensive set of solutions that meet
these demanding requirements. Check Points FireWall-1/VPN-1 security
suites enable all functionality to be deployed and managed with a single
10
2.3 FloodGate-1
Organizations worldwide are using the Internet to support mission-critical
business applications. At the same time, corporate intranets and extranets
are being deployed at an unprecedented rate to deliver valuable information
resources to both internal and external users. Although the benefits of
Internet technologies are undeniable, many corporations are suffering from
the inevitable network congestion on both Internet and intranet links resulting
from the flood of IP-based traffic.
Even during moderate levels of network congestion, users experience a
degradation in the performance and availability of critical Internet services.
Without the ability to control traffic flow at all network access points,
corporations are unable to direct limited bandwidth resources to
revenue-generating applications. Important services or users may be starved
of bandwidth by non-critical Internet or intranet traffic.
11
12
rc_def_targets
rc_def_filter_mode
rc_def_polfilter_mode
rc_def_uncheckedlist
rc_def_checkinterp
13
14
#!/bin/sh
#
# Default policy method for Remote Control Define Target list
#
# This method authorizes the user to define a new targets list.
#
# Possible modes are:
#
DefinableTargetList
(can filter the list)
#
FilteredList
(cannot filter the list)
#
UncheckedList
(the list is displayed w/o any validation)
#
#
DefinableTargetList-locked(the user cannot change the setting)
#
echo "DefinableTargetList"
exit 0
15
#!/bin/sh
#
# Default policy method for Remote Control
#
# This method allows to set another GUI Performance tuning :
# you can choose if avoid or not from the Endpoint list the UNIX
# ManagedNode
# Possible modes are:
#
Yes the check on each ManagedNode interp is done
#
No
no check is executed
#
echo "Yes"
exit 0
16
#!/bin/sh
# This method is to set a list of the possible RemoteControl targets
# Input values: i.e. echo "endpoint-label" list or
# echo "default-list" if you want to display all the machines.
echo "default-list"
exit 0
Figure 8. rc_def_targets Policy Method
with:
wgetallinst ManagedNode
wgetallinst Endpoint
17
18
#!/bin/sh
#
# Default policy method for Remote Control Policy Region
#
# This method prints the filtering mode for the list of possible
# targets.
#
# Possible modes are:
#
node
(show only managed nodes)
#
pcnode
(show only PC managed nodes)
#
nwnode
(show only netware clients)
#
epnode
(show only LCF Endpoints)
#
all
(show all)
#
#
XXX-locked(show XXX only, and the user cannot change the setting)
#
(eg. "pcnode-locked")
echo "all"
exit 0
"node"
"pcnode"
"nwnode"
"epnode"
19
20
#!/bin/sh
#
# Default policy method for Remote Control Policy Region
#
# This method prints the filtering mode for the list of
# possible targets .
#
# Possible modes are:
#
region (show according the policy choosen)
#
myregion (show according the policy region where is the
#
tool)
#
all
(show all)
#
#
XXX-locked(show XXX only, and the user cannot change the
#
setting)
#
(eg. "pcnode-locked")
echo "myregion"
exit 0
Figure 12. rc_def_polfilter_mode Policy Method
The rc_def_polfilter policy method can also be set to display nodes in all
regions or in a specific region. To allow the user to select a region from the
Policy Region Names list, change echo "myregion" to echo "region". To
display nodes in all regions, change echo "myregion" to echo "all". The types
of nodes displayed will be the types that are set in rc_def_filter_mode.
Figure 13 on page 22 is an example of the resulting target list when
rc_def_filter_mode is set to echo "epnode" and rc_def_polfilter_mode is set
to echo "region".
21
For this figure, if you select a different region from the policy region names
list, you get a different list of endpoints in the Endpoint Name list.
These statements will list all managed nodes and all PC managed nodes in
the TMR.
22
Note
#!/bin/sh
# This method is to set a list of the possible RemoteControl targets
# Input values follow this naming convention :
# ManagedNode
echo "label"
# PCManagedNode:
echo "label"
# NetWare Clientes
echo "NetWareClientName@NetWareManagedSiteName"
# Endpoint
echo "label+"
# Default value: wgetallinst ManagedNode wgetallinst PCManagedNode
wgetallinst
ManagedNode
wgetallinst PcManagedNode
exit 0
Figure 14. rc_def_uncheckedlist Policy Method
23
24
Since the target list can be very large, having the list in a file would make the
list easier to maintain without having to change the policy method over and
over. You can change rc_def_targets or rc_def_uncheckedlist to point to the
target list file by replacing the default statement in the policy method with
something like cat <drive:\path>\targetlist.txt where:
<drive:\path>
targetlist.txt
#!/bin/sh
# This method is to set a list of the possible RemoteControl targets
# Input values: i.e. echo "endpoint-label" list or
# echo "default-list" if you want to display all the machines.
cat c:\rctools\rclist.txt
exit 0
Figure 16. rc_def_targets Using a File for the List of Targets
.
echo "target01"
echo "target02"
echo "target03"
.
echo "target99"
exit 0
If the rc_def_targets policy method will get the list from a file (see Figure 16
on page 25), the entries in the file should be in the form of one target_name
per line as seen in Figure 17 on page 25.
25
target01
target02
target03
.
.
.
target100
MNtarget
PcMNtarget
EPTarget+
.
.
.
NWtarget@NetWareManagedSite
Figure 19. Target List File rclist.txt Used by rc_def_uncheckedlist Policy Method
26
In this example, two tasks were created. The first to query a list of nodes to
see if Remote Control target is installed. The second task starts the main
script which gathers a list of all endpoints in the TMR, compares the lists,
starts the first task to query only the list of new endpoints, creates a new list
of only endpoints with Remote Control installed, and appends them to the list
that will be used by one of the Remote Control policy methods. The list is
then sorted alphabetically and duplicates are removed.
The resulting list must be on the managed node where the Remote Control
tool was defined so the Remote Control policy method can read the list.
3.6.3.1 Create the Scripts
In our test TME, all nodes were running Windows NT 4.0 Server with SP3.
Your environment may be different; so, the scripts you need to create may be
different.
The first bash script, GetRCs.sh, checks each node in a temporary list for the
presence of the Remote Control target on each machine. You can view this
script in Figure 20 on page 27. This script is run by a task started from the
second script.
By searching for the presence of EQNRCMAI.EXE in directory
c:\Tivoli\Pcremote, the script determines if Remote Control has been installed
on each new endpoint. If the executable is found, a string made up of the
words VALIDRC and the hostname of the endpoint separated by a colon, is
passed to STDOUT. The inclusion of the string VALIDRC makes it easier to
identify the line in the final output that is collected from all the machines, as
you will see later.
If the executable is not found, then nothing is returned to STDOUT.
#!/bin/sh
# Determine if file eqnrcmai exists
# If it exists then return VALIDRC:hostname
#
dummyvar=hostname
if [ -f c:/tivoli/pcremote/eqnrcmai.exe ]
then
echo "VALIDRC:$dummyvar"
fi
27
We originally made use of a DOS batch script to do this, but the DOS script
failed because there is a limitation on the current version of the endpoints
which does not pass the output sent to STDOUT back to the executing task.
The second script, GetNewEPs.sh, is a bash shell script file and is listed in
Figure 21 on page 30. This script takes the output from GetRCs.sh and
extracts the list of machines which have returned data to STDOUT. This is
done by performing a search for the string VALIDRC. From this list, the script
drops the word VALIDRC as well as the colon, and only the hostnames
remain.
The output from the task contains comment lines, machine hostnames, error
output as well as the standard output from the various executions of
GetRCs.sh.
Each of the endpoints in the list is appended to the existing list of Remote
Control endpoint targets, and, if at least one new endpoint was added, the
endpoint gateway is restarted. The list of hostnames for endpoint targets
resides, in our case, in C:\RCTOOLS on the TMR server. The script then
proceeds to sort the full list of hostnames into alphabetical order which makes
locating a particular workstation much easier.
Now, we have a process to determine whether machines which previously did
not have Remote Control running now have it installed, and if so, to add these
machines to the total list of Remote Control workstations. A function was also
needed to analyze the list of existing endpoints, and determine which of
them, if any, do not appear in the list of Remote Control targets maintained in
C:\RCTOOLS. If there are such targets, then GetRCs.sh should be run
against only these, and not all nodes. Performing the process this way is
more efficient since it only runs on the machines when necessary.
The GetNewEPs.sh script performs this task by building a temporary list of all
the defined endpoints using the wgetallinst command, and then compares
this list against the list of Remote Control targets in C:\RCTOOLS. The script
extracts the names of the machines which do not exist in the temporary list,
but do exist in the C:\RCTOOLS list. This task simultaneously removes
machines which are no longer defined in the TMR from the list of Remote
Control Targets, while adding any new RC Targets to the list.
#!/bin/sh
# Create list of all endpoints with Remote Control Target
# installed to be used by RC policy method rc_def_targets
RCList=c:/rctools/list.txt
# List of all EP targets for rc_def_targets
WLookList=c:/rctools/temp/WlookList.txt # List of all EPS
TL=c:/rctools/temp/tl.txt
# List for nodes in WLooklist and not in RCList
28
TL1=c:/rctools/temp/tl1.txt
GetRCs=c:/rctools/temp/getrcs.txt
rm
rm
rm
rm
-f
-f
-f
-f
$WLookList
$TL
$TL1
$GetRCs
LIST=cat $RCList
echo "Building list of valid EPs in RC list"
for i in $LIST
# check the RCList content against WLookList
do
grep -ix "$i" $WLookList > /dev/null
RC=$?
if [ $RC -eq 0 ]
# if the node is in both lists then write it to TL1
then
echo $l >> $TL1
fi
done
if [ -f $TL1 ]
then
echo "Refreshing $RCList from $TL1" # Debug line
cat $TL1 > $RCList
# refresh RCList
fi
else
cat $WLookList > $TL
fi
LIST=cat $TL
rtcmd=wruntask -t "Is RC Installed" -l "RC Tools" -m 30 -M parallel -o 15
for i in $LIST
do
29
rtcmd="$rtcmd -h $i"
done
echo "Executing command $rtcmd"
echo $rtcmd > c:/rctools/go.cmd
c:/rctools/go.cmd > $GetRCs
# DEBUG
LIST=cat $TL
ctr=0
for i in $LIST
do
echo $i >> $RCList
echo "Added $i to list"
ctr=1
done
if [ $ctr -ne 0 ]
then
echo "Restarting the EP Gateway"
wgateway ostmr restart
# restart the EP Gateway after link
else
echo "No EP Gateway restart required"
fi
cat $RCList | sort -u > $TL1
cat $TL1 > $RCList
echo "$RCList created/updated"
# Sort RCList
# Refresh the list
For the scripts that we have described above to work correctly, they must be
defined as tasks in the TME and within a Tivoli task library.
3.6.3.2 Create the Task Library
For our scenarios, we decided to put all Remote Control related tasks and
jobs into one task library. We created the task library, RC Tools, as follows:
wcrttlib "RC Tools" ostmr-region
30
When the task is built, the script is immediately loaded from the source you
specified, and stored on the TMR database. This means that whenever you
make changes to the script, you must re-edit the task so that your new
script can be incorporated into the existing task.
Typically, we gave the tasks admin, senior, and super roles.
We found it was quicker to create the task from the command line, and we
created two separate tasks, one for each of the scripts. Here are the
commands that we used to create each task:
wcrttask -t "Get New EPs" -l "RC Tools" -r admin:senior:super -i
w32-ix86 ostmr c:\rctools\GetNewEPs.sh
wcrttask -t "Is RC Installed" -l "RC Tools" -r admin:senior:super -i
w32-ix86 ostmr c:\rctools\GetRCs.sh
31
32
Control targets. Each of these targets is added to the list of Remote Control
targets. If any new target was added to the list, the endpoint gateway is
restarted. The list is sorted alphabetically, any duplicates are removed, and
the file is now ready to be used by the Remote Control policy method
rc_def_targets or rc_def_uncheckedlist.
3.6.3.7 Potential Enhancements
A potential enhancement would build a list of Remote Control targets that
also have an application, such as Lotus Notes, installed.
Another task could be defined and started from the main script in the above
example to run against the list of new Remote Control targets, or all Remote
Control targets, in order to find which ones also have the application installed.
You could use Tivoli Inventory and extract the list of targets from a list
generated by an inventory scan that looked for all endpoints having Remote
Control and the particular application installed.
33
34
4.1 Background
The growth in outsourcing of IT services has created virtual extensions of the
enterprises network. More and more, network users are having to traverse
public net-space in order to access the domains of their private network.
Network security is therefore an essential facet of every Tivoli Managed
Environment installation.
Firewalls are network access control devices that are used in securing the
network perimeter of an enterprise installation. The firewall ensures that all
communication between an enterprises network and the Internet conforms to
the enterprises security policy.
The use of firewalls in a Tivoli Management Region (TMR) creates security
issues during the deployment. Firewall placement obviously influences the
workings of the TME installation. Outsourcers use Remote Control to provide
IT outsourcing services to their customers. This chapter addresses these
issues with the implementation of FireWall-1 from Check Point Software
Technologies, Ltd. in a number of scenarios and the successful use of
Remote Control in each of the scenarios.
35
4.2.1 Daemons/Services
Our TME installation included the following types of network (listening)
servers:
The Object Dispatcher running on all managed nodes/gateways
The LCF gateway daemon running on managed nodes configured as
gateways
The TMA (LCF) daemon that runs on endpoints
The TME 10 Remote Control service that runs on targets and controllers
36
37
Type of Connection
TCP Server
Listening Port
TCP
ClientEphemeral
Port
Protocol/Duration
Inter-Orb
94
TCP/Sustained.
Inter-TMR
94
TCP/Sustained.
Inter-Object
Messaging
TCP/On-Demand
creation for
duration of bulk
data exchange.
Endpoint to
Gateway Initial
login
Gateway server
port chosen at
installation
Ephemeral port
provided by the OS
at the endpoint
UDP/Initial login to
determine
assigned gateway
Endpoint to
Gateway
Normal login or
upcalls
Gateway server
port chosen at
installation
Ephemeral port
chosen by OS at
the endpoint
TCP/Sustained.
Gateway to
Endpoint
Endpoint Server
chosen at
installation
Ephemeral port
chosen from the
selected port
range, or assigned
by OS at the
gateway
TCP/Sustained for
the duration of the
downcall or control
packets.
Remote Control
Chosen from a
selected range or
assigned by OS or
port 2501
Ephemeral port
chosen by OS
TCP/Sustained
during the period of
the session.
The table refers to there being TCP servers and TCP clients. These
references are made purely in the context of the request. Therefore, when an
object requests a transaction, it is a TCP client. The roles of the TCP server
and client have no bearing on the TME roles of the TME client and server. In
38
other words, an ORB that is a server to one remote ORB can also invoke TCP
client requests on other remote ORBs, that is, the roles are interchangeable
and are determined by only one event - the request.
The object-call induced client ephemeral connections, the IOM channel
server, and IOM ephemeral client connections can be locally bound to a port
range. The port range selection in 3.6 is on a per-TMR basis, and 3.6.1
allows a per-managed-node basis, although this functionality will probably be
removed in future releases. The odadmin set_port_range command was used,
and we selected a port range of 30,000 - 35,000.
Note
TME installation uses network services such as rexec and trip (Tivolis
version of remote execution facility for Windows NT), which do not allow
port selection for connectivity. Thus, the firewall may need to open port 513
during installation. Once deployed, the port can be closed.
39
The NAT mappings from private to public addresses must be static (no
time slicing/sharing of public addresses).
The NAT device acts as a router for IP traffic between public and private
networks.
The NAT device must act as a proxy DNS server to ensure that client
systems can resolve hostname addresses on both sides of the NAT
address spaces.
Fully Qualified Host Names (FQHN) must be used for gateways when
providing login information.
The assigned gateways in the select_gateway_policy script must detail
the gateways FQHN along with its Object Identification (OID). This is done
by appending the FQHN to the OID, the strings being separated by the "|"
(pipe) symbol (no spaces between OID and pipe symbol).
Remote Control was not tested in a NAT environment.
40
tC
t
ge
ar
tT
St
ar
ar
St
on
tro
lle
r
Server
Controller
Target
For performance reasons, you may want to avoid using the Remote Control
gateway. When a Remote Control gateway is used, all communications
between the Remote Control controller and the Remote Control target must
first pass through the Remote Control gateway. However, if you must run
Remote Control through a firewall, the Remote Control gateway may provide
you better security.
Gateway
Server
t
Star
et
Targ
Star
t Co
ntro
ller
Start Gateway
Target
Controller
Figure 23. Remote Control Session Initialization with RC Gateway
41
We have attempted to show the most secure setup for different firewall
placements.
Note
The diagrams are merely a representation of the setup. In fact, Remote
Control server was always installed on the TMR server, and the TMR
server was always used as a Remote Control gateway. Also, Remote
Control target and Remote Control controller can be on machines on either
side of the firewall.
42
Controller or
Target Endpoint
TMR
Server
Remote Control
Controller
LAN
Router
Router
Firewall
LAN
Controller or
Target Endpoint
where:
EP is an endpoint.
GW is a Remote Control gateway.
TMR is a TMR sever.
RC is the Remote Control server.
CT means that the box is both a Remote Control target and a Remote
Control controller.
Note
43
External
Internal
Controller or
Target Endpoint
Controller or
Target Endpoint
Remote Control
Controller
LAN
Router
Router
Firewall
LAN
Remote Control
Gateway
Remote Control
Gateway
TMR
Server
44
TMR
Server
Remote Control
Gateway
LAN
Remote Control
Controller
Router
Controller or
Target Endpoint
Router
Firewall
TMR
Server
Remote Control
Controller
LAN
Controller or
Target Endpoint
Figure 26. Endpoint, Gateway, and TMR Server All External
This may be relevant to sites that have significant concerns about opening
inbound/outbound ports to a large number of external systems.
45
Inspection at this layer ensures that the FireWall Module intercepts and
inspects all inbound and outbound packets on the network gateway. No
packet is processed by the higher protocol stack layers unless the FireWall
Module verifies that the packet complies with the security policy. The FireWall
Module examines IP addresses, port numbers, and any other information to
determine whether packets should be accepted in accordance with the
Security Policy.
46
command from a DOS prompt in Windows NT. Continue to define any network
objects which you will be using in your FireWall-1 rule base.
2. Define any additional services.
Select Manage -> Services to bring up the Service Manager dialog box.
Choose the type of protocol you require, for example, TCP. Give the service a
name and fill in the destination and source port ranges.
47
Note
To add the source to a rule, right-click on the box of the source field and click
add. This brings up the Network Object Manager. Choose from the selections
given.
4. Load the policy.
48
Now, for the firewall to use your new settings, select Policy and then install.
Choose the module where you want this policy to be installed.
The Log Viewer is a very useful aid for seeing the communications that cross
the firewall between the TMRs components. Therefore, the Log Viewer was
opened (from the Window panel of Security Policy window) and was set to
refresh automatically.
4.7 Scenarios
The three different scenarios correspond to the implementation of the three
different firewall placements. Firewall-1 was used to implement as strict a
security policy as possible while still allowing Remote Control of machines on
both sides of the firewall. Remote Control controllers were placed on both
sides of the firewall, in the customer site (external), as well as in the
outsourser site (internal). Internal controllers represent customer machines
being supported remotely. External controllers represent the occasions where
a remote user has to take control of an internal machine.
49
Since we require a source port range representing all high ports from 1023 64000, and a destination port of 9494, this requirement becomes Rule 1 (see
Figure 30 on page 50).
The hostname of the endpoint that tried to log in is VIKING. But VIKING could
represent any machine trying to log in, and, therefore, it is equivalent to
having the source as any.
What is required now is to define a rule which allows this packet through
while opening a minimal amount of ports. Packets are matched against a
rules Source, Destination, Service and Time. The first rule that succeeds in
matching the packet is applied. In order for the EP gateway to reply to the
initial logon attempt by the endpoint, the EP gateway needs to open a high
port and connects to 9494 on the Endpoint. This requirement becomes Rule
2.
50
The response from the endpoint is on a high port and connects to port 9494
on the EP gateway. This response is covered by Rule 1.
Next, we started the Tivoli Desktop on the endpoint. The initial dialogue is
initiated from a high port to port 94, that is, Inter-ORB communications. For
the bulk data transfer, IOM communications are invoked from a high port on
the Endpoint to our selected range on the TMR server ports 30,000-35,000.
This requirement becomes Rule 3.
Now, all that is left is to start Remote Control. Once again, the machine that
initiates a transfer of data does so from a high port, and, with Remote
51
In Figure 34 on page 53, VIKING and OS1 are endpoints and OSTMR is the
TMR server, the EP gateway, and the Remote Control server.
52
53
Now, with the EP logins removed from the equation, Rule 1 has change
significantly. Now, we have ports opened in a much more restricted range
and, more importantly, between only two specified machines instead of any
machine.
We defined the Rule Base for Remote Control before that of the Tivoli
Desktop to highlight the fact that it is not always necessary to use the Tivoli
Desktop to initiate Remote Control.
In this case, we used the wrc command:
wrc RmtCtrl controlmr @Endpoint:montague @Endpoint:os1 -B:Y -C:Y -G:0 -Z:Y
54
where RmtCtrl is the Remote Control object, controlmr specifies that the
control session initial state is monitor, montague is the Tivoli name of the
target, os1 is the Tivoli name of the controller, -B:Y disables background,
-C:Y limits to 16 colors, -G:0 specifies no grace period, and -Z:Y enables
compression.
RC control can also be initialized from a Web interface (see Chapter 8, Web
Browser Integration on page 101) which is especially useful where slow
network :s are involved.
55
Rule 1 is very tight and opens a minimized port range to a single port from
known machines.
Table 2. Services Used Definitions
Service/Type
Source Port
Dest. Port
Protocol
AATiv_HighRange_9494
High Port
9494
UDP
High Port
9494
TCP/Sustained
High Port
94
TCP
High Port
30000- 35000
TCP
30000 - 35000
94
TCP/Sustained
EP - GW Initial login
AATivGW_HighRange_9494
EP - GW Normal
AATiv_HighRange_94
Inter-Orb/TMR
AATiv_HighRange_30K-35K
IOM
AATiv_30K-35K_94
Inter-Orb/TMR
56
Service/Type
Source Port
Dest. Port
Protocol
AATivGW_30K-35K_30K-35K
IOM
30000 - 35000
30000 - 35000
TCP
AATivRC_HighRange_2501
High Port
2501
TCP
RC
4.7.4 Summary
With Scenario 1, there was massive port exposure. In Scenario 2, this
exposure was reduced by replacing endpoint to gateway trans-firewall
communications with gateway to TMR communications. Further reductions in
the port exposure occur when the need for opening the Tivoli Desktop is
removed, and further still where multiple TMRs are involved, leaving Remote
Control as the primary exposure.
When Remote Control is being initiated from the internal site, this opens a
high port range to 2501 on any machine. This is quite loose, but it is at least
initiated from the internal site.
When Remote Control is being initiated from the external site, Remote
Control is opening a range of ports on any machine to port 2501 on internally
available machines that make it wide open.
4.8 Recommendations
General recommendations include:
It is strongly recommended that, in a security conscious environment, the
endpoint gateway is on the same side of the firewall as its endpoints.
Where possible, do not use the Tivoli Desktop.
Where relevant, use multiple TMRs.
Specific recommendations for Remote Control are:
To reduce the risk from Rule 2 in Scenario 3 above, you should implement
the use of a Remote Control gateway. The Remote Control gateway would
be placed external to the Remote Control controllers. Instead of the need
to open ports to any destination, you need only open the range to the
Remote Control gateway which then handles all of the communications
between Remote control controller and Remote Control target. Use of the
Remote Control gateway could significantly reduce performance.
57
58
59
60
61
intercepted and encrypted. Otherwise, the packet will be left to follow its
normal course.
After the user has confirmed the information on the screen and closed the
window, SecuRemote is ready to encrypt any data that is destined for the
firewall or for machines behind the firewall.
62
to Windows NT, then SecuRemote returns with a message that the user is
unknown to the operating system.
Note
The user ID and password for SecuRemote are both case sensitive. The
user ID and password for the operating system may not be case sensitive.
If you choose to validate a user ID against the operating system, then,
when logging on, enter the user ID in the same case as you used when you
defined it to FireWall-1 and not to the operating system.
63
OSTMR. You will notice that the action for Rule 2 is not Accept, but rather
Client Encrypt. Client Encrypt must be specified as it is this action that
performs the encryption and decryption of packets that go to and come from a
SecuRemote client. The action menu is shown in Figure 40 on page 64.
Rule 3 is necessary to allow the session to be able to connect back from the
target machine.
You will also notice that we added Rule 4. We added this rule so that the
continuous NetBIOS-name-find and other NetBIOS datagram packets that
Windows NT issues are not logged when dropped by the firewall. This rule
reduced the amount of clutter in the log file while we were taking traces of this
environment.
64
This set of rules was going to provide us with the basic environment to allow
us to establish a secure connection. We had to understand how the secure
connection would behave under different circumstances in order to apply this
knowledge to Tivoli Remote Control connections. We put SecuRemote
through some test cases.
This failed since the nbsession service was denied access by Rule 5. We
started SecuRemote on VIKING and repeated the net use command on
OSTMR.
We were immediately prompted for a userid and a password. When we used
the ID Jimboy (validation performed by FireWall-1), we received the following
authorization message:
User Jimboy authenticated by FireWall-1 Authentication.
In both cases, the log file showed no entry to indicate a successful logon.
However, if an unsuccessful logon occurs, an alert is generated in the log,
giving an explanation for the failure.
65
Note
If the user is defined at the firewall, but is not defined to the groups which
are permitted through the firewall, the users logon (to the firewall) will still
be successful, but the user will not be able to establish sessions through
the firewall.
Once user authorization completed, we could perform a net use across the
firewall to our target machine from the SecuRemote machine. Figure 41 is an
extract from the log file which shows the entry detailing the successful
session establishment. Notice that the action performed on the packet was a
decryption.
The session was not established. We saw that the nbsession and nbname
requests from OSTMR were accepted by the firewall, but we saw no
response from machine VIKING. Though there was nothing explicitly detailed
in the log of packets being dropped, we confirmed from a line trace taken on
the side of OSTMR that there were no responses from machine VIKING.
This means that even though a machine has a running application that is
listening for requests, this machine will not respond to a request coming from
66
behind the firewall until the user at the local machine has been validated
against the firewall.
What we did see was that, when we halted SecuRemote on the client, we
were able to successfully connect, indicating that the SecuRemote
application was probably intercepting packets leaving the workstation.
To further confirm our findings, we established a connection from machine
VIKING. We opened an HTTP connection and then repeated the above
net use command on machine VIKING. The log shown in Figure 42 on page
67 lists the transactions that took place.
First, you see the successful connection of the HTTP session from VIKING to
OSTMR. The next entry is the NetBIOS session establishment packet coming
from OSTMR and shows that the packet was accepted. This entry is what we
saw previously, but the third line, showing the encryption of the packet, is now
there because of the HTTP session that we established earlier. Because of
what happens in this third entry, the net use command is successful.
A request from a node inside the firewall to a SecuRemote node outside the
firewall is successful if the SecuRemote node outside the firewall has
established any successful connection to that node inside the firewall. This
behavior is an important aspect of SecuRemote that we need to bear in mind
when working with Remote Control, but raises questions about how
SecuRemote operates in more complex environments.
First, we modified Rule 2 (refer back to Figure 39 on page 63) to allow the
SecuRemote client to connect to any machine on our internal network. This
rule base was loaded, and then we repeated the situation discussed earlier in
this section. VIKING had been validated by the FireWall-1 and we had a
secure connection to and from OSTMR.
From a second machine on our internal network, MONTAGUE, we executed:
net use v: \\viking\c$
67
68
By adding the services nbname and nbsession to Rule 3, we allow both HTTP
and NetBIOS sessions to be established from within the firewall, but still only
HTTP sessions from the SecuRemote client may be created. Before the user
at the client is validated, we are not able to start any sessions from any of the
internal machines. After VIKING establishes an HTTP session across the
firewall, we are able to create HTTP and NetBIOS sessions in the opposite
direction.
When we open the ports for nbname and nbsession commands, we are able to
perform SMB and HTTP transactions through the firewall.
These results may be intuitive, but we tested them and documented what we
found here for completeness.
5.2.4.4 Termination of Secure Session
During our tests, we often used the net use command to initiate from our
SecuRemote client, across the firewall, to our internal network. But, these
sessions go to a disconnected state if they are left idle for some time. When
this happens, the firewall assumes that the connection from the client is
broken. No more connections are allowed from machines on the internal
network, and existing connections are disconnected.
69
that the endpoint uses to perform its initial logon. These rules only permit a
Remote Control session to take place. Naturally, the rules will need to be
modified to include the applications that the user must connect to.
Rule 4 is responsible for allowing the endpoint gateway, OSTMR, which is on
the internal network, to communicate with the endpoint service running on
machine VIKING. Rule 4 (see Figure 44 on page 70) opens all source ports
and permits a connection to port 9495 on the target.
70
The log file shown in Figure 46 indicates that it is the permissions set by
Rules 4 and 5 that permit the packets to be encrypted. Though the data that
is returned from the target is encrypted, the decrypting action was not entered
into the log.
Rules 2 and 4 can be improved by limiting the source port to the ephemeral
ports instead of opening all ports.
71
This command need not be issued from a command line, but can, of course,
be issued by clicking on an icon, from TEC, or by means of REXEC from the
SecuRemote client, along with many other ways.
For a successful connection to take place to the controller on VIKING, we had
to have the rules as shown in Figure 47.
Figure 47. SecuRemote Controller Started with the WRC Command - Rule Base
We found, in this scenario, that there was little complication caused by the
fact that the SecuRemote client must first issue a connection to a machine on
the internal network before communication takes place. For Remote Control
to operate, the endpoint service must be operational. As part of the endpoint
initialization process, an endpoint attempts to connect to its defined endpoint
gateway. In this case, the endpoint gateway is OSTMR. The problem,
however, is that this communication takes place when the service starts, that
is, at boot time. The SecuRemote application is not running since it only
starts at user logon; so, the user is not prompted for an ID or password, and
the LCF daemon remains in a login state and cannot get access to the
internal network. The status of an endpoint can be obtained by opening a web
browser and opening the IP address and the port of the endpoint.
We found that, in order to resolve this situation, we were forced to stop and
start the service on the endpoint after SecuRemote had started, and then we
were prompted for an ID and password. This action then establishes a
communication session to the endpoint gateway, which, in our case, also
happens to be the Remote Control server we will execute commands from.
This action can be seen in the first line of the log shown in Figure 48.
72
When the wrc command is executed, Rule 4 permits the Remote Control
server to send the command to start the controller, and Rule 3 permits
VIKING to establish a secure session to the target.
If the Remote Control server is the server you have specified to use in the wrc
command, and is not the gateway to which the endpoint on the SecuRemote
client is defined, then you will need to create an automated method of
creating a secure session to the Remote Control Server.
Figure 48. SecuRemote Controller Started with the WRC Command - Log
73
receive validation to connect to the TMR server when you start the Tivoli
Desktop. Since you are establishing a connection to the target from the
controller, SecuRemote permits access. Remember that the Remote Control
server sends a downcall instruction to the endpoint to start the controller, and
this is why you must have a validated ID and session to this machine before
the downcall will be successful.
74
6.1 Background
As the internet-centric business model becomes increasingly dominant
among corporations of all sizes, network administrators are faced with the
task of managing business-critical applications along with non-critical
applications so that they coexist. Or, when you connect your network to the
Internet, it is very important to make the most efficient use of the available
bandwidth. Under these situations, the bandwidth management may become
a critical issue.
To have sufficient bandwidth for application data being exchanged between
the head office and the branch office, a bandwidth management tool must
track and control the flow of communication.
This chapter explains the conditions where Floodgate-1 is useful. It further
explains the scenarios we tried in the labs and the installation procedure for
FloodGate-1.
We installed the FloodGate-1 tool from Check Point Software Technologies
Inc. (Redwood City, CA) in the labs, along with other applications which are
considered mission critical. The purpose was to see the effect of FloodGate-1
in the environment where the bandwidth utilization is almost 100%.
6.2 Requirements
The effective tool needs to address the following requirements:
Flexible Prioritization
Many times, prioritizing the communication is just not sufficient. For
example, you may want to specify higher priority for HTTP traffic than for
SMTP. The result can be that all the bandwidth resources get allocated to
HTTP and none to SMTP. We assume here that HTTP traffic has the
priority and is also occupying the entire bandwidth.
Minimum bandwidth
75
76
6.3 FloodGate-1
In order to experiment with the bandwidth management scenario in the lab,
we created the environment as described below.
There are two Token Ring LANs connected with a low bandwidth SLIP link
providing 38.4 Kbps.The connectivity is simple. We want to test the scenario
in which Remote Control is used across the SLIP link while HTTP and ftp
traffic is flowing across, and flood the available bandwidth. We install
FloodGate-1 on one of the nodes and configure FloodGate-1, build various
bandwidth policies, apply these bandwidth policies, and observe the traffic
flow across this slow link.
The following steps are involved in installing and configuring the FloodGate-1
tool on a node:
1. Load the software.
2. Configure the bandwidth policy which includes defining the network
objects used in the Rule Base.
3. Define the rule base where you classify the traffic by type of service
4. Define any proprietary services used in the network. We defined Remote
Control as the service. (The commonly used services are already defined
here as default.)
5. Define bandwidth policy; this is the set of rules for classifying connections
and allocating bandwidth among them.
6. Install the bandwidth policy.
7. Use the monitor tool to monitor the network and adjust the bandwidth
policy accordingly.
Bandwidth Management
77
78
Enter the license and the administrator ID and password in the following
popup windows.
Add the GIU clients. These are the nodes from where you can invoke the
FloodGate-1. In the next screen, add the nodes on which the FloodGate-1
module can be installed.
The setup is now complete.
6.4 Summary
During the installation steps, we discovered a minimum bandwidth
requirement for FloodGate-1 to work. Since we could not match the required
minimum bandwidth, we could not complete this investigation of the use of
Floodgate-1. We were not able to use the FloodGate-1 product in our
environment because Floodgate requires at lease a 56 Kbps link, and we only
had a 38.4 Kbps link.
Bandwidth Management
79
80
81
82
After this step, we were able to create the database tables that TEC requires.
The following script performs this task:
c:\usr\local\tivoli\bin\w32-ix86\TME\TEC\cr_tec_db.sh
The general recommendation is not to install the console, DBMS, and TEC
server on the same node because of performance constraints that may be
encountered under load. This configuration is also relatively impractical in a
production environment, but has served its purpose in our test environment.
Because we used a single node for all TEC components, we could perform
thorough TEC testing and even remove the TEC from our environment
without impacting the other tests that were being run.
83
The TEC Console was also installed on the same machine by performing the
standard Desktop -> Install -> Install Product... procedure.
After installation of TEC server and the TEC Console was complete, we
installed the TEC Adapter Configuration Facility (ACF) on the TMR server.
ACF must be installed to have the Application Configuration Profile (ACP)
type appear as an option in the list of possible policy types that can be
created when one creates a new policy in a policy manager. The ACF must
also be installed on the TEC server and to any managed nodes that act as
endpoint gateways to endpoints which will have the TEC Adapter installed.
The ACF does not need to be installed on the endpoints, since the binaries
and other configuration files are downloaded when the policy is sent to the
endpoints.
Though the documentation is not clear on this, the TEC NT event log adapter
only works on an endpoint. Any attempt to run any of the adapter binaries on
a managed node results in an attempt to load the endpoint file libraries, such
as libmrt.dll, for example. If you want events generated from a Windows NT
managed node, you must install an endpoint on the Windows NT managed
node.
When installing an endpoint on a managed node that is defined as an
endpoint gateway, the default listening ports of these services may conflict. In
Tivoli Framework version 3.6, both these services use port 9494 by default.
We modified the endpoints default listening port to be the same as the
default used in version 3.6.1. This port number is 9495 for the endpoint, and
the endpoint gateway continues to use port 9494.
84
Since the TEC NT event adapter resides on endpoints, we make this policy
manager a dataless one by executing:
wsetpm -d @ProfileManager:"TEC NT Profiles"
Once the profile manager is created within the specified policy region (in our
case the TEC36Region), from the open window of the profile manager, click
Create -> Profile... to create a new profile. A profile can be created using the
following command:
wcrtprf @ProfileManager:"TEC NT Adapter" ACP "NTnRC"
tecad_nt.conf
tecad_nt.fmt
tecad_nt.cds
tecad_nt.err
tecad_nt.exe
tecadnts.exe
7.3.1.1 TECAD_NT.CONF
The tecad_nt.conf file stores environment variables and connection settings
for the profile, as well as alert filters. When the policy is created or modified,
these changes are neither reflected in any file on the TEC server, nor on the
TMR server, but are stored in the TMR names database. The contents of this
file can be viewed using the following command:
wlsac -l "TEC policy for EP"
85
Commands such as wlsac and wsetac must be run from bash in order for
them to execute. We found that copying the files to new names with the
extension EXE allowed us to run the commands directly from a
command prompt.
7.3.1.2 TECAD_NT.FMT
The TEC NT Event Log adapter uses the tecad_nt.fmt file to determine how it
should categorize an event. An incoming event is mapped against the formats
specified in this file. When a match is found, the event is assigned the event
class against which the match was made, and then the various fields of
information from the event are mapped to TEC slots.
A slot is an attribute that is, in this context, a set of fields that define an event
that consists of an attribute name and an attribute description.
We added the lines shown in Figure 53 on page 87 to the end of the existing
TECAD_NT.FMT file using a standard text file editor.
86
We created one unique event class for each of the events that Remote
Control logs. At first, it was difficult to determine what mask to use, but we
were able to see the format of the information using tecad_nt.exe in debug
mode. Please see TECAD_NT.EXE and TECADNTS.EXE on page 88 for
the use of tecad_nt.exe.
Each of these events is uniquely identified by the event ID number which
follows the string Remote Control. Originally, we assigned the remaining
string, using %s, to msg, but then we identified a need to have a slot defined
for the IP address of the target. With the formats as above, the IP address of
the target was assigned to the target slot, and we built a customized message
for each event which we then assigned to slot msg.
7.3.1.3 TECAD_NT.CDS
The tecad_nt.cds file is the NT adapter Class Definition Statement file.
Though this file does contain information specific to the event class
configuration, we did not modify this file at all, since it is rebuilt each time a
policy is distributed to an endpoint. The tecad_nt.cds file is built from
tecad_nt.fmt with the command:
nt_gencds "${AC_TARGDIR}/tecad_nt.fmt" > "${AC_TARGDIR}/tecad_nt.cds
87
This command is executed on each subscriber after the profile has been
distributed. You see this command in the after file distribution entry panel
when you select the Actions radio button on the Edit Adapter Profile panel.
7.3.1.4 TECAD_NT.ERR
The tecad-nt.err file contains error logging and tracing options. We did not
find any need to view or modify this file while performing our tests.
7.3.1.5 TECAD_NT.EXE and TECADNTS.EXE
The two executables that make up the adapter perform the same function,
that is, locate entries in the NT event viewer and then act upon them based
on the information given. The executables are, however, used in two different
ways. The first, tecadnts.exe, is the executable run by the TEC Event Adapter
service on Windows NT. The other executable, tecad_nt.exe, can be run from
the command line. Ideally, the latter executable is used in problem
determination situations. If you decide to make use of tecad_nt.exe, ensure
that the service has stopped running. When the profile is distributed to an
endpoint, the TEC Event Adapter Service is automatically configured and
started once the files have been copied into place.
We encountered a problem with tecadnts.exe during our tests. The service
would abend as soon as it encountered an event which it had to forward. We
obtained the latest release of these executables from the Tivoli support page
at http://www.support.tivoli.com. We downloaded TEC service pack 13
which contains only refreshes for both of these executables. We copied them
to C:\tivoli\bin\lcf_bundle\bin\w32-ix86\tme\TEC\adapters\bin on the endpoint
gateway. The next time we distributed the profile to the endpoints, the new
executable was put in place, and the service remained active and forwarded
TEC.
Note
If you find that events are being forwarded, make certain that the default
distribution setting for the profile is Make each subscribers profile an
EXACT COPY of this profile.
The ACP profile is solely responsible for detecting and forwarding events to
the TEC server. How these alerts are handled and interpreted by TEC is
managed by a rule base.
88
89
TEC_CLASS :
NT_RemoteControl_Start ISA NT_Base
DEFINES {
target: STRING;
severity: default = HARMLESS;
};
END
TEC_CLASS :
NT_RemoteControl_End ISA NT_Base
DEFINES {
target: STRING;
severity: default = HARMLESS;
};
END
TEC_CLASS :
NT_RemoteControl_Fail ISA NT_Base
DEFINES {
target: STRING;
severity: default = WARNING;
};
END
Now, most of the ground work is done in preparing the changes. The next
step is to activate all these modifications by means of a rule base.
90
This command creates a rule base called Remote Control and places it in the
directory C:\RC_RULES. A new icon is created in the rule base folder. If the
directory does not exist, it is automatically created along with three
subdirectories. In our case the directories were:
C:\RC_Rules\TEC_CLASSES
C:\RC_Rules\TEC_RULES
C:\RC_Rules\TEC_TEMPLATES
Now that the rule base has been defined, we need to define event classes to
the rule base. In our environment, we wanted TEC to be aware of the NT
alerts as well as the alerts coming from Remote Control. The inclusion of
these event classes into the rule base is done by importing the BAROC files
in which these event classes are defined, namely, TECAD_NT.BAROC and
TECRC.BAROC. Refer to 7.3.2, The Event Classes and BAROC Files on
page 89 to see how we created this file. We imported these files using the
commands:
wimprbclass -a tec.baroc montague:c:/development/tecad_nt.baroc "Remote
Control"
wimprbclass -a tecad_nt.baroc montague:c:/development/tecrc.baroc
"Remote Control"
Note
The path parameter uses forward slashes (/) and not backslashes (\) if
you run this from the NT Command prompt. Using forward slashes in
the path causes the command to fail with error:
chdir failed with return code 22:invalid argument
This importing can also be accessed from the GUI by right-clicking on the
Rule Base icon. From the GUI, one can clearly see that classes root.baroc
and tec.baroc are already in place before the remaining two are imported. It
is best to import tecad_nt.baroc after tec.baroc, as some of the classes
defined in tec.baroc are parents to those used in tecad_nt.baroc. This
sequencing is done by using the -a switch on the command line.
After completing the import, our directory, C:\RC_Rules\TEC_CLASSES, contained
the following files:
.event_sum_slots
.load_classes
.task_slots
root.baroc
tec.baroc
91
tecad_nt.baroc
tecRC.baroc
The next step is to run a compile either from the icon menu, or with the
command:
C:\usr\local\Tivoli\bin\w32-ix86\bin\wcomprules "Remote Control"
The -u switch forces the rule to load and become immediately active, as
opposed to waiting until the event server is restarted before becoming active.
However, this does not apply to changes to the event classes. Although the
output of the wlsrbclass command at this point will show that the class
NT_RemoteControl_Event exists, the class is not active until the event server
is stopped and started. The command wstopesvr stops the event server and
wstartsrv starts the event server.
We occasionally encountered a problem when loading a rule base. This
particular problem is a probable defect in the version of TEC that we have in
our test environment. When performing a load, it would occasionally fail with
the message:
rmdir failed with code 41:Directory not empty
You must erase the working and current directories of the rule base. In our
environment, we had to remove the following directories if they existed:
\var\spool\tivoli\montague.db\TEC\rb_dir
\var\spool\tivoli\montague.db\TEC\rb_dir.bck
\var\spool\tivoli\montague.db\TEC\rb_dir.tmp
Once the rule base has loaded successfully, the icon should change to
indicate that it is now the active rule base. Refer to Figure 55 on page 93
92
93
Now, open the console view and the Event Groups window should look
similar to the one in Figure 56.
94
We created this script file using an ordinary text editor and saved it in
C:\RCTools on the TMR server. We used this directory to consolidate all our
scripts in one storage repository.
We then created the task using:
wcrttask -t BounceRC -l "RC Tools" -i w32-ix86 ostmr
c:\rctools\bouncerc.cmd -r senior
and we noted that the service had then started. One point we overlooked
when creating the rules was that the target slot returned the IP address of the
target and not the machine name of the target that the connection was made
to. This oversight posed a problem as to how we were to convert this IP
address to a machine name. We were not able to locate any objcalls that
would help us in this, and so, we were forced to use a far less elegant
solution which involved two tasks.
Now, with the modification, TEC executes task BounceIP.sh (See Figure 58
on page 96) on the TMR Server and passes the IP address of the target to
the task. This task, in turn, resolves the IP address and then executes the
BounceRC.cmd task on the correct endpoint. This solution is clumsy and
makes a few assumptions:
The hostname of the endpoint is the same as that of the machine name.
The hostname of the machine, as specified in the hosts file, matches the
case of the machine name as defined to Tivoli. This can be easily
remedied by modifying the hosts file which is located in
C:\winnt\system32\drivers\etc, but is probably not feasible in a large
environment.
95
You could also investigate the feasibility of using nslookup to retrieve the
information if you have a DNS in your environment.
#!/bin/sh
# set -x
ipaddr=$1
target=ping -n 1 -a $ipaddr | grep "Pinging" | cut -f 2 -d " "
wruntask -t BounceRC -l "RC Tools" -h $target -E
echo $target
Now, we have a task that TEC can execute upon receiving an event. We
proceeded to create a simple rule which will execute this task when Remote
Control fails to start on a node.
The rule that we used in the end is listed in Figure 59 on page 97 and was
created using Notepad on Windows NT. We saved this rule in our
development directory, in a file called BncRC_on_Fail.rls.
Note
When creating rules on NT, always make sure that there is a Carriage
Return/Line-Feed at the end of the last line of your rule. This is easily
achieved by pressing the Enter key at the end of the very last line of the
file. If this was not done, we encountered one of two errors during compile:
Unexpected end of file
Unexpected character
It was easier for us to manage the rules from the command line as we used
batch scripts to unload, delete, import, compile and load rules. You must
import the new rule into the rule base, and this can be done using the
command:
wimprbrules c:/development/BncRC_on_Fail.rls "Remote Control"
Before importing a rule that already exists, it is a good idea to delete the rule
in case conflicts occur. So, in the above case, before performing the import,
execute:
wdelrbrules BncRC_on_Fail.rls "Remote Control"
After importing the new rule, it needs to be compiled, and we do this using the
command:
96
Finally, the Rule Base must be loaded and made active, and the command to
do this is:
wloadrb -u "Remote Control"
Perhaps now you will understand why we put all the above commands in a
script file. In our environment, and with bad typists, you can find yourself
repeating the above process numerous times in an hour.
The rule which is responsible for restarting the Remote Control Service starts
by obtaining the slot target and assigning this value to the variable _target.
With the exec_task action, task BounceIP is started and passed the
arguments stored in the second parameter. Each occurrence of the %s
variable is replaced by the variables listed in the third parameter. In
BncRC_on_Fail.sh, the value of _target is passed as an argument to the -a
switch when the task is run.
The second action performed by the rule is to set the status of the previous
event to CLOSED.
97
session to the server. This is a critical event, but once we know that someone
at the help desk has looked into the problem, we are happy to drop the
severity.
First, we create a script that will allow us to establish remote control sessions
between machines. We created this script using a text editor and saved it as
C:\rctools\StartRCSess.cmd. You can see the listing of the command in
Figure 60.
call c:\winnt\system32\drivers\etc\tivoli\setup_env.cmd
wrc RmtCtrl controlm @Endpoint:%2 @Endpoint:%1 -P:Y -G:0 -T:Y.
The command used to start the session is wrc and is located on any of the
Remote Control servers in your TMR. Run this command on the Remote
Control server and pass the names of the machines you wish to connect to it.
The first parameter specifies the type of session to establish. In this case, we
are establishing Remote Control sessions that start in monitor mode. The
second parameter is the fully distinguished name of the Remote Control
controller, and this is followed by the name of the Remote Control target. The
P switch specifies whether to proceed with the establishment of the session
after the grace period has expired, and the length of the grace period is
controlled by the G switch. The last switch, T, allows the user to alter the state
of the session if it is set to Y.
The values for the names of the target and controller are passed to the
program as arguments, and are designated in the script by %1 and %2
respectively.
We created a Tivoli task to run this script with the command:
wcrttask -t "Start Session" -l "RC Tools" -i w32-ix86 ostmr
c:\rctools\StartRCSess.cmd -r senior
You can see in this command that the task executes on OSTMR, our TMR
server, and passes the names of the target and controller as two separate
arguments. This task established a remote control session between
MONTAGUE and OS1.
98
The final step is to create the rule, import it into the rule base, and compile
and load the rule base. These steps are covered in Initiating an Event on a
Remote Control Failure on page 94.
The rule that we used is listed in Figure 61.
This rule is only activated if both of the following conditions are met:
The machine which sent the alert is one of those specified in the list.
The drive which is full is I:.
This rule then executes two actions. First, the severity of the event is set to
Critical. Remember that events that do not meet the criteria will still be
viewable in the TEC console, but the requirement is that only these events
are set to critical. Second, a remote control session is established from the
controller at MONTAGUE to the client which has reported the problem.
99
100
3.6-RCL-0003
101
Note
102
103
4. Refer to Figure 62 on page 104 and fill in the three fields on the panel,
where:
Remote Control Server is the name of the Remote Control tool (icon) to
be launched.
Controller is the hostname of the Remote Control controller for this
Remote Control session and should be the hostname of this
workstation.
Select the correct workstation type of the Controller from the list using
radio buttons.
Target is the hostname of the intended target for this Remote Control
session.
Select the correct workstation type of the Target from the list using the
radio buttons.
104
If this is your attempt to initiate Remote Control after starting the Web
browser, you will see a pop-up panel at this point requesting user ID and
Password. You will need to enter a valid user ID and Password that has
the correct Tivoli authority and roles in the appropriate policy regions to
successfully complete the Remote Control session. For the test
scenario, the Administrator user ID and password were used.
6. Refer to Figure 63 on page 105 and select the Action from the drop down
list, where Action is one of the following:
monitor
controla
controlm
105
reboot
7. Click on the >> button to continue.
8. Refer to Figure 64 on page 106, and select the desired options, then click
on the Start button. If you have selected the Default for any option, the
option takes the value set in the governing policy method for the instance
of the Remote Control Tool that was entered into the Remote Control
Server field on the first panel. Also, if any method in the governing policy
object has been set with -locked, that option cannot be changed, and that
option uses the setting in the policy object method.
106
When the Remote Control session is terminated, or if it did not start correctly,
the result, or error message, will be displayed on the Web Access panel.
107
Note
If this is the first attempt to initiate Remote Control after starting the
browser, you will see a pop-up panel at this point requesting UserID and
Password. You will need to enter a valid UserID and Password that has
the correct Tivoli authority and roles in the appropriate policy regions in
order to successfully complete the Remote Control session. For our
scenario, the Administrator user ID and password were used.
108
7. Refer to Figure 63 on page 105 and select the Action from the drop down
list, where Action is one of the following:
monitor
controla
controlm
reboot
to read
# @TARGETS = wgetallinst ManagedNode;
# foreach $TARGET (@TARGETS) {
#
print ("<OPTION> $TARGET# ManagedNode");
# {
109
After this change, the list of targets will include only endpoints and PC
Managed nodes.
110
This chapter pertains to Remote Control Releases 3.6 and 3.6.1 only.
Future releases of Remote Control are planned to support caching for
automated installations on endpoints.
These binaries and sample profiles can only be used to install the
controller or target on endpoints. They are not valid for installation on other
types of clients.
111
.
.
.
\registry\machine\SYSTEM\CurrentControlSet\Services\TGrab
ErrorControl = REG_DWORD 0
Start = REG_DWORD 1
Type = REG_DWORD 1
\registry\machine\SOFTWARE\Tivoli
\registry\machine\SOFTWARE\Tivoli\Remote Control Target
Logging = REG_DWORD 0
Trace Length = REG_DWORD 0
Target = REG_DWORD 1
Build = REG_DWORD 00360001
Version = REG_SZ 3.6
If you are using Tivoli Software Distribution to install only the Remote Control
Controller to a Windows NT endpoint, edit
<drive:\path>\SDPACK\WINNT\CTL\Regilog.ini and add
\registry\machine\SOFTWARE\Tivoli to the top of the file, then add the
RCPath statement as the last line. The Remote Control Controller Regilog.ini
should look similar to Figure 67 on page 112.
\registry\machine\SOFTWARE\Tivoli
\registry\machine\SOFTWARE\Tivoli\Remote Control Controller
Logging = REG_DWORD 0
Trace Length = REG_DWORD 0
Controller = REG_DWORD 1
Build = REG_DWORD 00360001
Version = REG_SZ 3.6
Figure 67. Add Registry Key to REGILOG.INI - Remote Control Controller Only
112
Note
You have to create a profile for each type of package that you want to
install.
2. Select the Properties... option in the profile menu. The File Package
Properties dialog is displayed.
3. Select the File Package -> Import option to import a sample profile.
The following profiles are included in the /SDPACK/PROFILES directory of
the product CD-ROM and can be used as samples for the installation:
OS2CTL.PRF
OS2TGT.PRF
WIN31TGT.PRF
WIN95CTL.PRF
WIN95TGT.PRF
WINNTCTL.PRF
WINNTTGT.PRF
4. Select one of the sample profiles and select the Import & Close button.
5. If you are asked to specify a source host, select the host where the files to
be distributed are stored.
6. In the Source Directories & Files field, specify the following path:
x:/SDPACK/operating_system/component/*
where:
x
operating_system
113
WIN31
WIN95
WINNT
component
Note
114
115
Result=1
[SdStartCopy-0]
Result=1
[SdFinishReboot-0]
Result=1
BootOption=0
Note
116
For our scenario, we copied the Remote Control CD-ROM images to the TMR
server running Windows NT 4.0. Two drive shares were defined on the TMR
server, one was ostmr\36 which pointed to
<drive>:\Install\RCimages\lcf4win\cdrom\west\disk1, and the other was
ostmr\rspfiles, which pointed to <drive>:\Install\RCimages\lcf4win\respfiles.
The Remote Control target was installed on the Windows NT endpoint in
c:\Tivoli\Pcremote.
The InstallShield setup.exe options used were:
-s
-SMS
-f1<path\ResponseFile>
-f2<path\LogFile>
Success
General error
Invalid Mode
Required data not found in the Setup.iss file
117
-4
-5
-6
-7
-8
-9
-10
-11
-12
-51
-52
-53
ENGLISH
FRENCH
JAPANESE
PORTUGUESE
118
where:
<drive:\path>
/A:I
/L1:<drive:\path> The drive and path to the install error log file.
/O:
/R:<RspFile>
The drive, path and file name of the specific response file.
/T:<drive:\path>
The drive and path where the product files will be installed
on the target.
/X
119
120
Appendix A. GetNewEPs.sh
The GetNewEPs.sh script performs this task by building a temporary list of all
the defined endpoints using the wgetallinst command, and then it compares
this list against the list of Remote Control targets in C:\RCTOOLS. The script
extracts the names of the machines that do not exist in the temporary list, but
do exist in the C:\RCTOOLS list. This task simultaneously removes machines
which are no longer defined in the TMR from the list of Remote Control
Targets, while adding any new RC Targets to the list.
#!/bin/sh
# Create list of all endpoints with Remote Control Target
# installed to be used by RC policy method rc_def_targets
rm -f $WLookList
rm -f $TL
rm -f $TL1
rm -f $GetRCs
...done"
121
# If a list of targets exists, this checks for new possible targets and adds
them
if [ -f $RCList ]
then
echo "Obtaining list of new EPs"
LIST=cat $WLookList
for i in $LIST # check for machines in WLookList and not RCList
do
grep -ix "$i" $RCList > /dev/null
RC=$?
if [ $RC -ne 0 ]
then
echo $i >> $TL
fi
done
LIST=cat $RCList
echo "Building list of valid EPs in RC list"
for i in $LIST
do
then
echo $l >> $TL1
fi
done
122
if [ -f $TL1 ]
then
echo "Refreshing $RCList from $TL1" # Debug line
cat $TL1 > $RCList
# refresh RCList
fi
else
cat $WLookList > $TL
fi
LIST=cat $TL
rtcmd=wruntask -t "Is RC Installed" -l "RC Tools" -m 30 -M parallel -o 15
for i in $LIST
do
rtcmd="$rtcmd -h $i"
done
cat $TL
# DEBUG
GetNewEPs.sh
123
LIST=cat $TL
ctr=0
for i in $LIST
do
if [ $ctr -ne 0 ]
then
echo "Restarting the EP Gateway"
wgateway ostmr restart
else
echo "No EP Gateway restart required"
fi
# Sort RCList
124
Appendix B. SETUP.ISS
There are sample InstallShield response files on the Remote Control product
CD under the \lcf4win\rspfiles directory. There is a separate setup.iss for
each of the following supported platforms. Below is a SETUP.ISS modified for
installation of only the Remote Control target on a Windows NT 4.0 endpoint.
[InstallShield Silent]
Version=v5.00.000
File=Response File
[Application]
Name=Remote Control Target
Version=3.6
Company=Tivoli
[DlgOrder]
Dlg0=SdWelcome-0
Count=5
Dlg1=SdComponentDialog2-0
Dlg2=SdAskDestPath-0
Dlg3=SdStartCopy-0
Dlg4=SdFinishReboot-0
[SdWelcome-0] Result=1
[SdComponentDialog2-0]
Remote Control Target (Windows NT 4.0)-type=string
Remote Control Target (Windows NT 4.0)-count=12
Remote Control Target (Windows NT 4.0)-0=Remote Control Target (Windows NT
4.0)\Program
Remote Control Target (Windows NT 4.0)-1=Remote Control Target (Windows NT
4.0)\Help
Remote Control Target (Windows NT 4.0)-2=Remote Control Target (Windows NT
4.0)\Libraries
125
126
127
AS/400
BookManager
DB2
NetView
OS/390
RS/6000
SP
VisualAge
400
128
Special Notices
129
130
Developing Plus Modules for Tivoli with the TME 10 Integration Toolkit,
SG24-2007
Getting Started with TME 10 User Administration, SG24-2015
Managing Access from Desktop to Datacenter: Introducing TME 10
Security Management, SG24-2021
TME 10 Framework Version 3.2: An Introduction to the Lightweight Client
Framework, SG24-2025
Implementing TME 10 in High Availability Environments, SG24-2032
Tivoli Enterprise Internals and Problem Determination, SG24-2034
New Features in Tivoli Software Distribution 3.6, SG24-2045
Integrating TME 10 on the RS/6000 SP, SG24-2071
Managing a Notes Environment with TME 10 Module for Domino Version
1.5, SG24-2104
A First Look at TME 10 Distributed Monitoring 3.5, SG24-2112
Using the VisualAge for Smalltalk Tivoli Connection to Create a
Tivoli-Manageable Application, SG24-2114
TME 10 Deployment Cookbook: Inventory and Company, SG24-2120
An Industry Around the Tivoli Framework: Examples From the 10/Plus
Association, SG24-2122
TME 10 Inventory 3.2: New Features and Database Support, SG24-2135
Measuring Lotus Notes Response Times with Tivoli's ARM Agents,
SG24-4787
Examples of Using TME 10 NetView for AIX V5 and TME 10 NetView for
Windows NT, SG24-4898
TME 10 Global Enterprise Manager Event/Automation and User
Administration, SG24-4921
131
CD-ROM Title
System/390 Redbooks Collection
Networking and Systems Management Redbooks Collection
Transaction Processing and Data Management Redbook
Lotus Redbooks Collection
Tivoli Redbooks Collection
132
Subscription
Number
SBOF-7201
SBOF-7370
SBOF-7240
SBOF-6899
SBOF-6898
Collection Kit
Number
SK2T-2177
SK2T-6022
SK2T-8038
SK2T-8039
SK2T-8044
CD-ROM Title
AS/400 Redbooks Collection
RS/6000 Redbooks Collection (HTML, BkMgr)
RS/6000 Redbooks Collection (PostScript)
RS/6000 Redbooks Collection (PDF Format)
Application Development Redbooks Collection
Subscription
Number
SBOF-7270
SBOF-7230
SBOF-7205
SBOF-8700
SBOF-7290
Collection Kit
Number
SK2T-2849
SK2T-8040
SK2T-8041
SK2T-8043
SK2T-8037
Related Publications
133
The Floodgate-1 User Guide describes the Check Point Floodgate-1 products
and consists of the following product documentation, which is available from
Check Point Software Technologies, Inc.:
134
To register for information on workshops, residencies, and redbooks, type the following command:
TOOLS SENDTO WTSCPOK TOOLS ZDISK GET ITSOREGI 1998
135
IBMMAIL
usib6fpl at ibmmail
caibmbkz at ibmmail
dkibmbsh at ibmmail
Internet
usib6fpl@ibmmail.com
lmannix@vnet.ibm.com
bookshop@dk.ibm.com
Telephone Orders
United States (toll free)
Canada (toll free)
1-800-879-2755
1-800-IBM-4YOU
IBM Publications
144-4th Avenue, S.W.
Calgary, Alberta T2P 3N5
Canada
1-800-445-9269
1-800-267-4455
(+45) 48 14 2207
1-800-IBM-4FAX (United States) or (+1) 408 256 5422 (Outside USA) ask for:
Index # 4421 Abstracts of new redbooks
Index # 4422 IBM redbooks
Index # 4420 Redbooks for last six months
On the World Wide Web
Redbooks Web Site
IBM Direct Publications Catalog
http://www.redbooks.ibm.com
http://www.elink.ibmlink.ibm.com/pbl/pbl
Redpieces
For information so current it is still in the process of being written, look at "Redpieces" on the
Redbooks Web Site (http://www.redbooks.ibm.com/redpieces.html). Redpieces are redbooks in
progress; not all redbooks become redpieces, and sometimes just a few chapters will be published
this way. The intent is to get the information out much quicker than the formal publishing process
allows.
136
First name
Order Number
Quantity
Last name
Company
Address
City
Postal code
Country
Telephone number
Telefax number
VAT number
Card issued to
Signature
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not
available in all countries. Signature mandatory for credit card payment.
137
138
List of Abbreviations
ACF
TEC Adapter
Configuration Facility
ACP
Application
Configuration Profile
EP
Endpoint
HTML
HyperText Markup
Language
HTTP
HyperText Transport
Protocol
IBM
International Business
Machines Corporation
IOM
Inter-Object Messaging
IT
Information Technology
ITSO
International Technical
Support Organization
LCF
Lightweight Client
Framework (now called
TMA)
ORB
SMB
TMA
Tivoli Management
Agent
TMA
Tivoli Management
Architecture
TME
Tivoli Management
Environment
TMR
Tivoli Management
Region
RC
URL
Uniform Resource
Locator
VPN
139
140
Index
Symbols
$BINDIR 102
%BINDIR% 102
%s variable 97
_target 97
Numerics
2.1.1-RCL-0002 16, 23
3.6-RCL-0002 16, 23, 101
3.6-RCL-0003 101
38.4 Kbps 77
56 Kbps 79
A
abbreviations 139
absolute priorities 12
access
network 9
remote
secure 11
access control
network 35
accounting information 9
ACF
TEC Adapter Configuration Facility 84
ACK
TCP acknowledgment scheme 76
ACP profile 88
acronyms 139
ActiveX 9
address
IP 9, 39, 46, 72
dynamic 11
addressing schemes 9
agent
Tivoli Management Agent 37
alert 65
allocation
network 12
applets 9
attacks
network 9
audit trail 81
authentication 59
authentication scheme 62
authorization roles 2
authrc.exe 101
availability
high 9
B
bandwidth
limited 11
bandwidth allocation 12
bandwidth management 12, 75, 76
bandwidth management policy 12
bandwidth policy 77
BAROC 89
bash 6, 27, 28
BncRC_on_Fail.rls 96
BounceIP.sh 95
BounceRC.CMD 94
bulk data transfer 37, 51
C
CA
Entrust Certificate Authorities 11
card
network interface 45
case sensitive 63
certificates
digital 11
Check Point Software Technologies 9
class
event 89, 93
client
NetWare 26
UNIX 16
communications
dial-up 11
Inter-ORB 36, 51
Inter-TMR 37
IOM 51
compliance 48
congestion
network 11, 12
connectionless protocol 76
considerations
performance 42
controla 105
controller
141
D
daemon
HTTP 101
LCF 72
LCF gateway 36
TMA (LCF) 36
data link 45
data transfer
bulk 37, 51
database profile manager 84
datagram packet
NetBIOS 64
dataless profile manager 84
decryption 64
default policy 1
default policy method 2, 5
default policy object 5
default rule base 90
DefinableTargetList 15, 17
Desktop
Tivoli 14, 51, 73
Desktop Install Product 111
device
NAT 40
dial-up communications 11
digital certificates
X.509 11
digital signatures 11
direct requests 63
directory
pcremote 103
diskette 118
Dispatcher
Object 36
DNS server
proxy 40
DOS batch script 28
down-call 74
dynamic IP addressing 11
dynamic list 16
dynamic lists 13
142
E
encryption 11, 59, 64
IP-layer 11
encrytion scheme
FireWall-1 59
endpoint 17, 22, 26, 36
OS/2 119
endpoint ephemeral port 49
Endpoint Name list 22
engine
Intelligent Queuing 77
enterprise LAN 103
enterprise networking 9
Enterprise Security Management 9
Entrust Certificate Authorities (CA) 11
EP gateway 50
ephemeral 37, 39
endpoint port 49
ephemeral port 71
EQNRCMAI.EXE 27
error log 88
establishment
session 66
Event Adapter
TEC 88
event class 89, 93
event group 93
Event Log 82
events 84
standard 90
exposure
port 57
external
customer site 49
F
feedback mechanism 12
file
log 65, 117
response 117
FilteredList 15, 18, 20
firewall 35, 39, 53, 55, 63
FireWall Module 45
firewall placement 42
FireWall-1 9, 35, 59
FireWall-1 encrytion scheme 59
FireWall-1 gateway 11
FireWall-1 Rule Base 11
fixed keys 59
FloodGate-1 9, 12
FQHN
Fully Qualified Host Names 40
Framework
Tivoli 35
ftp.tivoli.com 117
Fully Qualified Host Names (FQHN) 40
fwenc.exe 60
FWZ 59, 62
G
gateway 36
endpoint 50
FireWall-1 11
network 45
Remote Control 1, 40, 41
GetNewEPs.sh 28
GetRCs.sh 27
grace period 3, 98
group
event 93
notice 2
interconnected TMRs 16
interface
Web 55
internal
outsourser 49
internal network 68, 72
Internet 9, 10, 11, 35, 39, 75
Internet service 10, 11
Inter-Object Messaging (IOM) 37
inter-ORB communications 36, 51
inter-TMR communications 37
intranet 11
Inventory
Tivoli 13, 24, 33, 37
IOM
Inter-Object Messaging 37
IOM communications 51
IP address 9, 39, 46, 72
dynamic 11
ipconfig 46
IP-layer encryption 11
IPSec
Manual 59
IPX/SPX 36
ISAKMP/OAKLEY 59
H
help desk 3, 69, 75, 103
high availability 9
high source port 49
HKEY_LOCAL_MACHINE 60, 81
HTTP daemon 101
HTTP session 66, 68
I
IKE key 11
information
accounting 9
port 38
initial logon 49
Inspection
Stateful 10, 77
Install Product
Tivoli Desktop 111
installation
silent 117
unattended 119
InstallShield 111, 114
Intelligent Queuing engine 77
J
Java 9
K
Kbps
38.4 77
56 79
kernel
operating system 45
key
fixed 59
IKE 11
public 11
key management 59
L
LAN
enterprise 103
layer
network 45
LCF daemon 72
143
M
managed node 17, 22, 26, 36
management
bandwidth 12, 75, 76
key 59
management policy
bandwidth 12
Manual IPSec 59
mapping
NAT 40
MDIST repeater 44
mechanism
feedback 12
method
policy 3, 6, 13, 24, 81, 106
default 2, 5
MKRCDSK.BAT 118
mobile users 10
model
security 1
Module
FireWall 45
monitor 6, 55, 105
144
N
NAT
Network Address Translation 39
NAT device 40
NAT mappings 40
nbname 66, 69
nbsession 66, 69
nbsession service 65
net use 65, 67
NetBIOS 64
NetBIOS datagram packets 64
NetBIOS session 69
net-space 35
NetWare 36
NetWare client 26
NetWare managed node 36
network
internal 68, 72
private 35, 39
secure 59
slow 55
network access 9
network access control 35
network address translation (NAT) 39
network attacks 9
network congestion 11, 12
network gateway 45
network interface card 45
network layer 45
network link
slow 55
Network Object Manager 46
network security 9, 35
network stacks
TCP/IP 10
network users 9
networking
enterprise 9
networks
public 9
notice group 2
nslookup 96
number
port 46
O
OAKLEY 59
object
policy
default 5
Remote Control 14
Object Dispatcher 36
object identification (OID) 40
Object Request Brokers (ORBs) 36
odadmin 37, 39
odadmin set_port_range 39
OID
object identification 40
OPSEC 10
Open Platform for Secure Enterprise Connectivity
(OPSEC) 10
operating system kernel 45
options
trace 88
options.cgi 103
Oracle 7.3 83
ORB
Object Request Broker 36
OS/2 endpoint 119
outsourser site (Internal) 49
P
packet
datagram
NetBIOS 64
UDP 37, 49, 69
patches 101
PC managed node 22, 26, 36
pcremote directory 103
pcremote.cgi 103
pcremote.html 103
performance considerations 42
period
grace 3, 98
PKCS
Public Key Cryptography Standard 11
PKI 11
placement
firewall 42
policy
bandwidth 77
default 1
security 35, 46
policy method 3, 6, 13, 24, 81, 106
default 2, 5
policy object
default 5
Remote Control 14
policy region 22
port
ephemeral 71
high source 49
port 2501 38, 55, 57, 70
port 513 39
port 94 37
port 9494 37, 49, 51, 84
port 9495 37, 49, 70, 84
port exposure 57
port information 38
port number 46
port specific information 38
ports 30,000-35,000 51
pre-release version 82
priorities
absolute 12
weighted 12
private network 35, 39
secure 59
process
systems management 59
profile
ACP 88
profile manager
database 84
dataless 84
protocol
connectionless 76
protocol stack 45
TCP/IP 59
proxy 10
proxy DNS server 40
public key 11
Public Key Cryptography Standard (PKCS) 11
public networks 9
R
rc_def_alt_t 7
rc_def_checkinterp 13, 16
rc_def_command 6
rc_def_define 13, 15, 22, 23
rc_def_filter 18
rc_def_filter_mode 13, 19, 20, 21
rc_def_grace_time 7
rc_def_polfilter 20, 21
145
rc_def_polfilter_mode 13, 19
rc_def_ports 42
rc_def_targets 13, 17, 19, 23, 25, 33
rc_def_timeout_op 7
rc_def_uncheckedlist 13, 22, 23, 25, 26, 33
rcinst.bat 116
reboot 106
receiver window size 76
REG_DWORD 81
regilog.ini 111
region
policy 22
remote access
secure 11
Remote Control
Web Access 101
Remote Control controller 1, 2, 7, 40, 41, 70
Remote Control gateway 1, 40, 41
Remote Control policy object 14
Remote Control server 1, 14, 40
Remote Control service 36
Remote Control target 1, 14, 27, 32, 40, 41
Remote Control tool 14
Remote Control user 14
remote execution facility 39
remote_boot 2
remote_control 2
remote_monitor 2
remote_probe 2
RemoteControl 4
RemoteControl_PDO 14
repeater
MDIST 44
requests
direct 63
response file 117
Result Code 117
Retransmission Detection Early Drop 77
rexec 39
risk
security 1
roles 31
authorization 2
root.baroc 91
round trip time (RTT) 76
route
virtual 39
RTT
round trip time 76
146
S
scheme
addressing 9
authrntication 62
encrytion
FireWall-1 59
script
DOS 28
logon 116, 117
secure private network 59
secure remote access 11
SecuRemote 9, 10, 59
security
network 9, 35
security model 1
security policy 35, 46
security risk 1
security services 9
select_gateway_policy 40
server
proxy DNS 40
Remote Control 1, 14, 40
TMR 13, 24, 28
service
Internet 10, 11
nbsession 65
Remote Control 36
TEC Event Adapter 88
Tivoli Remote Control 94
Service Manager 46
service pack
TEC 13 88
services
security 9
session
HTTP 66, 68
NetBIOS 69
type 98
session establishment 66
set_port_range
odadmin 39
setup.iss 115
setup.log 117
signatures
digital 11
silent installation 117
Simple Key-Management for Internet Protocols
(SKIP) 59
SIS
Tivoli Software installation Services 111
SKIP (Simple Key-Management for Internet Protocols) 59
SLIP link 77
slow network links 55
SMB 69
SMTP 75
Software Distribution
Tivoli 37
Software Installation Services (SIS) 111
stack
protocol 45
TCP/IP 59
TCP/IP 10
standard events 90
StartRCSess.cmd 98
startsession.cgi 103
State Change on Target 3
Stateful Inspection 10, 77
static lists 13, 24
STDOUT 27
Sun Microsystems 59
system administrator 103
systems management process 59
T
target
Remote Control 1, 14, 27, 32, 40, 41
state change 3
target list 15
task
Tivoli 26
task library
Tivoli 30
taskbar
Windows NT 60
tasks 13
TCP acknowledgment (ACK) 76
TCP receiver window size 76
TCP/IP network stacks 10
U
UDP 49
UDP packet 37, 69
unattended installation 119
UncheckedList 15, 16, 22, 23
UNIX clients 16
up-call 69
URL 103
users
mobile 10
network 9
Remote Control 14
147
V
validation 62
VALIDRC 27, 32
variable
$BINDIR 102
%BINDIR% 102
%s 97
Virtual Private Networks (VPNs) 10
virtual route 39
VPN 10
Virtual Private Network 10
VPN-1 9
wsetpr 7
wstartsrv 92
wstopesvr 92
X
X.509 digital certificates 11
W
wcomprules 92, 97
wcrtjob 31
wcrtpol 5, 14
wcrtprf 85
wcrtprfmgr 84
wcrtrb 90
wcrtrim 83
wcrttask 31, 98
wdel 83
wdelrbrules 96
Web Access for Remote Control 101
Web interface 55
webrc.zip 101
WEBRC_install.sh 103
weighted priorities 12
wgetallinst 22, 23, 28
wgetpolm 4, 14
wildcard 93
wimprbclass 91
wimprbrules 96
window size
receiver
TCP 76
Windows NT Event Log 82
Windows NT taskbar 60
wloadrb 97
wlsac 85
wlspolm 4
wlsrbclass 92
wputpolm 6, 14
wrc 54, 71, 98
wruntask 95, 98
wschedjob 32
wsetpm 85
148
_ IBM employee
Please rate your overall satisfaction with this book using the scale:
(1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor)
Overall Satisfaction
__________
Yes___ No___
Comments/Suggestions:
149
SG24-5125-00
Printed in the U.S.A.
SG24-5125-00