Disable OPEN VMS User Account Automatically

[Kumar_Sanjay]

I have requirement to disable the privilege user account (ABCUSER) after every successful login.
Could any one please help me find out? How to disable the user account automatically?


This implementation is for security purpose. Normally this powerful Application account should always be disabled. Once the user required using this ABCUSER account, he needs approval for it.
After performing the task, once he logout. The user account will automatically disable after 1 or 2 hrs.
User again needs approval to unlock this account and login.

[Karl Rohwedder]

You may set a very short lifetime or disable the account in its LOGIN.COM or SYLOGIN.
But note: since the account is privileged, the user has all he needs to circumvent your mesasures, except it is tied into a captive account.

regards Kalle

[Kumar_Sanjay]

This Account is equivalents to system account added some special identifiers for applications. I couldnâ t make this as captive account.

[Jan van den Ende]

Hi,


>>>
This Account is equivalents to system account
<<<

- A. Let the account have expiration in the past.
When enabling it, do so by setting short expiration.

(from other prive'd account):
$ MC authorize mod /EXPI="+2:0:0"
will allow two hours. of login window.

Mind. this will also block NETWORK and BATCH logins!

- B. Always allow just ONE login:
in the LOGIN.COM of the account, do
# MCR AUTHORIZE MOD /NOINTERACTIVE.

Befoe use, another priv'd account will need to set /INTERACTIVE.

Caveat: any user logged in into this account will always be able to change his own account at will!
There exists NO way to avoid that, once a priv'd user has command line access.

hth

Proost.

Have one on me.

jpe

[labadie_1]

I think what you try to do is nonsense.

How do you know that this privileged account has not started a detached or batch process that will re-enable this account, or create another privileged account, or anything else, like what some guys did long ago, patch loginout.exe, while still having a correct checksum ?
Are you suspicious if you have usually about 100 symbiont processes, if you have one more, that in fact does something completely different ?

I do not believe you can reliably do what you want.

[Robert Gezelter]

CA1467620,

Since the account has full privileges, and is not captive, it is straightforward to neutralize such restrictions, as Karl and Labadie have observed.

The obvious way to attempt this is to pre-expire the account. However, the expiration can simply be reset by using AUTHORIZE or another program. Resetting the LOGIN.COM file (e.g., to something that automatically logs off) can be similarly defeated.

Automatic emails to multiple persons can act as a discouragement to improper use, but they do not prevent the use.

It may be appropriate to reduce the privilege level of this account, in which case something can be done. Consulting with someone with extensive experience in OpenVMS security would be a sound idea [Disclosure: We provide services in this area, as do several other frequent participants in this forum].

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

[The Brit]

In my own experience, it is almost always possible to use a CAPTIVE account for this kind of issue, i.e. accounts used to access an application. In your case, you specify a user called ABCUSER (I don't know if this is just coincidental, or if the user is actually accessing Archive Backup Client (ABC)), however is is relatively simple to limit the input command strings at the DCL Level, to some predefined sub-set. Once inside the application/utility, then the DCL restrictions no longer apply so the user has full access to the application/utility commands. This solution does however require some skill at DCL scripting.
Alternatively, while the problems with privileged accounts being able to modify their own account while logged in, are certainly valid, if the user/application does not actually require BYPASS or SECURITY, then an identifier on the AUTHORIZE exe or the SYSUAF.DAT of the form,
(IDENTIFIER=ABCUSER, ACCESS=NONE) will stop them modifying their own account. However, if the account does require either of those privileges then there is little you can do.

Dave

[Jan van den Ende]

CA1467620,

It really boils down to the old main question: "What are you trying to achieve?"

If this is some application, that several applic managers must be able to stop and start, then there exist tricks to have this done from their own accounts (without ever logging in to this "application super user").

In general, LOTS of things CAN be done in controlled ways in VMS, but most of those DO require advanced skills and experience.

And, after a certain treshold, some people just HAVE to have full access to the system(s). In those cases, TRUST is all that is left.
And then, all that is left is to "trust, but verify".
(alas in many cases, the skills to verify are badly missing!)

hth

Proost.

Have one on me.

jpe

[Willem Grooters]

I would try the following:

Create the account to be a captive, normal user (that is: non-SYSTEM) account, with normal default privileges and only those that are required in some actions, as authorized.
The procedure (actually a menu) would do a SET PRIV to elevated levels before the required action (no more than really needed) and revoke these privileges afterwards - no matter the outcome.
On exit (whatever way) the procedure would need to set the /DISUSER flag of the account. Another approach is keeping the first login time of the script, and set the expiration date accordingly. You could do so in a (SYSTEM or GROUP) logical, that is deleted on logout after expiration.

Be sure this user has NO DCL access; all he does should be under full control of the procedure, and any escape should result in logout (that's what a captive account is meant for).

To reuse the account, someone that is able to chnage UAF records (using a similar captive account?) could allow him access for the next period.

Any file, touched by this account, should be secured for write access for any non-privileged user. You can do so by an ACL on identifier, and no access for non-holders.

If you require DCL access, it's a no-go. You cannot do without to prevent activities you do NOT want to be executed. Otherwise, this account should have no access to ANY file or resource unless explicitly allowed. Writing a DCL procedure that limits activities to the bare minimum required is less time consuming (and earier to maintain).

I have used such an approach in a development area to allow the (non-system) developers do some limietd system tasks they otherwise couldn't execute (except for the time limitation)

[Hoff]

Here's a configuration approach that should lead to a single-use password:

http://64.223.189.234/node/682

Alternatively, some sites use the two-password login mechanism for cases such as this, where two folks each have one of the two passwords needed to log into the (privileged) username for the target system. Both folks must be present to log in.