|
Chuck Lewis wrote on 08/12/2005 03:37:54 PM: > OK, it reset it to QSECOFR in upper case and it is case sensitive (i.e. the > field for password does not default to upper case like the user ID). > > So I get in and it says the password has expired. Correct. That is why in an earlier not in this thread that Rob suggested this: >>STRSST >>7. Work with system security >>Allow a service tools user ID with a >> default and expired password to change >> its own password . . . . . . . . . . . . . . 1 1=Yes, 2=No I disagree with that suggestion because it makes your system more vulnerable. If you have physical access to your system you can still use DST without IPLing the system. Then once you change the password from within DST you can use it in STRSST. The security vulnerability I was referring to is described below. One devious install exit program trick is to bypass the security policy of the system by using the virtual terminal API to invoke the Display Alter Dump function of STRSST and then using it to change a program from user state to system state. Since the install exit program could use the Change IBM Service Tools Pwd (CHGDSTPWD) command to change that password, we need something else to protect the system. The solution is a new V5R2 SST security option called "Allow a service tools user ID with a default and expired password to change its own password". When this option is set to 2 (No) a user cannot sign-on to SST with an expired and default password. This means that after CHGDSTPWD is used the QSECOFR service tool user ID can only sign-on to DST where they will be forced to change their password. Since virtual terminal API cannot be used to start DST the system can be fully protected from devious install exit programs changing system values. So to maintain maximum security and control while installing new applications, set your system values to the way you want them, and then use SST to set both the "Allow system value security changes" and the "Allow a service tools user ID with a default and expired password to change its own password" options to 2 (No). Ed Fishel, edfishel@xxxxxxxxxx
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.