vania-janet/multiturn-rag-retrieval-data huggingface dataset:
4. Specify The time a user will be locked out after trying to sign in with wrong credentials. The time is specified in minutes. You can use any whole value in range 1 - 1440 (24 hours).
5. Toggle The number of times a user can try to sign in before getting locked out row to Enabled.
6. Click Save.



You can unlock a user before the lockout period is over. To see whether they are locked out, check whether the active field is set to false. You can also check to see whether their status on the Users tab of the service dashboard is set to disabled. To unlock a user, you must use [the API](https://us-south.appid.cloud.ibm.com/swagger-ui//Cloud_Directory_Users/updateCloudDirectoryUser) to set the active field to true.





 Policy: Minimum period between password changes 

You might want to prevent your users from quickly switching passwords by setting a minimum time that a user must wait between password changes.

This feature is especially useful when used with the Avoid password reuse policy. Without this limitation, a user might simply change their password multiple times in quick succession to circumvent the limitation of reusing recent passwords.

To set this configuration by using the GUI:



1. Go to the Cloud Directory > Password policies tab of the App ID dashboard.
2. Toggle Advanced password policy to Enabled.
3. Specify The minimum time between password changes. The time is specified in hours. You can use any whole value in range 1 - 720 (30 days).
4. Toggle The minimum time between password changes to Enabled.
5. Click Save.







 Policy: Password expiration 

For security reasons, you might want to enforce a password rotation policy. By setting an expiration for your users password, they are forced to update their password to retain access to your application. This lessens the chance that a user's credentials can cause long term damage to your application. When their password expires, your users are forced to reset it on their next sign-in attempt.
Before you call the /change_password API to allow a user to reset their password, it is highly recommended to check whether the context has a successful result by using the /forgot_password/confirmation_result endpoint. This operation adds a higher level of security to your back-end reset password process and ensures that a user can modify their password only if the context is still valid.

To update a user's password after a reset request, supply the following data in the request body:



* Your tenantID.
* The user's new password.
* The Cloud Directory user UUID.
* Optional: The IP address from which the password reset was performed. If you choose to pass the IP address, then the placeholder %{passwordChangeInfo.ipAddress} is available for the change password email template.



Depending on your configuration, when a password is changed App ID sends an email to the user that lets them know that a change was made.

To allow users to change their password while they are signed in to your app, supply the following data in the request body:



* Your tenantID.
* The user's new password.
* The Cloud Directory user UUID.



Your change password page must prompt the user to enter their current password and their new password.

Your back-end validates the user's current password with the ROP API, and if valid, calls the endpoint with the new password. Depending on your configuration, when a password is changed App ID might send an email to the user letting them know that there was a change.





 Resend 

You can use the /resend/<templateName> to resend an email when a user does not receive it for some reason.

Supply the following data in the request body:



* The tenantID.
* The template name
* The Cloud Directory user UUID.







 Change details 

When a user is signed in to your app, they can update some of their information. You can use the /Users/<userID> to get and update their information.
--json, -j --json, -j Results as JSON.
--certroot, -c --certroot value, -c value Certificate Root. (default: "< >") [$CERTROOT]
--api-version, -v --api-version value, -v value API Version used for request.

Before running the command to update user passwords, ensure that you have updated the admin password. For more information, see [Setting the Admin Password](https://cloud.ibm.com/docs/databases-for-elasticsearch?topic=databases-for-elasticsearch-admin-password&interface=cli). Then, run the following command:

ibmcloud cloud-databases es user-list <formation_name> <admin_password>

If this command is run without the --json option, the plug-in user-list also prints the reset password commands for all users.

The user-list command output looks like:

ibmcloud cloud-databases es user-list es-akshay-res-717-new 12345678987654321
Getting user list for es-akshay-res-717-new...
8 user accounts are present in the Elasticsearch credential store:
Username Fullname Email
fred Fred Name fred@example.com
admin admin Name admin@example.com
ibmkibana ibmkibana Name ibmkibana@example.com
ibm_cloud_d68c8129_fea9_4e83_abc8_4a6c514248ac
ibm_cloud_2a526d0b_e101_49f3_bd13_7c065870a7b1
ibm_cloud_7052ee45_d702_4073_aea2_a5435989568e
ibm_cloud_29075661_76d0_405a_9619_480eb7a173d4
You must enter an SAP HANA main password and an SAP main password.

The SAP HANA main password must consist of at least one digit (0-9), one lowercase letter (a-z), and one uppercase letter (A-Z). It can contain only the following characters: a-z, A-Z, 0-9, !, @, #, $, _. It must not start with a digit or an underscore ( _ ).

The SAP main password must be 10 - 14 characters long and contain at least one digit (0-9). It can only contain the following characters: a-z, A-Z, 0-9, @, #, $, _. This password cannot contain !. It must not start with a digit or an underscore ( _ ).
8. Verify that the plan shows all of the resources that you want to create and that the names and values are correct. If the plan needs to be adjusted, edit the input.auto.tfvars file to correct resources and run terraform plan again.
9. Create the virtual private cloud for SAP instance and IAM access policy in IBM Cloud.

terraform apply

The virtual private cloud and components are created and you see output similar to the terraform plan output.







 Next steps 

If you need to rename your resources after they are created, modify the input.auto.tfvars file to change the names and run terraform plan and terraform apply again. Do not use the IBM Cloud Dashboard and user interface to modify your VPC after it is created. The Terraform scripts create a complete solution and selectively modifying resources with the user interface might cause unexpected results.

If you need to remove your VPC, go to your project folder and run terraform destroy.





 Related information 

For more information about Terraform on IBM Cloud, see [Terraform on IBM Cloud getting started tutorial](https://cloud.ibm.com/docs/ibm-cloud-provider-for-terraform?topic=ibm-cloud-provider-for-terraform-getting-started).
A smart card or hardware token designed and operated to FIPS 140-2 level 2 or above or equivalent (e.g., ANSI X9.24, ISO 13491-1:2007) is recommended.
* Locking user accounts after three (3) consecutive failed logon attempts within 15 minutes.
* Locking user accounts for 30 minutes when there have been more than three unsuccessful logon attempts. After the lockout period ends, the user will be able to reset their password. Internal privileged accounts must remain locked until released by an administrator.
* Session timeout after 15 minutes of inactivity.
* Providing a system use notification banner from either the bastion or the target system. The warning banner is displayed before the system grants access to the user and the usage conditions must be approved before proceeding. The banner will provide privacy and security notices consistent with applicable customer policies, regulations, standards, and guidance. The warning banner will state that:



* Users are accessing a financial services information system.
* Information system usage may be monitored, recorded, and subject to audit.
* Unauthorized use of the information system is prohibited and subject to criminal and civil penalties.
* Use of the information system indicates consent to monitoring and recording.







 Access to Red Hat OpenShift on IBM Cloud management APIs 

Red Hat OpenShift on IBM Cloud management tasks can be completed by using oc CLI tool and kubectl. If your bastion solution provides direct support for kubectl or oc sessions, it is recommended to configure such capabilities for the Red Hat OpenShift on IBM Cloud clusters that are deployed to your Satellite locations. Otherwise, you should consider setting up hosts in your management plane that can provide shell access with oc or kubectl CLI tools to complete Red Hat OpenShift on IBM Cloud management. Operators should access those hosts through SSH connecting through a bastion.





 Access to Red Hat OpenShift on IBM Cloud management UI 

Red Hat OpenShift on IBM Cloud cluster that is deployed on a Satellite location provides a management UI (web console). You should consider UI access as an exception, preferring the operator actions should CLI or CI/CD automation for effective access control, reliability, and audit.
[MAS-MS-Password-Change-2](https://cloud.ibm.com/docs-content/v1/content/bd177462727ef0a849ddcf8c842a6203b41f0625/mas-ms/images/MAS-MS-Password-Change-2.png)

Figure 2. MAS Login Screen
3. A confirmation code will be sent to your e-mail address. Enter the code contained in your email and click Continue

Zoom

![MAS-MS-Password-Change-3](https://cloud.ibm.com/docs-content/v1/content/bd177462727ef0a849ddcf8c842a6203b41f0625/mas-ms/images/MAS-MS-Password-Change-3.png)

Figure 3. MAS Login Code Confirmation
4. The email with the confirmation code will look similar to below.

Zoom

![MAS-MS-Password-Change-4](https://cloud.ibm.com/docs-content/v1/content/bd177462727ef0a849ddcf8c842a6203b41f0625/mas-ms/images/MAS-MS-Password-Change-4.png)

Figure 4. MAS Login Code Email
5. After the code is enter in the above screen with the code you received over an email, you will see below screen asking for the password. You will receive the temporary password (again via email).

Zoom

![MAS-MS-Password-Change-5](https://cloud.ibm.com/docs-content/v1/content/bd177462727ef0a849ddcf8c842a6203b41f0625/mas-ms/images/MAS-MS-Password-Change-5.png)

Figure 5. MAS Login Temp Password
6. Email with the temporary password will look similar to below.
If the Key Protect or HPCS instance has a context-based restriction (CBR) rule, a Direct Link Service Reference must be added to the network zone of that rule. For instructions, see [How Direct Link integrates with context-based restrictions](https://cloud.ibm.com/docs/dl?topic=dl-cbr&interface=clicbr-overview).







 Creating base64-encoded encryption keys 

This section describes how to base64 encode your key value for proper key creation. The following examples show you how to use utilities that are readily available on your operating system to receive the encoded key string.

There are many tools you can use to base64 encode your key material. For example, to use OpenSSL to create and encode new or existing key material, see [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-import-standard-keysencode-key-material-standard-key) or [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-import-standard-keyshow-to-encode-standard-key-material) documentation.



 Windows users 

You can use Powershell to base64-encode your key material.



 Key string input 

To encode a raw key string, first convert the string into bytes using UTF-8 encoding. Then, convert the bytes into a base64-encoded string:

$KEY_VALUE = "abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789"
$ENCODED_KEY = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($KEY_VALUE))

To verify that the value was encoded properly, print the $ENCODED_KEY variable to the console:

Write-Output $ENCODED_KEY
The value must match regular expression /^(?:[A-Za-z0-9_\-]{4})(?:[A-Za-z0-9_\-]{2}==|[A-Za-z0-9_\-]{3}=)?$/.

--lets-encrypt-environment (string)
: The configuration of the Let's Encrypt CA environment.

Allowable values are: production, staging.

--lets-encrypt-private-key (string)
: The PEM-encoded private key of your Let's Encrypt account.

The maximum length is 100000 characters. The minimum length is 50 characters. The value must match regular expression /(^-----BEGIN PRIVATE KEY-----.?)|(^-----BEGIN RSA PRIVATE KEY-----.?)/.

--lets-encrypt-preferred-chain (string)
: The preferred chain with an issuer that matches this Subject Common Name.

The maximum length is 30 characters. The minimum length is 2 characters. The value must match regular expression /(.?)/.

--cloud-internet-services-apikey (string)
: An IBM Cloud API key that can to list domains in your Cloud Internet Services instance.

To grant Secrets Manager the ability to view the Cloud Internet Services instance and all of its domains, the API key must be assigned the Reader service role on Internet Services (internet-svcs).

If you need to manage specific domains, you can assign the Manager role. For production environments, it is recommended that you assign the Reader access role, and then use the [IAM Policy Management API](https://cloud.ibm.com/apidocs/iam-policy-managementcreate-policy) to control specific domains. For more information, see the [docs](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-prepare-order-certificatesauthorize-specific-domains).

The maximum length is 128 characters.
* If you leave this setting blank, the default strongSwan algorithms aes128-sha1-modp2048,3des-sha1-modp1536 are used for the connection.



4. Change the value of local.id to any string that you want to use to identify the local Kubernetes cluster side that your VPN tunnel endpoint uses. The default is ibm-cloud. Some VPN implementations require that you use the public IP address for the local endpoint.
5. Change the value of remote.id to any string that you want to use to identify the remote on-premises side that your VPN tunnel endpoint uses. The default is on-prem. Some VPN implementations require that you use the public IP address for the remote endpoint.
6. Change the value of preshared.secret to the pre-shared secret that your on-premises VPN tunnel endpoint gateway uses for the connection. This value is stored in ipsec.secrets.
7. Optional: Set remote.privateIPtoPing to any private IP address in the remote subnet to ping as part of the Helm connectivity validation test.







 Step 3: Select inbound or outbound VPN connection 

When you configure a strongSwan VPN connection, you choose whether the VPN connection is inbound to the cluster or outbound from the cluster.

Inbound
: The on-premises VPN endpoint from the remote network initiates the VPN connection, and the cluster listens for the connection.

Outbound
: The cluster initiates the VPN connection, and the on-premises VPN endpoint from the remote network listens for the connection.

To establish an inbound VPN connection, modify the following settings.



1. Verify that ipsec.auto is set to add.
2. Optional: Set loadBalancerIP to a portable public IP address for the strongSwan VPN service. Specifying an IP address is useful when you need a stable IP address, such as when you must designate which IP addresses are permitted through an on-premises firewall. The cluster must have at least one available public load balancer IP address.
SSH keys 

Secure Socket Shell (SSH) is a network protocol that enables a user or client computer to connect, through a secure channel, to a remote computer over the internet and have access to issue commands on the remote computer.

SSH keys are the public-key credentials that are used by the SSH protocol for authentication and encryption.

For more information about SSH keys, see [Getting started with SSH keys](https://cloud.ibm.com/docs/ssh-keys?topic=ssh-keys-getting-started-tutorial).
Connecting an IBM policy-based VPN to a strongSwan peer 

Use the following configuration:



1. Choose IKEv2 in authentication.
2. Enable DH-group 2 in the Phase 1 proposal.
3. Set lifetime = 36000 in the Phase 1 proposal.
4. Disable PFS in the Phase 2 proposal.
5. Set lifetime = 10800 in the Phase 2 proposal.
6. Input your peers and subnets information in the Phase 2 proposal. In the following example, a connection is defined between the on-premises subnet 10.160.26.64/26 whose strongSwan VPN gateway has the IP address 169.45.74.119 and the VPC subnet 192.168.17.0/28 whose VPN for VPC gateway has the IP address 169.61.181.116.

vim /etc/ipsec.abc.conf
conn all
type=tunnel
auto=start
aggressive=no
esp=aes256-sha256!
ike=aes256-sha256-modp2048!
left=%any
leftsubnet=10.160.26.64/26
rightsubnet=192.168.17.0/28
right=169.61.181.116
leftauth=psk
rightauth=psk
leftid="169.45.74.119"
keyexchange=ikev2
rightid="169.61.181.116"
lifetime=10800s
ikelifetime=36000s
dpddelay=30s
dpdaction=restart
dpdtimeout=120s
Show more
7. Set the preshared key in /etc/ipsec.secrets:

vim ipsec.secrets
 This file holds shared secrets or RSA private keys for authentication.

169.45.74.119 169.61.181.116 : PSK ""
8. After the configuration file finishes running, restart the strongSwan VPN.

ipsec restart
IBM MQ client applications have two different methods of supplying credentials to a queue manager that is controlled by a switch called compatibility mode. You must ensure that when the application is connecting it is has compatibility mode disabled, otherwise only the first 8 characters of the password (long API key) is transmitted to the queue manager, and so the authentication check fails.

Client applications connecting using IBM MQ client libraries below version 8.0.0.0 are unable to supply long user credentials to the queue manager using this newer method and so will be unable to connect.





 First Solution 

When connecting using MQ Explorer you must uncheck the option for User identification compatibility mode that is found in in the User Identification details page of the connection wizard.

Java or JMS applications can disable the compatibility mode flag as follows:



1. Ensure that the IBM MQ client libraries being used are version 8.0.0.0 or above
2. Ensure that the client application is supplying valid user credentials in the MQCSP structure. For more information on the MQCSP structure see [the Knowledge Center here](https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.1.0/com.ibm.mq.ref.dev.doc/q095620_.htm)
3. Disable compatibility mode as described in [this Knowledge Center page](https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.1.0/com.ibm.mq.sec.doc/q118680_.htm) - for example by setting JmsConstants.USER_AUTHENTICATION_MQCSP = true or via the equivalent ConnectionFactory setting



Other products that connect to IBM MQ typically provide a mechanism for configuring this setting using their own administrative interfaces;



* IBM AppConnect Enterprise disables compatibility mode by default and so there are no problems connecting to queue managers in the MQ on Cloud service as [described in this blog post](https://developer.ibm.com/integration/blog/2018/09/28/support-ibm-mq-cloud-ibm-app-connect/)
Warning: Permanently added 'xxx.xxx.xxx.xxx' (ECDSA) to the list of known hosts.
2. Use the tsocmd command to configure password phrases for the z/OS instance. Replace YOUR PASSWORD PHRASE with your own password phrase.

tsocmd "ALTUSER IBMUSER PHRASE('YOUR PASSWORD PHRASE') NOEXPIRE RESUME"

You must follow the password policies to enforce more secure connection:



* Must be 8 characters.
* Valid values for passwords include numerals, capital letters, lowercase letters, and special characters (.,<,+,|,%,!,,-,%,>,?,:,=).
* The minimum period between password changes is 0 day.
* The password expiration time is 30 days. For this release, you do not receive any password expiration warning messages.
* The z/OS virtual server instance retains the last five passwords for each user and prevents these passwords from being reused.
* Inactive user IDs are not automatically revoked.



For more information about the commands, see [tsocmd - Run a TSO/E command from the shell (including authorized commands)](https://www.ibm.com/docs/en/zos/2.5.0?topic=scd-tsocmd-run-tsoe-command-from-shell-including-authorized-commands) and [ALTUSER (Alter user profile)](https://www.ibm.com/docs/en/zos/2.5.0?topic=syntax-altuser-alter-user-profile).







 Step 2. Getting connected 

You can interact with your z/OS virtual server instance with the following approaches.



 Using TN3270 terminal emulator 

You can use the TN3270 terminal emulator to log on to the Time Sharing Option/Extensions (TSO/E). The default port for the secured TN3270 is 992 and you need to provide a self-signed certificate-authority (CA) certificate as a parameter to have a secured connection to the 3270 emulation program.
ibm_cloud_d68c8129_fea9_4e83_abc8_4a6c514248ac
ibm_cloud_2a526d0b_e101_49f3_bd13_7c065870a7b1
ibm_cloud_7052ee45_d702_4073_aea2_a5435989568e
ibm_cloud_29075661_76d0_405a_9619_480eb7a173d4
ibm_cloud_eb148643_099a_4334_a88a_f2e5e1f8ccdd

You can use these commands to set new passwords for them:
ibmcloud cdb deployment-user-password "es-akshay-res-717-new" fred

ibmcloud cdb deployment-user-password "es-akshay-res-717-new" admin

ibmcloud cdb deployment-user-password "es-akshay-res-717-new" ibmkibana

ibmcloud cdb deployment-user-password "es-akshay-res-717-new" ibm_cloud_d68c8129_fea9_4e83_abc8_4a6c514248ac

ibmcloud cdb deployment-user-password "es-akshay-res-717-new" ibm_cloud_2a526d0b_e101_49f3_bd13_7c065870a7b1

ibmcloud cdb deployment-user-password "es-akshay-res-717-new" ibm_cloud_7052ee45_d702_4073_aea2_a5435989568e

ibmcloud cdb deployment-user-password "es-akshay-res-717-new" ibm_cloud_29075661_76d0_405a_9619_480eb7a173d4
The value must match regular expression /^-?(created_at|updated_at|name)$/.

--search (string)
: Filter locks that contain the specified string in the field "name".

The maximum length is 128 characters. The minimum length is 2 characters. The value must match regular expression /(.?)/.

--all-pages (bool)
: Invoke multiple requests to display all pages of the collection for secret-locks.





 Example 

ibmcloud secrets-manager secret-locks --id=0b5571f7-21e6-42b7-91c5-3f5ac9793a46 --offset=0 --limit=10 --sort=name --search=example





 Example output 

Example of response body for listing secret locks

{
"first" : {
"href" : "https://us-south.secrets-maanger.cloud.ibm.com/88b75b20-aa21-4174-85c9-1feb3cc93c9a/api/v2/secrets/0cf4addb-7a90-410b-a3a7-a15bbe2b7909/locks?limit=50"
},
"previous" : {
"href" : "https://us-south.secrets-maanger.cloud.ibm.com/88b75b20-aa21-4174-85c9-1feb3cc93c9a/api/v2/secrets/0cf4addb-7a90-410b-a3a7-a15bbe2b7909/locks?offset=50&limit=50"
},
"limit" : 50,
"last" : {
create a random, base64-encoded, 32-byte data encryption key (DEK)
$ PLAINTEXT=$(openssl rand -base64 32)

$ echo $PLAINTEXT

tEqoiCu9CeUsbqRe6yBUkrJg80QKKG/z46OkX0YQMV8=

 wrap the plaintext key with the root key, creating a DEK (this is the ciphertext)
$ CIPHERTEXT=$(ibmcloud kp key wrap $KEY_ID -p $PLAINTEXT --output json | jq -r '.["Ciphertext"]')

$ echo $CIPHERTEXT

eyJjaXBoZXJ0ZXh0IjoiTkdQRlhCb1dT ...<redacted>... M2ExNjdiNTA3In0=

 unwrap the ciphertext and reveal the original DEK
$ ibmcloud kp key unwrap $KEY_ID $CIPHERTEXT

tEqoiCu9CeUsbqRe6yBUkrJg80QKKG/z46OkX0YQMV8=





 Example 3 

Wrap a root key and provide AAD information.

One use case for supplying additional authentication data (AAD) is to "password protect" and add a "verification phrase" to the ciphertext, which makes it more difficult to unwrap.

The ciphertext and the AAD is required to unwrap the ciphertext and reveal the plaintext DEK.

 create a root key
$ KEY_ID=$(ibmcloud kp key create my-root-key --output json | jq -r '.["id"]')

$ echo $KEY_ID

5f2cc155-fe16-492c-845c-4d1f0688c7ba

 set the additional authentication data (AAD)
$ AAD1=My-Secret-Password
$ AAD2=My-Verification-Phrase

 wrap the plaintext DEK with the root key and AAD