Discussion:
suggestion about user account files
Add Reply
brendan welch
2017-05-02 18:47:17 UTC
Reply
Permalink
Raw Message
It has been over 20 years since I dealt with anything
like this, so please let me know if I am TOTALLY
obsolete.

(My introduction to VMS management was on a September
day at a university, where I was told to add
thousands of accounts. I later worked on a Unix system
for a large service provider, and had this same problem,
especially when on the telephone, dealing with stolen
passwords or compromised accounts.)

When a manager brings a user's file on-screen, there should
be 1 or 2 fields, usually empty, directly after the
username. The first should tell you, maybe in screaming
color, if there has been any history of problems with
the account. The second could be administrative
comments, or a link thereto.

So, if applicable, I suggest that the "new" workers
on VMS be allowed to make such changes.
Stephen Hoffman
2017-05-03 15:38:52 UTC
Reply
Permalink
Raw Message
When a manager brings a user's file on-screen, there should be 1 or 2
fields, usually empty, directly after the username. The first should
tell you, maybe in screaming color, if there has been any history of
problems with the account. The second could be administrative
comments, or a link thereto.
So, if applicable, I suggest that the "new" workers on VMS be allowed
to make such changes.
Not entirely sure where you're headed with this... a product
suggestion for VSI, maybe?

OpenVMS doesn't have LDAP integration beyond single sign-on, nor
account or device provisioning, nor self-hosted password change
support, nor particular integration with distributed security and
logging...

Closest user interface display to what you're discussing is probably
either via LDAP-accessing interfaces and tools common on other
platforms, or maybe the long-deprecated OpenVMS Management Station
(OMS, Argus) in the OpenVMS environment. I'd really not want most
folks to have to use AUTHORIZE, as that's a rather cryptic user
interface and with more than a few ways to get into trouble, and it's
limited in what it can do and show.

OpenVMS doesn't integrate with LDAP (beyond the single-sign-on password
and whether the account is enabled or not), and LDAP would be the usual
location for that per-user data. Either via Open Directory or Active
Directory or a self-hosted local LDAP database.

SYSUAF and RIGHTSLIST and the rest of the traditional authentication
database is an utter pain to make any changes, too. This due to
mixed-version clusters and the use of RMS records, and due to apps that
read the files directly.

Universities and businesses usually end up writing tools for this. I
wrote a registration system for OpenVMS, too. Not that it covers most
of what you're mentioning here about problems, though.
--
Pure Personal Opinion | HoffmanLabs LLC
brendan welch
2017-05-03 19:20:00 UTC
Reply
Permalink
Raw Message
When a manager brings a user's file on-screen, there should be 1 or 2
fields, usually empty, directly after the username. The first should
tell you, maybe in screaming color, if there has been any history of
problems with the account. The second could be administrative
comments, or a link thereto.
So, if applicable, I suggest that the "new" workers on VMS be allowed
to make such changes.
Not entirely sure where you're headed with this... a product suggestion
for VSI, maybe?
Yes, that is what I was thinking. I just was not sure that I properly
understand the whole VSI thing.
.
.
.
SYSUAF and RIGHTSLIST and the rest of the traditional authentication
database is an utter pain to make any changes, too.
I had even forgotten the name SYSUAF, but that is about what I was
thinking. My whole thinking about this suggestion centers around
what SYSUAF brought up, when looking up a user.
Universities and businesses usually end up writing tools for this.
Yes, I finally had found and inherited some tools in DCL and Basic.
j***@yahoo.co.uk
2017-05-03 19:41:16 UTC
Reply
Permalink
Raw Message
Post by brendan welch
When a manager brings a user's file on-screen, there should be 1 or 2
fields, usually empty, directly after the username. The first should
tell you, maybe in screaming color, if there has been any history of
problems with the account. The second could be administrative
comments, or a link thereto.
So, if applicable, I suggest that the "new" workers on VMS be allowed
to make such changes.
Not entirely sure where you're headed with this... a product suggestion
for VSI, maybe?
Yes, that is what I was thinking. I just was not sure that I properly
understand the whole VSI thing.
.
.
.
SYSUAF and RIGHTSLIST and the rest of the traditional authentication
database is an utter pain to make any changes, too.
I had even forgotten the name SYSUAF, but that is about what I was
thinking. My whole thinking about this suggestion centers around
what SYSUAF brought up, when looking up a user.
Universities and businesses usually end up writing tools for this.
Yes, I finally had found and inherited some tools in DCL and Basic.
Can you paint a bit more of a picture please? I'm not sure I
understand enough of your description so far. That said...

