Chat now with support
Chat with Support

Safeguard Authentication Services 4.1.5 - Management Console for Unix Administration Guide

One Identity Privileged Access Suite for Unix Introducing One Identity Management Console for Unix Installing Management Console for Unix Preparing Unix Hosts Working with Host Systems Managing Local Groups Managing Local Users Active Directory Integration Authentication Services Integration Privilege Manager Integration Reporting Setting Preferences Security Troubleshooting Tips
Auto Profile Issues Active Directory Issues Auditing and Compliance Cannot Create a Service Connection Point Check Authentication Services Agent Status Commands Not Available CSV or PDF Reports Do Not Open Database Port Number Is Already in Use Elevation Is Not Working Hosts Do Not Display Import File Lists Fakepath Information Does Not Display in the Console Java Applet Failures License Info in Report is not Accurate Out of Memory Error Post Install Configuration Fails on Unix or Mac Privilege Manager Feature Issues Profile Task Never Completes questusr Account was Deleted Readiness Check Failed Recovering From a Failed Upgrade Reports Are Slow Reset the Supervisor Password Running on a Windows 2008 R2 Domain Controller Service Account Login Fails Setting Custom Configuration Settings Single Sign-on (SSO) Issues JVM Memory Tuning Suggestions Start/Stop/Restart Management Console for Unix Service Tool Bar Buttons Are Not Enabled UID or GID Conflicts
System Maintenance Command Line Utilities Web Services Database Maintenance

Handling Changes to SSH Host Keys

If an SSH host key is different than what is expected, the mangement console might indicate that the host is experiencing a "man-in-the-middle" attack. More commonly however, it simply indicates that the SSH host key has changed. When profiling, if the mangement console finds a SSH host key that is different than the one that is already cached on the server, it prompts you to accept the changed key.

For other actions, such as adding or deleting a user, a changed host key always results in an error. If you encounter an error, you must update the new SSH key before you can complete the action. (See Managing SSH Host Keys for information about updating the host's SSH Key cached in the mangement console database.)

Note: Management Console for Unix caches SSH connections to improve performance when multiple actions need to be performed against a host. Because of this, you might see unexpected behavior. For example, if you profile a host and accept its public key, the mangement console stores the host's public key and caches the SSH connection for a short period of time. If you perform another host action, such as profiling, it uses the cached connection if it is available. You are not prompted to accept a new key while re-using the previously verified and trusted SSH connections obtained from the cache. Once the connection is flushed from the cache, any subsequent host action will identify a new public key and the console will prompt you to accept the new SSH host key.

Detecting Multiple Hosts With the Same Key

By default, Management Console for Unix prevents you from adding hosts with the same SSH host key to the mangement console. This is to ensure uniqueness of hosts since a host can have more than one resolvable DNS name and multiple IP addresses. There should only be one SSH host key returned for whichever DNS name or IP address you use to access the host. However, if you want to enable the mangement console to add hosts that share the same SSH key, enable the Duplicate SSH Host Keys setting in System Settings. (See Duplicate SSH Host Keys for details.)

Note: When you enable the Duplicate SSH Host Keys option, it is possible to add the same host more than once, each with a unique name. In this case the reported data will be duplicated for that host.

Caching Unix Host Credentials

Management Console for Unix caches both standard and elevated credentials:

  • Session caching: User names and passwords are cached for the duration of the browser session (that is, until the session expires upon log out or you close your browser page). The mangement console uses the cached credentials any time during the current session. That is, if persistent credentials are not already cached, the user name and password fields will be blank the first time it needs credentials to complete a task on the host during a browser session. Once entered, it caches these fields and reuses them during the current session; therefore, these fields are pre-populated for subsequent tasks with the previously entered credentials.
  • Persistent caching: When you select the option to save your credentials on the server, the mangement console encrypts the user name and password and stores the encryption key on the Management Console for Unix server. When persistent credentials are available, the mangement console uses them any time you access the service. That is, saved user names and passwords persist across browser sessions, and when needed, it pre-populates these fields the first and subsequent times it needs them to complete a task on a host.

You can remove the persistent credentials from the cache. (See Remove Saved Host Credentials.) Once removed, the mangement console uses the session-cached credentials.

Note: The option to create persistent credentials is available through several actions such as Profile Host where you can select the Save my credentials on the server option. If you are profiling multiple hosts and select the Enter different credentials for each selected host option, you can select the Save option for individual hosts or click the Save all credentials button to save credentials for all hosts.

See Modify Saved Host Credentials for more information about managing Unix host credentials.

Security of Credential Caching

When using persistent caching, the mangement console encrypts host credentials, as follows:

  1. It generates a salt or retrieves it from the Java KeyStore, a storage facility for cryptographic keys and certificates, if it has previously been stored in the keystore.
  2. It uses the salt to generate a unique 128-bit encryption key for the authenticated user. The key generation algorithm is the PBKDF2 algorithm using HMAC with SHA1. This algorithm is designed to prevent brute force attacks on the password by ensuring that the same passwords will result in different keys and by increasing the work factor by iterating many times over the key generation function.
  3. It uses the generated key to encrypt the credentials (including user name, password, and any elevation credentials) using the AES algorithm in CBC mode. It then uses Message Authentication Code (MAC) using the HMAC with SHA-256 algorithm to verify the integrity of the saved data.
Related Documents