Inside VESOFT #15 (multi-cpu security part 2)
by
Shawn Gordon
Last month we talked about setting up multi-cpu security with a two system environment. This month I’m going to extend it to how to cover ‘n’ number of machines in a spoke and ring fashion.
The two-machine configuration described last month is actually a minimal version of a “ring” topology, where changes are passed from the first machine to the second, the second machine to the third, and so on until the LAST machine in the chain transmits data to the FIRST machine.
For example, let’s rename system “KYLE” to system “KENNY” and add the new system “CARTMAN” to the chain. Using a ring analogy, the network now looks like this:
+---------+ +---------+ +---------+
+->>| STAN |---->>| CARTMAN |---->>| KENNY |---+
| +---------+ +---------+ +---------+ |
| NODEA NODEE NODEZ |
+---------------------------------------------------+
As you can see, you can put as many of “nodes” between STAN and KENNY as you want. In actual practice, however, you are not likely to add more than a dozen nodes in this manner, especially since you will run out of names from South Park. After that point, it may be easier to define a star or wheel type of network in which one machine is considered the “hub” and all other machines are “spokes”. Changes made on any spoke are only sent to the hub, and the hub is then responsible for forwarding the changes to the other spokes. This is actually the method I preferred since it planned ahead.
The reason that this works is due to the fact that you can specify more than one $NET-SEND in your SECURCON.DATA.VESOFT file to indicate that user profile change information should be transmitted to several computers. For example:
$SYS-NAME "HUB" $NET-SEND STAN $NET-SEND CARTMAN $NET-SEND KENNY
Similarly, you can specify more than one $FROM-SYS in your HUB’s NETRECV.DATA.VESOFT file, indicating that information should be received from
several computers.
$FROM-SYS NODEA STAN $FROM-SYS NODEE CARTMAN $FROM-SYS NODEZ KENNY
If you have many machines, you might want to set up a pair of files in the group NETRECV.VESOFT that contains a list of machine names and DSLINE node names. You can then refer to these lists of machines in $NET-SEND and $FROM-SYS keywords. For example, you might build a file called
SPOKENS.NETRECV.VESOFT (for SPOKE NameS) that contains the lines:
STAN CARTMAN KENNY
and then say in your SECURCON file
$NET-SEND ^SPOKENS.NETRECV.VESOFT
Then build SPOKEDS.NETRECV.VESOFT (SPOKE DSlines) which contains:
NODEA NODEE NODEZ
and in your NETRECV.DATA.VESOFT file
$FROM-SYS ^SPOKEDS CHANGES
The file CHANGES.NETRECV (on the HUB) would be used for ALL the nodes listed in SPOKEDS. Each “spoke” machine (STAN, CARTMAN and KENNY) should have $NET-SEND HUB in their SECURCON file and $FROM-SYS HUB in their NETRECV file. Therefore, a change on system STAN will be sent to the HUB system which in turn will be received from the HUB by CARTMAN and KENNY.
Note that if your system names are the same as their DSLINE node names, then the same file can be used for both the SECURCON $NET-SEND and NETRECV $FROM-SYS keywords. Given how convoluted this can get, I strongly recommend keeping it as simple as possible and reuse the names.
When a user is changed, it usually wouldn’t make sense to transmit the entire user profile, including the terminal restrictions, time-of-day restrictions, day-of-week restrictions, and menu file. This is because these things are typically quite different on different systems, you’d almost certainly want to have different menu files on different systems, the terminals are configured as different LDEVs, and the normal working days and times might be different too.
So only the user name and password information (including password history, last change date, etc.) actually get sent from one system to another.
Now what if you want to impose terminal, time-of-day or day-of-week restrictions on users who might get, say, automatically added as a result of an addition on another system? The $FORBID keyword, lets you impose restrictions on entire usersets, not just individual user profiles so in your SECURCON file you could say:
$FORBID "NOT BETWEEN(CLOCK,9AM,5PM)" "Bad time" @.AP
which will impose a time-of-day restriction on all the users in the AP account, these restrictions will be enforced even though the users won’t have specific time-of-day restrictions in their user profiles.
Pushing is another method of maintaining security profiles on multiple systems. Normally, a SECURITY user profile on system STAN gets moved to system KYLE by a NETRECV task running under the BACKG job on KYLE which keeps a remote session logged on to STAN. What if, you don’t want to keep this session permanently logged on?
SECURITY lets you indicate that data is to be “pushed” across the network, i.e. have the data transfer be done by the computer on which the changes were initially done rather than “pulled”.
(In the following discussion, “system STAN” is the system on which the SECURITY user profiles were changed; “system KYLE” is the system you wish to
forward those changes to.)
1) Instead of having a "$FROM-SYS nodename sysname" line in your NETRECV.DATA.VESOFT file on system KYLE, you should have a "$FROM-SYS-PUSHED
nodename sysname" line. This tells the NETRECV task on KYLE that the data from STAN will be pushed by STAN, and doesn't need to be pulled by KYLE.
2) There are two different ways that you can have system STAN push data to
system KYLE, immediately or intermittently.
a) If you add to your NETRECV.DATA.VESOFT file on system STAN a line that says "$PUSH-IMMEDIATE KYLE", the NETRECV task on STAN will every time
a change is made on STAN, do a :REMOTE HELLO to KYLE, transmit the change, and do a :REMOTE BYE.
b) If you add a line that says "$PUSH-INTERMITTENT KYLE", the changes will only be pushed when you do a %SEC NETPUSH command (either online or using the NETPUSH task under the BACKG job). BACKG allows you to schedule the NETPUSH task to run once a day at a given time (1:00 AM, by default) so that it transmits all the changes to all the systems specified in the $PUSH-INTERMITTENT commands. If you find that you want to send the data to the other machines immediately, you can just do a %SEC NETPUSH online.
You will however need to keep the NETRECV task running on system KYLE; the main difference is it never logs onto system STAN. In addition, you must either run the NETRECV task on system STAN (for $PUSH-IMMEDIATE) or the NETPUSH task (for $PUSH-INTERMITTENT) to transmit the data to system
KYLE. [A third alternative is to manually issue a %SEC NETPUSH command which is what the NETPUSH task does once a day.] The NETRECV task on system KYLE then updates the SECURITY user profile.
Example 3: large network model. The large network model is much more complex. Imagine a large network of systems scattered across the country. Using X.25, each one can connect with each other one, but they shouldn't be continually connected. Instead, what we will do is have each system dial-in to a "master" or "hub" system every time a profile is changed. Then, once a night, the "hub" will send all of the changes made to it during the day to each of the "slave" or "spoke" systems. Using this plan, the "hub" will always have the current SECURITY configuration of all of the "spokes", and each "spoke" will be updated with changes from all the other "spokes" at the end of the day. A user who changes his password on a "spoke" will be able to use his new password on the "hub" virtually immediately, and on other "spokes" starting tomorrow. This is going to be a little confusing so do your best to follow along:
A) On system HUB, add the following:
Filename: SECURCON.DATA.VESOFT
$SYS-NAME "HUB"
$NET-SEND ^SPOKELST.NETRECV.VESOFT
Filename: SPOKELST.NETRECV.VESOFT
SPOKE01
SPOKE02
...
Filename: NETRECV.DATA.VESOFT
$PUSH-INTERMITTENT SPOKE01
$PUSH-INTERMITTENT SPOKE02
...
$FROM-SYS-PUSHED ^SPOKELST SPOKECON
Filename: SPOKECON.NETRECV.VESOFT
$RECEIVE @ !HPJOBNAME,!HPUSER.!HPACCOUNT @,@.@
B) On each SPOKE system (SPOKE01, SPOKE02, ...), add the following:
Filename: SECURCON.DATA.VESOFT
$SYS-NAME "SPOKE01"
$NET-SEND HUB
Filename: NETRECV.DATA.VESOFT
$PUSH-IMMEDIATE HUB
$FROM-SYS-PUSHED HUB HUB
Filename: HUB.NETRECV.VESOFT
$RECEIVE @ !HPJOBNAME,!HPUSER.!HPACCOUNT @,@.@
C) On all systems (HUB and SPOKEs),
%SEC BACKG STARTJOB (* If it's not already running *)
%SEC BACKG START,NETRECV
D) On system HUB only:
%SEC BACKG START,NETPUSH
The NETRECV task on the HUB merely waits for a SPOKE to send a change, which it then posts to the SECURITY user profiles on the HUB.
The NETRECV task on each SPOKE does two things: sends changes to the HUB throughout the day (by logging on to the HUB, sending the change, and then logging off), and at night, when NETPUSH on the HUB sends the changes to the spokes, NETRECV on each spoke posts the changes to the SECURITY user profiles.
Now, if you haven’t slipped into a coma reading that, you are certainly now a master at network security.