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.

[Kumar_Sanjay]

Hi Willem Grooters

Thanks for your reply. We have two different accounts for this application.

1. User id -ABCLOWPRV - This is regular user account for application startup and shutdown.
2. User id -ABCUSER - this account has all the privilege and use rarely for application maintained or trouble shooting application problems. Since this has all the privileges we want to protect this account.

You suggested procedure is suitable to this environment and want to implement the same.
I want to add the /DISUSER Flag on the exit/logout of the ABCUSER. This will prevent users login if he know the last password..

How do I implement the same;
Is there any options in authorize to do this ?
or do i need to write a command procedure for this?

[Jan van den Ende]

CA1467620 ,

>>>
I want to add the /DISUSER Flag on the exit/logout of the ABCUSER. This will prevent users login if he know the last password..

How do I implement the same;
Is there any options in authorize to do this ?
<<<

$ MCR AUTHORIZE MODIFY ABCUSER /FLAG=DISUSER

(undo with /FLAG=NODISUSER)

Before using AUTHORIZE in this way, you should have defined
$ DEFINE /SYSTEM/EXECUTIVE SYSUAF (by default: SYS$SYSTEM:SYSUAF.DAT)
Be aware that the logical might already be defined, in that case LEAVE it!

hth

Proost.

Have one on me.

jpe

[Robert Gezelter]

CA1467620,

AUTHORIZE is used to set the DISUSER flag (see HELP MOD /FLAGS within AUTHORIZE).

As Willem noted, unless the user has NO ACCESS to DCL, this is not an effective measure. If the user has access to DCL, they can undo (or fail to do) this measure as they please.

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

[Jan van den Ende]

CA1467620,

In the spirit of "trust but verify", giving this account TWO different passwords (see AUTHORIZE HELP /SECONDARY ), where each person to use the account has only ONE of those, then the account can only ever be used if TWO people are available to log in.
Now, (as long as they do not conspire :-) ), you can be reasonably sure that they will only do legitimate things.

This will get you much closer to what you want than any other OS. If this does not satidfy the auditors, then let THEM show how it has to be done!

hth

Proost.

Have one on me.

jpe

[Hein van den Heuvel]

Hmm, I don't know why the first reply by Karl did not get the full 10 points for a perfect reply and closed the question.

It solves the problem and as bonus points out legitimate and serious concerns.

As Karl indicates, in the login.com for the account issue MCR AUTHOURIZE /DISUER.

Anything more is just window dressing / fluff.

You may want to describe the real problem better. That is, what is the task to be 'protected' and why is the user not trusted the rest of the time.

One of my customs uses a 'careful' mode where specially flagged users can login with full privs, but with all input and output logged. I'm sure that also can be hacked around, but any person caught attempting that is 'questionable'.
Just enough of a hurdle and clear demarkation imho.

fwiw,
Hein.

[Doug Phillips]

No user should have ALL privileges unless they need access to ALL resources on the system, and those *few* users should be very knowledgeable and very trusted.

Any Application-level manager should only have full access to the resources needed to manage that application. It's better to look at the system's security from the bottom-up rather than top-down.

To use AUTHORIZE, a user needs W access to the SYSUAF, NET($)PROXY and RIGHTSLIST files (SYSTEM uic or SYSPRV) so you shouldn't give them that, and don't give them BYPASS or any such elevated priv's (which they *really* shouldn't need to do what you describe.) Application resources should be protected/isolated at the Group level, and/or via ACL's.

Following the other advice on ways to limit their access times should work fine for you if your system and application's security is properly configured.

[John Gillings]

>I want to add the /DISUSER Flag on the
>exit/logout of the ABCUSER. This will
>prevent users login if he know the last
>password..

If I'm understanding your objective, I'd suggest adding the DISUSER it to the *LOGIN* rather than the LOGOUT. DISUSER doesn't affect an existing process, it just prevents new processes from starting. You definitely have control over LOGIN, but may not get to the LOGOUT (process disconnection, bug in application, power fail, system crash, etc...). This also prevents your user from connecting a second session before finishing with the first.

