[Info-vax] login information capture

[pcoviello at gmail.com]

hmmm interesting ideas I'll have to look into it, yes it is one company and
a bunch of users that does change,  

well I had to remove the part about interactive logins, it was preventing the
vendor from getting in. and we also noticed that it is asking to enter the info 
below even though the info is above and you are at the prompt!

OSC$FACS1> @dsa100:[osc]login.com
Why are you here?: Name, CCS Contact and Case # please!  testing
Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit:
OSC$FACS1>


On Wednesday, February 19, 2014 8:15:22 PM UTC-5, BillPedersen wrote:
> On Tuesday, February 18, 2014 9:59:18 AM UTC-5, pcov... at gmail.com wrote
> 
> > I tried to do a search but was unable to find anything, so if this has already
> 
> > been covered please just point me to in the right direction.
> 
> > 
> 
> > thanks
> 
> > 
> 
> > we would like to be able to look at a file and see who has logged in from
> 
> > a vendor site using a generic account.  we would be looking for something 
> 
> > where the support person has to put in their name and reason for being there, I'm
> 
> > hoping someone has done this already.
> 
> > 
> 
> > thanks
> 
> > Paul
> 
> 
> 
> Ok, what is the important thing here?  Who logged in to the account or what did they log in to do?
> 
> 
> 
> Can you characterize what someone is logging in for by a necessary permissions so as to protect your environment, or is this a general account for any support by this vendor?  Can you adjust the privileges based on planned activity?
> 
> 
> 
> If this above can not help, can do know the "universe" of who is supporting your environment?  At least initials?  If that is the case then if their initials do not match a given set you know, then they should not be on the system.
> 
> 
> 
> I would recommend a menu of basic tasks which is displayed for selection.  A list of possible staff (which is not displayed so people have to know they are on the list).
> 
> 
> 
> Now you do not need to go further unless you are paranoid, then consider adding records to sysuaf.dat for each person which do not have places to log into not privileges.  Then use sys$getuai/sys$setuai to access the record and verify access for that identified user of the account.  You can have an identifier for the users who can access the account so it does not let ANYONE in who has an account.
> 
> 
> 
> Then the security is still similar to the overall VMS security and you do not have "invent" much other than the control aspects of accessing the sysuaf.
> 
> 
> 
> Yes, it is more work than just "logging" the information but it depends upon how you want to manage this "generic" account.
> 
> 
> 
> Bill.