Last successful credentials caching

TADDM can cache last working access credentials. They can be reused in the next (Level 2 or script-based) discovery.

During the initial discovery of a target, TADDM server iterates through the access list and validates each item against the discovery target. When the valid credentials are found, they are stored in a cache and reused during the consecutive discoveries of the same discovery target.

A cache can store the two following values:
credentials
This value is stored in a cache when the valid credentials for a discovery target are found during the discovery. During the next discovery, they are read from the cache and checked whether they are still valid. If they are still valid, they are used for the discovery. If they are no longer valid and the fallback is disabled, the information that the last attempt failed is stored in the server and the discovery is stopped. When the fallback is enabled, the server iterates through the access list and tries to find new valid credentials. To enable the fallback, set the com.ibm.cdb.security.auth.cache.fallback.failed property to true.
information that the last attempt failed (along with the last error)
This value is stored in a cache when the valid credentials for a discovery target are not found during the discovery. If the fallback is disabled, the information that the last attempt failed is displayed and the discovery is stopped. If the fallback is enabled, the server iterates through the access list and tries to find new valid credentials. To enable the fallback, set the com.ibm.cdb.security.auth.cache.fallback.invalid property to true.
By default, fallback in both cases is enabled. You can customize the fallback behavior and credentials caching by appropriately setting the access credentials caching properties.
Note: Credentials are cached per IP address, location tag, credential type, and protocol that is used during connection. When access entry is removed, all associated cache entries are also removed. Credentials cache can be managed by the new utility cachemgr.

Limitations

  • Credentials caching is not used in Level 3 discovery. It is used only for Level 2 computer system discovery and script-based sensors.
  • A cache does not track scope access restriction changes. For example, if a discovery target is within scope access restriction and is discovered and cached, and then moved out of scoped restriction, the cached value is still used.
  • The cached value has precedence over the profiled access list. For example, if you run discovery by using the main access list and valid credentials are stored, the cache value is still used, even if you specify other credentials in a profile.

You can remove a cached value by using the cachemgr utility. If you often use different profiles with different access entries against the same discovery target or scope, you can disable caching for them. Otherwise, wrong credentials might be used in the discovery.