The Question is:
I am trying to write a FORTRAN
program that allows a select group of users to reset passwords for people in
their area. Like New York, Hong Kong , California. If you are a New York user
you can only reset a
New York users password. Every one is in the same UIC group. The users have a
identifier granted to them that says they are either New York , Hong Kong ,
California. If I was writing a DCL program I could do a
$ MC AUTHORIZE LIST INxxxxxx
Username: INxxxxxx Owner: xxxx,xxxx
Account: GFT UIC: [100,1111] ([INxxxxxx])
Identifier Value Attributes
Then search that file for the identifier IS_GROUP002 Then if both users had
the identifier IS_GROUP002 he could then reset the password. If they didn't
have the same identifier he could not reset the password.
I have the rest of the program working.
So the question is how do I get
the identifier that a user has using FORTRAN?
The Answer is :
The intended and available mechanism for this particular purpose involves
the GRPPRV privilege, and the specification and use of unique UIC groups.
Users within the UIC group possessing GRPPRV privilege are entrusted to
perform management tasks for the other members of the same UIC group.
(System services such as SYS$SETUAI permit users with GRPPRV to perform
authorization-related operations on other members of the same UIC group.)
If you wish to enforce your own subsetting within a particular UIC group,
the use of the OpenVMS system service SYS$CHECK_ACCESS (third-party check;
"can user X access object Y?") or SYS$CHKPRO (first-party check; "can the
current user access the specified object?") would be one common approach.
The system service call where the object targeted by the call would be
coded permit access by holders of the specified identifier or by users
with sufficient privileges. The object would likely match the profile
of the SYSUAF object, though with the addition of access permitted via
the possession of the specified identifier of course.
An explicit search for holders of the identifier via calls to services
such as SYS$FIND_HELD is also clearly possible, but misses cases where
the particular user has additional privileges that would normally grant
the required access.
Other alternatives include verification of the user's identity using
other locally-available data, mechanisms (web pages or captive logins
with dedicated login procedures) which would then directly permit the
individual end-user to reset their own password. (The temporary (and
random) password could also then be made available to the user via
telephone messaging or other out-of-band mechanism.)