diff --git a/docs/user-guide/assign-security-permissions-to-users.md b/docs/user-guide/assign-security-permissions-to-users.md index 20323ddaac..1cbd26e142 100644 --- a/docs/user-guide/assign-security-permissions-to-users.md +++ b/docs/user-guide/assign-security-permissions-to-users.md @@ -59,6 +59,23 @@ see [zwe init security](../appendix/zwe_server_command_reference/zwe/init/zwe-in | Cross memory server (ZIS) | FACILITY | `ZWES.IS` | READ | Allow Zowe ZWESLSTC processes to access the Zowe ZIS cross memory server. | This parameter permits the Zowe main server to use ZIS cross memory server. Run the command that applies to your ESM.
• [RACF](https://github.com/zowe/zowe-install-packaging/blob/79527166f34e28c205c5f60bf4b4bb7b630bc6a1/workflows/templates/ZWESECUR.vtl#L329)
• [ACF2](https://github.com/zowe/zowe-install-packaging/blob/79527166f34e28c205c5f60bf4b4bb7b630bc6a1/workflows/templates/ZWESECUR.vtl#L560)
• [Top Secret](https://github.com/zowe/zowe-install-packaging/blob/79527166f34e28c205c5f60bf4b4bb7b630bc6a1/workflows/templates/ZWESECUR.vtl#L780) | +## Configuring address space job naming + +The user ID `ZWESVUSR` that is associated with the Zowe started task must have `READ` permission for the `BPX.JOBNAME` profile in the `FACILITY` class. This is to allow setting of the names for the different z/OS UNIX address spaces for the Zowe runtime components. + +1. To display who is authorized to the profile, issue the following command: +``` +RLIST FACILITY BPX.JOBNAME AUTHUSER +``` + +2. Activate the facility class, permit `BPX.JOBNAME`, and refresh facility class: +``` +SETROPTS CLASSACT(FACILITY) RACLIST(FACILITY) +PERMIT BPX.JOBNAME CLASS(FACILITY) ID(ZWESVUSR) ACCESS(READ) +SETROPTS RACLIST(FACILITY) REFRESH +``` + +For more information, see [Setting up the UNIX-related FACILITY and SURROGAT class profiles](https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxb200/fclass.htm) in the "z/OS UNIX System Services" documentation. ## Granting users permission to access z/OSMF diff --git a/docs/user-guide/configure-zos-system.md b/docs/user-guide/configure-zos-system.md index 64ca26a40e..7f765ed0bc 100644 --- a/docs/user-guide/configure-zos-system.md +++ b/docs/user-guide/configure-zos-system.md @@ -1,10 +1,18 @@ -# Addressing z/OS requirements for Zowe +# Security customization of your z/OS system -As a security administrator it is necessary to configure the z/OS system for Zowe. Review the following article to learn about z/OS prerequisites, and z/OS configuration requirements for specific settings. +As a security administrator, configure your z/OS system according to the specific features and functionalities you choose to include in your Zowe installation. Review the following article for specific configuration steps that apply to these features and fuctionalities. :::info Required role: security administrator ::: + +:::note +Before performing configuration steps specific to your use case, ensure that you meet the z/OS system requirements presented in the section _Preparing for installation_. For detailed information, see [Addressing z/OS requirements](./systemrequirements-zos.md). +::: + + of free space for Zowe server components, their keystore, instance configuration files and logs, and third-party plug-ins. +- zFS volume has at least 833 mb of free space for Zowe server components, their keystore, instance configuration files and logs, and third-party plug-ins. - (Optional, recommended) z/OS OpenSSH V2.2.0 or later @@ -25,27 +33,48 @@ Be sure your z/OS system meets the following prerequisites: To deploy Zowe for high availability, a Parallel Sysplex environment is recommended. For more information, see [Configuring Sysplex for high availability](configure-sysplex.md). - ## Settings specific configuration requirements +--> -Configuration of your z/OS system is dependent on the specific Zowe features and functionalities you would like to employ with your Zowe installation. Review the following table to determine which configuration steps are required based on your Zowe use case. - -| Purpose | Configuration step | -| --- | --- | -| Set the names for the different z/OS UNIX address spaces for the Zowe runtime components.
**Important:** This configuration step is required. | [Configure address space job naming](#configure-address-space-job-naming) | -| To use Zowe desktop. This step generates random numbers for zssServer that the Zowe desktop uses. | [Configure an ICSF cryptographic services environment](#configure-an-icsf-cryptographic-services-environment) | -| To allow users to log on to the Zowe desktop through impersonation. | [Configure security environment switching](#configure-security-environment-switching) | -| Required for TSS only. A TSS FACILITY needs to be defined and assigned to the `ZWESLSTC` started task. | [Configure multi-user address space for TSS only](#configure-multi-user-address-space-for-tss-only) | -| Required if you have not run `ZWESECUR` and are manually creating the user ID and groups in your z/OS environment. | [Configure user IDs and groups for the Zowe started tasks](#configure-user-ids-and-groups-for-the-zowe-started-tasks) | -| Required if you have not run `ZWESECUR` and are configuring your z/OS environment manually. This step describes how to configure the started task ZWESLSTC to run under the correct user ID and group. | [Configure ZWESLSTC to run Zowe high availability instances under ZWESVUSR user ID](#configure-zweslstc-to-run-zowe-high-availability-instances-under-zwesvusr-user-id) | -| Required if you have not run `ZWESECUR` and are configuring your z/OS environment manually. This step describes how to configure the cross memory server for SAF to guard against access by non-privileged clients. | [Configure the cross memory server for SAF](#configure-the-cross-memory-server-for-saf) | -| Required for API Mediation Layer to map a client certificate to a z/OS identity. | [Configure main Zowe server to use client certificate identity mapping](#configure-main-zowe-server-to-use-client-certificate-identity-mapping) | -| Required for API ML to map the association between a z/OS user ID and a distributed user identity. | [Configure main Zowe server to use distributed identity mapping](#configure-main-zowe-server-to-use-distributed-identity-mapping) | -| To configure SAF Identity tokens on z/OS so that they can be used by Zowe components like zss or API Mediation Layer. | [Configure signed SAF Identity tokens IDT](#configure-signed-saf-identity-tokens-idt) | -| Required for API Mediation Layer to issue SMF records. | [Configure the main Zowe server to issue SMF records](api-mediation/api-mediation-smf.md#configure-the-main-zowe-server-to-issue-smf-records) | -| To use multi-factor authentication (MFA) | [Multi-Factor Authentication (MFA)](#multi-factor-authentication-mfa) | -| To use Single Sign-On (SSO) | [Single Sign-On (SSO)](#single-sign-on-sso) | -| To use OIDC Authentication with API Mediation Layer | [API Mediation Layer OIDC Authentication](#api-mediation-layer-oidc-authentication) | + Review the following table to determine which configuration steps are required based on your Zowe use case. + +| Purpose | Applicable Zowe Component(s) | Configuration step | +| --- | --- | --- | +| Set the names for the different z/OS UNIX address spaces for the Zowe runtime components.
**Important:** This configuration step is required. | All components | [Configure address space job naming](#configure-address-space-job-naming) | +| To use Zowe desktop. This step generates random numbers for zssServer that the Zowe desktop uses. | Application Framework | [Configure an ICSF cryptographic services environment](#configure-an-icsf-cryptographic-services-environment) | +| To allow users to log on to the Zowe desktop through impersonation. | Application Framework | [Configure security environment switching](#configure-security-environment-switching) | +| Required for TSS only. A TSS FACILITY needs to be defined and assigned to the `ZWESLSTC` started task. | ? | [Configure multi-user address space for TSS only](#configure-multi-user-address-space-for-tss-only) | +| Required to manually create the user ID and groups in your z/OS environment. Tasks are performed as part of [Zowe runtime configuration](./configure-zowe-runtime.md) | ? | [Configure user IDs and groups for the Zowe started tasks](#configure-user-ids-and-groups-for-the-zowe-started-tasks) | +| Required to configure the started task ZWESLSTC to run under the correct user ID and group. Tasks are performed as part of [Zowe runtime configuration](./configure-zowe-runtime.md).| ? | [Configure ZWESLSTC to run Zowe high availability instances under ZWESVUSR user ID](#configure-zweslstc-to-run-zowe-high-availability-instances-under-zwesvusr-user-id). | +| Required to configure the cross memory server for SAF to guard against access by non-privileged clients. Tasks are performed as part of [Zowe runtime configuration](./configure-zowe-runtime.md).| Application Framework | [Configure the cross memory server for SAF](#configure-the-cross-memory-server-for-saf) | +| Required for API Mediation Layer to map a client certificate to a z/OS identity. | API ML | [Configure main Zowe server to use client certificate identity mapping](#configure-main-zowe-server-to-use-client-certificate-identity-mapping) | +| Required for API ML to map the association between a z/OS user ID and a distributed user identity. | API ML | [Configure main Zowe server to use distributed identity mapping](#configure-main-zowe-server-to-use-distributed-identity-mapping) | +| To configure SAF Identity tokens on z/OS so that they can be used by Zowe components like zss or API Mediation Layer. | Application Framework
API ML | [Configure signed SAF Identity tokens IDT](#configure-signed-saf-identity-tokens-idt) | +| Required for API Mediation Layer to issue SMF records. | API ML | [Configure the main Zowe server to issue SMF records](api-mediation/api-mediation-smf.md#configure-the-main-zowe-server-to-issue-smf-records) | +| To use multi-factor authentication (MFA) | ? | [Multi-Factor Authentication (MFA)](#multi-factor-authentication-mfa) | +| To use Single Sign-On (SSO) | ? | [Single Sign-On (SSO)](#single-sign-on-sso) | +| To use OIDC Authentication with API Mediation Layer | API ML | [API Mediation Layer OIDC Authentication](#api-mediation-layer-oidc-authentication) | + +### Configure address space job naming + +The user ID `ZWESVUSR` that is associated with the Zowe started task must have `READ` permission for the `BPX.JOBNAME` profile in the `FACILITY` class. This is to allow setting of the names for the different z/OS UNIX address spaces for the Zowe runtime components. + +:::note +This procedure may require security administrator authorization. Consult with your security administrator. +::: + +To display who is authorized to the profile, issue the following command: +``` +RLIST FACILITY BPX.JOBNAME AUTHUSER +``` + +Additionally, you need to activate facility class, permit `BPX.JOBNAME`, and refresh facility class: +``` +SETROPTS CLASSACT(FACILITY) RACLIST(FACILITY) +PERMIT BPX.JOBNAME CLASS(FACILITY) ID(ZWESVUSR) ACCESS(READ) +SETROPTS RACLIST(FACILITY) REFRESH +``` +For more information, see [Setting up the UNIX-related FACILITY and SURROGAT class profiles](https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxb200/fclass.htm) in the "z/OS UNIX System Services" documentation. ### Configure an ICSF cryptographic services environment @@ -66,62 +95,89 @@ Define or check the following configurations depending on whether ICSF is alread - Create CKDS, PKDS, TKDS VSAM data sets. - Define and activate the CSFSERV class: - - If you use RACF, issue the following commands: - ``` - RDEFINE CSFSERV profile-name UACC(NONE) - ``` - ``` - PERMIT profile-name CLASS(CSFSERV) ID(tcpip-stackname) ACCESS(READ) - ``` - ``` - PERMIT profile-name CLASS(CSFSERV) ID(userid-list) ... [for - userids IKED, NSSD, and Policy Agent] - ``` - ``` - SETROPTS CLASSACT(CSFSERV) - ``` - ``` - SETROPTS RACLIST(CSFSERV) REFRESH - ``` - - If you use ACF2, issue the following commands (note that `profile-prefix` and `profile-suffix` are user-defined): - ``` - SET CONTROL(GSO) - ``` - ``` - INSERT CLASMAP.CSFSERV RESOURCE(CSFSERV) RSRCTYPE(CSF) - ``` - ``` - F ACF2,REFRESH(CLASMAP) - ``` - ``` - SET RESOURCE(CSF) - ``` - ``` - RECKEY profile-prefix ADD(profile-suffix uid(UID string for tcpip-stackname) SERVICE(READ) ALLOW) - ``` - ``` - RECKEY profile-prefix ADD(profile-suffix uid(UID string for IZUSVR) SERVICE(READ) ALLOW) - ``` - (repeat for userids IKED, NSSD, and Policy Agent) +
- ``` - F ACF2,REBUILD(CSF) - ``` - - If you use Top Secret, issue the following command (note that `profile-prefix` and `profile-suffix` are user defined): - ``` - TSS ADDTO(owner-acid) RESCLASS(CSFSERV) - ``` - ``` - TSS ADD(owner-acid) CSFSERV(profile-prefix.) - ``` - ``` - TSS PERMIT(tcpip-stackname) CSFSERV(profile-prefix.profile-suffix) ACCESS(READ) - ``` - ``` - TSS PERMIT(user-acid) CSFSERV(profile-prefix.profile-suffix) ACCESS(READ) - ``` - (repeat for user-acids IKED, NSSD, and Policy Agent) + +For RACF, click here for command details. + + +If you use RACF, issue the following commands: +``` +RDEFINE CSFSERV profile-name UACC(NONE) +``` +``` +PERMIT profile-name CLASS(CSFSERV) ID(tcpip-stackname) ACCESS(READ) +``` +``` +PERMIT profile-name CLASS(CSFSERV) ID(userid-list) ... [for +userids IKED, NSSD, and Policy Agent] +``` +``` +SETROPTS CLASSACT(CSFSERV) +``` +``` +SETROPTS RACLIST(CSFSERV) REFRESH +``` +
+ +
+ + +For ACF2, click here for command details. + + + +If you use ACF2, issue the following commands (note that `profile-prefix` and `profile-suffix` are user-defined): + +``` +SET CONTROL(GSO) +``` +``` +INSERT CLASMAP.CSFSERV RESOURCE(CSFSERV) RSRCTYPE(CSF) +``` +``` +F ACF2,REFRESH(CLASMAP) +``` +``` +SET RESOURCE(CSF) +``` +``` +RECKEY profile-prefix ADD(profile-suffix uid(UID string for tcpip-stackname) SERVICE(READ) ALLOW) +``` +``` +RECKEY profile-prefix ADD(profile-suffix uid(UID string for IZUSVR) SERVICE(READ) ALLOW) +``` +(repeat for userids IKED, NSSD, and Policy Agent) + +``` +F ACF2,REBUILD(CSF) +``` +
+ +
+ + +For Top Secret, click here for command details. + + +If you use Top Secret, issue the following command (note that `profile-prefix` and `profile-suffix` are user defined): + +``` +TSS ADDTO(owner-acid) RESCLASS(CSFSERV) +``` +``` +TSS ADD(owner-acid) CSFSERV(profile-prefix.) +``` +``` +TSS PERMIT(tcpip-stackname) CSFSERV(profile-prefix.profile-suffix) ACCESS(READ) +``` +``` +TSS PERMIT(user-acid) CSFSERV(profile-prefix.profile-suffix) ACCESS(READ) +``` +(repeat for user-acids IKED, NSSD, and Policy Agent) + +
:::note Notes - Determine whether you want SAF authorization checks against `CSFSERV` and set `CSF.CSFSERV.AUTH.CSFRNG.DISABLE` accordingly. @@ -138,171 +194,228 @@ To enable impersonation, you must grant the user ID `ZWESVUSR` associated with t You can issue the following commands first to check whether you already have the impersonation profiles defined as part of another server configuration, such as the FTPD daemon. Review the output to confirm that the two impersonation profiles exist and the user `ZWESVUSR` who runs the Zowe server started task has UPDATE access to both profiles. -- If you use RACF, issue the following commands: - ``` - RLIST FACILITY BPX.SERVER AUTHUSER - ``` - ``` - RLIST FACILITY BPX.DAEMON AUTHUSER - ``` -- If you use Top Secret, issue the following commands: - ``` - TSS WHOHAS IBMFAC(BPX.SERVER) - ``` - ``` - TSS WHOHAS IBMFAC(BPX.DAEMON) - ``` -- If you use ACF2, issue the following commands: - ``` - SET RESOURCE(FAC) - ``` - ``` - LIST BPX - ``` +
+ + +For RACF, click here for command details. + -If the user `ZWESVUSR` who runs the Zowe server started task does not have UPDATE access to both profiles follow the instructions below. +If you use RACF, issue the following commands: +``` +RLIST FACILITY BPX.SERVER AUTHUSER +``` +``` +RLIST FACILITY BPX.DAEMON AUTHUSER +``` + +
+ +
+ + +For Top Secret, click here for command details. + + +If you use Top Secret, issue the following commands: +``` +TSS WHOHAS IBMFAC(BPX.SERVER) +``` +``` +TSS WHOHAS IBMFAC(BPX.DAEMON) +``` -- If you use RACF, complete the following steps: +
+ +
+ + +For ACF2, click here for command details. + + +If you use ACF2, issue the following commands: +``` +SET RESOURCE(FAC) +``` +``` +LIST BPX +``` + +
+ +If the user `ZWESVUSR` who runs the Zowe server started task does not have UPDATE access to both profiles follow the instructions according to your ESM. + +
+ + +For RACF, click here for procedure details. + + +If you use RACF, complete the following steps: - 1. Activate and RACLIST the FACILITY class. This may have already been done on the z/OS environment if another z/OS server has been previously configured to take advantage of the ability to change its security environment, such as the FTPD daemon that is included with z/OS Communications Server TCP/IP services. - ``` - SETROPTS GENERIC(FACILITY) - SETROPTS CLASSACT(FACILITY) RACLIST(FACILITY) - ``` - 2. Define the impersonation profiles. This may have already been done on behalf of another server such as the FTPD daemon. - ``` - RDEFINE FACILITY BPX.SERVER UACC(NONE) - ``` - ``` - RDEFINE FACILITY BPX.DAEMON UACC(NONE) - ``` - 3. Having activated and RACLIST the FACILITY class, the user ID `ZWESVUSR` who runs the Zowe server started task must be given update access to the BPX.SERVER and BPX.DAEMON profiles in the FACILITY class. - ``` - PERMIT BPX.SERVER CLASS(FACILITY) ID() ACCESS(UPDATE) - ``` - ``` - PERMIT BPX.DAEMON CLASS(FACILITY) ID() ACCESS(UPDATE) - ``` - where `` is `ZWESVUSR` unless a different user ID is being used for the z/OS environment. - - /* Activate these changes */ - - ``` - SETROPTS RACLIST(FACILITY) REFRESH - ``` - 4. Issue the following commands to check whether permission has been successfully granted: - ``` - RLIST FACILITY BPX.SERVER AUTHUSER - ``` - ``` - RLIST FACILITY BPX.DAEMON AUTHUSER - ``` -- If you use Top Secret, complete the following steps: +1. Activate and RACLIST the FACILITY class. This may have already been done on the z/OS environment if another z/OS server has been previously configured to take advantage of the ability to change its security environment, such as the FTPD daemon that is included with z/OS Communications Server TCP/IP services. +``` +SETROPTS GENERIC(FACILITY) +SETROPTS CLASSACT(FACILITY) RACLIST(FACILITY) +``` +2. Define the impersonation profiles. This may have already been done on behalf of another server such as the FTPD daemon. +``` +RDEFINE FACILITY BPX.SERVER UACC(NONE) +``` +``` +RDEFINE FACILITY BPX.DAEMON UACC(NONE) +``` +3. Having activated and RACLIST the FACILITY class, the user ID `ZWESVUSR` who runs the Zowe server started task must be given update access to the BPX.SERVER and BPX.DAEMON profiles in the FACILITY class. +``` +PERMIT BPX.SERVER CLASS(FACILITY) ID() ACCESS(UPDATE) +``` +``` +PERMIT BPX.DAEMON CLASS(FACILITY) ID() ACCESS(UPDATE) +``` +where: + +* `` is `ZWESVUSR` unless a different user ID is being used for the z/OS environment. + +/* Activate these changes */ + +``` +SETROPTS RACLIST(FACILITY) REFRESH +``` +4. Issue the following commands to check whether permission has been successfully granted: +``` +RLIST FACILITY BPX.SERVER AUTHUSER +``` +``` +RLIST FACILITY BPX.DAEMON AUTHUSER +``` + +
+ +
+ + +For Top Secret, click here for procedure details. + + +If you use Top Secret, complete the following steps: - 1. Define the BPX Resource and access for ``. - ``` - TSS ADD(`owner-acid`) IBMFAC(BPX.) - ``` - ``` - TSS PERMIT() IBMFAC(BPX.SERVER) ACCESS(UPDATE) - ``` - ``` - TSS PERMIT() IBMFAC(BPX.DAEMON) ACCESS(UPDATE) - ``` - where `` is `ZWESVUSR` unless a different user ID is being used for the z/OS environment. - 2. Issue the following commands and review the output to check whether permission has been successfully granted: - ``` - TSS WHOHAS IBMFAC(BPX.SERVER) - ``` - ``` - TSS WHOHAS IBMFAC(BPX.DAEMON) - ``` -- If you use ACF2, complete the following steps: - 1. Define the BPX Resource and access for ``. - ``` - SET RESOURCE(FAC) - ``` - ``` - RECKEY BPX ADD(SERVER ROLE() SERVICE(UPDATE) ALLOW) - ``` - ``` - RECKEY BPX ADD(DAEMON ROLE() SERVICE(UPDATE) ALLOW) - ``` - where `` is `ZWESVUSR` unless a different user ID is being used for the z/OS environment. - ``` - F ACF2,REBUILD(FAC) - ``` - 2. Issue the following commands and review the output to check whether permission has been successfully granted: - ``` - SET RESOURCE(FAC) - ``` - ``` - LIST BPX - ``` +1. Define the BPX Resource and access for ``. +``` +TSS ADD(`owner-acid`) IBMFAC(BPX.) +``` +``` +TSS PERMIT() IBMFAC(BPX.SERVER) ACCESS(UPDATE) +``` +``` +TSS PERMIT() IBMFAC(BPX.DAEMON) ACCESS(UPDATE) +``` +where: +* `` is `ZWESVUSR` unless a different user ID is being used for the z/OS environment. +2. Issue the following commands and review the output to check whether permission has been successfully granted: +``` +TSS WHOHAS IBMFAC(BPX.SERVER) +``` +``` +TSS WHOHAS IBMFAC(BPX.DAEMON) +``` +
+ +
+ + +For ACF2, click here for procedure details. + + +If you use ACF2, complete the following steps: +1. Define the BPX Resource and access for ``. +``` +SET RESOURCE(FAC) +``` +``` +RECKEY BPX ADD(SERVER ROLE() SERVICE(UPDATE) ALLOW) +``` +``` +RECKEY BPX ADD(DAEMON ROLE() SERVICE(UPDATE) ALLOW) +``` +where: +* `` is `ZWESVUSR` unless a different user ID is being used for the z/OS environment. +``` +F ACF2,REBUILD(FAC) +``` +2. Issue the following commands and review the output to check whether permission has been successfully granted: +``` +SET RESOURCE(FAC) +``` +``` +LIST BPX +``` + +
You must also grant READ access to the OMVSAPPL profile in the APPL class to the Zowe STC user as well as **all other Zowe users** using various Zowe features. Skip the following steps when the OMVSAPPL profile is not defined in your environment. -- If you use RACF, complete the following steps: +
+ + +For RACF, click here for procedure details. + + +If you use RACF, complete the following steps: - 1. Check if you already have the required access defined as part of the environment configuration. Skip the following steps if access is already granted. - ``` - RLIST APPL OMVSAPPL AUTHUSER - ``` +1. Check if you already have the required access defined as part of the environment configuration. Skip the following steps if access is already granted. +``` +RLIST APPL OMVSAPPL AUTHUSER +``` - 2. Issue the following commands and review the output to check if permission has been successfully granted: - ``` - PERMIT OMVSAPPL CLASS(APPL) ID() ACCESS(READ) - SETROPTS RACLIST(APPL) REFRESH - ``` +2. Issue the following commands and review the output to check if permission has been successfully granted: +``` +PERMIT OMVSAPPL CLASS(APPL) ID() ACCESS(READ) +SETROPTS RACLIST(APPL) REFRESH +``` -- If you use Top Secret, complete the following steps: +
- 1. Check if you already have the required access as part of the environment configuration. Skip the following steps if access is already granted. - ``` - TSS WHOHAS APPL(OMVSAPPL) - ``` +
- 2. Issue the following commands and review the output to check if permission has been successfully granted: - ``` - TSS PERMIT() APPL(OMVSAPPL) - ``` + +For Top Secret, click here for procedure details. + -- If you use ACF2, complete the following steps: +If you use Top Secret, complete the following steps: - 1. Check if you already have the required access defined as part of the environment configuration. Skip the following steps if access is already granted. - ``` - SET RESOURCE(APL) - LIST OMVSAAPL - ``` +1. Check if you already have the required access as part of the environment configuration. Skip the following steps if access is already granted. +``` +TSS WHOHAS APPL(OMVSAPPL) +``` - 2. Issue the following commands and review the output to check if permission has been successfully granted: - ``` - SET RESOURCE(APL) - RECKEY OMVSAPPL ADD(SERVICE(READ) ROLE() ALLOW) - F ACF2,REBUILD(APL) - ``` +2. Issue the following commands and review the output to check if permission has been successfully granted: +``` +TSS PERMIT() APPL(OMVSAPPL) +``` -### Configure address space job naming +
-The user ID `ZWESVUSR` that is associated with the Zowe started task must have `READ` permission for the `BPX.JOBNAME` profile in the `FACILITY` class. This is to allow setting of the names for the different z/OS UNIX address spaces for the Zowe runtime components. +
-:::note -This procedure may require security administrator authorization. Consult with your security administrator. -::: + +For ACF2, click here for procedure details. + -To display who is authorized to the profile, issue the following command: +If you use ACF2, complete the following steps: + +1. Check if you already have the required access defined as part of the environment configuration. Skip the following steps if access is already granted. ``` -RLIST FACILITY BPX.JOBNAME AUTHUSER +SET RESOURCE(APL) +LIST OMVSAAPL ``` -Additionally, you need to activate facility class, permit `BPX.JOBNAME`, and refresh facility class: +2. Issue the following commands and review the output to check if permission has been successfully granted: ``` -SETROPTS CLASSACT(FACILITY) RACLIST(FACILITY) -PERMIT BPX.JOBNAME CLASS(FACILITY) ID(ZWESVUSR) ACCESS(READ) -SETROPTS RACLIST(FACILITY) REFRESH +SET RESOURCE(APL) +RECKEY OMVSAPPL ADD(SERVICE(READ) ROLE() ALLOW) +F ACF2,REBUILD(APL) ``` -For more information, see [Setting up the UNIX-related FACILITY and SURROGAT class profiles](https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.bpxb200/fclass.htm) in the "z/OS UNIX System Services" documentation. +
### Configure multi-user address space (for TSS only) @@ -391,25 +504,49 @@ If you have run `ZWESECUR`, you do not need to perform the steps described in th If you have not run `ZWESECUR` and are configuring your z/OS environment manually, the following steps describe how to configure the started task `ZWESLSTC` to run under the correct user ID and group. -- If you use RACF, issue the following commands: - ``` - RDEFINE STARTED ZWESLSTC.* UACC(NONE) STDATA(USER(ZWESVUSR) GROUP(ZWEADMIN) PRIVILEGED(NO) TRUSTED(NO) TRACE(YES)) - SETROPTS REFRESH RACLIST(STARTED) - ``` +
-- If you use ACF2, issue the following commands: + +For RACF, click here for command details. + - ``` - SET CONTROL(GSO) - INSERT STC.ZWESLSTC LOGONID(ZWESVUSR) GROUP(ZWEADMIN) STCID(ZWESLSTC) - F ACF2,REFRESH(STC) - ``` +If you use RACF, issue the following commands: +``` +RDEFINE STARTED ZWESLSTC.* UACC(NONE) STDATA(USER(ZWESVUSR) GROUP(ZWEADMIN) PRIVILEGED(NO) TRUSTED(NO) TRACE(YES)) +SETROPTS REFRESH RACLIST(STARTED) +``` -- If you use Top Secret, issue the following commands: +
- ``` - TSS ADDTO(STC) PROCNAME(ZWESLSTC) ACID(ZWESVUSR) - ``` +
+ + +For ACF2, click here for command details. + + +If you use ACF2, issue the following commands: + +``` +SET CONTROL(GSO) +INSERT STC.ZWESLSTC LOGONID(ZWESVUSR) GROUP(ZWEADMIN) STCID(ZWESLSTC) +F ACF2,REFRESH(STC) +``` + +
+ +
+ + +For Top Secret, click here for command details. + + +If you use Top Secret, issue the following commands: + +``` +TSS ADDTO(STC) PROCNAME(ZWESLSTC) ACID(ZWESVUSR) +``` + +
### Configure the cross memory server for SAF @@ -426,60 +563,85 @@ If you have not run `ZWESECUR` and are configuring your z/OS environment manuall Activate the FACILITY class, define a `ZWES.IS` profile, and grant READ access to the user ID `ZWESVUSR`. This is the user ID that the main Zowe started task runs under. -To do this, issue the following commands that are also included in the `ZWESECUR` JCL member. The commands assume that you run the Zowe server under the `ZWESVUSR` user. +Issue the following commands that are also included in the `ZWESECUR` JCL member. The commands assume that you run the Zowe server under the `ZWESVUSR` user. -- If you use RACF, issue the following commands: +
- - To see the current class settings, use: - ``` - SETROPTS LIST - ``` - - To define and activate the FACILITY class, use: - ``` - SETROPTS GENERIC(FACILITY) - SETROPTS CLASSACT(FACILITY) - ``` - - To RACLIST the FACILITY class, use: - ``` - SETROPTS RACLIST(FACILITY) - ``` - - To define the `ZWES.IS` profile in the FACILITY class and grant Zowe's started task userid READ access, issue the following commands: - ``` - RDEFINE FACILITY ZWES.IS UACC(NONE) - ``` - ``` - PERMIT ZWES.IS CLASS(FACILITY) ID() ACCESS(READ) - ``` - where `` is the user ID `ZWESVUSR` under which the Zowe server started task runs. - ``` - SETROPTS RACLIST(FACILITY) REFRESH - ``` - - To check whether the permission has been successfully granted, issue the following command: - ``` - RLIST FACILITY ZWES.IS AUTHUSER - ``` - This shows the user IDs who have access to the `ZWES.IS` class, which should include Zowe's started task user ID with READ access. + +For RACF, click here for command details. + -- If you use ACF2, issue the following commands: +If you use RACF, issue the following commands: +- To see the current class settings, use: ``` - SET RESOURCE(FAC) + SETROPTS LIST + ``` +- To define and activate the FACILITY class, use: ``` + SETROPTS GENERIC(FACILITY) + SETROPTS CLASSACT(FACILITY) ``` - RECKEY ZWES ADD(IS ROLE(IZUSVR) SERVICE(READ) ALLOW) +- To RACLIST the FACILITY class, use: ``` + SETROPTS RACLIST(FACILITY) ``` - F ACF2,REBUILD(FAC) +- To define the `ZWES.IS` profile in the FACILITY class and grant Zowe's started task userid READ access, issue the following commands: ``` - -- If you use Top Secret, issue the following commands, where `owner-acid` can be IZUSVR or a different ACID: - + RDEFINE FACILITY ZWES.IS UACC(NONE) + ``` + ``` + PERMIT ZWES.IS CLASS(FACILITY) ID() ACCESS(READ) + ``` + where: + * `` is the user ID `ZWESVUSR` under which the Zowe server started task runs. ``` - TSS ADD(`owner-acid`) IBMFAC(ZWES.) + SETROPTS RACLIST(FACILITY) REFRESH ``` +- To check whether the permission has been successfully granted, issue the following command: ``` - TSS PERMIT(ZWESVUSR) IBMFAC(ZWES.IS) ACCESS(READ) + RLIST FACILITY ZWES.IS AUTHUSER ``` + This shows the user IDs who have access to the `ZWES.IS` class, which should include Zowe's started task user ID with READ access. + +
+ +
+ + +For ACF2, click here for command details. + + +If you use ACF2, issue the following commands: + +``` +SET RESOURCE(FAC) +``` +``` +RECKEY ZWES ADD(IS ROLE(IZUSVR) SERVICE(READ) ALLOW) +``` +``` +F ACF2,REBUILD(FAC) +``` + +
+ +
+ + +For Top Secret, click here for command details. + + +If you use Top Secret, issue the following commands, where `owner-acid` can be IZUSVR or a different ACID: + +``` +TSS ADD(`owner-acid`) IBMFAC(ZWES.) +``` +``` +TSS PERMIT(ZWESVUSR) IBMFAC(ZWES.IS) ACCESS(READ) +``` + +
:::note Notes - The cross memory server treats "no decision" style SAF return codes as failures. If there is no covering profile for the `ZWES.IS` resource in the FACILITY class, the request will be denied. @@ -491,7 +653,11 @@ To do this, issue the following commands that are also included in the `ZWESECUR This security configuration is necessary for API ML to be able to map client certificate to a z/OS identity. A user running API Gateway must have read access to the SAF resource `IRR.RUSERMAP` in the `FACILITY` class. To set up this security configuration, submit the `ZWESECUR` JCL member. For users upgrading from version 1.18 and lower use the following configuration steps. -#### Using RACF +
+ + +For RACF, click here for procedure details. + If you use RACF, verify and update permission in the `FACILITY` class. @@ -511,8 +677,13 @@ If you use RACF, verify and update permission in the `FACILITY` class. ``` SETROPTS RACLIST(FACILITY) REFRESH ``` +
-#### Using ACF2 +
+ + +For ACF2, click here for procedure details. + If you use ACF2, verify and update permission in the `FACILITY` class. @@ -534,7 +705,13 @@ If you use ACF2, verify and update permission in the `FACILITY` class. F ACF2,REBUILD(FAC) ``` -#### Using TSS +
+ +
+ + +For Top Secret, click here for procedure details. + If you use TSS, verify and update permission in `FACILITY` class. @@ -549,12 +726,18 @@ If you use TSS, verify and update permission in `FACILITY` class. TSS PER(ZWESVUSR) IBMFAC(IRR.RUSERMAP) ACCESS(READ) ``` +
+ ### Configure main Zowe server to use distributed identity mapping This security configuration is necessary for API ML to be able to map the association between a z/OS user ID and a distributed user identity. A user running the API Gateway must have read access to the SAF resource `IRR.IDIDMAP.QUERY` in the `FACILITY` class. To set up this security configuration, submit the `ZWESECUR` JCL member. For users upgrading from version 1.28 and lower, use the following configuration steps. -#### Using RACF +
+ + +For RACF, click here for procedure details. + If you use RACF, verify and update permission in the `FACILITY` class. @@ -582,7 +765,13 @@ If you use RACF, verify and update permission in the `FACILITY` class. SETROPTS RACLIST(FACILITY) REFRESH ``` -#### Using ACF2 +
+ +
+ + +For ACF2, click here for procedure details. + If you use ACF2, verify and update permission in the `FACILITY` class. @@ -604,7 +793,13 @@ If you use ACF2, verify and update permission in the `FACILITY` class. F ACF2,REBUILD(FAC) ``` -#### Using TSS +
+ +
+ + +For Top Secret, click here for procedure details. + If you use TSS, verify and update permission in `FACILITY` class. @@ -620,11 +815,13 @@ If you use TSS, verify and update permission in `FACILITY` class. TSS PER(ZWESVUSR) IBMFAC(IRR.IDIDMAP.QUERY) ACCESS(READ) ``` +
+ ### Configure signed SAF Identity tokens (IDT) This section provides a brief description of how to configure SAF Identity tokens on z/OS so that they can be used by Zowe components like zss or API Mediation layer ([Implement a new SAF IDT provider](../extend/extend-apiml/implement-new-saf-provider.md)) -Follow these general steps: +**Follow these general steps:** 1. Create PKCS#11 token 2. Generate a secret key for the PKCS#11 token (you can use the sample program ZWESECKG in the SZWESAMP dataset) @@ -644,54 +841,103 @@ To set up this security configuration, submit the `ZWESECUR` JCL member. For use To check whether you already have the auditing profile defined, issue the following command and review the output to confirm that the profile exists and that the user `ZWESVUSR` who runs the `ZWESLSTC` started task has READ access to this profile. -- If you use RACF, issue the following command: - ``` - RLIST FACILITY IRR.RAUDITX AUTHUSER - ``` -- If you use Top Secret, issue the following command: - ``` - TSS WHOHAS IBMFAC(IRR.RAUDITX) - ``` -- If you use ACF2, issue the following commands: +
+ + +For RACF, click here for command details. + + +If you use RACF, issue the following command: +``` +RLIST FACILITY IRR.RAUDITX AUTHUSER +``` + +
+ +
+ + +For Top Secret, click here for command details. + + +If you use Top Secret, issue the following command: +``` +TSS WHOHAS IBMFAC(IRR.RAUDITX) +``` + +
+ +
+ + +For ACF2, click here for command details. + + +If you use ACF2, issue the following commands: +``` +SET RESOURCE(FAC) +``` +``` +LIST LIKE(IRR-) +``` +
+ +If the user `ZWESVUSR` who runs the `ZWESLSTC` started task does not have READ access to this profile, follow the procedure that corresponds to your ESM. + +
+ + +For RACF, click here for procedure details. + + +If you use RACF, update permission in the `FACILITY` class. + +**Follow these steps:** + +1. Add user `ZWESVUSR` permission to `READ`. ``` - SET RESOURCE(FAC) + PERMIT IRR.RAUDITX CLASS(FACILITY) ACCESS(READ) ID(ZWESVUSR) ``` +2. Activate changes. ``` - LIST LIKE(IRR-) + SETROPTS RACLIST(FACILITY) REFRESH ``` +
+ +
+ + +For Top Secret, click here for procedure details. + + +If you use Top Secret, add user `ZWESVUSR` permission to READ. Issue the following command: +``` +TSS PER(ZWESVUSR) IBMFAC(IRR.RAUDITX) ACCESS(READ) +``` + +
+ +
+ + +For ACF2, click here for procedure details. + + +If you use ACF2, add user `ZWESVUSR` permission to `READ`. Issue the following commands: +``` +SET RESOURCE(FAC) +``` +``` +RECKEY IRR ADD(RAUDITX ROLE(&STCGRP.) SERVICE(READ) ALLOW) +``` +``` +F ACF2,REBUILD(FAC) +``` + +
-If the user `ZWESVUSR` who runs the `ZWESLSTC` started task does not have READ access to this profile, follow the procedure that corresponds to your ESM: - -- If you use RACF, update permission in the `FACILITY` class. - - **Follow these steps:** - - 1. Add user `ZWESVUSR` permission to `READ`. - ``` - PERMIT IRR.RAUDITX CLASS(FACILITY) ACCESS(READ) ID(ZWESVUSR) - ``` - 2. Activate changes. - ``` - SETROPTS RACLIST(FACILITY) REFRESH - ``` - -- If you use Top Secret, add user `ZWESVUSR` permission to READ. Issue the following command: - ``` - TSS PER(ZWESVUSR) IBMFAC(IRR.RAUDITX) ACCESS(READ) - ``` - -- If you use ACF2, add user `ZWESVUSR` permission to `READ`. Issue the following commands: - ``` - SET RESOURCE(FAC) - ``` - ``` - RECKEY IRR ADD(RAUDITX ROLE(&STCGRP.) SERVICE(READ) ALLOW) - ``` - ``` - F ACF2,REBUILD(FAC) - ``` - For more information about SMF records, see [SMF records](../user-guide/api-mediation/api-mediation-smf.md) in the Using Zowe API Mediation Layer documentation. + ### Multi-Factor Authentication (MFA) Multi-factor authentication is supported for several components, such as the Desktop and API Mediation Layer. diff --git a/docs/user-guide/configure-zowe-runtime.md b/docs/user-guide/configure-zowe-runtime.md index 53efa6b085..f826ee8cb3 100644 --- a/docs/user-guide/configure-zowe-runtime.md +++ b/docs/user-guide/configure-zowe-runtime.md @@ -10,14 +10,14 @@ Use one of the following options to initialize Zowe z/OS runtime: * Initialize Zowe maunually using zwe init command group * Configure Zowe with z/OSMF workflows -## Initialize Zowe maunually using zwe init command group +## Initialize Zowe manually using zwe init command group After your installation of Zowe runtime, you can run the `zwe init` command to perform the following configurations: * Initialize Zowe with copies of data sets provided with Zowe -* Create user IDs and security manager settings -* Provide APF authorize load libraries -* Configure Zowe to use TLS certificates +* Create user IDs and security manager settings (Security Admin) +* Provide APF authorize load libraries (Security Admin) +* Configure Zowe to use TLS certificates (Security Admin) * Configure VSAM files to run the Zowe caching service used for high availability (HA) * Configure the system to launch the Zowe started task diff --git a/docs/user-guide/configuring-security.md b/docs/user-guide/configuring-security.md index 221504a5c2..e23b8d4d9f 100644 --- a/docs/user-guide/configuring-security.md +++ b/docs/user-guide/configuring-security.md @@ -7,16 +7,91 @@ During the initial installation of Zowe server-side components, it is necessary ## Validate and re-run `zwe init` commands -During installation, the system programmer customizes values in the zowe.yaml file. However, due to insufficient permissions of the system programmer, the `zwe init security` command may fail. Consult with your security administrator to review your `ZWESECUR` job content so that your security adminstrator can re-submit this JCL. +During installation, the system programmer customizes values in the zowe.yaml file. However, due to insufficient permissions of the system programmer, the `zwe init security` command may fail without sufficient user authorization. ## Initialize Zowe security configurations +This security configuration step is required for first time setup of Zowe and may require security autorization. If Zowe has already been launched on a z/OS system from a previous release of Zowe v2, and the `zwe init security` subcommand successfully ran when initializing the z/OS subsystem, you can skip this step unless told otherwise in the release documentation. + Choose from the following methods to initialize Zowe security configurations: -* Configuring with `zwe init security` -* Configuring with `ZWESECUR` JCL +
+Click here to configure with the `zwe init security` command. + +**Configure with `zwe init security` command** + +The `zwe init security` command reads data from `zowe.yaml` and constructs a JCL member using `ZWESECUR` as a template which is then submitted. This is a convenience step to assist with driving Zowe configuration through a pipeline or when you prefer to use USS commands rather than directly edit and customize JCL members. + +:::note +If you do not have permissions to update your security configurations, use the `security-dry-run` described in the following tip. We recommend you inform your security administrator to review the `ZWESECUR` job content. +::: + +:::tip + +To avoid having to run the `init security` command, you can specify the parameter `--security-dry-run`. This parameter enables you to construct a JCL member containing the security commmands without running the member. This is useful for previewing commands and can also be used to copy and paste commands into a TSO command prompt for step by step manual execution. + +**Example:** + +``` +#>zwe init security -c ./zowe.yaml --security-dry-run +------------------------------------------------------------------------------- +>> Run Zowe security configurations + +Modify ZWESECUR +- IBMUSER.ZWEV2.CUST.JCLLIB(ZW134428) is prepared + +Dry-run mode, security setup is NOT performed on the system. +Please submit IBMUSER.ZWEV2.CUST.JCLLIB(ZW134428) manually. +>> Zowe security configurations are applied successfully. + +#> +``` +::: + +
+ + + +
+Click here to configure with `ZWESECUR` JCL. + + +**Configure with `ZWESECUR` JCL** + +An alternative to using `zwe init security` is to prepare a JCL member to configure the z/OS system, and edit `ZWESECUR` to make changes. + +The JCL allows you to vary which security manager you use by setting the _PRODUCT_ variable to be one of the following ESMs: +* `RACF` +* `ACF2` +* `TSS`. + +**Example:** +``` +// SET PRODUCT=RACF * RACF, ACF2, or TSS +``` + +If `ZWESECUR` encounters an error or a step that has already been performed, it continues to the end, so it can be run repeatedly in a scenario such as a pipeline automating the configuration of a z/OS environment for Zowe installation. + +:::info Important +It is expected that your security administrator will be required to review, edit where necessary, and either execute `ZWESECUR` as a single job, or execute individual TSO commands to complete the security configuration of a z/OS system in preparation for installing and running Zowe. +::: + +The following video shows how to locate the `ZWESECUR` JCL member and execute it. + + + +
+ + + +### Undo security configurations + +To undo all of the z/OS security configuration steps performed by the JCL member `ZWESECUR`, use the reverse member `ZWENOSEC`. This member contains steps that reverse steps performed by `ZWESECUR`. This is useful in the following situations: + +- You are configuring z/OS systems as part of a build pipeline that you want to undo, and redo configuration and installation of Zowe using automation. +- You configured a z/OS system for Zowe that you no longer want to use, and you prefer to delete the Zowe user IDs and undo the security configuration settings rather than leave them enabled. -For more information about both of these methods, see [Initialize Zowe security configurations](./initialize-security-configuration.md). +If you run `ZWENOSEC` on a z/OS system, it is necessary to rerun `ZWESECUR` to reinitialize the z/OS security configuration. Zowe cannot be run until `ZWESECUR` is rerun. ## Perform APF authorization of load libraries diff --git a/docs/user-guide/initialize-security-configuration.md b/docs/user-guide/initialize-security-configuration.md index 965b2590a4..f55102ebdd 100644 --- a/docs/user-guide/initialize-security-configuration.md +++ b/docs/user-guide/initialize-security-configuration.md @@ -1,5 +1,8 @@ # Initializing Zowe security configurations + + + This security configuration step is required for first time setup of Zowe. If Zowe has already been launched on a z/OS system from a previous release of Zowe v2, and the `zwe init security` subcommand successfully ran when initializing the z/OS subsystem, you can skip this step unless told otherwise in the release documentation. :::info Required roles: system programmer, security administrator diff --git a/docs/user-guide/initialize-zos-system.md b/docs/user-guide/initialize-zos-system.md index 349f87b80c..c96f599fe9 100644 --- a/docs/user-guide/initialize-zos-system.md +++ b/docs/user-guide/initialize-zos-system.md @@ -24,6 +24,9 @@ Configures the VSAM files needed if the Caching service is set to VSAM mode. Thi :::info Recommendation: We recommend you to run these sub commands one by one to clearly see the output of each step. To successfully run `zwe init security`, `zwe init apfauth`, and `zwe init certificate`, it is likely that your organization requires elevated permissions. We recommend you consult with your security administrator to run these commands. For more information about tasks for the security administrator, see the section [Configuring security](./configuring-security.md) in this configuration documentation. + + +For information about the `zwe init security` command, see [configuring with `zwe init security` command](./initialize-security-configuration.md#configuring-with-zwe-init-security-command). ::: :::tip diff --git a/docs/user-guide/systemrequirements-zos.md b/docs/user-guide/systemrequirements-zos.md index acfd4521fa..58930418a5 100644 --- a/docs/user-guide/systemrequirements-zos.md +++ b/docs/user-guide/systemrequirements-zos.md @@ -107,3 +107,7 @@ Zowe consumption reference data were measured with the default Zowe configuratio - For production use of Zowe, we recommend configuring z/OSMF to leverage Zowe functionalities that require z/OSMF. For more information, see [Configuring z/OSMF](systemrequirements-zosmf.md). - For non-production use of Zowe (such as development, proof-of-concept, demo), you can customize the configuration of z/OSMF to create **_z/OS MF Lite_** to simplify your setup of z/OSMF. z/OS MF Lite only supports selected REST services (JES, DataSet/File, TSO and Workflow), resulting in considerable improvements in startup time as well as a reduction in steps to set up z/OSMF. For information about how to set up z/OSMF Lite, see [Configuring z/OSMF Lite (non-production environment)](systemrequirements-zosmf-lite.md). ::: + +:::note +For specific z/OS security configuration options that apply to the specific Zowe server-side components in your configuration, see [Security customization of your z/OS system](./configure-zos-system.md). +::: diff --git a/docs/user-guide/zwe-init-subcommand-overview.md b/docs/user-guide/zwe-init-subcommand-overview.md index fa21b906c8..b5ee1db520 100644 --- a/docs/user-guide/zwe-init-subcommand-overview.md +++ b/docs/user-guide/zwe-init-subcommand-overview.md @@ -6,11 +6,15 @@ Review this article to learn about the individual subcommands executed in `zwe i Some of the following `zwe init` subcommands require elevated permissions. See the required roles associated with each of these commands. ::: -* [Initializing Zowe custom data sets (`zwe init mvs`)](#initializing-zowe-custom-data-sets-zwe-init-mvs) -* [Initializing Zowe security configurations (`zwe init security`)](#initializing-zowe-security-configurations-zwe-init-security) -* [Performing APF authorization of load libraries (`zwe init apfauth`)](#performing-apf-authorization-of-load-libraries-zwe-init-apfauth) -* [Configuring Zowe to use TLS certificates (`zwe init certificate`)](#configuring-zowe-to-use-tls-certificates-zwe-init-certificate) -* [Installing Zowe main started tasks (`zwe init stc`)](#installing-zowe-main-started-tasks-zwe-init-stc) +- [zwe init subcommand overview](#zwe-init-subcommand-overview) + - [Initializing Zowe custom data sets (`zwe init mvs`)](#initializing-zowe-custom-data-sets-zwe-init-mvs) + - [Procedure to initialize Zowe custom data sets](#procedure-to-initialize-zowe-custom-data-sets) + - [Initializing Zowe security configurations (`zwe init security`)](#initializing-zowe-security-configurations-zwe-init-security) + - [Performing APF authorization of load libraries (`zwe init apfauth`)](#performing-apf-authorization-of-load-libraries-zwe-init-apfauth) + - [Configuring Zowe to use TLS certificates (`zwe init certificate`)](#configuring-zowe-to-use-tls-certificates-zwe-init-certificate) + - [Installing Zowe main started tasks (`zwe init stc`)](#installing-zowe-main-started-tasks-zwe-init-stc) + - [(Deprecated) Creating VSAM caching service datasets (`zwe init vsam`)](#deprecated-creating-vsam-caching-service-datasets-zwe-init-vsam) + - [Next steps](#next-steps) ## Initializing Zowe custom data sets (`zwe init mvs`) @@ -108,7 +112,31 @@ If Zowe has already been launched on a z/OS system from a previous release of Zo The JCL member `.SZWESAMP(ZWESECUR)` is provided to assist with the security configuration. Before submitting the `ZWESECUR` JCL member, customize this member to match site security rules. For script driven scenarios, you can run the command `zwe init security` which uses `ZWESECUR` as a template to create a customized member in `.CUST.JCLLIB`. This member contains the commands required to perform the security configuration. -For more information about `zwe init security`, see [Initializing Zowe security configurations](./initialize-security-configuration). +For more information about `zwe init security`, see [Configuring with `zwe init security` command](./configuring-security.md#configuring-with-zwe-init-security-command). + +:::tip + +To avoid having to run the `init security` command, you can specify the parameter `--security-dry-run`. This parameter enables you to construct a JCL member containing the security commmands without running the member. This is useful for previewing commands and can also be used to copy and paste commands into a TSO command prompt for step by step manual execution. + +**Example:** + +``` +#>zwe init security -c ./zowe.yaml --security-dry-run +------------------------------------------------------------------------------- +>> Run Zowe security configurations + +Modify ZWESECUR +- IBMUSER.ZWEV2.CUST.JCLLIB(ZW134428) is prepared + +Dry-run mode, security setup is NOT performed on the system. +Please submit IBMUSER.ZWEV2.CUST.JCLLIB(ZW134428) manually. +>> Zowe security configurations are applied successfully. + +#> +``` +For production environments, inform your security administrator to re-submit the `init security` command with proper authorization. + +::: ## Performing APF authorization of load libraries (`zwe init apfauth`)