Local API Server and Identity Manager tools fail when using encrypted global.cfg (4381856)

Customers may encounter connection failures when configuring a local API Server or running administration tools using an encrypted global.cfg file.
Connections succeed only when stored in the Windows registry, which creates challenges in multi-user and multi-environment setups (DEV / TEST / PROD).

This behavior forces each user to manually configure connections and handle privileged credentials, making automation, shared tool directories, and secure environment separation difficult to maintain.

The global.cfg file uses weak and outdated encryption and is not supported or recommended for secure or production use.

See: https://support.oneidentity.com/kb/4378383/note-regarding-the-use-of-the-global-cfg-file-in-production-environments

When encrypted, connections defined in global.cfg may not be usable by local API Servers or tools.

Additionally:

• global.cfg persists on disk, increasing credential exposure risk.
• Registry-based storage uses Windows DPAPI encryption but is user-specific (HKEY_CURRENT_USER), preventing easy sharing across users.
• Copying registry entries to HKEY_LOCAL_MACHINE does not provide the expected shared behavior.
• There is no fully equivalent, secure replacement for global.cfg that preserves per-environment separation with shared tool directories.

Using global.cfg is not recommended. Instead, choose one of the following supported alternatives based on security and operational requirements:

1. Use a Privileged Access Management (PAM) solution (Recommended)
   1. Eliminates reliance on stored credentials in configuration files.
   2. Supports secure access to administration tools.
   3. Works with One Identity Safeguard or third-party PAM solutions (e.g., CyberArk).
   4. Best suited for production and shared environments.
2. Store connections in the Windows registry (HKEY_CURRENT_USER)
   1. Uses Windows DPAPI for secure encryption.
   2. Requires each user to configure connections individually.
   3. Does not preserve clean environment separation within tool directories.
3. Run the API Server on a remote machine
   1. The API Server is designed to run remotely, not locally, especially in production.
   2. Tools can connect via Application Server URLs instead of direct database connections.
   3. Reduces local credential handling and improves security posture.

Important Notes:

• There is currently no supported, secure alternative that fully replicates global.cfg behavior (shared, per-environment configuration without manual setup).
• Some additional complexity is unavoidable to meet modern security requirements.
• This limitation is not specific to any Identity Manager versions and is considered "by design"