It's a decade or two since serious sites (especially multi-vendor
ones) started to use things like helldesk support systems,
ticket-tracking systems and such like, either free ones or
commercial ones. I don't recollect there being a VMS-specific one,
maybe others do. Would such a system address your requirements?
brendan welch
2017-05-03 20:26:23 UTC
Reply
Permalink
Raw Message
Post by j***@yahoo.co.uk
Can you paint a bit more of a picture please? I'm not sure I
understand enough of your description so far. That said...
It's a decade or two since serious sites (especially multi-vendor
ones) started to use things like helldesk support systems,
ticket-tracking systems and such like, either free ones or
commercial ones. I don't recollect there being a VMS-specific one,
maybe others do. Would such a system address your requirements?
I feel that the first few paragraphs of my original post
delineate it all. I have been out of touch for 20 years.
I have NO system requirements.

I think it is something which perchance VSI could think about.

========================
and that reminds me of another pet peeve of mine, the prompt
for entering your password a second time (Again, senility
strikes; what was that word?)

I used to have to translate computereze into English, and
then into English as a second language for many foreign
students. That whole subject was indeed discussed in
comp.os.vms, before some of you were born. I ended up,
successfully, into my only binary editing of a system
file, to make the prompt read something like
"Enter that same password again". and every time a tape
came out with a newer version of VMS, I would have to
do that same binary editing again.
Stephen Hoffman
2017-05-03 21:43:56 UTC
Reply
Permalink
Raw Message
...and that reminds me of another pet peeve of mine, the prompt for
entering your password a second time (Again, senility strikes; what was
that word?)
Ayup. Slightly cryptic phrasing.

$ SET PASSWORD
Old password: HONCHO
New password: BIG_ENCHILADA
Verification: BIG_ENCHILADA

