3k Associates Sponsor Message

Security Profiles

By Steve Hammond

Inside VESOFT covers tips and techniques you can use with VESOFT’s products, especially MPEX.

The years, like operating systems, come and go. Time passes, but there are some constants — the sun rising and setting (often spectacularly), the rising and falling of the tides, and children’s holiday plays. I’ve seen my fill of them over the years — some good, some bad, but you can bet between Thanksgiving and New Year, most families will enjoy/endure one or more of these productions that sets Flo Ziegfeld spinning in his grave.

One of the more recent twists is for the program at these productions to feature a brief synopsis of each participant’s theatrical CV (“Joshua played the third tree from the left in Camp Tuckahoe’s Wigwam review”). As I sat reading a program full of those recently, I realized it’s like a little profile — similar to the profile you need to build for your users when you use Security/3000.

It seems like a nice time to look into some of the beginner’s fundamentals of Security, We’ll just start to look at Security with more ideas in future columns. Now down to the basics.

Logon security itself is controlled by the use of a logon UDC or, in the newer versions of MPE/iX and Security, via issuing some commands in the MAIN.PUB.VESOFT program (more on those later). The UDC is LOGONUDC.PUB.VESOFT and when set for an account or a system, runs all logons through the ‘traps’ of Security. The UDC aside, the guts of Security lie to two places — the file SECURCON.DATA.VESOFT and the security profiles.

Like MPEXMGR, SECURCON is a flat MPE file that can be manipulated with any editor program. The values placed in this file set any number of parameters for how Security protects your system. The SECURCON file on my system calls in several of the proverbial ‘bells and whistles’ (note only my account TESTCOM is currently protected by Security — that’s all we’re using our e3000 for these days):

$LOG-LOGON @.testcom-manager.testcom-admin.testcom

$NO-CONCUR-SESS @.testcom-manager.testcom-testuser.testcom-admin.testcom

$NO-BATCH @.testcom-manager.testcom

$VEPROFILE @.testcom-manager.testcom-admin.testcom

$SESS-EDIT “?@” @.testcom-testuser.testcom

$SESS-EDIT “??###” testuser.testcom

$VE-NUM-TRIES 3

$WELCOME-MESSAGE “‘Welcome to the Test Xfer System!!” @.testcom

$FORBID “HPDAY=6 and between(CLOCK,5:00PM,11:59PM)” &

“EDT and MAL access prohibited after 5 pm Friday” &

@.testcom-manager.testcom-admin.testcom

One thing I always did, and this is pure preference, was to put the keywords (those proceeded by a ‘$’) in upper case and leave everything else in lower case (A luxury I no longer having working on my Unix server — sorry, that was a cheap shot, I couldn’t help it!).

This file tells Security to log in its history file all logons to TESTCOM except for the users MANAGER and ADMIN ($LOG-LOGON). There can be no concurrent sessions for any users except for MANAGER, TESTUSER and ADMIN ($NO-CONCUR-SESS). No batch processes can be activated by any user except MANAGER and ADMIN ($NO-BATCH). The big command is the next one — all users, again except MANAGER and ADMIN must have a Security profile on file and the logon will validate against that profile ($VEPROFILE). Other commands create a welcome message ($WELCOME), limit times when users can log on ($FORBID), set the number of retries for bad passwords ($VE-NUM-TRIES) and set the masks for session names ($SESS-EDIT). (There is a multitude of other SECURCON commands that we will explore in another column.)

The next big chuck of Security is the profile. Again, you need to establish a user with a profile in order to allow them log on. Here’s an example from my system:

:run main.pub.vesoft,add

SECURITY/ADD 30N10511 (c) VESOFT Inc, 1981 03:06569 For help type ‘?’

Enter user id: entry

Enter account: testcom

Enter session name: steve

Enter user’s real name: Steve Hammond

Enter permitted terminal numbers: 101,102,103

Enter day-of-week access restrictions: monday-friday

Enter time-of-day access restrictions: 8am-6pm

Enter the menu file name:

Enter Y if the user is to have SECURITY/3000 passwords;

N if the user is not to have SECURITY/3000 passwords;

A if the user is to have passwords, but should enter the correct passwords himself the first time he logs on.

Your selection (Y/n/a)? y

Enter your password:

Please enter the answer again:

*** User has been added. ***

Enter user id:

Here I have added the user ENTRY to the account TESTCOM (both MUST exist before you start creating the profile). The session name must be STEVE and the user’s real name is yours truly. I can only log in on terminals 101, 102 and 103 (on my system, the three external modem lines) and I can only do so from 8 AM to 6 PM on Monday through Friday. I am not using a menu file and my password was assigned as the profile was created (as opposed to having no password or having me enter my password when I log on for the first time). Passwords are a topic for another column.

If you have SM or AM capability so that you control the creation of user names, like I am able to do on TESTCOM, you can use a simple “@” for session name and let the user name be your identifier. If you declare the session name here, the format of the name must match exactly — another level of security.

But what about when you have a third party package like we used for financials in my office for many years? There were only a few users in the account defined within the software to use the package; i.e., CLERK.FINANCE and INPUT.FINANCE. So if you want to know who’s doing what, you really need to require the session name. We also needed to define a means for the operators to contact, at time for backups, any users who still might be logged on. We decided to require the users to log in using as the session name ‘EXT’ followed by their extension. We accomplished that by adding the following line to SECURCON:

$SESS-EDIT “ext####” @.FINANCE — MANAGER.FINANCE — MGR.FINANCE

We simply required the FINANCE users (except MANAGER and MGR), at logon time, to use as their session name the only letters ‘ext’ followed by their four-digit extension number. ‘EX555’ would not work, but ‘EXT5505’ would work. Therefore, when you signed on as CLERK to FINANCE,

Hello steve,clerk.finance

would be rejected by Security, but

Hello ext4448,clerk.finance

would work.

More on the SECURCON file and passwords next month.

One last hint, if your office has an aversion to system-wide logon UDCs, Security does offer an alternative way to enforce security. Vesoft uses the AIF:PE LOGON trap to enforce it by issuing these commands

:RUN MPEX.PUB.VESOFT

%BACKG STARTJOB (assuming your MPEX background job is not running)

%BACKG START, LOGON

This will run SECURITY on all logons until the %BACKG STOP, LOGON is issued. As my old boss used to say — same church, different pew.

Steve Hammond, who works for a trade association in Washington, DC, wasn’t a good enough actor to even play a tree at Camp Susquehannock.