Assuming your user has a high level of privileges, just add these lines to LOGIN.COM

$ IF F$TRNLNM("SYSUAF").EQS."" THEN DEFINE/USER SYSUAF SYS$SYSTEM:SYSUAF
$ MCR AUTHORIZE MODIFY 'F$GETJPI("","USERNAME")' /FLAG=DISUSER

This will use the system defined SYSUAF, or set a logical name to use the default one if there's no system defined one.
(note to Jan, for AUTHORIZE use, the SYSUAF logical name may be in any mode, or in any table visible to the process)

If the user doesn't have SYSPRV (and doesn't need it for the other processing), you can set it as a "trapdoor" privilege:

(permanent setting for account:
$ MCR AUTHORIZE user/DEFPRIVILEGE=SYSUAF/PRIVILEGE=NOSYSUAF

Once you've done the AUTHORIZE command in LOGIN.COM, issue:

$ SET PROCESS/PRIVILEGE=NOSYSPRV

Once SYSPRV has gone from the default mask, it can't be reinstated because it's not in the authorized mask.

All that said, as others have already mentioned, but it's worth stressing... if the privileged user has ANY access to DCL, or, in some cases even a prompt for data, it really doesn't matter how many tricks and traps you set, if they know what they're doing they WILL be able to get past them.

It comes down to a very simple test - If you don't trust the person, don't give them privilege.

[John Gillings]

>I want to add the /DISUSER Flag on the
>exit/logout of the ABCUSER. This will
>prevent users login if he know the last
>password..

If I'm understanding your objective, I'd suggest adding the DISUSER it to the *LOGIN* rather than the LOGOUT. DISUSER doesn't affect an existing process, it just prevents new processes from starting. You definitely have control over LOGIN, but may not get to the LOGOUT (process disconnection, bug in application, power fail, system crash, etc...). This also prevents your user from connecting a second session before finishing with the first.

Assuming your user has a high level of privileges, just add these lines to LOGIN.COM

$ IF F$TRNLNM("SYSUAF").EQS."" THEN DEFINE/USER SYSUAF SYS$SYSTEM:SYSUAF
$ MCR AUTHORIZE MODIFY 'F$GETJPI("","USERNAME")' /FLAG=DISUSER/NOACCESS

This will use the system defined SYSUAF, or set a logical name to use the default one if there's no system defined one.
(note to Jan, for AUTHORIZE use, the SYSUAF logical name may be in any mode, or in any table visible to the process)

If the user doesn't have SYSPRV (and doesn't need it for the other processing), you can set it as a "trapdoor" privilege:

