Itschak I see you are there and able to respond. Since we haven't heard a "Thanks Chris that exactly meets my requirements." I must assume that my purely VTAM solution using CDRM statement operands and CDRSC statements where necessary didn't somehow answer your needs. I'd rather like to know why since it's so straightforward.
And, of course, I'm still trying to have you avoid any unnecessary expense! So let's try again from the beginning. > CICS of organization "A" is connected (LU6.2 Connection) to CICS of organization "B". No problem with that. Translation: There is a CICSA-CICSB set of sessions. (being LU 6.2 it will be a set of sessions rather than a single session.). Whatever measures are taken to prevent other sessions being established need to allow this set of sessions to be established. > I looked into the CDRM and found some other application (probably plural "applications") of organization "B" defined in VTAMLST of oranization "A". Translation: I browsed the CDRSC (CDRM was corrected in a following post to CDRSC) major node VTAMLST member or members in the VTAMA VTAMLST library and found other CDRSC statements presumably corresponding to other applications, some of them other CICS applications. (The fact some were other CICS applications is mentioned in a following post.) > Tried LOGON APPLID(xxx) and gpt the GMtran of org. "B" (if it is the default, I can travel in this CICS...). Translation: I succeeded in logging onto one or more CICS applications in VTAMB, CICSB, CICSB1 ..., using the names I found in the CDRSC statements and I was presented with the "Good Morning" messages. Assuming there is no CICS-level security imposed, I can enter transactions in these CICS applications. > I also riched TSO logon etc. Translation: I also succeeded in logging onto the TSO application in VTAMB, TSOB, as far as the logon panel. And I succeeded in logging onto other applications. > Now, I want to block (at) org "b" ability to get to org "a" applications > other then the CICS connection that was agreed between Org "A" and "B". Translation: Having seen what I can do as a user associated with VTAMA in accessing applications in VTAMB, I am concerned that a user associated with VTAMB can access applications in VTAMA, the VTAM with which I am working. I want to prevent a user associated with VTAMB accessing applications in VTAMA. > Is this possible? Translation: None needed! Answer: Assuming you have the authority to change VTAM definitions, in the VBUILD TYPE=CDRM member in VTAMA VTAMLST, change the VTAMB CDRM statement to specify CDRSC=REQ and do *not* define any of the end-user LUs associated with, "owned by", VTAMB as CDRSCs. That way none of the VTAMB end-users can initiate a session with any of the VTAMA applications - exactly what I think you want to achieve. In order still to be able to set up the CICSA-CICSB sessions, you will need to define a CDRSC in VTAMA for CICSB as CICSB CDRSC CDRM=VTAMB within a VBUILD TYPE=CDRSC member. Hitherto, I expect this CDRSC will have been defined dynamically because you specified CDRSC=OPT for VTAMB and CDRDYN=YES is in effect for your local CDRM. Walt, these are not just pointers, this is chapter and verse! To continue: > I also want to block the ability to enter logon applid command (may be by userid, even of the solution will require entering userid & password). How to achive that? Answer: Presumably you are talking about blocking the use of LOGON APPLID (xxx) at VTAMB for the VTAMA applications. When stated like that, this is clearly undesirable since it would prevent end-users in VTAMB accessing applications in VTAMB! Also, unless that "trick" of using SSCPFM=FSS works and that value can be applied to the VTAM definition, there is no way actually to prevent the use of the default USS LOGON and LOGOFF commands. If the end-users in VTAMB access SNA by means of a TN3270 server, then use of RESTRICTAPPL can impose use of a userid and password as described in the Communications Server IP Configuration Guide. > What other alternatives are offered to connect to vtam applications when USS tab is displaied, other then LOG APPLID and selecting from the uss tab? I mean, is there any bypass to LOG APPLID if blocked? Translation: What other alternatives are offered to connect to VTAM applications when USS message 10 is displayed other then LOGON APPLID(xxx) *or* selecting from LOGON command aliases defined in the USS table? I mean, is there any bypass to LOGON APPLID(xxx) if blocked? Answer: Use of the interpret table can, in effect, bypass the use of commands defined in the USS table. The usual alternative to use of USS LOGON commands in order to initiate sessions from end-user LUs is to use a session manager with which a session is established by means of a LOGAPPL operand on the LU (or LOCAL) statement definition. - > Now, there is no way to stop some one in org "A" to simply logon to org "B" CICS. Answer: Oh yes there is - see above. > Believe me, I tried it and accessed many vtam applications. few of them where no protected well. Some of them uses default ACB names. the ability to finally logon into is depend on the level of security implemented at org "B". In many cases I tested, it was not a problem to enter in. I am sure I can do it with some success at any site. There are always holes in security. Translation: Believe me, I tried it and accessed many VTAM applications. A few of them were not well protected. Some of them use default ACB names, that is, the names in the installation samples. The ability to logon to the application is dependent on the level of security implemented at org "B". In many cases I tested, it was not a problem to enter into the application. I am sure I can do it with some success at any site. There are always holes in security. Question: Are your organisations A and B using different network identifiers? If so that would explain how you were able to log onto applications which had not had the default APPL names changed. Response: You will not be able to get near the application if you adopt the CDRM definition operand values I mentioned. However, as the VTAM administrator at VTAMA and with no influence over the VTAM definitions in VTAMB, there is unavoidably one application logon you cannot block: that of end-users in VTAMA accessing - via the USS LOGON command - CICSB, the CICS for which you were obliged to define a CDRSC. In order to cover that you will be obliged to persuade the VTAM administrator at VTAMB to specify CDRSC=REQ on the CDRM statement for VTAMA and to create a CDRSC statement for CICSA. > Now that I found the door, I am looking to see how to limit Access from A to B by LU 6.2 from CICS and not from any terminal at "A". Translation: Now that I have found the door, I am looking to see how to allow access from A to B by means of the LU 6.2 connection from CICSA to CICSB but to forbid access from A to B by direct logon using the USS LOGON command from an end-user in VTAMA. > I think that the two organization agrred to connect their CICS systems on a limited services. Not to open a door to any terminal and to any vtam application. Assume that LOG APPL will accept netname.applid as P1... Translation: I believe that the two organizations want to connect their CICS systems for limited functions. I believe that they do not want to allow any end-user LU to logon to any application LU where the USS command is of the form LOGON APPLID(netname.applid). - Am I getting closer? Chris Mason On Wed, 14 Jan 2009 16:51:31 +0200, Itschak Mugzach <[email protected]> wrote: >Walt, I might used worng wording, but when I said LOGON to CICS (or any >other VTAM application on partner sight, I ment it. The only limit I >have when Pentesting is the partner company to agree for the signon. >I have seen few sites using no GMTRAN at all, so you signon to CICS with no >password and get the default user auth! There are also few other VTAM >applications that uses internal userid and passowrd that is stored in a >file. NDM is a sumple for super user that is described in a parameter >library. > >ITschak > >On Wed, Jan 14, 2009 at 4:42 PM, Walt Farrell <[email protected]> wrote: > >> In response to a Wed, 14 Jan 2009 08:00:36 +0200 message from Itschak >> Mugzach <[email protected]>: >> >> You seem to be mixing terminology, and possibly causing confusion, Itschak. >> (Though I think Chris understands what you've said and has provided some >> good pointers.) >> >> You start out by saying >> > Now, there is no way to stop some one in org "A" to simply logon to org >> "B" >> > CICS. >> >> Logging on to CICS is controlled by the user ID and password provided >> during >> the CICS signon processing. >> >> You go on to say: >> >Believe me, I tried it and accessed many vtam applications. few of >> >them where no protected well. Some of them uses default ACB names. the >> >ability to finally logon into is depend on the level of security >> implemented >> >at org "B". >> >> What you're talking about there is NOT "logging on to CICS" but connecting >> to org B's system, via VTAM, and logging on to other VTAM applications they >> have, not CICS. >> >> I'm not disputing that you were able to do that, but I feel it's important >> to properly express what has happened and thus, perhaps, avoid confusion. >> >> And yes, the ability to logon to B's applications, if you can reach B via >> an >> LU2 connection, is dependent on the security implemented at B and in its >> applications. >> >> -- >> Walt Farrell, CISSP >> IBM STSM, z/OS Security Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
