vania-janet/multiturn-rag-retrieval-data huggingface dataset:
If they try to set their password to one that was recently used, an error is shown in the default Login Widget GUI and the user is prompted to enter another option. This setting allows for you to choose the number of passwords that a user must have before they're able to repeat a previously used password.

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 number of times that a password can't be repeated. You can use any whole value in range 1 - 8.
4. Toggle The number of times that a password can't be repeated to Enabled.
5. Click Save.



Previous passwords are securely stored in the same way that a user's current password is stored.





 Policy: Lockout after repeated wrong credentials 

You might want to protect your users' accounts by temporarily blocking the ability to sign in when a suspicious behavior is detected, such as multiple consecutive sign-in attempts with an incorrect password. This measure can help to prevent a malicious party from gaining access to a user's account by guessing their password.

If an account is locked, users are unable to sign in or complete any other self-service operations until the specified lockout period is complete. When the lockout period is over, the user is automatically unlocked.

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 number of times a user can try to sign in before getting locked out. You can use any whole value in range 1 - 10.
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.
The algorithms must be specific in the format encryption-integrity[-prf]-dhgroup.



* If ipsec.keyexchange is set to ikev1, this setting must be specified.
* If ipsec.keyexchange is set to ikev2, this setting is optional.
* 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 Red Hat OpenShift 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.
If provided, domain and password must also be provided. If not provided, the guest account is used.
* password - The Samba password to authenticate with. If the username is provided, this is required. Password must be encrypted using the vcrypt program shipped with the Data Crawler.
* archive - Enables the Samba connector to crawl and index files that are compressed within archive files. Value is either true or false; default value is false.
* max-policies-per-handle - Specifies the maximum number of Local Security Authority (LSA) policies that can be opened for a single RPC handle. These policies define the access permissions that are required to query or modify a particular system under various conditions. The default value for this option is 255.
* crawl-fs-metadata - Turning on this option causes the Data Crawler to add a VXML document containing the available filesystem metadata about the file (creation date, last modified date, file attributes, etc.).
* enable-arc-connector - Unused option.
* disable-indexes - Newline-separated list of indexes to disable, which might result in a faster crawl, for example:



* disable-url-index
* disable-error-state-index
* disable-crawl-time-index



* exact-duplicates-hash-size - Sets the size of the hash table used for resolving exact duplicates. Be very careful when modifying this number. The value that you select must be prime, and larger sizes can provide faster lookups but require more memory, while smaller sizes can slow down crawls but substantially reduce memory usage.
* user-agent - Unused option.
* timeout - Unused option
* n-concurrent-requests - The number of requests that are sent in parallel to a single IP address. The default is 1.
* enqueue-persistence - Unused option.







 Configuring the Samba Crawl Seed 

The following values can be configured for the Samba crawl seed file. To set these values, open the file config/seeds/samba-seed.conf and specify the following values specific to your use cases:
eyJjaXBoZXJ0ZXh0IjoiKzhjbHVqcUNP ...<redacted>... NmY3MTJjNGViIn0=

 capture the ciphertext
$ CIPHERTEXT=eyJjaXBoZXJ0ZXh0IjoiKzhjbHVqcUNP ...<redacted>... NmY3MTJjNGViIn0=

 unwrap the ciphertext to reveal the plaintext data encryption key (DEK)
$ ibmcloud kp key unwrap 807eb0a6-cc10-4bfe-8331-41a6f712c4ea $CIPHERTEXT

Unwrapping key...
OK
Plaintext Rewrapped Plaintext
mXW4GmBhkRG1+Dzkx1D6dMX99a4KyYwtwbghaaLEQZ0=





 Example 2 

Unwrap a ciphertext and provide AAD information.

One use case for supplying additional authentication data (AAD) is to "password protect" the ciphertext to make it more difficult to unwrap.

