System_services to remove a VMS account

[Toine_1]

Hi,

I want to write a Fortran program that deletes VMS accounts that are disabled and not used for 180 days.

Is there a system services that can be used.
$REM_ACCOUNT ???

/Toine

[Richard J Maher]

Hi Toine,

Just open it as any other RMS file (making sure to specify "allowing all" how ever that is achieved in fortran and then just use an RMS fortran "delete" verb after verifying it is the username you desire.

Don't lock the record as I don't think any other utilities are prepared for a record-lock on a UAF record. Don't worry there's no locking between $getuai and $setuai either

Who's gonna run it? Try $install/priv=noall if you only want /sys/exec logical name use.

Cheers Richard Maher

PS> There is a should of thought that Usernames should never be delete. Prevent the re-use of UICs etc.

[Hoff · Accepted solution]

No such system service exists.

The supported path to this end state is via AUTHORIZE commands. Ugly, yes, but functional.

Traversing the SYSUAF database (wildcard) is available only via RMS calls. And if you're so inclined, yes, you can delete the entry directly out of SYSUAF the same way.

The usual path for aging usernames is to disable the username entry, as deleting the username disconnects the context and ownerships on existing objects. (This can lead to collisions, if entries with matching UICs are added later.) Or you can disable the user in the LDAP databases or such, if you're using external authentication. Or to use account expiration, and move it forward.

I have some user management tools and topics available:

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

Not written in Fortran, though. And no deletions.

[Steve Reece_3]

There isn't a system service that I'm aware of, though you could write a DCL script in your Fortran code and then use SNDJBC to submit the job to a queue.
Agree on the idea of not reusing accounts due to the risks of reusing UICs and thereby assigning ownership to existing objects. That, of course, depends on what your system model is since it could be that all of the users or groups of users share UICs anyway.

Steve

[Robert Gezelter]

Toine,

Strange. ITRC seems to have not caught my earlier post.

I recommend extreme caution. There are several issues here, some of which Hoff has mentioned in his earlier post.

First, "disabled and and not used for 180 days" is a true statement for an account that is disabled after 180 days the moment it is disabled. Unless there is an unmentioned part of the protocol, this means that a dormant account will be automatically deleted at 180 days.

Second, safely deleting something is more than merely deleting the account. One should ensure that the UIC is not available for re-use, to avoid inadvertently granting access to resources based on stale access control elements. Additionally, what happens to the files directly in that directory tree? What are their preservation requirements?

What about accounts that are only used at certain times of year (e.g., year end) and may be disabled in the interim to avoid accidents? One must carefully walk through all of the possibilities.

If I were faced with this request, I would make sure that I had some written documentation of the implications, and a signature from management taking responsibility for this implementation.

If I were implementing something, I would integrate into a report/auditing mechanism that did a SHOW/FULL of the UAF entry, and archived the account profile and the directory contents to an archive medium. I would automatically invoke AUTHORIZE from a DCL script (as I have done many times) or using SPAWN.

If this is a financial or other organization subject to compliance issues, I would check with BOTH Human Resources and Compliance as to their other requirements.

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

[Toine_1]

Thank you Richard, Hoff, Steve and Bob,

I made this program because we had an external audit and the result was that we had some users that were not logged on since 180 days. We got a remark that these uesers should be deleted when the are not used.

But it is good that you all replied with excellent answers.

I will use $SETUAI system service to disable accounts.

I will not delete users for the moment.

P.S.
You tips for OpenVMS usernames are well documented Hoff.

/Toine

[John McL]

If your users access the system via means other than a VMS login there's a good chance that the timestamp of their access won't be recorded.

This certainly used to be true with the Pathworks interface to PC's and I have a feeling that it may also be true now of ftp access and perhaps of access controlled via ACME.

(Unfortunately it's rare to find an IT auditor who understands VMS. They tend to work from a checklist that was devised for some other operating system.)

[Hoff]

Various corporate "security" auditors tend to work from checklists, and those checklists tend to target other operating system platforms, and blindly following the suggestions from those checklists is useful when you want to make the auditors and the managers (and yourself) all look bad while also disrupting and destabilizing your system operations. Often while decreasing - yes, decreasing - your system security, too.

The typical security checklist here is found in the appendix of the OpenVMS System Security manual; I have some information and links to this and to other resources posted at: http://labs.hoffmanlabs.com/node/43

[Hein van den Heuvel]

>> I will not delete users for the moment.

Just some hints...

1) to satisfy auditors it is probably good enough to just delete the SYSUAF records. You migh want to keep the RIGHTSLIST entries to remember who used to use them, ans to reserve the UIC against too early reuse

2) to 'properly' delete a user you may want to clean up much more: SYSUAAF, RIGHTLIST, MAIL_PROFILE, user-directories, ACE's

3) Instead of deleting records from SYSUAF outright, consider copying them to a parallel file. Just create a fresh SYSUAF by defining a (process) logical for SYSUAF pointing to a new place: SYS$SYSTEM:.DAT
Now go into AUTHORIZE and have it generate a fresh empty file by answerrign YES to:

$ mcr authorize
%UAF-E-NAOFIL, unable to open system authorization file (SYSUAF.DAT)
-RMS-E-FNF, file not found
Do you want to create a new file?

You can of coarse also use FDL to create a fresh file. Use my FDL$GENERATE tool on the live file, or ANAL/RMS/FDL on an old or back/igno=inter copy. If you use an FDL, you may want to consider to ALLOW DUPLICATES on teh primary key... for this purpose.
Now just use DCL to copy records before deleting.
After that you can use the regular AUTHROIZE tool to re-visit the deleted records if/when needed.

:
$open /share=write /read /write sysuaf sysuaf.dat
$open /share=write /read /write remuaf SYSUAF_REMOVED_USERS.dat
:
$read/delete/key= sysuaf record
$write/symbol remuaf record
:

Hth,
hein.