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.
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.