Carlos Cordero wrote:
Colleagues,
Somebody knows if there is an alternate way to proctect a password of a userid, this means that the
userId is for a GroupWise application; but as always happen, this user sometimes is used to try to
signin to the platform (this "must be" not allowed by "policies") due to the
reason that is the userid of the product.
Actually this user has the RACF Pass-Interval N/A but you agree that if anybody
knows this user and try to use to signin on the application after 3 attempts
must be revoked; this represents a big problem because many services and
applications uses this userid to interact with GroupWise application.
I´ve thinking in the properly options of z/OS to search for a schema that
allows to protect the userid and the password DO NOT be ruled by a attempts
policie (Global options, APFs, etc); in few words, if anybody try to use this
user, after many attepmts the userid do not get a revoked status, it is this
possible?
What I've done in the past is this:
1. Using the RACF Started Tasks table, assign a Userid-Password to your
automation product.
2. Let these values propogate to any job that is submitted by your
automation product.
3. Provide a started task, again also in the table, with a
Userid/Password, that can RESUME the userid/password that you choose in
step 1. Note that password information is NOT needed for a ALU xxx
RESUME command.
4. If users attempt to submit jobs and cause the production
userid/password to be revoked inappropriately, run the started task
created in step 3.
5. Severely chastise anyone who can be proven to attempt this sort of
userid/password abuse. In my company, they were immediately "promoted to
the sidewalk" (fired). That may or may not be appropriate for your
organization.
Note that if you adopt this approach, you can remove userid/password
information from all jobs submitted by your automation product, as long
as you assure that appropriate access is permitted to the automation
product's userid/password. (Userid/password propogation via JES2)
Note also that if you take this approach, no user need EVER know the
userid/password combination for your production workload. You can use
similar steps to assure that the STC userid/password combination need
never be disclosed, either.
Feel free to contact me privately if you want more detail. Happy to help.
--
Rick
--
Remember that if you’re not the lead dog, the view never changes.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
