[Info-vax] VMS and MFA?

[Jan-Erik Söderholm]

Den 2020-08-20 kl. 05:41, skrev geze... at rlgsc.com:
> 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.
> 
> 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.
> 
> - Bob Gezelter, http://www.rlgsc.com
> 

All our users are captive. They can not leave their menus without
being logged out. The only ones that can "see VMS" are myself and
one or two from the large indian outsourcing company. That is, the
complete support-group for this environment.

The "home directory" is one common VMS directory shared by all
workplaces. They have no real use for a directory and there are
no files created as part of the job done at the workplaces.

And it would not be practical to replace the workspace specific
usernames with personal accounts.

But yes, when there has been some issue at a specific workplace,
we cannot know which operator it was. But that can usually be
sorted out together with the management of that assembly line.