There is also IBM page http://www.ibm.com/support/docview.wss?rs=171&uid=swg21205523 which gives examples of digital certificate commands in various dialects.
Bill On Tue, 8 Jul 2008 11:55:52 -0500, Big Iron <[EMAIL PROTECTED]> wrote: >There is a cookbook for Top Secret running in a z/OS environment at >http://supportconnectw.ca.com/public/ca-topsecret/manuals/TSSCookB.pdf >which might be helpful to you or your Top Secret person. > >Bill > >On Mon, 7 Jul 2008 10:47:19 -0500, Tony B. <[EMAIL PROTECTED]> wrote: > >>For the examples below: >> >>TSS ADD( any-dept-acid ) IBMFAC(IRRDPIOO) >>TSS PERMIT(jeg) IBMFAC(IRRDPIOO) ACCESS(READ) >> >>If further information is needed regarding this "translation" is needed, let >>me know. >>There is a Top Secret related list server in YAHOO. >> >> >> >> >> >>"John Eells" <[EMAIL PROTECTED]> wrote in message news: >><[EMAIL PROTECTED]>... >>> Jim wrote: >>> > I just started working for a new company where I am installing z/OS >>> > 1.9. I have virtually no security other than what I need to get by. >>> > The 3rd job in the 1.9 installation is job RACFDRV which is a bunch of >>> > updates to the security system. We have Top Secret administered by >>> > another person who is slow to non-responsive for requests. I gave him >>> > the RACF job to convert to Top Secret. He informed me that he does not >>> > know what to do. >>> > >>> > I have included the job. Can anyone help me get the Top Secret >>> > equivelences for these statements? Thanks. Jim >>> <chop> >>> >>> >>> Long ago and far away, we attempted to document all the security updates >>> needed to make installation succeed with ServerPac. They were scattered >>> about the documentation and hard to test. As a result, testing failed a >>> lot and our customers had no consolidated view of what profiles they >>> needed to have. So we put them all into new jobs called RACFDRV and >>> RACFTGT that get tested. >>> >>> While you can certainly run RACFDRV as-is (in a RACF environment, at >>> least), it's not actually intended to be run except after suitable >>> modification to meet your installation's security standards, and then >>> only against a new, empty RACF database. >>> >>> Mostly, the same goes for RACFTGT. >>> >>> What these jobs are really for is to provide a (tested!) list of >>> security definitions that will get you through initial installation and >>> IVPs. Your security administrator should be able to figure out what >>> should really be done to provide any missing definitions you need in >>> your environment, according to your standards. Once that's all done, >>> you might still need more definitions to enable more functions to work. >>> >>> As I understand it, this is even more true in an ACF2 or TopSecret >>> environment than it is in a RACF environment because they have >>> fundamentally different approaches to security definitions. >>> >>> To take the first pair as an example: >>> >>> RDEFINE + >>> FACILITY IRRDPI00 + >>> UACC(NONE) >>> PE + >>> IRRDPI00 + >>> CLASS(FACILITY) + >>> ID(JEG) + >>> ACC(READ) >>> >>> What this means is that the user "JEG" needs to have READ (or higher) >>> access to the "IRRDPI00" profile in the FACILITY class. However you >>> accomplish that with ACF2 or TopSecret I have no clue, but someone should. >>> >>> (Note: This is actually a bad example. In this particular case, since I >>> believe IRRDPI00 is specific to a RACF environment you can probably >>> ignore it in an ACF2 or TopSecret environment.) >>> >>> -- >>> John Eells >>> z/OS Technical Marketing >>> IBM Poughkeepsie >>> [EMAIL PROTECTED] >>> > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
