On 10/14/2009 03:44 PM, Rick Fochtman wrote:
>>> --------------------------<snip>------------------------------
>>>>> But you still need to prevent testers from submitting jobs with a
>>>>> production USERID. We used a TSO exit to remove USER/PASSWORD parms
>>>>> from the JOB statement. Got a better idea?
>>>>>
>>>>>
>>>> Sure; don't have passwords for production jobs. Only allow them to be
>>>> submitted by a user with surrogate access to the production user id.
>>>> Only
>>>> give that surrogate access to user ids that need it, e.g., scheduler.
>>>>
>>> ----------------------------<unsnip>-------------------------------
>>> We eventually did just that. I set the password to a "private" value and
>>> never told anyone what it was. Surrogate access was the ONLY way to
>>> submit a production job, either by the automation or the production
>>> support staff.
>>>
>>> Rick
>>>
>>
>> But if you're going to use the userid in that fashion, it makes sense to
>> go one step further and make it a RACF "PROTECTED" userid. Then there
>> is no password to "forget" or protect, and better yet the userid cannot
>> even be used in a context where a password would be required.
>> Otherwise, someone can either intentionally or accidentally execute a
>> denial-of-service attack against your production job streams by trying
>> enough bad passwords to revoke the userid and prevent production batch
>> from running. Also, "PROCTECTED" will prevent a rarely used production
>> userid from getting auto-revoked from excessive days from last use.
>>
>>
> -----------------------------------------------------------------------------------------------------
>
> True enough, but the "PROTECTED" attribute didn't exist when this was
> all put in place.
>
> Rick
>
Granted. You are always constrained by what's available. We have gone
through three stages since 1985 as RACF enhancements were added:
We started before the SURROGAT class was available with production
userid passwords only recorded long enough to get them embedded in
encrypted form in a program that was only available to the job scheduler
and a few other applications that needed to run jobs under production
userids.
When SURROGAT became available, we were able to phase out our encrypted
password handler for SURROGAT profiles.
When "PROTECTED" became available, it took us a while before we
realized that it could solve a few remaining problems that rarely but
occasionally disabled some production jobs. Adding the "PROTECTED"
attribute to production userids was completely transparent, because by
then SURROGAT profiles had already eliminated all legitimate usage of
production job userids in a context where the password was needed.
Joel
--
Joel C. Ewing, Fort Smith, AR [email protected]
----------------------------------------------------------------------
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
