- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- System_services to remove a VMS account
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-07-2009 01:17 PM
тАО11-07-2009 01:17 PM
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
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-07-2009 03:26 PM
тАО11-07-2009 03:26 PM
Re: System_services to remove a VMS account
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-07-2009 06:46 PM
тАО11-07-2009 06:46 PM
SolutionThe 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-08-2009 05:04 AM
тАО11-08-2009 05:04 AM
Re: System_services to remove a VMS account
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-08-2009 06:45 AM
тАО11-08-2009 06:45 AM
Re: System_services to remove a VMS account
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-08-2009 09:37 AM
тАО11-08-2009 09:37 AM
Re: System_services to remove a VMS account
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-08-2009 01:13 PM
тАО11-08-2009 01:13 PM
Re: System_services to remove a VMS account
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-09-2009 04:53 AM
тАО11-09-2009 04:53 AM
Re: System_services to remove a VMS account
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-09-2009 08:31 AM
тАО11-09-2009 08:31 AM
Re: System_services to remove a VMS account
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=
$write/symbol remuaf record
:
Hth,
hein.