Re: Get a user password from RACF.
Well technically the user ID is stored since it is the name of the User profile. Lou Artificial Intelligence is no match for Natural Stupidity On Fri, Aug 19, 2011 at 9:45 AM, Tom Russell tom_russ...@sympatico.cawrote: There is no command that will get a Password from RACF. You can reset it to a known value if you have authority, but you can not display it. Your assumption that there is hash of the password is incorrect. RACF encrypts the user ID with the password, and the resultant ciphertext is all that is stored in the RACF data set. This is done so that neither the user ID nor the password is stored in the clear for perusal by hackers on the RACF data set, or more likely on a backup copy. regards, Tom On 2011-08-19 12:00 AM, IBM-MAIN automatic digest system wrote: Date:Thu, 18 Aug 2011 08:20:42 -0400 From:Chicklon, Thomasthomas.chick...@53.com** Subject: Re: Get a user password from RACF. I am not aware of this being documented anywhere. Maybe someone else can jump in with that info if they have it. Tom Chicklon -Original Message- thanks , Is the literature specifying the HASH algurithm and where the HASH password is located? -- G. Tom Russell “Stay calm. Be brave. Wait for the signs.” — Jasper FriendlyBear “... and remember to leave good news alone.” — Gracie HeavyHand --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/**ibm-main.htmlhttp://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to allocate PDSE's
In the z/OS 1.12 TSO/E Command Reference the keywords for the ALLOC command includes: *DSNTYPE(LIBRARY* *|* *PDS* *|* *HFS* *|* *PIPE* *|LARGE* *|* *BASIC* *|* * EXTREQ* *|* *EXTPREF)* specifies the type of data set to be allocated. *LIBRARY* specifies a partitioned data set extended (*PDSE*). *PDS* specifies a partitioned data set (PDS). *HFS* specifies a UNIX file system. For better performance, do not use this type of data set. Instead, define a VSAM linear data set and define a z/OS file system (zFS) in it. *PIPE* specifies a first-in first-out (FIFO) special file, which is also called a named pipe. If you specify PIPE, you must also specify PATH and not specify DATASET or DSNAME. *LARGE* specifies a large format sequential data set. It can have a size greater than 65535 tracks on a single volume. *BASIC* specifies a basic format sequential data set. It is limited to no more than 65535 tracks per volume, which is about 3.6 GB. *EXTREQ* specifies that the data set must be extended format. It can be sequential or VSAM. It can be striped, compressed format or neither. *EXTPREF* specifies that the data set should be allocated as extended format, if possible. If not possible, allocate the data set as basic format . If you omit DSNTYPE, the type of data set is determined by other data set attributes, the data class for the data set, or an installation default. Lou Artificial Intelligence is no match for Natural Stupidity On Wed, Jul 6, 2011 at 2:00 PM, Ray Overby rayove...@comcast.net wrote: I was looking at my options for allocating a PDSE. They appear to be: -ISPF 3.2 using LIBRARY as Data set name type value. -JCL - DSNTYPE= parameter. You would use other parameters similar to what you would use for a PDS. -SVC 99 in assembler - DALDSNT (DSNTYPE) Text unit appears to allow the specification of PDSE. You would use other parameters similar to what you would use for a PDS. Am I missing any options? It also appears that the TSO ALLOCATE command cannot be used to allocate PDSE's. Is this true? I reviewed the ALLOC command help and could not find a DSNTYPE parameter. Perhaps I missed it. I wonder if the LIKE() parameter might be used? I also looked at the ATTRIB TSO command and did not see a DSNTYPE parameter there either.. Is it true that PDSE's can be allocated on SMS and NON-SMS volumes? I was able to allocate one on a non-sms volume. I have not tried to use the file yet.. --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/**ibm-main.htmlhttp://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OT IBM breaks OSS patent promise, targets mainframe emulator
When IBM announced the patent pledge, they specifically reserved the right to defend itself from attack: IBM has no intention of asserting its patent portfolio against the Linux kernel, unless of course we are forced to defend ourselves, said Nick Donofrio, senior vice president for technology and manufacturing, drawing applause in a speech at the LinuxWorld Conference and Expo. And in the TurboHercules story, who is suing whom? It's not IBM. The complaint against IBM was filed with the EU Commission by TurboHercules. At that exact moment, did they not take themselves out from under the patent pledge's safety umbrella? Lou On Thu, Apr 8, 2010 at 11:33 PM, Ed Gould ps2...@yahoo.com wrote: http://arstechnica.com/open-source/news/2010/04/ibm-breaks-oss-patent-promise-targets-mainframe-emulator.ars -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Fri, Apr 2, 2010 at 8:45 AM, Mark Zelden mzel...@flash.net wrote: On Fri, 2 Apr 2010 10:41:36 +, Bob Shannon bshan...@rocketsoftware.com wrote: We applied the APAR. We protect the SMP data. I'm sort of baffled why IBM felt SAF support was necessary for SMPE. Since we are a development shop in which dozens of people use SMPE, we simply set the access to UACC(READ) which gives everyone access to all of the SMP/E commands. It's not necessary, but I can stretch and see the case where a shop might want to let an ID or group have RECEIVE authority for example, but not let them to do an APPLY or not let them perform admin functions. Perhaps a production userid that does RECEIVE ORDER via a job scheduler on a nightly or weekly basis. For query only, the CSI can simply be protected from update via RACF data set profiles. I'd be mildly curious to know where the requirement came from. The thing is integrity APARs do not come from requirements, they come from exposures that violate IBMs integrity statement. So I would think that the reason behind the APAR has to be deeper than just segregating the use of SMPE. Lou -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Fri, Apr 2, 2010 at 12:27 PM, R.S. r.skoru...@bremultibank.com.plwrote:
W dniu 2010-04-02 16:19, Paul Gilmartin pisze:
On Fri, 2 Apr 2010 10:41:36 +, Bob Shannon wrote:
We applied the APAR. We protect the SMP data. I'm sort of baffled why IBM
felt SAF support was necessary for SMPE.
Grrr
Me either. And since it's called integrity, we'll never know.
It's a pity. I'd like to know.
[...]
What is becoming of the philosophy, Protect resources; don't
restrict access to tools.
/Grrr
I agree with the rule. However I would imagine the following scenario:
multiple rules within SMP/E team. I.e. John can receive the service, but he
cannot APPLY, because it's Fred's responsibility. Both need access to
datasets. Think about granularity. Of course it's my guess only, but not so
wild - see latest SAF changes in ICSF - very reasonable and a (very) little
bit similar to those in SMP/E.
Last but not least: What's a problem gyus??? Do you want it to work in the
old manner? You need to issue 2-3 RACF commands:
RDEF FACI GIM.** DATA('I dont like security for SMPE') UACC(A)
SETR RACLIST(FACI) REF
And voila.
Yes, but since it is an integrity apar and you are now making everything
like it was what 'integrity hole' are you re-opening?
Happy Easter
--
Radoslaw Skorupka
Lodz, Poland
--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru
Sądowego, nr rejestru przedsiębiorców KRS 025237
NIP: 526-021-50-88
Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w
całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją
warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z
dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r.,
może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym
kapitale zakładowym BRE Banku SA będą w całości opłacone.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Any MXI 4.3 Issues on z/OS 1.9/10/11 ?
The only problem that I am aware of is that starting with z/OS 1.9, MXI does not process PCs correctly due to IBM expanding the size of the PC number and MXI not being updated to cope. Lou Artificial Intelligence is no match for Natural Stupidity On Sun, Oct 18, 2009 at 6:30 AM, Michael Cleary michaeljosephcle...@yahoo.com wrote: Greetings, I wanted to see if anyone has experienced or knows of any issues at all with running the freeware MXI 4.3 under z/OS 1.9, z/OS 1.10 or z/OS 1.11? This would include, but not be limited to the following functionality: - MXI standard ISPF panels - MXI server and subsystem - MXI Collecting LPAR Information (MXIU83 exit for RMF or MXIU84 exit for CMF) - MXI Collecting Log Stream Information (MXIU83 exit) - MXI Collecting LLA module fetch statistics (CSVLLIX1/MXILLIX1 exit) - MXI TCP/IP Server - MXI Exception Rules Table - MXI Security Cheers… Michael Cleary -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Long parms ... again (was: Reading DD card information)
The problem is that in many companies the pressure is to make the schedule rather than to write robust code. Additionally, the knowledge base of competent z/OS programmers grows smaller each year. I have encountered numerous cases of this and other 'appalling' coding practices during penetration/integrity testing engagements at customer sites. So whether it irks people, or it is not the correct way to do things is not the issue. The real concern is that it does happen in real life that not all code is written to comply with the rules and therefore security exposures exist. Lou Artificial Intelligence is no match for Natural Stupidity On Thu, Sep 24, 2009 at 8:31 AM, Scott Rowe scott.r...@joann.com wrote: [rant] This whole thread really irks me. Simply the idea that a program might move a variable length string without first checking for limits is just appalling. I would be pretty ashamed if I found I had done that in any of my personal programs, let alone any code I wrote when I was working for an ISV, authorized or not. This is the very type of sloppy code that causes many of Microsoft's security exposures. I thought that we, as a community, had better discipline than that. I know I would never assume that the parm string passed to one of my programs was no longer than 100 bytes, even if there is a JCL limitation, simply because I wouldn't assume that I was always being called from JCL. Even if I checked to be sure I was being called from JCL I wouldn't skip the check, I would still write the one or two more instructions to do the check because I can't be sure that nothing will ever change. [/rant] We now return you to your previously scheduled programming. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Long parms ... again (was: Reading DD card information)
I doesn't have to be an end user interface, and you don't need update access. Almost everyone has read access and can invoke authorized code in authorized libraries. Lou Artificial Intelligence is no match for Natural Stupidity Sent from Gurnee, IL, United States On Thu, Sep 24, 2009 at 11:23 AM, zoswork zosw...@gmail.com wrote: On Thu, Sep 24, 2009 at 11:29 AM, Hal Merritt hmerr...@jackhenry.com wrote: CERT alert? Bugs in authorized programs cause problems all the time. IBM even has a 'red alert' newsletter to quickly inform the community when a bug in their code poses a serious threat. This is a key reason why update access to authorized libraries has to be tightly controlled. Yeah, that was sort of tongue-in-cheek, since it's unlikely to be an end-user interface. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to switch UID under OMVS
Hi Tommy, It appears that both EDPXPER and TEST001 have a uid=0. If this is the case, then what you are seeing is working as designed. If there are multiple uid's with the same value (0 in this case), the name associated with the display of the uid (for instance with as ls -l command) is only guaranteed to be one with that numeric uid. There is no guarantee for the name to be a name associated with a specific instance of the numeric uid. Lou Losee On 8/28/07, Tommy Tsui [EMAIL PROTECTED] wrote: Hi all, Anyone know how to switch the UID under OMVs. I try to use SU but failed. #id uid=0(EDPXPER) gid=2(SYS1) when I invoke using the TSO OMVS with userid TEST001, it always show the EDPXPER and cannot be changed to other TEST001. Anything need to be set... thanks for help Tommy -- 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 -- Artificial Intelligence is no match for Natural Stupidity -- 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
Re: Changing logon behavior using RACF
I believe TSO write the command last used during logon to the TSO segment when the user logs off. Since you did not issue the command when you logged on, the command you added was overwritten when you logged off. Lou Losee atsec information security corp. On 2/9/07, Schwarz, Barry A [EMAIL PROTECTED] wrote: snip -Original Message- From: Steve Rawlins [mailto:snip] Sent: Friday, February 09, 2007 9:00 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Changing logon behavior using RACF snip 2. For the TSO CLIST change. I have tried updating the TSO command. EX USER.CLIST(STARTUP) RACF seems to have taken this COMMAND update, but when I log-off and log-in again - it's gone. As if I'd never tried updating RACF this way. -- 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 -- Artificial Intelligence is no match for Natural Stupidity -- 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
Re: TCP/IP
Hi Phillip, The command vary tcpip,,purgecache should do the trick, see: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1c250/1.6.7?ACTION=MATCHESREQUEST=ARPTYPE=FUZZYSHELF=F1A1BK80.bksDT=20060622162258CASE=searchTopic=TOPICsearchText=TEXTsearchIndex=INDEXrank=RANKScrollTOP=FIRSTHIT#FIRSTHIT Lou Losee atsec information security On 1/31/07, Philip Miscione [EMAIL PROTECTED] wrote: FYI Is there a way I can clear the ARP cache on the TCP/ip stack on the Mainframe without shutting down TCP/IP ? Thanks in advance Philip A. Miscione Sr Project Leader Barnes Noble, Inc. email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Phone: 516-338-8227 Fax : 516-338-8487 -- 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 -- Artificial Intelligence is no match for Natural Stupidity -- 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
Re: TCP/IP
On 1/31/07, Philip Miscione [EMAIL PROTECTED] wrote: Will this work on on a z/OS 1.4 System ? snip Don't know for sure - the Summary of changes in the pub only goes back to 1.6. A sure way to find out is to try it. Lou Losee atsec information security -- 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
