Re: Full z/OS SPOOL
Ok. I must have missed it somewhere that the OP is perhaps using ADCD, but he said he is using VM to access his JES2? So, can you run ADCD as a guest under VM? The OP said that he is running in Dallas. It is my understanding (having never worked on any of their systems) that Dallas provides ADCD systems to vendors, also early code for new releases. In the description I have seen of that early access, it was clearly an ADCD system. Like any z/OS system, it can run under VM. Automation is your friend (just careful not to purge sensitive jobs...). ;-) ADCD systems don't have automation configured. Ours came with NetView, and I could see remnants of SA/390, but nothing was set up to actually work. In my copious spare time, I have attempted to set up NetView (with the help of a former colleague), I just haven't gotten around to attempting a logon to it, much less to use it for actual automation on our system. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Full z/OS SPOOL
Elardus, Just curious, at what z/OS level are you? I'm asking because that APAR is somewhat old, but I'm sure that local fix also mentioned by Bob should help you out until you can fix the init deck. Are other LPARs using the same JES2? If so, you could try out the local fix or purge job entries? Welcome to the wonderful world of ADCD systems! (Which is what I understand Dallas is using.) ADCD systems come with a teeny tiny spool, and most parms in the init deck are set so low that it just functions on a lowly loaded system. After the second or third real 100% spool shortage I substantially increased not only spool and related parms, I also had to go through checkpoint reconfig to accomodate the larger spool values. And ever since, I keep an eagle eye on any HASP050* message. And on spool usage. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Full z/OS SPOOL
Barbara Nitz wrote: Welcome to the wonderful world of ADCD systems! (Which is what I understand Dallas is using.) ADCD systems come with a teeny tiny spool, and most parms in the init deck are set so low that it just functions on a lowly loaded system. After the second or third real 100% spool shortage I substantially increased not only spool and related parms, I also had to go through checkpoint reconfig to accomodate the larger spool values. Ok. I must have missed it somewhere that the OP is perhaps using ADCD, but he said he is using VM to access his JES2? So, can you run ADCD as a guest under VM? About those low, very ultra low values, yes, I also experienced that on JES2, low TSO logons space, small RACF db, small VTAM and TCP/IP settings, etc. Annoying of course. The small spool size and the parameters have indeed in the past a negative impact on my SMP/E Team where they XMIT (sloww!) large datasets (DFDSS dumps) to a small LPAR causing lockup of JES2 and that LPAR just froze to a standstill. Thats where I showed them how to do a FTP to avoid using a temp space on JES2 spool. Whenever a spool is getting full quickly, I'm always thinking about a runaway train. ;-) http://en.wikipedia.org/wiki/Runaway_Train_%28film%29 [1] And ever since, I keep an eagle eye on any HASP050* message. And on spool usage. Automation is your friend (just careful not to purge sensitive jobs...). ;-) Groete / Greetings Elardus Engelbrecht [1] - %28 is ( and %29 is ). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: what is the diffenet between volcount and Dynamic Volume Count
W dniu 2015-01-04 o 08:08, ibmmain pisze: Hi all Could you explain what is the diffenet between volcount and Dynamic Volume Count ? I am very confused how to use volcount and Dynamic Volume Count DVC is DYNAMIC. That means you can change it for existing datasets. Volcount is static. It is done during creation of dataset and ...can also be changed. ;-) But the change is harder: for DVC it's enough to change dataclass definition and all datasets with the class are affected. For static volcount you have to issue IDCAMS command for each dataset you want to change. -- Radoslaw Skorupka Lodz, Poland --- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.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.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: what is the diffenet between volcount and Dynamic Volume Count
There is one more important difference: this is an (the first) occasion where Dataclass attributes are used during the life of a dataset. This means that altering the DVC attributes of a dataclass will have effect on already existing datasets. Before, the Dataclass attributes were only applied to the dataset at its creation time. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Dean Montevago Sent: 04 January, 2015 15:35 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: what is the diffenet between volcount and Dynamic Volume Count Using volcount creates the UCB entries in the catalog at allocation taking up space in the catalog upfront, where DVC creates the UCB as an additional volume is needed. I set volcount to 1 and specify a value for DVC, and have not had any issues. I too am looking for the reason why you would choose volcount over DVC. On Sun, Jan 4, 2015 at 2:08 AM, ibmmain ibmm...@foxmail.com wrote: Hi all Could you explain what is the diffenet between volcount and Dynamic Volume Count ? I am very confused how to use volcount and Dynamic Volume Count Thanks a lot! Best Regards, Jason Cai -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Dean Montevago -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SDUMPX questions
What is the exact format of the LIST64 parameter. It is not clear if the counts and lengths include a slack four bytes (like the SUMLIST64 parameter). SUMLIST64 does have 4 reserved bytes after the field containing the length. LIST64 does not. The description in the book really is correct in saying that the LIST64 format is analogous to the LISTD format. The first word is the only length field. The book indicates correctly When LIST64=list addr is specified, the first fullword of the storage list contains the number of bytes, including the first word, in the list. I don't understand why you mention the counts since those are unrelated to lengths. I will suggest an addition to The LIST64 storage list format is exactly analogous to the LISTD storage list format of something like with 8-byte-long starting and ending addresses As SDUMPX with a DCB only does HOME, will a SVC entered SDUMPX ever have the ECB posted or will the dump always be complete upon return from the DCB. I don't know what upon return from the DCB means. Perhaps you meant from the SVC? In any case, your or does not represent mutually exclusive conditions. When you return from the SVC (assuming a valid return code), both the ECB will be posted and also the dump will be complete if it is a synchronous dump. The doc for ECB does mention (under A-type) posted on completion of a scheduled dump. I suspect that that is true but a bit misleading, in that the ECB is (very likely, but it would need to be verified) posted on completion of the dump, whether the dump is scheduled or synchronous. I did notice under ECB Note that these interfaces will not be driven if the call to SDUMPX results in a non-zero return code.. I believe this is incorrect. It should say ...results in a return code greater than 4 which matches the wording for return code 04 that describes the ECB being posted for that case. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
On Sun, January 4, 2015 17:56, Paul Gilmartin wrote: (why?) and must reconnect. Is there any way to get directly back to IKJ56700A? PA1. You won't get back to IKJ56700A but you can enter LOGON userid there without a reconnect. Regards, Boris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Querying the contents of the Access List
On Sat, 3 Jan 2015 01:31:14 -0500, Jim Mulder d10j...@us.ibm.com wrote: Was it the task's DU-AL that got full? Or was it actually the address space's PASN-AL? I don't know for sure, but I would guess that it's the DU-AL, we have a call scheduled to discuss it this week. If it was actually the PASN-AL, you may want to make sure that your vendor is aware of the recent changes made for APAR OA45768, with additional discussion in Info APAR II14766. The vendor is IBM, but I realize that doesn't insure anything. Dana -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
Paul Gilmartin wrote: My logon PROC is set up to bypass any solicitor and put me directly at: IKJ56700A ENTER USERID - userif Review your solicitor to eliminate this pain. Is there any way to get directly back to IKJ56700A? Or even better, to change the Userid and continue with the logon? As Boris Lenz kindly suggested, use PA1. You will see LOGON on a clean 3270 screen, just retype LOGON followed optionally by your right id and you're in. If you don't use id after LOGON, you get that familiar IKJ message as usual which is waiting for your input. SSHD doesn't tell me that 0123456789 is unknown to RACF, or even that it's syntactically invalid. I can't use SSH to probe for known user IDs. I believe this is WAD. RACF won't tell you via TSO/SSHD *why* your logon is rejected, it simply says your attempt is invalid. That topic of not telling the reason of failed logon was covered in RACF-L in the past. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
RACF won't tell you via TSO/SSHD *why* your logon is rejected, it simply says your attempt is invalid Ah, but it does, right? Is that not the whole point of the topic? If I say LOGIN FOO I can tell right away that FOO is an invalid userid (from the appearance of the login screen). There is nothing to stop me from trying every possible userid from $ to Z999 in an automated fashion to enumerate the userid's of the LPAR (other than time, there being around 5 * 10^11 of them). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Monday, January 05, 2015 6:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CANCEL TSO Logon? Paul Gilmartin wrote: My logon PROC is set up to bypass any solicitor and put me directly at: IKJ56700A ENTER USERID - userif Review your solicitor to eliminate this pain. Is there any way to get directly back to IKJ56700A? Or even better, to change the Userid and continue with the logon? As Boris Lenz kindly suggested, use PA1. You will see LOGON on a clean 3270 screen, just retype LOGON followed optionally by your right id and you're in. If you don't use id after LOGON, you get that familiar IKJ message as usual which is waiting for your input. SSHD doesn't tell me that 0123456789 is unknown to RACF, or even that it's syntactically invalid. I can't use SSH to probe for known user IDs. I believe this is WAD. RACF won't tell you via TSO/SSHD *why* your logon is rejected, it simply says your attempt is invalid. That topic of not telling the reason of failed logon was covered in RACF-L in the past. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
Groan, I hate it to correct myself, but I was contacted offlist that I'm wrong ... ouch, so early in 2015! ... So here goes ... SSHD doesn't tell me that 0123456789 is unknown to RACF, or even that it's syntactically invalid. I can't use SSH to probe for known user IDs. I believe this is WAD. RACF won't tell you via TSO/SSHD *why* your logon is rejected, it simply says your attempt is invalid. That topic of not telling the reason of failed logon was covered in RACF-L in the past. Should be this: I believe this is WAD for SSHD, but somewhat different for TSO for passwords, not for TSO ids. For passwords - RACF won't tell [1] you via *why* your logon is rejected, it simply says your password is invalid. (syntax rules/re-used passwords, etc.) For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. That topic of not telling the reason of failed logon (password) was indeed covered in RACF-L in the past. Sorry Paul. Groete / Greetings Elardus Engelbrecht [1] - But, you can see the actual reasons for invalid password in RACF SMF records. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
John McKown wrote: Tony's Basement Computer wrote: DoS, revoke all the non-Special and non-Protected users. True. That concern was raised on RACF-L. Hum, this sounds like a job for an IDS package. Perhaps something which would dynamically update the z/OS firewall so that when an ID is revoked due to password limit exceeded _and_ all the tries were from a specific IP address (perhaps tied to one or more LU names), then do a deny all in the firewall to any attempt for that IP to connect to the system. Not if that IP address is NATted, ie shared by a VPN. We have some user groups who are using a shared IP address (NATted) on some router. ... then things are getting interesting ... (trying to get the co-operation of the owner of that router hosting that NATted address to resolve that errant logon attempt) Too bad, IMO, the z/OS firewall is _nowhere_ near as easy to use as my Linux firewall. True. Hmmm, will IBM hear you? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Enumerating User IDs (was: CANCEL TSO Logon?)
On Mon, 5 Jan 2015 09:48:28 -0600, Tony's Basement Computer wrote: DoS, revoke all the non-Special and non-Protected users. -Original Message- From: Vernooij, CP (ITOPT1) - KLM What is the point in trying to find a valid userid, if the userid will be suspended after trying 3 invalid passwords (in our situation)? And here we have a cultural divide. Open systems folks are quite sensitive to the possibility of enumerating user IDs; less sensitive to exhaustive password search, and feel that revoking a user's ID upon detecting password probing invites that form of DoS. If I hadn't noticed my coworker's ID when I inadvertently typoed it, I'd have unwittingly revoked him with repeated password tries. One interesting approach in a product (ISTR from Simware?) was to increase the login processing latency after each password rejection. And YA product (ISTR IBM VM/370?) logically locked the terminal on detected probing. This caught me once (wasn't mischief, merely clumsiness). I left my terminal emulator connected to the disabled port, opened a new window, and logged in successfuly with the next port in the hunt. YA DoS potential. It's interesting (if I believe the news reports and Obama) that North Korea was able to hack Sony in retribution. This appears to be not a shotgun blast but a narrowly targeted attack. It could have been any one selected of many victims. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Trace Option for OMVS
Hello, Cross Posted : MVS-OE and IBM Main I am trying to take OMVS tace with the below command : TRACE CT,64M,COMP=SYSOMVS R XX,JOBNAME=(CC),OPTIONS=ALL,END The above command fails with the below command : IEE309I TRACEUNIDENTIFIABLE KEYWORD ITT038I NONE OF THE TRANSACTIONS REQUESTED VIA THE TRACE CT COMMAND WE SUCCESSFULLY EXECUTED. IEE839I ST=(ON,0001M,3M) AS=ON BR=OFF EX=ON MO=OFF MT=(ON,064K) 417 ISSUE DISPLAY TRACE CMD FOR SYSTEM AND COMPONENT TRACE STATUS ISSUE DISPLAY TRACE,TT CMD FOR TRANSACTION TRACE STATUS I tried checking the manual but I am not able to identify if there is anything wrong with the above command. Any suggestions are much appreciated. Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
Mike Wawiorko wrote: Logon to TSO is an SNA session and not a (direct) IP connection. It may or may not be from a tn3270 connection. If it is tn3270 the IP connection may well be to another system and via a multi-session tool like TPX, Supersession, Tubes, Multsess etc. where is the IP address and on which system? I know. Thanks for highlighting this. As well as NAT many sites have a thin client with tn3270 on Citrix. Makes any attempt to deal with DoS or userid/password misuse on the TSO system by blocking an IP address futile and probably likely to block genuine users in many configurations. Indeed. This is why I said things can get *interesting* ... And it is not only TSO, but also with DoS attack with scripted FTP jobs... We got a victim who used a machine infected with a keystroke device. That victim could not use his usual id, since that will get repeately revoked via a hidden FTP script. They resolved it by formatting the PC and destroyed that device. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs (was: CANCEL TSO Logon?)
On 01/05/2015 09:35 AM, Paul Gilmartin wrote: On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote: For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. In the video cited: On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk ... the speaker opined that such probing is less likely to be detected by Security than by Operations as a spike in CPU usage. -- gil RACF uses SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring. We used independent review of daily summary reports generated from RACF SMF records to verify that such probing had not occurred, just the typical typos and forgotten passwords from terminals within the corporation. With our normal system workload, someone would have been more likely to notice a flood of unusual console messages than see any noticeable impact on CPU. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
Logon to TSO is an SNA session and not a (direct) IP connection. It may or may not be from a tn3270 connection. If it is tn3270 the IP connection may well be to another system and via a multi-session tool like TPX, Supersession, Tubes, Multsess etc. where is the IP address and on which system? As well as NAT many sites have a thin client with tn3270 on Citrix. Makes any attempt to deal with DoS or userid/password misuse on the TSO system by blocking an IP address futile and probably likely to block genuine users in many configurations. Mike Wawiorko Please consider the environment before printing this e-mail -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: 05 January 2015 16:12 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CANCEL TSO Logon? John McKown wrote: ... all the tries were from a specific IP address (perhaps tied to one or more LU names), then do a deny all in the firewall to any attempt for that IP to connect to the system. Not if that IP address is NATted, ie shared by a VPN. We have some user groups who are using a shared IP address (NATted) on some router. ... then things are getting interesting ... (trying to get the co-operation of the owner of that router hosting that NATted address to resolve that errant logon attempt) Too bad, IMO, the z/OS firewall is _nowhere_ near as easy to use as my Linux firewall. True. Hmmm, will IBM hear you? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority (Financial Services Register No. 122702). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
On 2015-01-05, at 09:24, Mike Wawiorko wrote: Logon to TSO is an SNA session and not a (direct) IP connection. It may or may not be from a tn3270 connection. If it is tn3270 the IP connection may well be to another system and via a multi-session tool like TPX, Supersession, Tubes, Multsess etc. where is the IP address and on which system? As well as NAT many sites have a thin client with tn3270 on Citrix. Makes any attempt to deal with DoS or userid/password misuse on the TSO system by blocking an IP address futile and probably likely to block genuine users in many configurations. Ah, yes. As Abby Sciuto might say, He's bouncing off a dozen routers; it'll take me an extra 30 seconds to find the originating IP. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs (was: CANCEL TSO Logon?)
SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring Yup! Come to either of my sessions at SHARE to learn about how to do that (albeit with one of several commercial products). Unfortunately I know of no way to intercept in real time the invalid userid at its initial usage and possible validation as opposed to when it is actually used for a logon with password. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel Ewing Sent: Monday, January 05, 2015 8:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) On 01/05/2015 09:35 AM, Paul Gilmartin wrote: On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote: For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. In the video cited: On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk ... the speaker opined that such probing is less likely to be detected by Security than by Operations as a spike in CPU usage. -- gil RACF uses SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring. We used independent review of daily summary reports generated from RACF SMF records to verify that such probing had not occurred, just the typical typos and forgotten passwords from terminals within the corporation. With our normal system workload, someone would have been more likely to notice a flood of unusual console messages than see any noticeable impact on CPU. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs (was: CANCEL TSO Logon?)
Philip is larger than life and very into himself. He's keynoting at SHARE. Come see him in person. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony's Basement Computer Sent: Monday, January 05, 2015 8:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) Back years ago I worked at a Top Secret shop. That product wrote a console message when a log on attempt has occurred that specified an unknown user. Sadly, what was usually seen was a password. It's been years since I was in that business so I don't know if that display is a configurable option. Sidebar: I watched video and I found it dismaying. The presenter spoke in demeaning tone of the traditional terminology to which we are all familiar which I found insulting. I felt he acted proud that *his* technology was superior because *his* terms are more current, thus better. I felt he made some assumptions in his presentation that would lead the uninitiated to believe that these exposures exist in all cases and in all environments. Stipulating that a deficiently configured z/OS-RACF (or TS or ACF2) shop could present these opportunities, I feel he should have made this disclaimer at the outset. Had he done so I might have taken him more seriously. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Full z/OS SPOOL
In addition to what Dennis said, these buffers are for concurrent access and are IN MEMORY above 16M. So they don't indicate SPOOL full. Even on my relatively small z/OS system, I set this number to 209. It's virtual, so it's not a real problem! grin/ On Mon, Jan 5, 2015 at 11:09 AM, Phil Smith p...@voltage.com wrote: We have an open-source STC which, if not shut down cleanly, has a tendency to fill SPOOL. Obviously we need to hunt down the problem and kill it. In the meantime, when it happens, and our system gets IPLed (second-level guest, at IBM Dallas), we wind up unable to logon. Starting the guest gets: *$HASP050 JES2 RESOURCE SHORTAGE OF BUFX - 100% UTILIZATION REACHED A TOTAL OF 49 BUFX ARE CURRENTLY DEFINED, OF WHICH: 49 (100%) ARE IN USE 40 (81%) ARE BEING WAITED FOR 0 PROCESSORS REQUESTED BUFX BUT DID NOT WAIT THE LARGEST UNFULFILLED REQUEST WAS FOR 0 BUFX A MINIMUM OF 89 BUFX IS REQUIRED TO SATISFY CURRENT DEMAND Issuing commands like VINPUT VMSG $POJOBQ,ALL,PROTECTED,DAYS0 seems to purge a bunch of stuff (we get messages that suggest this is true, and repeating the command gets HASP003 RC=(52),PO JOBQ - NO SELECTABLE ENTRIES FOUND MATCHING) but doesn't seem to actually help. So...from a SECUSERed VM logon, how can we clear SPOOL? A cold start would suffice, although of course knowing how to do so without a cold start would be even better (for those times when it's full but not yet down). Thanks. And yes, I've Googled and Googled 'til my Googler is sore; there must be something I haven't thought of before... (with apologies to Mr. Geisel) ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- While a transcendent vocabulary is laudable, one must be eternally careful so that the calculated objective of communication does not become ensconced in obscurity. In other words, eschew obfuscation. 111,111,111 x 111,111,111 = 12,345,678,987,654,321 Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs (was: CANCEL TSO Logon?)
On Mon, Jan 5, 2015 at 8:57 AM, Tony's Basement Computer tbabo...@comcast.net wrote: Back years ago I worked at a Top Secret shop. That product wrote a console message when a log on attempt has occurred that specified an unknown user. Sadly, what was usually seen was a password. It's been years since I was in that business so I don't know if that display is a configurable option. Sidebar: I watched video and I found it dismaying. The presenter spoke in demeaning tone of the traditional terminology to which we are all familiar which I found insulting. I felt he acted proud that *his* technology was superior because *his* terms are more current, thus better. I felt he made some assumptions in his presentation that would lead the uninitiated to believe that these exposures exist in all cases and in all environments. Stipulating that a deficiently configured z/OS-RACF (or TS or ACF2) shop could present these opportunities, I feel he should have made this disclaimer at the outset. Had he done so I might have taken him more seriously. Agreed. What I found interesting was that the vulnerabilities presented all related to the Unix side and add-ons related to the web world. I think the only exception to this was the comments related to job submission related to FTP. In the presentation, I did not see (perhaps i missed it) was how to obtain root (special) access to a z/OS system. All of the thing presented seemed to assume you were dealing with a logon id which already had considerable capabilities. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, January 05, 2015 10:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring Yup! Come to either of my sessions at SHARE to learn about how to do that (albeit with one of several commercial products). Unfortunately I know of no way to intercept in real time the invalid userid at its initial usage and possible validation as opposed to when it is actually used for a logon with password. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel Ewing Sent: Monday, January 05, 2015 8:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) On 01/05/2015 09:35 AM, Paul Gilmartin wrote: On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote: For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. In the video cited: On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk ... the speaker opined that such probing is less likely to be detected by Security than by Operations as a spike in CPU usage. -- gil RACF uses SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring. We used independent review of daily summary reports generated from RACF SMF records to verify that such probing had not occurred, just the typical typos and forgotten passwords from terminals within the corporation. With our normal system workload, someone would have been more likely to notice a flood of unusual console messages than see any noticeable impact on CPU. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Full z/OS SPOOL
We have an open-source STC which, if not shut down cleanly, has a tendency to fill SPOOL. Obviously we need to hunt down the problem and kill it. In the meantime, when it happens, and our system gets IPLed (second-level guest, at IBM Dallas), we wind up unable to logon. Starting the guest gets: *$HASP050 JES2 RESOURCE SHORTAGE OF BUFX - 100% UTILIZATION REACHED A TOTAL OF 49 BUFX ARE CURRENTLY DEFINED, OF WHICH: 49 (100%) ARE IN USE 40 (81%) ARE BEING WAITED FOR 0 PROCESSORS REQUESTED BUFX BUT DID NOT WAIT THE LARGEST UNFULFILLED REQUEST WAS FOR 0 BUFX A MINIMUM OF 89 BUFX IS REQUIRED TO SATISFY CURRENT DEMAND Issuing commands like VINPUT VMSG $POJOBQ,ALL,PROTECTED,DAYS0 seems to purge a bunch of stuff (we get messages that suggest this is true, and repeating the command gets HASP003 RC=(52),PO JOBQ - NO SELECTABLE ENTRIES FOUND MATCHING) but doesn't seem to actually help. So...from a SECUSERed VM logon, how can we clear SPOOL? A cold start would suffice, although of course knowing how to do so without a cold start would be even better (for those times when it's full but not yet down). Thanks. And yes, I've Googled and Googled 'til my Googler is sore; there must be something I haven't thought of before... (with apologies to Mr. Geisel) ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Full z/OS SPOOL
Check out $TBUFDEF to increase value of EXTBUF. $DBUFDEF will show your current value which should be 49. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith Sent: Monday, January 05, 2015 11:10 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Full z/OS SPOOL We have an open-source STC which, if not shut down cleanly, has a tendency to fill SPOOL. Obviously we need to hunt down the problem and kill it. In the meantime, when it happens, and our system gets IPLed (second-level guest, at IBM Dallas), we wind up unable to logon. Starting the guest gets: *$HASP050 JES2 RESOURCE SHORTAGE OF BUFX - 100% UTILIZATION REACHED A TOTAL OF 49 BUFX ARE CURRENTLY DEFINED, OF WHICH: 49 (100%) ARE IN USE 40 (81%) ARE BEING WAITED FOR 0 PROCESSORS REQUESTED BUFX BUT DID NOT WAIT THE LARGEST UNFULFILLED REQUEST WAS FOR 0 BUFX A MINIMUM OF 89 BUFX IS REQUIRED TO SATISFY CURRENT DEMAND Issuing commands like VINPUT VMSG $POJOBQ,ALL,PROTECTED,DAYS0 seems to purge a bunch of stuff (we get messages that suggest this is true, and repeating the command gets HASP003 RC=(52),PO JOBQ - NO SELECTABLE ENTRIES FOUND MATCHING) but doesn't seem to actually help. So...from a SECUSERed VM logon, how can we clear SPOOL? A cold start would suffice, although of course knowing how to do so without a cold start would be even better (for those times when it's full but not yet down). Thanks. And yes, I've Googled and Googled 'til my Googler is sore; there must be something I haven't thought of before... (with apologies to Mr. Geisel) ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs (was: CANCEL TSO Logon?)
I do not believe you will get RACF SMF and console messages for this type of probing. It is my understanding that TSO performs a RACROUTE REQUEST=EXTRACT to obtain the data to fill in the various fields in the logon panel. When retrieving or replacing fields, the RACF manual explicitly states: *Logging* of RACROUTE REQUEST*=*EXTRACT invocations is not done except indirectly. *Logging* can occur during field access checking if the RACROUTE REQUEST=AUTH request exit requests it. Therefore I do not believe any logging would be performed. Lou -- Artificial Intelligence is no match for Natural Stupidity - Unknown On Mon, Jan 5, 2015 at 10:18 AM, Joel Ewing jcew...@acm.org wrote: On 01/05/2015 09:35 AM, Paul Gilmartin wrote: On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote: For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. In the video cited: On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk ... the speaker opined that such probing is less likely to be detected by Security than by Operations as a spike in CPU usage. -- gil RACF uses SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring. We used independent review of daily summary reports generated from RACF SMF records to verify that such probing had not occurred, just the typical typos and forgotten passwords from terminals within the corporation. With our normal system workload, someone would have been more likely to notice a flood of unusual console messages than see any noticeable impact on CPU. -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Full z/OS SPOOL
IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 01/05/2015 12:09:35 PM: From: Phil Smith p...@voltage.com To: IBM-MAIN@LISTSERV.UA.EDU Date: 01/05/2015 12:10 PM Subject: Full z/OS SPOOL Sent by: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU We have an open-source STC which, if not shut down cleanly, has a tendency to fill SPOOL. Obviously we need to hunt down the problem and kill it. In the meantime, when it happens, and our system gets IPLed (second-level guest, at IBM Dallas), we wind up unable to logon. Starting the guest gets: *$HASP050 JES2 RESOURCE SHORTAGE OF BUFX - 100% UTILIZATION REACHED A TOTAL OF 49 BUFX ARE CURRENTLY DEFINED, OF WHICH: 49 (100%) ARE IN USE 40 (81%) ARE BEING WAITED FOR 0 PROCESSORS REQUESTED BUFX BUT DID NOT WAIT THE LARGEST UNFULFILLED REQUEST WAS FOR 0 BUFX A MINIMUM OF 89 BUFX IS REQUIRED TO SATISFY CURRENT DEMAND Issuing commands like VINPUT VMSG $POJOBQ,ALL,PROTECTED,DAYS0 seems to purge a bunch of stuff (we get messages that suggest this is true, and repeating the command gets HASP003 RC=(52),PO JOBQ - NO SELECTABLE ENTRIES FOUND MATCHING) but doesn't seem to actually help. So...from a SECUSERed VM logon, how can we clear SPOOL? A cold start would suffice, although of course knowing how to do so without a cold start would be even better (for those times when it's full but not yet down). Thanks. And yes, I've Googled and Googled 'til my Googler is sore; there must be something I haven't thought of before... (with apologies to Mr. Geisel) You might see if the local fix in http://www-01.ibm.com/support/docview.wss?uid=isg1OA26484 still works. Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
On my system the USERIF data of the TSO/E LOGON panel is unprotected. I can overtype it with the correct userid. I hit Enter and TSO populates the panel with the usual account number, etc. Don't know what is different on my (V1R13) system, but the implication is that yours might be made to work this way also. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Sunday, January 04, 2015 8:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: CANCEL TSO Logon? My logon PROC is set up to bypass any solicitor and put me directly at: IKJ56700A ENTER USERID - userif Oops! Typo. I recognize it by sight or by proprioception an instant after I press ENTER. But USERIF is another valid user ID in my department. I'm at the TSO GUI LOGON panel. I don't want to enter a password and risk revoking my coworker's account. I'd like to overtype the last character in USERIF: --- TSO/E LOGON --- Enter LOGON parameters below: RACF LOGON parameters: Userid=== USERIF Damn! The field is not modifiable! (Why?) If I press END, I'm disconnected (why?) and must reconnect. Is there any way to get directly back to IKJ56700A? Or even better, to change the Userid and continue with the logon? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs (was: CANCEL TSO Logon?)
Yep. BTW, how did Mr. Mainframehacker get to the TSO log on screen? Did someone provide the magic VTAM command? I ask from ignorance because I didn't watch 100% of the video and I'm not connect literate. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Monday, January 05, 2015 6:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) Something like this?ICH408I USER(MYPSWD99) GROUP() NAME(??? ) LOGON/JOB INITIATION - USER AT TERMINAL DVDU NOT RACF-DEFINED The above was generated using the CICS CESN signon transaction. From: Tony's Basement Computer tbabo...@comcast.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 5, 2015 9:57 AM Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) Back years ago I worked at a Top Secret shop. That product wrote a console message when a log on attempt has occurred that specified an unknown user. Sadly, what was usually seen was a password. It's been years since I was in that business so I don't know if that display is a configurable option. Sidebar: I watched video and I found it dismaying. The presenter spoke in demeaning tone of the traditional terminology to which we are all familiar which I found insulting. I felt he acted proud that *his* technology was superior because *his* terms are more current, thus better. I felt he made some assumptions in his presentation that would lead the uninitiated to believe that these exposures exist in all cases and in all environments. Stipulating that a deficiently configured z/OS-RACF (or TS or ACF2) shop could present these opportunities, I feel he should have made this disclaimer at the outset. Had he done so I might have taken him more seriously. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, January 05, 2015 10:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring Yup! Come to either of my sessions at SHARE to learn about how to do that (albeit with one of several commercial products). Unfortunately I know of no way to intercept in real time the invalid userid at its initial usage and possible validation as opposed to when it is actually used for a logon with password. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel Ewing Sent: Monday, January 05, 2015 8:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) On 01/05/2015 09:35 AM, Paul Gilmartin wrote: On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote: For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. In the video cited: On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk ... the speaker opined that such probing is less likely to be detected by Security than by Operations as a spike in CPU usage. -- gil RACF uses SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring. We used independent review of daily summary reports generated from RACF SMF records to verify that such probing had not occurred, just the typical typos and forgotten passwords from terminals within the corporation. With our normal system workload, someone would have been more likely to notice a flood of unusual console messages than see any noticeable impact on CPU. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
Being old enough to remember the pre-Protected days, when this feature appeared we implemented it into every user profile we could find that satisfied the criteria. Zero pain, more uninterrupted sleep. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lester, Bob Sent: Monday, January 05, 2015 6:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CANCEL TSO Logon? Hey Lou, BTDT, *very* painful. Had to learn that one the hard way. Cheers! BobL -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lou Losee Sent: Monday, January 05, 2015 4:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CANCEL TSO Logon? [ EXTERNAL ] Hopefully all of your started proc user ids are PROTECTED otherwise those 3 invalid password attempts could cause you big problems. Lou -- Artificial Intelligence is no match for Natural Stupidity - Unknown On Mon, Jan 5, 2015 at 2:21 PM, Mike Schwab mike.a.sch...@gmail.com wrote: On Mon, Jan 5, 2015 at 9:45 AM, Vernooij, CP (ITOPT1) - KLM kees.verno...@klm.com wrote: What is the point in trying to find a valid userid, if the userid will be suspended after trying 3 invalid passwords (in our situation)? Kees. But not if you keep rotating IDs. It is three in a row for the same ID. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
Beep,beep,beep...Tape Mgr puts. INIT proc in one of STC Proclibs. Damn that traffic jam.' In a message dated 1/5/2015 6:17:54 P.M. Central Standard Time, tbabo...@comcast.net writes: Being old enough to remember the pre-Protected days, when this feature appeared we implemented it into every user profile we could find that satisfied the criteria. Zero pain, more uninterrupted sleep. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs (was: CANCEL TSO Logon?)
On 5 January 2015 at 19:19, Tony's Basement Computer tbabo...@comcast.net wrote: Yep. BTW, how did Mr. Mainframehacker get to the TSO log on screen? Did someone provide the magic VTAM command? I ask from ignorance because I didn't watch 100% of the video and I'm not connect literate. His (incredibly annoying if you're an old non-hip guy like me) tumblr page is chock full of GIFs of logon screens with their publicly reachable IP addresses. So anyone could just TN3270 to any of those. Even if they support TLS, that protects the data in transit, but it's unlikely that authentication by the TN3270 client is required. I have no idea how he got the addresses, and presumably some have been fixed by now, but doubtless not all. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs (was: CANCEL TSO Logon?)
Something like this?ICH408I USER(MYPSWD99) GROUP( ) NAME(??? ) LOGON/JOB INITIATION - USER AT TERMINAL DVDU NOT RACF-DEFINED The above was generated using the CICS CESN signon transaction. From: Tony's Basement Computer tbabo...@comcast.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 5, 2015 9:57 AM Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) Back years ago I worked at a Top Secret shop. That product wrote a console message when a log on attempt has occurred that specified an unknown user. Sadly, what was usually seen was a password. It's been years since I was in that business so I don't know if that display is a configurable option. Sidebar: I watched video and I found it dismaying. The presenter spoke in demeaning tone of the traditional terminology to which we are all familiar which I found insulting. I felt he acted proud that *his* technology was superior because *his* terms are more current, thus better. I felt he made some assumptions in his presentation that would lead the uninitiated to believe that these exposures exist in all cases and in all environments. Stipulating that a deficiently configured z/OS-RACF (or TS or ACF2) shop could present these opportunities, I feel he should have made this disclaimer at the outset. Had he done so I might have taken him more seriously. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, January 05, 2015 10:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring Yup! Come to either of my sessions at SHARE to learn about how to do that (albeit with one of several commercial products). Unfortunately I know of no way to intercept in real time the invalid userid at its initial usage and possible validation as opposed to when it is actually used for a logon with password. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel Ewing Sent: Monday, January 05, 2015 8:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) On 01/05/2015 09:35 AM, Paul Gilmartin wrote: On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote: For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. In the video cited: On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk ... the speaker opined that such probing is less likely to be detected by Security than by Operations as a spike in CPU usage. -- gil RACF uses SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring. We used independent review of daily summary reports generated from RACF SMF records to verify that such probing had not occurred, just the typical typos and forgotten passwords from terminals within the corporation. With our normal system workload, someone would have been more likely to notice a flood of unusual console messages than see any noticeable impact on CPU. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
Hey Lou, BTDT, *very* painful. Had to learn that one the hard way. Cheers! BobL -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lou Losee Sent: Monday, January 05, 2015 4:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CANCEL TSO Logon? [ EXTERNAL ] Hopefully all of your started proc user ids are PROTECTED otherwise those 3 invalid password attempts could cause you big problems. Lou -- Artificial Intelligence is no match for Natural Stupidity - Unknown On Mon, Jan 5, 2015 at 2:21 PM, Mike Schwab mike.a.sch...@gmail.com wrote: On Mon, Jan 5, 2015 at 9:45 AM, Vernooij, CP (ITOPT1) - KLM kees.verno...@klm.com wrote: What is the point in trying to find a valid userid, if the userid will be suspended after trying 3 invalid passwords (in our situation)? Kees. But not if you keep rotating IDs. It is three in a row for the same ID. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs (was: CANCEL TSO Logon?)
I don't see those on my LPAR for the situation we are talking about -- invalid userid but no password entry yet. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Monday, January 05, 2015 4:06 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) Something like this?ICH408I USER(MYPSWD99) GROUP() NAME(??? ) LOGON/JOB INITIATION - USER AT TERMINAL DVDU NOT RACF-DEFINED The above was generated using the CICS CESN signon transaction. From: Tony's Basement Computer tbabo...@comcast.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 5, 2015 9:57 AM Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) Back years ago I worked at a Top Secret shop. That product wrote a console message when a log on attempt has occurred that specified an unknown user. Sadly, what was usually seen was a password. It's been years since I was in that business so I don't know if that display is a configurable option. Sidebar: I watched video and I found it dismaying. The presenter spoke in demeaning tone of the traditional terminology to which we are all familiar which I found insulting. I felt he acted proud that *his* technology was superior because *his* terms are more current, thus better. I felt he made some assumptions in his presentation that would lead the uninitiated to believe that these exposures exist in all cases and in all environments. Stipulating that a deficiently configured z/OS-RACF (or TS or ACF2) shop could present these opportunities, I feel he should have made this disclaimer at the outset. Had he done so I might have taken him more seriously. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, January 05, 2015 10:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring Yup! Come to either of my sessions at SHARE to learn about how to do that (albeit with one of several commercial products). Unfortunately I know of no way to intercept in real time the invalid userid at its initial usage and possible validation as opposed to when it is actually used for a logon with password. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs (was: CANCEL TSO Logon?)
I have no idea how he got the addresses I suspect by scanning. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Monday, January 05, 2015 4:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) On 5 January 2015 at 19:19, Tony's Basement Computer tbabo...@comcast.net wrote: Yep. BTW, how did Mr. Mainframehacker get to the TSO log on screen? Did someone provide the magic VTAM command? I ask from ignorance because I didn't watch 100% of the video and I'm not connect literate. His (incredibly annoying if you're an old non-hip guy like me) tumblr page is chock full of GIFs of logon screens with their publicly reachable IP addresses. So anyone could just TN3270 to any of those. Even if they support TLS, that protects the data in transit, but it's unlikely that authentication by the TN3270 client is required. I have no idea how he got the addresses, and presumably some have been fixed by now, but doubtless not all. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs (was: CANCEL TSO Logon?)
The problem is, that when TSO populates the logon panel, it does not do a(RACROUTE REQUEST=INIT (RACINIT) but rather does an RACROUTE REQUEST=EXTRACT (RACXTRT) against the user id specified to populate the fields on the logon panel. This does not result in any RACF message or SMF record, but TSO does use the RC to inform the user if the user id specified is defined or not. Lou -- Artificial Intelligence is no match for Natural Stupidity - Unknown On Mon, Jan 5, 2015 at 6:05 PM, Frank Swarbrick 002782105f5c-dmarc-requ...@listserv.ua.edu wrote: Something like this?ICH408I USER(MYPSWD99) GROUP() NAME(??? ) LOGON/JOB INITIATION - USER AT TERMINAL DVDU NOT RACF-DEFINED The above was generated using the CICS CESN signon transaction. From: Tony's Basement Computer tbabo...@comcast.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 5, 2015 9:57 AM Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) Back years ago I worked at a Top Secret shop. That product wrote a console message when a log on attempt has occurred that specified an unknown user. Sadly, what was usually seen was a password. It's been years since I was in that business so I don't know if that display is a configurable option. Sidebar: I watched video and I found it dismaying. The presenter spoke in demeaning tone of the traditional terminology to which we are all familiar which I found insulting. I felt he acted proud that *his* technology was superior because *his* terms are more current, thus better. I felt he made some assumptions in his presentation that would lead the uninitiated to believe that these exposures exist in all cases and in all environments. Stipulating that a deficiently configured z/OS-RACF (or TS or ACF2) shop could present these opportunities, I feel he should have made this disclaimer at the outset. Had he done so I might have taken him more seriously. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, January 05, 2015 10:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring Yup! Come to either of my sessions at SHARE to learn about how to do that (albeit with one of several commercial products). Unfortunately I know of no way to intercept in real time the invalid userid at its initial usage and possible validation as opposed to when it is actually used for a logon with password. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel Ewing Sent: Monday, January 05, 2015 8:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) On 01/05/2015 09:35 AM, Paul Gilmartin wrote: On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote: For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. In the video cited: On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk ... the speaker opined that such probing is less likely to be detected by Security than by Operations as a spike in CPU usage. -- gil RACF uses SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring. We used independent review of daily summary reports generated from RACF SMF records to verify that such probing had not occurred, just the typical typos and forgotten passwords from terminals within the corporation. With our normal system workload, someone would have been more likely to notice a flood of unusual console messages than see any noticeable impact on CPU. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the
Re: CANCEL TSO Logon?
Hopefully all of your started proc user ids are PROTECTED otherwise those 3 invalid password attempts could cause you big problems. Lou -- Artificial Intelligence is no match for Natural Stupidity - Unknown On Mon, Jan 5, 2015 at 2:21 PM, Mike Schwab mike.a.sch...@gmail.com wrote: On Mon, Jan 5, 2015 at 9:45 AM, Vernooij, CP (ITOPT1) - KLM kees.verno...@klm.com wrote: What is the point in trying to find a valid userid, if the userid will be suspended after trying 3 invalid passwords (in our situation)? Kees. But not if you keep rotating IDs. It is three in a row for the same ID. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
'Three in a row' means a sequence of accesses to a *particular* userid without an intervening success. Accessing any number of *other* userids in the meantime has no effect on the error count for that single userid. Only a successful access to that userid resets the count, which may increment over a long period of time. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Finnell Sent: Monday, January 05, 2015 4:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CANCEL TSO Logon? Beep,beep,beep...Tape Mgr puts. INIT proc in one of STC Proclibs. Damn that traffic jam.' In a message dated 1/5/2015 6:17:54 P.M. Central Standard Time, tbabo...@comcast.net writes: Being old enough to remember the pre-Protected days, when this feature appeared we implemented it into every user profile we could find that satisfied the criteria. Zero pain, more uninterrupted sleep. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
On 01/05/2015 05:56 PM, Lou Losee wrote: Hopefully all of your started proc user ids are PROTECTED otherwise those 3 invalid password attempts could cause you big problems. Lou -- Artificial Intelligence is no match for Natural Stupidity - Unknown On Mon, Jan 5, 2015 at 2:21 PM, Mike Schwab mike.a.sch...@gmail.com wrote: On Mon, Jan 5, 2015 at 9:45 AM, Vernooij, CP (ITOPT1) - KLM kees.verno...@klm.com wrote: What is the point in trying to find a valid userid, if the userid will be suspended after trying 3 invalid passwords (in our situation)? Kees. But not if you keep rotating IDs. It is three in a row for the same ID. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? No, it's not three failed attempts in a row from the same source for the same ID; it's three failed logon attempts (if that is the limit) for the same ID before the next successful logon authentication for that same ID, whether the logon attempts are spread over seconds, hours, or days, and across all possible MVS systems and applications that might be requesting userid authentication. If your hack attempt rotates through all known userids more than three times in the same day on a system where the average userid is only authenticated one or two times a day, the odds are you will start revoking some userids during the third pass (and start potentially being noticed). For a userid that only has one legitimate logon per week, three bad attempts spread across a week would be sufficient to cause a revoke. At a max of three bad password hack attempts per ID per day, how many years does that take to have reasonable odds of hacking any individual userid? How does installation rules that force users to change their password every 60 to 90 days affect the odds of that success, since there is a non-zero probability a user could change to a password value the hacker had already attempted and will never try again because he already knows it is invalid? -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spam (11.802):Re: CANCEL TSO Logon?
Before PROTECTED was implemented we only had this happen once that I know of -- for a CICS region. It wasn't a hack or DoS attempt. Just a user who wasn't paying attention and thought he was telling SuperSessions to take him to that CICS region three times in a row when he was really on a logon screen and the CICS region name (which was same as the started task name) was instead being taken as the userid on a logon three times and revoked the CICS region userid. I got the night call. J C Ewing On 01/05/2015 06:17 PM, Tony's Basement Computer wrote: Being old enough to remember the pre-Protected days, when this feature appeared we implemented it into every user profile we could find that satisfied the criteria. Zero pain, more uninterrupted sleep. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lester, Bob Sent: Monday, January 05, 2015 6:07 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CANCEL TSO Logon? Hey Lou, BTDT, *very* painful. Had to learn that one the hard way. Cheers! BobL -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lou Losee Sent: Monday, January 05, 2015 4:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CANCEL TSO Logon? [ EXTERNAL ] Hopefully all of your started proc user ids are PROTECTED otherwise those 3 invalid password attempts could cause you big problems. Lou -- Artificial Intelligence is no match for Natural Stupidity - Unknown On Mon, Jan 5, 2015 at 2:21 PM, Mike Schwab mike.a.sch...@gmail.com wrote: On Mon, Jan 5, 2015 at 9:45 AM, Vernooij, CP (ITOPT1) - KLM kees.verno...@klm.com wrote: What is the point in trying to find a valid userid, if the userid will be suspended after trying 3 invalid passwords (in our situation)? Kees. But not if you keep rotating IDs. It is three in a row for the same ID. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs
So what TSO logon should be doing if the userid is invalid or not authorized for TSO is not give any error indication on the logon screen but populate the panel fields with plausible default values that look as if a RACF TSO segment was found and force the user to supply the password field before giving a failure message. Doesn't sound like a big change to implement, but what do I know. J C Ewing On 01/05/2015 07:20 PM, Lou Losee wrote: The problem is, that when TSO populates the logon panel, it does not do a(RACROUTE REQUEST=INIT (RACINIT) but rather does an RACROUTE REQUEST=EXTRACT (RACXTRT) against the user id specified to populate the fields on the logon panel. This does not result in any RACF message or SMF record, but TSO does use the RC to inform the user if the user id specified is defined or not. Lou -- Artificial Intelligence is no match for Natural Stupidity - Unknown On Mon, Jan 5, 2015 at 6:05 PM, Frank Swarbrick 002782105f5c-dmarc-requ...@listserv.ua.edu wrote: Something like this?ICH408I USER(MYPSWD99) GROUP() NAME(??? ) LOGON/JOB INITIATION - USER AT TERMINAL DVDU NOT RACF-DEFINED The above was generated using the CICS CESN signon transaction. From: Tony's Basement Computer tbabo...@comcast.net To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 5, 2015 9:57 AM Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) Back years ago I worked at a Top Secret shop. That product wrote a console message when a log on attempt has occurred that specified an unknown user. Sadly, what was usually seen was a password. It's been years since I was in that business so I don't know if that display is a configurable option. Sidebar: I watched video and I found it dismaying. The presenter spoke in demeaning tone of the traditional terminology to which we are all familiar which I found insulting. I felt he acted proud that *his* technology was superior because *his* terms are more current, thus better. I felt he made some assumptions in his presentation that would lead the uninitiated to believe that these exposures exist in all cases and in all environments. Stipulating that a deficiently configured z/OS-RACF (or TS or ACF2) shop could present these opportunities, I feel he should have made this disclaimer at the outset. Had he done so I might have taken him more seriously. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, January 05, 2015 10:35 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring Yup! Come to either of my sessions at SHARE to learn about how to do that (albeit with one of several commercial products). Unfortunately I know of no way to intercept in real time the invalid userid at its initial usage and possible validation as opposed to when it is actually used for a logon with password. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel Ewing Sent: Monday, January 05, 2015 8:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Enumerating User IDs (was: CANCEL TSO Logon?) On 01/05/2015 09:35 AM, Paul Gilmartin wrote: On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote: For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. In the video cited: On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk ... the speaker opined that such probing is less likely to be detected by Security than by Operations as a spike in CPU usage. -- gil RACF uses SMF and console messages to record logon/authentication failures. These could be intercepted in real time to alert someone of unusual probing while it is occurring. We used independent review of daily summary reports generated from RACF SMF records to verify that such probing had not occurred, just the typical typos and forgotten passwords from terminals within the corporation. With our normal system workload, someone would have been more likely to notice a flood of unusual console messages than see any noticeable impact on CPU. ... -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enumerating User IDs
I watched the flick and agree with a lot of what he said. He obviously has no scruples about disclosing any and all information, but isn't that how Open Source software protects itself? And if someone opens their TN3270 port to the public internet, whose fault is that really? One thing he said right off was that SPECIAL effectively has full system access. I hope auditors understand that. Years ago I had the cleanup job of removing OPERATIONS auth from as many users as possible, and I told the auditors they needed to look at SPECIAL users too. They argued that SPECIAL was out-of-scope for the project :) I had to laugh a bit when he made fun of names like ISPF and RACF, just like we make fun of grep and awk. But he's correct in putting down mainframe people (me included) who haven't fully learned some of the basics like netstat and nslookup. However, I'm not sure he understands as much as he thinks he does. For example, I saw my name while browsing his tumblr page - he made fun of an ibm-main post where Skip mentioned we had quickly applied IBM security PTF's, but it would take some time to roll out to production. I'm not sure he understands change control and the related risk assessment. What I REALLY DON'T LIKE is that he seems focused on providing automated hacking solutions. That goes well past a simple lack of scruples. Tony Harminc wrote: His (incredibly annoying if you're an old non-hip guy like me) tumblr page is chock full of GIFs of logon screens with their publicly reachable IP addresses. So anyone could just TN3270 to any of those. Even if they support TLS, that protects the data in transit, but it's unlikely that authentication by the TN3270 client is required. I have no idea how he got the addresses, and presumably some have been fixed by now, but doubtless not all. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Trace Option for OMVS
try: OPTIONS=(ALL) In article cahtvvrwv3qp6o8eshr_ewoua2e3nbey+ccghwbada7vrb_e...@mail.gmail.com you wrote: Hello, Cross Posted : MVS-OE and IBM Main I am trying to take OMVS tace with the below command : TRACE CT,64M,COMP=SYSOMVS R XX,JOBNAME=(CC),OPTIONS=ALL,END The above command fails with the below command : IEE309I TRACEUNIDENTIFIABLE KEYWORD ITT038I NONE OF THE TRANSACTIONS REQUESTED VIA THE TRACE CT COMMAND WE SUCCESSFULLY EXECUTED. IEE839I ST=(ON,0001M,3M) AS=ON BR=OFF EX=ON MO=OFF MT=(ON,064K) 417 ISSUE DISPLAY TRACE CMD FOR SYSTEM AND COMPONENT TRACE STATUS ISSUE DISPLAY TRACE,TT CMD FOR TRANSACTION TRACE STATUS I tried checking the manual but I am not able to identify if there is anything wrong with the above command. Any suggestions are much appreciated. Jake -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
On Mon, Jan 5, 2015 at 9:45 AM, Vernooij, CP (ITOPT1) - KLM kees.verno...@klm.com wrote: What is the point in trying to find a valid userid, if the userid will be suspended after trying 3 invalid passwords (in our situation)? Kees. But not if you keep rotating IDs. It is three in a row for the same ID. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
I once suggested to management that we secure our z/OS user profiles. At the time they were used as EMAIL addresses as well. I explained the scenario of rotating IDs as Mike suggested it could lead to a DoS exploitation. Naturally the EMAIL people prevailed.sigh. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Monday, January 05, 2015 2:21 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CANCEL TSO Logon? On Mon, Jan 5, 2015 at 9:45 AM, Vernooij, CP (ITOPT1) - KLM kees.verno...@klm.com wrote: What is the point in trying to find a valid userid, if the userid will be suspended after trying 3 invalid passwords (in our situation)? Kees. But not if you keep rotating IDs. It is three in a row for the same ID. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Full z/OS SPOOL
Bob Rutledge wrote: and our system gets IPLed (second-level guest, at IBM Dallas), we wind up unable to logon. Starting the guest gets: [ ... snipped ... ] To Phil Smith, does that APAR OA26484 mentioned by Bob Rutledge describes your symptom? Just curious, at what z/OS level are you? I'm asking because that APAR is somewhat old, but I'm sure that local fix also mentioned by Bob should help you out until you can fix the init deck. Are other LPARs using the same JES2? If so, you could try out the local fix or purge job entries? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: mainframe tribute song
I had not heard (and do not fully believe) that the hashed password data set is generally readable (UACC=READ?). It is not clear what data set you are referring to. I believe the hashed password is stored in SYS1.RACF, which should be UACC=NONE. I suppose I should watch the video. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Young's Black Hat 2013 talk - was mainframe tribute song
On 01/03/2015 09:23 PM, Paul Gilmartin wrote: On Sat, 3 Jan 2015 10:13:21 -0600, Ed Gould wrote: Indeed it was at least interesting. I would be curious if IBM would like to comment on some of the statements on how how RACF encrypts the passwords. I disagree with how RACF encryption is done (at least by the commentator)but I am not RACF trained so I can not call the commentator out. IBM? On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk It has been mentioned here and not refuted that RACF uses single-DES with the password as key and the user ID as salt. I had not heard (and do not fully believe) that the hashed password data set is generally readable (UACC=READ?). I had not heard, but it's quite plausible, that passphrases, however long, are collapsed to 56 bits becase DES supports no greater. And Phillip Young stressed the weakness of the potential for user ID enumeration -- TSO LOGON tells you immediately whether a string is a known user ID -- he calls it much too friendly. But z/OS partisans here have advocated that excess friendliness as a boon. It reduces the search space from MxN to M+N, regarded contemptuously by non-mainframers. -- gil From the full title of the report, perhaps Young is referring to MVS installations that have been in existence for over 30 years that have somehow managed to ignore all the security advice of the last several decades and have continued in unsafe configurations. Perhaps some such installations do exist. The password mangling Young describes sounds like the old pre-DES password encoding (not an encryption). It wasn't even recommended by 1985 when we migrated to MVS/XA. If the old encoding is still supported, it should be way past time to discontinue that support. But, the password encoding in the RACF data base only becomes a security issue if READ access to the RACF data base itself is not properly restricted by RACF. Without READ access to the RACF database, one is reduced to making actual logon/authentication attempts, which may serve as a denial of service attack when a userid is revoked after a relatively-low, installation-specified number of failures, but would be of marginal use in finding a functional userid/password combination by trial and error and attract attention from a user whose userid gets revoked. And, SMF RACF logging data shows what LU or IP address is responsible for invalid authentication attempts -- we audited logon failures and all revoked userids daily. MVS can certainly be made insecure, but the basic security concepts are not that complex to understand Require all users of the system to authenticate. By default, protect all DASD and tape data sets, and have rational data set naming standards that make default identification of ownership and access rights feasible. Protect all system data-sets, system configuration data, PROCLIB sources for started task JCL, and any installation Authorized libraries from UPDATE by all but Technical Support staff entrusted with maintenance of the system. Disallow even READ access to sensitive data sets (like RACF databases). Restrict physical access to corporate network and MVS consoles, and use RACF to restrict usage of sensitive commands, resources and applications. RACF Security Administrators and their Technical Support counterparts must be properly trained, which includes knowing what authorization requests from managers are unreasonable and must be denied to preserve system integrity -- and being slightly paranoid about protecting their own authentication credentials helps. 3270 communication protocols were designed with secure corporate networks in mind, and as Young points out that means logon passwords transmit in clear text even though visually hidden. Any remote access to MVS over non-corporate, unsecured networks MUST be encrypted, via use of a VPN or some other technique, and standards should also be in place to protect remote user's equipment from password-trapping malware. Users should only be authorized to the functional access on MVS required by their job. Need to access a transactional system (e.g., CICS), does not imply a need for access to TSO, or OMVS/UNIX, or FTP, or batch job submission; access to FTP does not imply a need for FILETYPE=JES job submission and retrieval (and it is not that difficult to design an FTP exit that uses RACF to selectively allow/disallow JES access via FTP to specific users). I was also mildly amused by the idea of someone using FTP FILETYPE=JES to submit a surreptitious interactive listener job. In our shop, batch initiators that were not restricted to production use were a closely watched commodity, and nothing would have attracted the attention of Operators, Tech Services, or other users quicker than a job that appeared to be hung using few resources, and holding up the
Re: Young's Black Hat 2013 talk - was mainframe tribute song
The fact is there have been several successful real hacks of production mainframes, so some sort of real, present-day hacker exposure is not unheard-of in the wild. By real I mean not some staged attack on Hercules or the like but a real outsider breach of a production mainframe, with disastrous results. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel Ewing Sent: Monday, January 05, 2015 11:26 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Young's Black Hat 2013 talk - was mainframe tribute song On 01/03/2015 09:23 PM, Paul Gilmartin wrote: On Sat, 3 Jan 2015 10:13:21 -0600, Ed Gould wrote: Indeed it was at least interesting. I would be curious if IBM would like to comment on some of the statements on how how RACF encrypts the passwords. I disagree with how RACF encryption is done (at least by the commentator)but I am not RACF trained so I can not call the commentator out. IBM? On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk It has been mentioned here and not refuted that RACF uses single-DES with the password as key and the user ID as salt. I had not heard (and do not fully believe) that the hashed password data set is generally readable (UACC=READ?). I had not heard, but it's quite plausible, that passphrases, however long, are collapsed to 56 bits becase DES supports no greater. And Phillip Young stressed the weakness of the potential for user ID enumeration -- TSO LOGON tells you immediately whether a string is a known user ID -- he calls it much too friendly. But z/OS partisans here have advocated that excess friendliness as a boon. It reduces the search space from MxN to M+N, regarded contemptuously by non-mainframers. -- gil From the full title of the report, perhaps Young is referring to MVS installations that have been in existence for over 30 years that have somehow managed to ignore all the security advice of the last several decades and have continued in unsafe configurations. Perhaps some such installations do exist. The password mangling Young describes sounds like the old pre-DES password encoding (not an encryption). It wasn't even recommended by 1985 when we migrated to MVS/XA. If the old encoding is still supported, it should be way past time to discontinue that support. But, the password encoding in the RACF data base only becomes a security issue if READ access to the RACF data base itself is not properly restricted by RACF. Without READ access to the RACF database, one is reduced to making actual logon/authentication attempts, which may serve as a denial of service attack when a userid is revoked after a relatively-low, installation-specified number of failures, but would be of marginal use in finding a functional userid/password combination by trial and error and attract attention from a user whose userid gets revoked. And, SMF RACF logging data shows what LU or IP address is responsible for invalid authentication attempts -- we audited logon failures and all revoked userids daily. MVS can certainly be made insecure, but the basic security concepts are not that complex to understand Require all users of the system to authenticate. By default, protect all DASD and tape data sets, and have rational data set naming standards that make default identification of ownership and access rights feasible. Protect all system data-sets, system configuration data, PROCLIB sources for started task JCL, and any installation Authorized libraries from UPDATE by all but Technical Support staff entrusted with maintenance of the system. Disallow even READ access to sensitive data sets (like RACF databases). Restrict physical access to corporate network and MVS consoles, and use RACF to restrict usage of sensitive commands, resources and applications. RACF Security Administrators and their Technical Support counterparts must be properly trained, which includes knowing what authorization requests from managers are unreasonable and must be denied to preserve system integrity -- and being slightly paranoid about protecting their own authentication credentials helps. 3270 communication protocols were designed with secure corporate networks in mind, and as Young points out that means logon passwords transmit in clear text even though visually hidden. Any remote access to MVS over non-corporate, unsecured networks MUST be encrypted, via use of a VPN or some other technique, and standards should also be in place to protect remote user's equipment from password-trapping malware. Users should only be authorized to the functional access on MVS required by their job. Need to access a transactional system (e.g., CICS), does not imply a need for access to TSO, or OMVS/UNIX, or FTP, or batch job
Re: CANCEL TSO Logon?
.a user without a TSO segment ? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Boris Lenz Sent: Monday, January 05, 2015 9:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CANCEL TSO Logon? On Mon, January 5, 2015 16:29, Charles Mills wrote: I see no console message at all (absent some SLIP trap) for simply testing a userid (as opposed to a userid and password). Did I miss it? But you can probe for a valid userid on the logon panel. No message to the syslog. If you don't get IKJ56420I USERID user_id NOT AUTHORIZED TO USE TSO on the logon screen then you know you have a valid TSO userid. That's why I think it would be sane to omit this message. But oh well Regards, Boris P.S. To Paul Gilmartin's (Why?) [is the userid field not modifyable], that's probably so you don't log in with USERIF's procedure, region size and Command, etc... since they get pulled from the TSO segment. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SDUMPX questions
On Mon, 5 Jan 2015 08:16:26 -0500 Peter Relson rel...@us.ibm.com wrote: :What is the exact format of the LIST64 parameter. It is not clear if the :counts and lengths include a slack four bytes (like the SUMLIST64 :parameter). :SUMLIST64 does have 4 reserved bytes after the field containing the :length. LIST64 does not. The description in the book really is correct in :saying that the LIST64 format is analogous to the LISTD format. The :first word is the only length field. The book indicates correctly When :LIST64=list addr is specified, the first fullword of the storage list :contains the number of bytes, including the first word, in the list. I :don't understand why you mention the counts since those are unrelated to :lengths. :I will suggest an addition to The LIST64 storage list format is exactly :analogous to the LISTD storage list format of something like with :8-byte-long starting and ending addresses IOW, Length ds f stoken ds xl8 number_of ranges ds f Ranges ds (2*x)D :As SDUMPX with a DCB only does HOME, will a SVC entered SDUMPX ever have :the :ECB posted or will the dump always be complete upon return from the DCB. : :I don't know what upon return from the DCB means. Perhaps you meant :from the SVC? In any case, your or does not represent mutually :exclusive conditions. When you return from the SVC (assuming a valid :return code), both the ECB will be posted and also the dump will be :complete if it is a synchronous dump. The doc for ECB does mention (under :A-type) posted on completion of a scheduled dump. I suspect that that is :true but a bit misleading, in that the ECB is (very likely, but it would :need to be verified) posted on completion of the dump, whether the dump is :scheduled or synchronous. : :I did notice under ECB Note that these interfaces will not be driven if :the call to SDUMPX results in a non-zero return code.. :I believe this is incorrect. It should say ...results in a return code :greater than 4 which matches the wording for return code 04 that :describes the ECB being posted for that case. In my case the dump completed (I only used SUMLIST64) with RC=0 but the ECB was not posted. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Enumerating User IDs (was: CANCEL TSO Logon?)
On Mon, 5 Jan 2015 07:21:28 -0800, Charles Mills wrote: For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. In the video cited: On Jan 2, 2015, at 3:31 PM, Mark Regan wrote: Black Hat 2013 - Mainframes: The Past Will Come to Haunt You, by a Philip Young and it's about an hour long. http://youtu.be/uL65zWrofvk ... the speaker opined that such probing is less likely to be detected by Security than by Operations as a spike in CPU usage. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
DoS, revoke all the non-Special and non-Protected users. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Vernooij, CP (ITOPT1) - KLM Sent: Monday, January 05, 2015 9:46 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CANCEL TSO Logon? What is the point in trying to find a valid userid, if the userid will be suspended after trying 3 invalid passwords (in our situation)? Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Boris Lenz Sent: 05 January, 2015 16:44 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CANCEL TSO Logon? On Mon, January 5, 2015 16:29, Charles Mills wrote: I see no console message at all (absent some SLIP trap) for simply testing a userid (as opposed to a userid and password). Did I miss it? But you can probe for a valid userid on the logon panel. No message to the syslog. If you don't get IKJ56420I USERID user_id NOT AUTHORIZED TO USE TSO on the logon screen then you know you have a valid TSO userid. That's why I think it would be sane to omit this message. But oh well Regards, Boris P.S. To Paul Gilmartin's (Why?) [is the userid field not modifyable], that's probably so you don't log in with USERIF's procedure, region size and Command, etc... since they get pulled from the TSO segment. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
On Mon, Jan 5, 2015 at 9:48 AM, Tony's Basement Computer tbabo...@comcast.net wrote: DoS, revoke all the non-Special and non-Protected users. Hum, this sounds like a job for an IDS package. Perhaps something which would dynamically update the z/OS firewall so that when an ID is revoked due to password limit exceeded _and_ all the tries were from a specific IP address (perhaps tied to one or more LU names), then do a deny all in the firewall to any attempt for that IP to connect to the system. If this is caused by a forgetful user (or someone silly enough to change their password before a 4 day weekend - it just happened here), then they need to call the help desk to reinstate their ID anyway, so I don't see where it would be any more inconvenient to have the help desk to have a tool which reinstates the ID and removes the firewall rule too. Too bad, IMO, the z/OS firewall is _nowhere_ near as easy to use as my Linux firewall. -- While a transcendent vocabulary is laudable, one must be eternally careful so that the calculated objective of communication does not become ensconced in obscurity. In other words, eschew obfuscation. 111,111,111 x 111,111,111 = 12,345,678,987,654,321 Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Monday, January 05, 2015 7:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CANCEL TSO Logon? Groan, I hate it to correct myself, but I was contacted offlist that I'm wrong ... ouch, so early in 2015! ... So here goes ... SSHD doesn't tell me that 0123456789 is unknown to RACF, or even that it's syntactically invalid. I can't use SSH to probe for known user IDs. I believe this is WAD. RACF won't tell you via TSO/SSHD *why* your logon is rejected, it simply says your attempt is invalid. That topic of not telling the reason of failed logon was covered in RACF-L in the past. Should be this: I believe this is WAD for SSHD, but somewhat different for TSO for passwords, not for TSO ids. For passwords - RACF won't tell [1] you via *why* your logon is rejected, it simply says your password is invalid. (syntax rules/re-used passwords, etc.) For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
I see no console message at all (absent some SLIP trap) for simply testing a userid (as opposed to a userid and password). Did I miss it? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Monday, January 05, 2015 7:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CANCEL TSO Logon? For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. Only if you set a specific SLIP trap for this condition. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Elardus Engelbrecht Sent: Monday, January 05, 2015 7:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CANCEL TSO Logon? Groan, I hate it to correct myself, but I was contacted offlist that I'm wrong ... ouch, so early in 2015! ... So here goes ... SSHD doesn't tell me that 0123456789 is unknown to RACF, or even that it's syntactically invalid. I can't use SSH to probe for known user IDs. I believe this is WAD. RACF won't tell you via TSO/SSHD *why* your logon is rejected, it simply says your attempt is invalid. That topic of not telling the reason of failed logon was covered in RACF-L in the past. Should be this: I believe this is WAD for SSHD, but somewhat different for TSO for passwords, not for TSO ids. For passwords - RACF won't tell [1] you via *why* your logon is rejected, it simply says your password is invalid. (syntax rules/re-used passwords, etc.) For TSO, you can probe for known user ids, but you will see a lot of LOGON and IEA989I message in the SYSLOG. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CANCEL TSO Logon?
On Mon, January 5, 2015 16:29, Charles Mills wrote: I see no console message at all (absent some SLIP trap) for simply testing a userid (as opposed to a userid and password). Did I miss it? But you can probe for a valid userid on the logon panel. No message to the syslog. If you don't get IKJ56420I USERID user_id NOT AUTHORIZED TO USE TSO on the logon screen then you know you have a valid TSO userid. That's why I think it would be sane to omit this message. But oh well Regards, Boris P.S. To Paul Gilmartin's (Why?) [is the userid field not modifyable], that's probably so you don't log in with USERIF's procedure, region size and Command, etc... since they get pulled from the TSO segment. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
