The daily edition.

Scope: Rocket Enterprise Developer 12.0 for Eclipse (UNIX) documentation, bundle enterprisedevelopereclux_ug_120. Everything below is the UNIX behavior described in that manual; I did not blend in other releases or platforms.

What the vault is

The Vault Facility lets certain Enterprise Server components store sensitive data, such as passwords, in a "vault" reached through a configurable vault provider. The manual describes a vault as storage that provides more protection than typical file storage, and notes it might be implemented with encryption, an operating system feature, a network service, specialized hardware, or some other mechanism. In other words, the protection you actually get depends on the provider behind it.

The same page carries a note worth taking literally: Rocket Software strongly recommends that you restrict access to the Vault Facility. The vault is not self-protecting on a shared host. The documented control is ordinary filesystem permissions.

Working with secrets: mfsecretsadmin

The mfsecretsadmin utility is the command line tool for setting up, administering and migrating vault contents. Its documented forms are:

mfsecretsadmin [options] read <secret name> [outpath]
mfsecretsadmin [options] write <secret name> [secret]
mfsecretsadmin [options] list <secret path> [outpath]
mfsecretsadmin [options] migrate <secret path> <to vault> <to secret path>
mfsecretsadmin [options] delete <secret name>

Two behaviors are easy to miss:

• Write with no value deletes. For write, the secret operand is optional, and if it is not specified, the secret name is deleted. A write with the value accidentally omitted is therefore a delete.
• File mode. With -file, a write expects the secret operand to be a path, and a read expects outpath to be set. outpath on read and list is only available with -file.

The documented options are:

• -vault <vault>: the source vault; the default vault is used if not set.
• -config <config>: the full path of the secrets.cfg file; the default config is used if not specified.
• -targetconfig <config>: the secrets.cfg to migrate to; the default is used if not specified.
• -overwrite: the write or migrate action only replaces existing secrets.
• -move: secrets are deleted once successfully migrated to the new vault.
• -loglevel <level>: 1 all messages, 2 warnings and errors only, 3 errors only.

For migrate, the * wildcard on the source path migrates all secrets from that location, and a * for the target path maintains the secrets path. Wildcards * and ? are accepted when listing.

The manual's examples show the naming convention used for SQL compiler directive credentials, for instance:

mfsecretsadmin write Microfocus/ODBCECM/MFV_MySecretName MyUser.MyPassword

Restricting access: the documented procedure

Restricting Access to the Vault Facility says to restrict access to the vault files and to secrets.cfg, which contains the information required to read secrets from the vault, and that modifying filesystem permissions achieves this. The steps are:

1. Create a group (the manual's example name is mfes). Add root, the Enterprise Server administration userid ("ESadminID", specified at product installation or when the casperm.sh script is run), and the userids of anyone who will run commands needing vault access, such as mfsecretsadmin.
2. Change the owner of $COBDIR/etc/secrets and its contents to root and the group to the one just created, for example chown -R root.mfes $COBDIR/etc/secrets.
3. Restrict the permissions to owner and group only, for example chmod -R 770 $COBDIR/etc/secrets.

chown -R root.mfes $COBDIR/etc/secrets
chmod -R 770 $COBDIR/etc/secrets

The manual adds a parenthetical that matters in practice: $COBDIR/etc/secrets is typically a symbolic link to a directory in the persistent configuration area, but by default commands such as chown operate on the target of a symbolic link. Your ownership and mode changes therefore land on the real directory, not on the link itself, which is what you want, but it is worth confirming where the link points before you check the result.

The operational catch: who must be in the group

Once the directory is limited to owner and group, anything that needs to read the vault and is not in that group stops working. The manual's note spells out who that includes:

• All users who start enterprise server regions from the command line.
• Any accounts used to start regions by running casstart (for example, schedulers).
• The MFDS service account, if it is changed.

If you apply the permissions change and later add a scheduler account or switch the MFDS service account, the group membership is part of that change. The manual also points to its "Hardening filesystem permissions" topic for related guidance.

Clean up the install-time SYSAD secret

Default Generated Password for SYSAD explains that installation generates a random password for the system administrator account SYSAD. On UNIX you retrieve it from a terminal that has the COBOL environment set:

mfsecretsadmin read microfocus/temp/admin

Two documented details frame how to treat that value. First, it is not used by the default Security Manager (VSAM ESM) to validate input credentials; its purpose is to let users discover the generated password, and Server Explorer uses the location to pre-populate the ESCWA connection and credentials dialog at region start-up. Second, Rocket Software recommends removing it once the credentials are safely known or changed:

mfsecretsadmin delete microfocus/temp/admin

Takeaway

The vault only protects what your permissions let it protect: put the vault directory under root and a dedicated group with mode 770, make sure every account that starts regions or runs mfsecretsadmin is in that group, and delete microfocus/temp/admin once the SYSAD password is safely recorded or changed.