eTrust CA-Top Secret Security for z/OS and OS ... - SupportConnect
eTrust CA-Top Secret Security for z/OS and OS ... - SupportConnect eTrust CA-Top Secret Security for z/OS and OS ... - SupportConnect
InfoPrint Server for z/OS and OS/390 (z/OS and OS/390 Print Server)In addition, if you are securing daemon authority, the TELNET server ID musthave the following permission:TSS PER(OMVSKERN) IBMFAC(BPX.DAEMON)InfoPrint Server for z/OS and OS/390 (z/OS and OS/390 PrintServer)The z/OS and OS/390 Print Server available with OS/390 V2R5 allowed forconsolidation of print files from multiple servers into one central server. AtOS/390 V2R8, the Print Server was renamed to InfoPrint Server for z/OS andOS/390. Control of the resources defined under the Print Server requires thedefinition of two groups: AOPOPER and AOPADMIN. These are IBM defaults.AOPOPER is the operator group with authority to start and stop the printinterface. AOPADMIN provides authority to administer the printer inventoryand controls. If the separation of authority is not necessary, then one group namecan be defined for both functions.Use the following steps to define the security environment for eTrust CA-TopSecret:TSS CRE(AOPADMIN) TYPE(GROUP) NAME('PRINT SERVER') DEPT(dept)TSS ADD(AOPADMIN) GID(6)TSS ADD(admin acid) GROUP(AOPADMIN)TSS CRE(AOPER) TYPE(GROUP) NAME('PRINT SERVER') DEPT(dept)TSS ADD(AOPER) GID(7)TSS ADD(acid) GROUP(AOPER)TSS ADD(JDCSYS) IBMFAC(AOPADMIN)TSS PERMIT(dept acid) IBMFAC(AOPADMIN) ACCESS(ALL)WebSphere Application Server for z/OS AND OS/390WebSphere for z/OS supports access to resources by clients and servers in adistributed network. Part of your security strategy should be to determine howto control access to these resources and prevent inadvertent or maliciousdestruction of the system or data.1–36 Cookbook
WebSphere Application Server for z/OS AND OS/390These are the pieces in the distributed network that you must consider:■■■■You must authorize servers to the base operating system services in z/OS orOS/390. These services include eTrust CA-Top Secret security, databasemanagement, and transaction management.For the servers, you must distinguish between control regions and serverregions. Control regions run authorized system code, so they are trusted.Server regions run application code and are given access to resources, so youshould carefully consider the authorizations you give server regions.You must also distinguish between the level of authority given to run-timeservers compared to your own application servers. For example, the SystemManagement server needs the authority to start other servers, while yourown application servers do not need this authority.You must authorize clients (users) to servers and objects within servers. Thecharacteristics of each client requires special consideration:- Is the client on the local system or is it remote? The security of thenetwork becomes a consideration for remote clients.- Will you allow unidentified (unauthenticated) clients to access thesystem? Some resources on your system can be intended for publicaccess, while others must be protected. In order to access protectedresources, clients must establish their identities and have authorizationto use those resources.- What kind of objects will the client access? Enterprise beans and CORBAobjects have differing authorization mechanisms.If you must protect resources, identifying who accesses those resources is critical.Thus, any security system requires client (user) identification, also known asauthentication. In a distributed network supported by WebSphere for z/OS,clients can be accessing resources from:■■■■Within the same system as a serverWithin the same sysplex as the serverRemote z/OS or OS/390 systemsHeterogeneous systems, such as WebSphere on distributed platforms, CICS,or other CORBA-compliant systems.Additionally, clients can request a service that requires a server to forward therequest to another server. In such cases the system must handle delegation, theavailability of the client identity for use by intermediate servers and targetservers.Implementing eTrust CA-Top Secret in a z/OS or OS/390 Environment 1–37
- Page 1 and 2: eTrust CA-Top Secret ® Securityfo
- Page 3: Technical UpdatesMay 2003The follow
- Page 6 and 7: Superuser Granularity .............
- Page 8 and 9: WLM (Workload Management)..........
- Page 11 and 12: Chapter1Implementing eTrust CA-TopS
- Page 13 and 14: z/OS and OS/390 CompatibilityThe li
- Page 15 and 16: z/OS and OS/390 Release-Specific Se
- Page 17 and 18: OpenEdition MVS / UNIX System Servi
- Page 19 and 20: OpenEdition MVS / UNIX System Servi
- Page 21 and 22: OpenEdition MVS / UNIX System Servi
- Page 23 and 24: OpenEdition MVS / UNIX System Servi
- Page 25 and 26: OpenEdition MVS / UNIX System Servi
- Page 27 and 28: OpenEdition MVS / UNIX System Servi
- Page 29 and 30: OpenEdition MVS / UNIX System Servi
- Page 31 and 32: Tracing UNIX System Services (OMVS)
- Page 33 and 34: Tracing UNIX System Services (OMVS)
- Page 35 and 36: Tracing UNIX System Services (OMVS)
- Page 37 and 38: Tracing UNIX System Services (OMVS)
- Page 39 and 40: Using TCP/IPFILE AUDIT OPTIONS—Th
- Page 41 and 42: Using TCP/IPwheresysname is the nam
- Page 43 and 44: Using FTPHow to Secure FTPFTP runs
- Page 45: Using TELNETTerminal Source Restric
- Page 49 and 50: WebSphere Application Server for z/
- Page 51 and 52: WebSphere Application Server for z/
- Page 53 and 54: WebSphere Application Server for z/
- Page 55 and 56: WebSphere Application Server for z/
- Page 57 and 58: Lotus Domino Go Webserver/* PERMITT
- Page 59 and 60: Lotus Domino Go WebserverTo disable
- Page 61 and 62: Lotus Notes and Novell Directory Se
- Page 63 and 64: Digital Certificate SupportGeneral
- Page 65 and 66: Digital Certificate SupportFOR|UNTI
- Page 67 and 68: Digital Certificate SupportDCDSN(re
- Page 69 and 70: Digital Certificate SupportNote: In
- Page 71 and 72: Digital Certificate SupportYou can
- Page 73 and 74: Digital Certificate SupportCase #2.
- Page 75 and 76: Digital Certificate SupportImportan
- Page 77 and 78: Digital Certificate SupportAdding a
- Page 79 and 80: Digital Certificate SupportReconnec
- Page 81 and 82: Digital Certificate SupportTSS LIST
- Page 83 and 84: Certificate Name Filtering SupportT
- Page 85 and 86: Certificate Name Filtering SupportI
- Page 87 and 88: Certificate Name Filtering SupportD
- Page 89 and 90: Certificate Name Filtering SupportL
- Page 91 and 92: KerberosKerberosetrust CA-Top Secre
- Page 93 and 94: KerberosThe command syntax for this
- Page 95 and 96: KerberosThe following command creat
WebSphere Application Server <strong>for</strong> z/<strong>OS</strong> AND <strong>OS</strong>/390These are the pieces in the distributed network that you must consider:■■■■You must authorize servers to the base operating system services in z/<strong>OS</strong> or<strong>OS</strong>/390. These services include <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> security, databasemanagement, <strong>and</strong> transaction management.For the servers, you must distinguish between control regions <strong>and</strong> serverregions. Control regions run authorized system code, so they are trusted.Server regions run application code <strong>and</strong> are given access to resources, so youshould carefully consider the authorizations you give server regions.You must also distinguish between the level of authority given to run-timeservers compared to your own application servers. For example, the SystemManagement server needs the authority to start other servers, while yourown application servers do not need this authority.You must authorize clients (users) to servers <strong>and</strong> objects within servers. Thecharacteristics of each client requires special consideration:- Is the client on the local system or is it remote? The security of thenetwork becomes a consideration <strong>for</strong> remote clients.- Will you allow unidentified (unauthenticated) clients to access thesystem? Some resources on your system can be intended <strong>for</strong> publicaccess, while others must be protected. In order to access protectedresources, clients must establish their identities <strong>and</strong> have authorizationto use those resources.- What kind of objects will the client access? Enterprise beans <strong>and</strong> CORBAobjects have differing authorization mechanisms.If you must protect resources, identifying who accesses those resources is critical.Thus, any security system requires client (user) identification, also known asauthentication. In a distributed network supported by WebSphere <strong>for</strong> z/<strong>OS</strong>,clients can be accessing resources from:■■■■Within the same system as a serverWithin the same sysplex as the serverRemote z/<strong>OS</strong> or <strong>OS</strong>/390 systemsHeterogeneous systems, such as WebSphere on distributed plat<strong>for</strong>ms, CICS,or other CORBA-compliant systems.Additionally, clients can request a service that requires a server to <strong>for</strong>ward therequest to another server. In such cases the system must h<strong>and</strong>le delegation, theavailability of the client identity <strong>for</strong> use by intermediate servers <strong>and</strong> targetservers.Implementing <strong>eTrust</strong> <strong>CA</strong>-<strong>Top</strong> <strong>Secret</strong> in a z/<strong>OS</strong> or <strong>OS</strong>/390 Environment 1–37