[Info-vax] VMS and MFA?

[geze...@rlgsc.com]

On Thursday, August 20, 2020 at 3:09:05 AM UTC-4, Dave Froble wrote:
> On 8/19/2020 11:41 PM, geze... at rlgsc.com wrote: 
> > On Wednesday, August 19, 2020 at 4:20:30 PM UTC-4, Arne Vajhøj wrote: 
> >> On 8/19/2020 3:08 PM, Dave Froble wrote: 
> >>> On 8/19/2020 2:13 PM, Arne Vajhøj wrote: 
> >>>> On 8/19/2020 11:44 AM, Jan-Erik Söderholm wrote: 
> >>>>> Thanks all. Yes, there are several "layers" before anyone reach the VMS 
> >>>>> "Username:" prompt. I first login to the Citrix Remote Desktop, and that 
> >>>>> is throught a MFA (6-digit code in SMS/text message). From there is it 
> >>>>> a Putty session against the VMS system "as usual". 
> >>>>> 
> >>>>> We had a discussion, and many of our "users" are generic and named 
> >>>>> after the workplace. There can be 10 different operators working there 
> >>>>> and using a group login VMS account setup for each "process terminal". 
> >>>>> 
> >>>>> So, the decision was that MFA is not suitable for us. 
> >>>> 
> >>>> If you have started a process of looking at security then 
> >>>> one account used by multiple persons could raise some 
> >>>> serious red flags. 
> >>> 
> >>> In my opinion, the best security is being able to control what can be 
> >>> accomplished. 
> >>> 
> >>> As far as I'm aware, and I'd welcome any information I'm unaware of, a 
> >>> captive account is very effective. Of course, it depends on what 
> >>> activity a captive account can accomplish. 
> >>> 
> >>> It may be that multiple users can perform the same activity, and if so, 
> >>> multiple users of the same user account need not be a problem. Though 
> >>> setting up individual user accounts is usually not a problem. 
> >>> 
> >>> Depending on requirements, various amounts of logging of activity can be 
> >>> implemented. Perhaps good for exploring issues, but as always, who 
> >>> watches the watchers? 
> >>> 
> >>> While access control is possible, it's my feeling that trust of 
> >>> authorized users is usually a much greater security issue. 
> >> It is usually considered a good thing security wise to be able 
> >> to actually log who successfully did what and who unsuccessfully 
> >> tried what. 
> >> 
> >> Unique accounts helps with that. 
> >> 
> >> It is not even a new thing. 
> >> 
> >> Arne 
> > Arne, 
> > 
> > Quite 
> > 
> > For "captive" applications, my general recommendation is for 
> > individual logins, for control and accountability purposes. If a 
> > user's access is deemed no longer necessary or appropriate, their 
> > access can be revoked without impacting others. 
> > 
> > I also prefer individuals to have individual work/home directories. 
> > Sometimes programs have presumptions that each user will run a single 
> > copy, it is better for the home directory to be separate for each 
> > user. If large numbers of files are common, logical names with search 
> > lists can be used to provide access to common files.
> Yep.
> > That said, such users are normally put in a group, which has a 
> > group-specific login which sets up the environment (see my old 
> > OpenVMS Consultant column on http://www.rlgsc.com for how to setup 
> > group-specific login files. 
> > 
> > One such client had tens or hundreds of users who never saw VMS. They 
> > logged in to individual accounts. All of the accounts were set up as 
> > captive in a single group, with a group-specific login. Each user was 
> > granted RIGHTSLIST identifiers as to what tasks they were allowed to 
> > perform. A simple menu system, driven by the rightslist entries 
> > allowed them to acces their authorized applications.
> I'm aware there are multiple methods to achieve desired results. But 
> I'm curious, why get into the complexity of rightslist entries? 
> 
> A captive account, with a menu of possible apps to run, pretty much 
> locks a user into just those apps. Of course a menu utility that allows 
> for custom menus for each user makes this simple. If a user somehow 
> gets out of the allowed apps, being captive, the process is killed.
> -- 
> David Froble Tel: 724-529-0450 
> Dave Froble Enterprises, Inc. E-Mail: da... at tsoft-inc.com 
> DFE Ultralights, Inc. 
> 170 Grimplin Road 
> Vanderbilt, PA 15486
David,

The reason for a dynamic menu based driven by rightslist entries was straightforward. 

Not all workers were qualified or authorized to work on all tasks. The client was a data entry job shop. The applications were specific jobs presently in house. The goal was for most (read that as "almost all") operators to have two choices: enter a batch on the present jobn or logout. A very small number of senior supervisory operators might have authorization to switch between jobs, but that was very limited. Clearance for a particular job was a shift-by-shift assignment. Thus, Monday an operator might be authorized to work on JOB_15; Tueday the operator might be working on JOB_90. Ideally, identifiers were added at the beginning of a shift and revoked at the end. 

Worked excellently. In all of the years used, never had an operator mis-enter a batch.

- Bob Gezelter, http://www.rlgsc.com