FreeBSD uses "Retype new password:" there, rather than confirm or
verify or similar phrasing.
I used to have to translate computereze into English, and then into
English as a second language for many foreign students. That whole
subject was indeed discussed in comp.os.vms, before some of you were
born. I ended up, successfully, into my only binary editing of a
system file, to make the prompt read something like "Enter that same
password again". and every time a tape came out with a newer version
of VMS, I would have to do that same binary editing again.
VMS is replete with jargon, certainly. We've been told by some folks
around here in comp.os.vms that VSI should not use now-common terms and
concepts in the documentation, too. If that tech-writing approach
sticks, I don't hold out much hope of support for making the platform
easier to understand. But I digress. As for the command line, I
don't see OpenVMS servers selling into a student-focused or end-user
market for the foreseeable future, nor are servers in general seeing
numbers of folks logging directly into the servers as was the
traditional timeshare command-line interface approach, nor does it seem
likely that the command line will itself ever become popular anew
outside of some pretty specialized environments. We're not going back
anywhere near as far back as the Y2K timesharing computing model, much
less any earlier. In various common environments, even application
development is moving away from the command line. Integration with
tools to edit LDAP directories, and tools that allow self-service and
helpdesk password resets within LDAP or local or otherwise, and other
such... yes. Better OpenVMS integration with LDAP services, yes.
Better and simpler and clearer terminology where that's feasible too,
certainly.
--
Pure Personal Opinion | HoffmanLabs LLC
Bob Koehler
2017-05-04 13:14:32 UTC
Reply
Permalink
Raw Message
Post by Stephen Hoffman
FreeBSD uses "Retype new password:" there, rather than confirm or
verify or similar phrasing.
I'm always amuzed that Linux prompts for "UNIX password".
Stephen Hoffman
2017-05-03 19:59:25 UTC
Reply
Permalink
Raw Message
Post by brendan welch
Post by Stephen Hoffman
When a manager brings a user's file on-screen, there should be 1 or 2
fields, usually empty, directly after the username. The first should
tell you, maybe in screaming color, if there has been any history of
problems with the account. The second could be administrative
comments, or a link thereto.
So, if applicable, I suggest that the "new" workers on VMS be allowed
to make such changes.
Not entirely sure where you're headed with this... a product
suggestion for VSI, maybe?
Yes, that is what I was thinking. I just was not sure that I properly
understand the whole VSI thing.
VSI acquired rights to OpenVMS from HPE, and have already forked and
have started making updates and changes to VSI OpenVMS, and are
planning to continue work on VSI OpenVMS including a port to x86-64,
and have added support for new Itanium servers not supported by HPE
OpenVMS V8.4. This transition as the HPE roadmap for OpenVMS reaches
its end at the end of 2020. V8.4 and earlier is HPE, releases after
V8.4 are VSI. VSI OpenVMS V8.4-2L1 is the current release.
Post by brendan welch
Post by Stephen Hoffman
SYSUAF and RIGHTSLIST and the rest of the traditional authentication
database is an utter pain to make any changes, too.
I had even forgotten the name SYSUAF, but that is about what I was
thinking. My whole thinking about this suggestion centers around what
SYSUAF brought up, when looking up a user.
The basic design of SYSUAF and RIGHTSLIST and AUTHORIZE and the rest
haven't appreciably changed in an aeon or two, and changes — while
possible — are constrained by RMS and tradition and mixed-version
clusters and upward-compatibility. I've previously suggested a
wholesale migration to LDAP (Active Directory or Open Directory or
otherwise) and deprecating SYSUAF et al, but that's a large project and
likely well outside of what will contribute to VSI revenues over the
next five or ten years. In the interim, those of us that need these
tools are going to be maintaining our own front-ends for SYSUAF and
AUTHORIZE and the rest; whether self-service password management,
migrating entries over from LDAP or otherwise. If you've a large
opportunity hinging on this, check with VSI directly, or maybe NEWUSER
(the front-end I'm dealing with) or another existing tool can be
modified to provide this.
--
Pure Personal Opinion | HoffmanLabs LLC
GerMarsh
2017-05-04 10:07:11 UTC
Reply
Permalink
Raw Message
Post by brendan welch
It has been over 20 years since I dealt with anything
like this, so please let me know if I am TOTALLY
obsolete.
(My introduction to VMS management was on a September
day at a university, where I was told to add
thousands of accounts. I later worked on a Unix system
for a large service provider, and had this same problem,
especially when on the telephone, dealing with stolen
passwords or compromised accounts.)
When a manager brings a user's file on-screen, there should
be 1 or 2 fields, usually empty, directly after the
username. The first should tell you, maybe in screaming
color, if there has been any history of problems with
the account. The second could be administrative
comments, or a link thereto.
So, if applicable, I suggest that the "new" workers
on VMS be allowed to make such changes.
There is a user data area within each UAF record but that is rather small and cannot be accessed via AUTHORIZE. You could put some external link reference in there though. It has been used to store recertification data and stuff like that.
d***@gmail.com
2017-05-04 14:00:48 UTC
Reply
Permalink
Raw Message
Post by GerMarsh
There is a user data area within each UAF record but that is rather small and cannot be accessed via AUTHORIZE. You could put some external link reference in there though. It has been used to store recertification data and stuff like that.
255 bytes. Available via the $SETUAI/$GETUAI system services.
Stephen Hoffman
2017-05-04 16:45:58 UTC
Reply
Permalink
Raw Message
Post by GerMarsh
There is a user data area within each UAF record but that is rather
small and cannot be accessed via AUTHORIZE. You could put some external
link reference in there though. It has been used to store
recertification data and stuff like that.
I'd avoid that particular storage area, and would store the application
data somewhere else. Why? Because that SYSUAF storage area is
entirely uncoordinated. Any random app with sufficient privileges
can choose to use to stomp on the data from some other
randomly-selected application sharing that area. Then there's the
discussion about cleaning up that data, if the app gets removed. Then
there's why an app needs write access into SYSUAF and whether that app
is robust against exploits or just opens up a path for attackers.
Then there's adding to the quantity of audits and alarms and sorting
through all that dreck as the app reads and writes SYSUAF, as many
sites have some combination of audits and alarms enabled on SYSUAF.
Better to store application data in the LDAP directory, or store the
application data in an application-specific database when LDAP is not
in use. That SYSUAF storage area should have been deprecated an aeon
or two ago.
--
Pure Personal Opinion | HoffmanLabs LLC
Loading...