Remove user

[Deepthy]

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 ..

[RBrown_1]

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]

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]

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]

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

[Ian Miller.]

See also /EXPIRATION qualifier

[Robert Gezelter]

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]

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]

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]

>>>>
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

[Hoff]

I have an acl_scrub tool posted at:

http://labs.hoffmanlabs.com/node/426

This tool can locate and optionally correct stale identifiers that can be left dangling on file system objects when users are deleted.

Here is a write-up on creating and deleting users:

http://labs.hoffmanlabs.com/node/856

with links to various procedures and tools.

[John Gillings]

I agree with Dan, don't delete the user, just DISUSER & NOACCESS the account and set the password to a random string.

I you must remove the UAF entry, I recommend using:

UAF> REMOVE/NOREMOVE user

This deletes the UAF entry, but leaves the UIC identifier intact. There are several reasons.

Primarily, you don't lose the textual name on security objects (owner fields, ACLs etc). It also makes it much easier to prevent reuse of the UIC.

For most systems there is sufficient keyspace in UICs to never have to reuse a UIC. Sure, you can use a scrubber, like the one referenced by Hoff, but not reusing the UIC is better assurance that a stale ACE won't ever be misused.

It may make sense to change the identifier string to make it obvious it's expired.

UAF> MODIFY/IDENT/NAME=DISUSER_SOMEUSER SOMEUSER

(although usernames are effectively limited to 12 characters, identifiers are allowed to be up to 31 characters)