1748081 Members
5210 Online
108758 Solutions
New Discussion юеВ

Re: Remove user

 
Deepthy
New Member

Remove user

I have one requirement which is like this..

** When ever a user resign from company I need to disable the user and keep it for 7 days (for in case of reactive request come).

** After 7 days I want to remove the user from system.
- is there any way I can set the expiration date at the time of disable the user? I want to make this process simple ..in one goтАж
I am new to OpenMVS.. pls help me ..
11 REPLIES 11
RBrown_1
Trusted Contributor

Re: Remove user

Welcome to the ITRC forums!

Disabling a user is easy:

UAF> MODIFY username /FLAGS=DISUSER

A disabled user cannot log in.

Removing a user is easy:

UAF> REMOVE username

Whether or not removing a user is a good idea is open to discussion. When you remove a user, files owned by the user will remain, but instead of them being owned by [USER, FRED] (for example) they would then be owned by the equivalent but less informative [200,1] (for example). (The corollary here is that if you remove a user, you should not reuse the UIC when a new user is added, otherwise the new user will own all of the previous user's files).

If you want to only type a single command (or set of commands) at one time to disable the user now and remove the user 7 days from now, you will probably have to write a command file that:

1. disables the user
2. creates a temporary command file to remove the user
3. submit the temporary command file to run as a batch job 7 days from now

Not difficult. You will probably want to read the VMS User's Manual, especially the chapters about DCL programming, and check out the VMS System Management Utilities Reference Manual for info about the Authorize Utility. The System Manager's Manual: Essentials chapters about user accounts will also be useful.

Have fun!
Shriniketan Bhagwat
Trusted Contributor

Re: Remove user

Hi,

Please refer the chapter 7 Managing User Accounts from HP OpenVMS System Manager's Manual, Volume 1. Below is the link.

https://www.hpe.com/psnow/doc/a00058396en_us

Regards,
Ketan

[Moderator edit: Updated the valid link. You may also refer to https://support.hpe.com/]

Deepthy
New Member

Re: Remove user

is there any variable which tell the date in which user disabled ? ..

in my case i would like to run the batch each day and check if there is any user which disabled 7 days before...
Jan van den Ende
Honored Contributor

Re: Remove user

Deepthy,

Let me start with
WELCOME to the VMS forum!

>>>
is there any variable which tell the date in which user disabled ? ..

in my case i would like to run the batch each day and check if there is any user which disabled 7 days before...
<<<

Well, without any (freeware) tools to make things even easier, you can DEFINE a /SYSTEM logical name that holds the info.

Choose a relevant prefix, like REMUSER_,
then _I_ would add the removal date in COMPARISON format, followed by the USERNAME.

eg. REMUSER_20110120_DEEPTHY.

The daily removeal job would convert TODAY to comparison, try to translate REMOVE__*, and if found substract REMOVE__ to get the relevant username.
Remove that, and DO NOT FORGET to DEASSIGN the LNM. Next search for the next such KNM to process, until none found.

note: there does exist freeware that makes things like this a little easier, but it will always need to be tweeked to suit your specific requirements.

Success.

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Ian Miller.
Honored Contributor

Re: Remove user

See also /EXPIRATION qualifier
____________________
Purely Personal Opinion
Robert Gezelter
Honored Contributor

Re: Remove user

Deepthy,

Welcome to the ITRC OpenVMS Forum.

Disabling an account by setting the DISUSER flag is straightforward, as has already been mentioned.

Deleting the account has deeper implications. As has been noted, the AUTHORIZE REMOVE function also removes the rightlist entry for that UIC. Thus, any remaining files will show up as being owned by a numeric identifier (e.g., [221,63761]) rather than a name associated with the user. If files remain behind, this can be a problem. As has been noted, reusing UICs is typically a bad idea on several levels.

Deleting files is also generally a bad idea. Archiving the files in the user's directory to long term storage, with later disposition is a far safer alternative. This is not a question of personal files, I have seen many situations where files inadvertently placed in personal directories were critical to a technical or business purpose. There could also be legal issues (jurisdiction dependent) where file destruction could have severe negative consequences.

The date that the DISUSER flag was set is preserved in the system logs, but that becomes a laborious process. More importantly, keying removal actions on having set DISUSER erroneously conflates several different possibilities. There are many reasons an account may be set to DISUSER without implying that the user is to be removed (e.g., the field engineering account). It is also often a practice to DISUSER an account when someone is out of the office for an extended vacation or medical leave.

With all due respect to Jan, I disagree with the use of logical names of any form to store the list of accounts that have been deleted (in any table, system, group, or purpose-specific). Logical names do not survive system restarts, and the list of accounts to be deleted would then be lost.

The only solution that works is to encapsulate your termination process into a command procedure. The command procedure DISUSERs the account immediately; then makes an entry into a file with the account name and the removal date. A separate command file (possibly run automatically every day) scans that file, and takes other actions as appropriate.

In the case of terminations, I would also be tempted to set the password to nonsense, and possibly to set the allowed login hours to never. This makes it more difficult to create a way back into the system for a terminated individual, who may or may not have "friends" still inside the organization.

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

abrsvc
Respected Contributor

Re: Remove user

Bob summarized it well. As a rule where I am currently contracted, we DO NOT delete accounts. All accounts are disabled with the /disuser flag, the passwords changed and the access times flagged as never. This prevents us from re-using the name or UIC. All files are saved (usually off system) should they be required later on.

Leaving the account in the UAF allows us to track active/unactive accounts.

Dan
The Brit
Honored Contributor

Re: Remove user

Hi Deepthy,

To your last question, "i.e. the date when an account was disusered?"

To get this, it is best to enable UAF auditing. This would normally be enabled anyway.

To check, type

$ show audit

should get something like;

System security alarms currently enabled for:
ACL
Authorization
Audit: illformed
Breakin: dialup,local,remote,network,detached
Logfailure: batch,dialup,local,remote,network,subprocess,detached

System security audits currently enabled for:
ACL
Authorization
Audit: illformed
Breakin: dialup,local,remote,network,detached
Logfailure: batch,dialup,local,remote,network,subprocess,detached

You are interested in "Authorization".

if it is not enabled then see the OpenVMS help,

$ help set audit/enable

Dave.
tsgdavid
Frequent Advisor

Re: Remove user

>>>>
Deleting files is also generally a bad idea. Archiving the files in the user's directory to long term storage, with later disposition is a far safer alternative. This is not a question of personal files, I have seen many situations where files inadvertently placed in personal directories were critical to a technical or business purpose. There could also be legal issues (jurisdiction dependent) where file destruction could have severe negative consequences.
>>>>

As Bob mentioned, there can sometimes be implications regarding files in a user's directory that are still in use and/or processes that use the particular user account. there also could be files that might be needed sometime in the future. Although this is often not the case, as a general rule I would check for this with some or all of the following:

- SHOW QUE/ALL/FULL !to see if any jobs in the queues have the user account as the OWNER

- SHOW DEVICE/FILES dduu: for each disk device to see if there are any open files in the user's directory

- After a period of time, verify that no files have been accessed in the user's directory. I do this by making sure that all of my VMS disks have a retention period of 10 days using SET VOLUME/RETEN=(10-,10-) ddcu:. Once this is done, an expiration date and time is set in the header of every file each time it is opened no matter whether it was opened for read or write access. In my case the expiration is set to exactly 10 days after the last file access. This only needs to be set on each disk once and affects all file accesses from that period on. Expiration dates are not typically used in VMS for anything but can be used by utilities that have been added to the base system. You should be sure that nothing on the system is actually using expiration dates before changing this. With this in place, you can determine if files have been accessed after a certain date using DIR/EXPIRED/SINCE=date-time. The date specified can be in the future. Of course, it you browse around in the directory and type out a file to see what it is, that will update the expiration date.

- Make a BACKUP of the disk as it was before removing any files.

- Consider rebooting the system after removing the user account and/or moving the user's directory.

Dave Williams