The ciphertext and the AAD is required to unwrap the ciphertext and reveal the plaintext data encryption key (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

 create a random, base64-encoded, 32-byte data encryption key (DEK)
$ PLAINTEXT=$(openssl rand -base64 32)

$ echo $PLAINTEXT

H4ZfQe66aKcxirfCdNZ/3Na0JECP6HsAM3yclKmIfPQ=

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



 Set commands 

set system login user pokeyjo uid 2000

set system login user pokeyjo class super-user

set system login user pokeyjo authentication encrypted-password
"removed for security"

set system root-authentication encrypted-password
"removed for security"

set system services ssh

set system services web-management http interface fxp0.0

set system services web-management http interface ge-0/0/0.0

set system syslog user * any emergency

set system syslog file messages any any

set system syslog file messages authorization info

set system syslog file interactive-commands interactive-commands any

set security screen ids-option untrust-screen icmp ping-death

set security screen ids-option untrust-screen ip source-route-option

set security screen ids-option untrust-screen ip tear-drop

set security screen ids-option untrust-screen tcp syn-flood
alarm-threshold 1024

set security screen ids-option untrust-screen tcp syn-flood
attack-threshold 200

set security screen ids-option untrust-screen tcp syn-flood
source-threshold 1024

set security screen ids-option untrust-screen tcp syn-flood
destination-threshold 2048

set security screen ids-option untrust-screen tcp syn-flood queue-size
2000

set security screen ids-option untrust-screen tcp syn-flood timeout 20

set security screen ids-option untrust-screen tcp land

set security policies from-zone trust to-zone trust policy
default-permit match source-address any

set security policies from-zone trust to-zone trust policy
default-permit match destination-address any

set security policies from-zone trust to-zone trust policy
default-permit match application any

set security policies from-zone trust to-zone trust policy
default-permit then permit

set security policies from-zone trust to-zone untrust policy
default-permit match source-address any
In the response, locate the User accounts and SSH keys fields. The value of “User accounts” is your account name. You need to use the first SSH key to decrypt the password.
3. After you have the SSH key, run the following command to obtain your password:

ibmcloud is bare-metal-server-initialization-values $bare_metal_server_id [--private-key (KEY | @KEY_FILE)]
4. Add either '<content of the private key file>' or @private_key_file_path for the --private-key flag to decode and decrypt your password.



After you retrieve the account name and password, you can use them to access the ESXi DCUI and web client.





 Accessing ESXi DCUI by using a VNC or serial console 

You can access the VMware® ESXi DCUI by connecting to a VNC or serial console.

To connect to a console, you need to be assigned Operator (or greater) and Bare Metal Console Administrator roles for the bare metal server in IBM Cloud Identity and Access Management (IAM). If you are an administrator of your account, you also need to self-assign the Bare Metal Console Administrator role.

ESXi DCUI doesn’t output from a serial console by default. You can enable it by following [Connecting to a serial console](https://cloud.ibm.com/docs/vpc?topic=vpc-connect-to-ESXi-bare-metal-serversconnect-to-serial-console).





 Connecting to a VNC console 

You can use the UI, [CLI](https://cloud.ibm.com/docs/vpc?topic=vpc-connect-to-ESXi-bare-metal-serversconnect-to-vnc-console-cli), or [API](https://cloud.ibm.com/docs/vpc?topic=vpc-connect-to-ESXi-bare-metal-serversconnect-to-vnc-console-api) to connect to a VNC console.



 Connecting to a VNC console by using the UI 



1.
The value must match regular expression /^([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}|current|previous)$/.

--offset (int64)
: The number of locks to skip.

The minimum value is 0.

--limit (int64)
: The number of secrets with locks to list.

The maximum value is 100. The minimum value is 1.

--sort (string)
: Sort a collection of locks by the specified field in ascending order. To sort in descending order use the - character

Available values: created_at | updated_at | name

Usage: To sort a list of locks by their creation date, use ../locks?sort=created_at.

The maximum length is 17 characters. The minimum length is 4 characters. 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-version-locks.





 Example 

ibmcloud secrets-manager secret-version-locks --secret-id=0b5571f7-21e6-42b7-91c5-3f5ac9793a46 --id=eb4cf24d-9cae-424b-945e-159788a5f535 --offset=0 --limit=10 --sort=name --search=example





 Example output 

Example response for listing secret version locks

{
"first" : {
The format for each element in the list is the same as OpenSSL: <oid>:<type>:<value> where the current valid type is UTF8. To allow any value for an OID, use * as its value. Alternatively, specify a single * to allow any other_sans input.

The list items must match regular expression /(.?)/. The maximum length is 100 items. The minimum length is 0 items.

--server-flag (bool)
: This field indicates whether private certificates are flagged for server use.

--client-flag (bool)
: This field indicates whether private certificates are flagged for client use.

--code-signing-flag (bool)
: This field indicates whether private certificates are flagged for code signing use.

--email-protection-flag (bool)
: This field indicates whether private certificates are flagged for email protection use.

--key-type (string)
: The type of private key to generate.

Allowable values are: rsa, ec.

--key-bits (int64)
: The number of bits to use to generate the private key.

Allowable values for RSA keys are: 2048 and 4096. Allowable values for EC keys are: 224, 256, 384, and 521. The default for RSA keys is 2048. The default for EC keys is 256.

--key-usage ([]string)
: The allowed key usage constraint to define for private certificates.

You can find valid values in the [Go x509 package documentation](https://pkg.go.dev/crypto/x509KeyUsage). Omit the KeyUsage part of the value. Values are not case-sensitive. To specify no key usage constraints, set this field to an empty list.

The list items must match regular expression /^[a-zA-Z]+$/. The maximum length is 100 items. The minimum length is 0 items.

--ext-key-usage ([]string)
trap 'rm -r $TMP_DIR' EXIT

PASSWORD_ENC="${TMP_DIR}/password_enc"
MESSAGE_ENC="${TMP_DIR}/message_enc"

 extract encrypted AES key and encrypted message
cut -d. -f 2 "$INPUT_FILE"| base64 -d > "$PASSWORD_ENC"
cut -d. -f 3 "$INPUT_FILE"| base64 -d > "$MESSAGE_ENC"

 decrypt message
openssl pkeyutl -decrypt -inkey "$RSA_PRIV_KEY" -in "$PASSWORD_ENC" aes-256-cbc -d -pbkdf2 -in "$MESSAGE_ENC" -pass stdin
Show more

The decrypt-attestation.sh file can be accessed by mounting the /var/hyperprotect in the docker container. For example,

volumes:
- "/var/hyperprotect/:/var/hyperprotect/:ro"



 The attestation document 

The attestation document is available at /var/hyperprotect/se-checksums.txt, within the Hyper Protect Virtual Servers for VPC instance. The other related files are also located in the same directory.

The following information is available at the /var/hyperprotect/ directory:

/var/hyperprotect
|-- cidata
| |-- meta-data
| |-- user-data
| -- vendor-data
|-- README
|-- se-checksums.txt[.enc]
|-- se-signature.bin
|-- se-commit-id
|-- se-version
-- user-data.decrypted

Checksums are the SHA256 of the message digest and can be calculated by using the following Linux command-line utility:

sha256sum <file>

The following snippet is an example of an attestation document:

1.0.0
The length must be 36 characters. The list items must match the regular expression /^[-0-9a-z]+$/.

--algorithm ([]string)
: Optional. The algorithm of returned keys. Values that can be set are aes, rsa, hmac, and ec.

--state ([]string)
: Optional. The state that returned keys are to be in. The default value is ["pre_activation","active"]. Values that can be set are: pre_activation, active, deactivated, and destroyed.

--limit (int64)
: Optional. The number of keys to retrieve. The maximum value is 1000. The minimum value is 1. The default value is 20.

--offset (int64)
: Optional. The number of keys to skip. The minimum value is 0.

--sort ([]string)
: Optional. The sorting order. The default value is ["-updated_at"]. The list items must match regular expression /^-?[a-z0-9_.\[\],-]+$/.

--label (string)
: Optional. The label of the key. The value must match regular expression /.+/.

--activation-date (string)
: Optional. Return only managed keys whose activation date matches the parameter. The value must match regular expression /[0-9]{4}-[0-9]{2}-[0-9]{2}/.

--activation-date-min (string)
: Optional. Return only managed keys whose activation date is at or after the parameter value. This query parameter cannot be used in conjunction with the activation_date query parameter. The value must match regular expression /[0-9]{4}-[0-9]{2}-[0-9]{2}/.

--activation-date-max (string)
: Optional.
This value applies only for registry secrets. This value is optional.

--format, --fo
: The format of the secret. Valid values are basic_auth, generic, registry, ssh, or tls. This value is optional. The default value is generic.

--from-env-file, -e
: Create a generic secret from a file which contains one or more lines that match the format KEY=VALUE. You must provide the path to the file as a value. Each line from the specified file is added as a key-value pair. Any lines in the specified file that are empty or begin with are ignored. This value is required if --from-literal or --from-file is not specified. This option can be specified multiple times. This value applies only for generic secrets.

--from-file, -f
: Create a generic secret from a file. You must provide the path to the file as a value. This value is required if --from-literal or --from-env-file is not specified. This option can be specified multiple times. This value applies only for generic secrets.

--from-literal, -l
: Create a generic secret from a key-value pair. Must be in KEY=VALUE format. This value is required if --from-file or --from-env-file is not specified. This option can be specified multiple times. This value applies only for generic secrets.

--key-path, --kp
: The path to your unencrypted SSH private key file for an SSH secret. If you use your personal private SSH key, then this file is usually located at $HOME/.ssh/id_rsa (Mac OS or Linux) or at %HOMEPATH%.sshid_rsa (Windows). This value is required for ssh secrets. This value is optional.

--known-hosts-path, --khp
: The path to your known hosts file for an SSH secret.
<password>: The password that you use to connect to your Db2 Warehouse on Cloud database.







 Example 

The following syntax shows sample C# code that uses the .NET driver to make a connection to the database.

using System;
using IBM.Data.DB2;

namespace dotNetSSLTest
{
class Program
{
static void Main(string[] args)
{
DB2Command MyDB2Command = null;
// Use the dsn alias that you defined in db2dsdriver.cfg with the db2cli writecfg command in step 1.
String MyDb2ConnectionString = "database=alias;uid=userid;pwd=password;";
DB2Connection MyDb2Connection = new DB2Connection(MyDb2ConnectionString);
MyDb2Connection.Open();
MyDB2Command = MyDb2Connection.CreateCommand();
MyDB2Command.CommandText = "SELECT branch_code, city from GOSALES.BRANCH";
Console.WriteLine(MyDB2Command.CommandText);

DB2DataReader MyDb2DataReader = null;
MyDb2DataReader = MyDB2Command.ExecuteReader();
Console.WriteLine("BRANCHtCITY");
Console.WriteLine("============================");
while (MyDb2DataReader.Read())
{
for (int i = 0; i <= 1; i++)
{
try
{
if (MyDb2DataReader.IsDBNull(i))
{
Console.Write("NULL");
}
else
{
Console.Write(MyDb2DataReader.GetString(i));
}
}
catch (Exception e)
{
You can enable the sessionauth parameter to encrypt the generated keys into the keystore or to decrypt the key before you use it. The password can be 6 - 8 characters.



Keystore passwords are not stored in the service instance. You, as the keystore administrator, are responsible for maintaining a local copy of the passwords. If a password is lost, you need to contact the Support team to reset the keystore, which means all data in the keystore is cleared.

Both the in-memory keystores and the database-backed keystores are composed of the following types of keystores:



* Public keystore: Stores keys that are less sensitive and that are to be accessed by any user types.
* Private keystore: Stores keys that encrypt sensitive data and that are to be accessed by normal users only.



Depending on the [user types](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-uko-pkcs11-introuko-pkcs11-user-intro) and key attributes settings, the generated keys are stored in different keystores. The following list summarizes the criteria of how keys are stored:



* The CKA_TOKEN attribute value decides whether the generated key is stored in an in-memory keystore or in a database-backed keystore.

If you want to store the key in the database-backed keystore, set CKA_TOKEN to TRUE in key or key pair generation templates. The PKCS #11 library initialization process establishes a gRPC connection with the IBM Cloud, which facilitates the storing and retrieval of key objects to or from the database-backed keystore. By default, CKA_TOKEN is set to FALSE, which means the key object is stored in an in-memory keystore within the process address space of the PKCS #11 application.
* The CKA_PRIVATE attribute value decides whether a key that is generated by normal users is to be stored in a public or private keystore.

By default, if a user is logged in as a normal user, generated keys are stored in the private keystores, except for the case where CKA_PRIVATE is set to FALSE.
The value must match regular expression /^([0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}|current|previous)$/.

--name ([]string)
: Specify the names of the secret locks to be deleted.

The list items must match regular expression /^[a-zA-Z]{1}[a-zA-Z0-9-_.]{1,63}$/. The maximum length is 1000 items. The minimum length is 1 item.





 Example 

ibmcloud secrets-manager secret-version-locks-bulk-delete --secret-id=0b5571f7-21e6-42b7-91c5-3f5ac9793a46 --id=eb4cf24d-9cae-424b-945e-159788a5f535 --name=lock-example-1





 Example output 

Example of response body to create secret locks

{
"secret_id" : "0cf4addb-7a90-410b-a3a7-a15bbe2b7909",
"secret_group_id" : "d8371728-95c8-4c12-b2af-1af98adb9e41",
"versions" : [ {
"version_id" : "7bf3814d-58f8-4df8-9cbd-f6860e4ca973",
"version_alias" : "current",
"locks" : "lock-3", "lock-4" ],
"payload_available" : true
}, {
"version_id" : "5bf89b0c-df55-c8d5-7ad6-8816951c6784",
"version_alias" : "previous",
Authentication Username The username that you use to connect. 
 Authentication Password A password for the user - might be shown as $PASSWORD 
 Authentication Method How authentication takes place; "direct" authentication is handled by the driver. 
 Hosts 0... A hostname and port to connect to. 
 Composed 0... A URI combining Authentication, Host, and Port used to connect. 
 Certificate Name The allocated name for the self-signed certificate for database deployment 
 Certificate Base64 A base64 encoded version of the certificate. 





* 0... indicates that there might be one or more of these entries in an array.







 TLS and self-signed certificate support 

All connections to Messages for RabbitMQ are TLS 1.2 enabled, so the driver or client you use to connect needs to be able to support encryption. Your deployment also comes with a self-signed certificate so the driver can verify the server upon connection.



 Using the self-signed certificate 



1. Copy the certificate information from the Endpoints panel or the Base64 field of the connection information.
2. If needed, decode the Base64 string into text.
3. Save the certificate to a file. (You can use the Name that is provided or your own file name).
4. Provide the path to the certificate to the driver or client.
5. (optional) If your driver or client supports it you can add the certificate its (or your system's) certificate store.







 CLI plug-in support for the self-signed certificate 

You can display the decoded certificate for your deployment with the CLI plug-in with the command ibmcloud cdb deployment-cacert "your-service-name". It decodes the base64 into text. Copy and save the command's output to a file and provide the file's path to the driver or client.