You can take precautions to ensure that authentication credentials (usernames and passwords) are securely stored and retrieved when using the OES 11 migration tool.
By default, neither the migration GUI utilities (File System Migration Utility) nor the command line tools (mls, migfiles, etc.) store the usernames and passwords entered by the user running the migration.
When using the migration commands, administrators can choose to use the Novell Common Authentication Service Adapter (CASA) to store credentials during a migration, so that they are not prompted repeatedly for usernames and passwords when authenticating to the source and target servers. This feature can be selected by adding the --use-casa option in the migration commands. If this option is used, the username and password information is stored in the CASA secret store.
NOTE:As an alternative to using the --use-casa option in the migration commands, you can set the MIG_USE_CASA environment variable by using the following export command:
You can set this environment variable in the shell init scripts so that every shell has it set.
Various migration commands provide the --use-casa option, which tells the command to obtain the credentials from the CASA store and not prompt the user for them. If the --use-casa option is used and the credentials are not found in the CASA store, the command prompts for them and then stores them in the CASA store.
The migration commands use the CASA API library to securely store and retrieve credentials from the secret store.
The migration GUI utilities do not use CASA, nor do they store user credentials in any file format. Rather, the utilities accept the user credentials entered for the source server and target server and, after validating them (via secure or non-secure LDAP authentication), the utilities store this information in a proprietary cache. These credentials are used by the applications to execute various migration-related operations. For example:
To retrieve NetWare source volumes, the File System Migration Utility issues an ncpshell command.
To carry out migrations, the GUI utilities execute the required migration commands (mls, migfiles, maprights, maptrustees, etc.).
The migration utility cache is flushed when the applications are closed.
In a saved migration project, only the IP addresses of the source and target servers, the volume names, and any other migration options, are stored in the .xml configuration file. When you open and rerun a saved project, you are prompted to reenter the credentials.
The GUI utilities execute migration commands within their process context and pass the user credentials whenever required or prompted through their process APIs, which can be hidden from the user. The GUI applications neither set the credentials in environment variables nor use the CASA store, even though the migration commands provide the option.
To pass credentials to the migration commands, the GUI utilities open a terminal connected to the standard input and feed in the password to the command line prompt.
As mentioned previously, administrators can choose to store user credentials in CASA so that they are not prompted for usernames and passwords every time they perform a migration task.
You can use the migcred command to control and manage what is stored in the CASA secret store. This command provides options to store, view, and delete information for a particular identity. With the necessary user credentials stored in CASA, usernames and passwords can be retrieved as needed by other migration commands.
Administrators might also want to pipe the output of one migration command to another, so they cannot feed usernames and passwords to the commands through the console. Using the CASA secret store provides a way to protect this secure information when piping migration commands.
The user must include the --use-casa option when building the pipelines. For example:
mls -s 192.168.131.135 -v V1 --use-casa | maptrustees -s 192.168.131.135 -r --use-casa