(permanent setting for account:
$ MCR AUTHORIZE user/DEFPRIVILEGE=SYSUAF/PRIVILEGE=NOSYSUAF

Once you've done the AUTHORIZE command in LOGIN.COM, issue:

$ SET PROCESS/PRIVILEGE=NOSYSPRV

Once SYSPRV has gone from the default mask, it can't be reinstated because it's not in the authorized mask.

All that said, as others have already mentioned, but it's worth stressing... if the privileged user has ANY access to DCL, or, in some cases even a prompt for data, it really doesn't matter how many tricks and traps you set, if they know what they're doing they WILL be able to get past them.

It comes down to a very simple test - If you don't trust the person, don't give them privilege.

[Thomas Ritter]

CA1467620, if you want the account disusered as the user logs off then bad news. No direct way of doing it.
We use a nightly job which disables and changes password for a number of selected accounts. One being FIELD. We also produce reports on when specific accounts were used. This seems to please the auditors.

Maybe an internals specialist can hook in some code to disable accounts at logout ?

My 2 cents.

[Martin Hughes]

If you decide to DISUSER the account during login, I'd also add the RESTRICTED flag to the account, to ensure that LOGIN.COM is executed.

Another tool that I use is a daily job to analyse accounting records and report on what I deem to be suspect modifications to SYSUAF. This approach is not bullet proof, but I find it adequate for keeping an eye on privileged users (typically application managers).

[Jon Pinkley]

Others have noted the futility of "restricting" a fully privileged user. You should consider using the JUMP package, which gives you the ability to log what is being done by the privileged account. If you are interested in JUMP, see my replay dated Jan 16, 2008 08:11:51 GMT in http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1193355 The method I will demonstrate later is compatible with using JUMP too.

RE: "have requirement to disable the privilege user account (ABCUSER) after every successful login.
...After performing the task, once he logout. The user account will automatically disable after 1 or 2 hrs."

So which do you want? Disable after login or 1 or 2 hours after logout? We can do the first with standard built-in capabilities, but their isn't any automatic way to disable an account after some period of inactivity.

You asked for a onetime non-renewable password. Hoff gave a method of forcing a change with each use via UAF> modify /pwdlifetime="0 00:00:01", but that doesn't prevent reuse by the use that had access. He also has a section about some other flags for single login, but didn't explicitly talk about pre-expiring the password, and for a single login case, that is a key component.

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1164674 is another thread that discusses the difference between

UAF> modify /flag=PWD_EXPIRED

and

UAF> modify /pwdexpired

The following shows one other way to get a "single login" without having to modify any login.com. Because it does not rely on something being done in the user's login.com, it also avoids the problem of non-restricted accounts having the ability to bypass the login.com. This example also assumes that external authentication is not enabled. If you are running a version VMS that supports external authentication, you may want to add noextauth,dispwdsynch to the flags

Also, if you are "arming the account" for a specific event, you may want to explicitly put a timeout with the /expiration= with time that the login must be done before.

One downside of any of the methods that disable the account "on the way in" is that they will prevent multiple logins to the account while it is being used. In fact, the method proposed here will stop all new logins once the login has happened; that includes batch jobs. The point being, it does what you ask for in the first paragraph.

Here's a demonstration of the method.

$ mc authorize mod pinkley/flag=(disforce,lockpwd)/pwde /pass=demoonetimepassword ! enable for 1 login, you may want to specify /expir=
%UAF-I-MDFYMSG, user record(s) updated
$ telnet 0
%TELNET-I-TRYING, Trying ... 127.0.0.1
%TELNET-I-SESSION, Session 01, host localhost, port 23
-TELNET-I-ESCAPE, Escape character is ^]

Username: pinkley
Password:
Welcome to OpenVMS (TM) Alpha Operating System, Version V7.3-2 on node SIGMA
Last interactive login on Monday, 18-FEB-2008 16:35:46.30
Last non-interactive login on Monday, 14-JAN-2008 19:30:25.23
WARNING - Primary password has expired; update immediately with SET PASSWORD!
Current login process name is PINKLEY_1 on terminal SIGMA::VTA283:

$ set pass
%SET-F-PWDLOCKED, password is locked to prevent change
$ log
PINKLEY logged out at 18-FEB-2008 16:38:09.96
%TELNET-S-REMCLOSED, Remote connection closed
-TELNET-I-SESSION, Session 01, host localhost, port 23
$ telnet 0
%TELNET-I-TRYING, Trying ... 127.0.0.1
%TELNET-I-SESSION, Session 01, host localhost, port 23
-TELNET-I-ESCAPE, Escape character is ^]

Username: pinkley
Password:
Your password has expired; contact your system manager
%TELNET-S-REMCLOSED, Remote connection closed
-TELNET-I-SESSION, Session 01, host localhost, port 23
$

[Wim Van den Wyngaert]

Whatever you do, it will never be 100% secure.

Just tried a rsh to a captive account : it works (rlogin doesn't). You have to close that hole too.

The user can create prived batch jobs that run for ever and execute procedures on behalf of the user.

Etc

Wim

[labadie_1]

if you want to know what ABCUSER has done while logged, try Peek and Spy
http://www.networkingdynamics.com/Peek.htm
or the freeware logger, or modify the ABCUSER account to begin with
set h 0/log
USER
PASSWORD

so (in theory), all the session will be logged in sethost.log

Good luck.

[Kumar_Sanjay]

thanks