  Extending OpenVMS Password Security? 
 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.)
 
