Key Manager Management States, Key Statuses and User States

Key Manager assigns a management state and a status to each key that is found in the managed environment. To display the management state and status information of each user key in individual columns, you can add the respective columns using the list control bar.

For newly discovered keys, the purpose of the management state is to distinguish whether the key was present before or after their parent host was added into the managed environment. The management state also distinguishes whether a key was added using the Key Manager system. The possible management states and their meanings are as follows:

• legacy: Keys that were found while the host is in the monitored state. Generally, these are keys that have been present on the host before the host was added to the managed environment. When a monitored host is scanned for existing keys (such as, when the host is added to the managed environment), all keys found during the scan are marked as legacy keys.

• managed: Keys that were created using Key Manager. These keys are created by Key Manager administrators who add authorizations using Key Manager. Alternatively, these may be legacy/ unmanaged keys that have been converted to managed keys (after being reviewed and approved by Key Manager administrators).

  note

  Key Manager admins can convert legacy and unmanaged keys to managed keys. This action can be used to indicate that the legacy/unmanaged key has undergone approval, and is a trusted key in the managed environment.

• unmanaged: These are any new keys that Key Manager detects on managed hosts. These may be keys that were manually added to a managed host (potential unauthorized key setups), or keys that for some reason were not detected by host scans when the host was in the monitored state. As an example of the latter case, the key may have been on a temporarily unavailable network drive. We recommend that you carefully review the validity of such keys. If you conclude that an unmanaged key enables an approved trust relationship, you should convert the key to a managed key. Otherwise, you should remove the key.

The possible key statuses and their meanings are as follows:

• appeared: The key is located at a location where it is not expected to be. Any key that is detected after the initial host scan and which was not placed using Key Manager, is marked as appeared. Appeared keys may be keys that were manually added to a file location (potential unauthorized key setup). Appeared keys can be used for user authentication, however, their origins are unknown. As such, you should carefully review whether the authorizations enabled by appeared keys are acceptable.

• deleted: A Key Manager administrator has deleted this key using Key Manager. Deleted keys cannot be used for user authentication.

  You can use Key Manager to restore authorized keys that have been deleted.

• missing: A key is no longer located where it should be. Missing keys may be keys that were moved or deleted using unknown means. A missing key cannot be used for user authentication until it is restored.

• present: The key is present on its host and located at the file location where Key Manager expects it to be. After a host is added to the managed environment, any keys found during the initial scan are marked as present. Also, any user keys created using Key Manager are marked as present (as long as they are not moved or deleted manually). Present keys can be used for user authentication.

• blacklisted: The key has been blacklisted by an administrator. Any user keys with fingerprints corresponding with the blacklisted key are deleted and cannot be restored using Key Manager. Blacklisted user keys are not reused when creating new authorizations using Key Manager. Alerts are generated when Key Manager detects attempts to authorize into the managed environment using blacklisted keys. Additionally, such events will be be recorded in the Key Manager audit log.

Additionally, Key Manager features the following filter criteria that match user keys with certain statuses:

• is on host: Filter criteria matching both present and appeared keys.

• not on host: Filter criteria matching both deleted and missing keys.

Figure 9.2. Key statuses and transitions

A key may also be subject to pending operations. When Key Manager administrators initiate key- management jobs, it may take some time before the job is run. For example, on agent-based hosts, initiated jobs must wait until the next agent connection to be run. In such situations, the key is marked with a pending operation.

Pending operations indicate that the key is currently being modified by a Key Manager job. Pending operations block the execution of other jobs. Therefore, you must wait for the current pending operation to finish before you can run other jobs for the key.

The possible pending operations are as follows:

• delete: A Key Manager admin has initiated a removal job for the key. The key will be deleted when the job finishes.

• generate: The private key is currently being generated. A private key can have this pending operation after a Key Manager admin adds authorizations that require the generation of new private keys. The private key will become usable after the key-generation job finishes.

• install: The authorized key is currently being added to the authorized-keys file. An authorized key can have this pending operation after a Key Manager admin adds new authorizations. The authorized key will become usable after the key-installation job finishes.

• renew: A Key Manager admin has initiated a key-renewal job for the key. The key will be renewed when the job finishes.

• add_options: A Key Manager admin has initiated a set-options job for the key (for adding authorized- key options). The options of the key will be updated when the job finishes.

• remove_options: A Key Manager admin has initiated a set-options job for the key (for removing authorized-key options). The options of the key will be updated when the job finishes.

• set_options: A Key Manager admin has initiated a set-options job for the key (for setting authorized- key options). The options of the key will be updated when the job finishes.

• update_options: A Key Manager admin has initiated a set-options job for the key (for updating authorized-key options). The options of the key will be updated when the job finishes.

• failed_<operation>: The latest management action for this key failed. <operation> describes the type of the failed operation, and is always one of the possible pending operations. For example, failed_generate or failed_add_options.

  Unlike other pending operations, a failed pending operation indicates that there are no operations for this key, and does not block management actions for the key. You can check the job logs for additional information about the possible causes of the failure. For more information about reviewing job logs, see Reviewing Job Logs.

A user account can have the following states:

• Discovered: the user account has been found while scanning the host.

• Requested: the user account has been requested via Access Request, and pending actions are performed by 3rd party software. See chapter 9.3 Example 3: Access Requests With User Provisioning in User Portal Manual for more information.

• Created: the user account has been created by a 3rd party software during request processing. See chapter 9.3 Example 3: Access Requests With User Provisioning in User Portal Manual for more information.

• Deleted: During a scan it is noticed that a previously active user has been deleted.

• Disabled: During a scan it is noticed that a previously active user has been disabled.