|
HP OpenVMS Systemsask the wizard |
|
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])
. .
.
AuthorizedPrivileges: .
DefaultPrivileges: .
.
Identifier Value Attributes
IS_GROUP002
%X80010038
-----------------------------------------------
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.)
|