Environment
NSL6.x
NSL7.x
Shared workstation environment
NSL7.x
Shared workstation environment
Situation
SecureLogin data is not deleted after clicking "Delete SecureLogin configuration on this object" in the directory, and deleting the local cache on the workstation.
SecureLogin data is repopulated after being deleted.
Local cache file was deleted from the workstation, and "Delete SecureLogin configuration on this object" was clicked in the directory management tool, but user specific SecureLogin data still showed for the user after a refresh.
SecureLogin data is repopulated after being deleted.
Local cache file was deleted from the workstation, and "Delete SecureLogin configuration on this object" was clicked in the directory management tool, but user specific SecureLogin data still showed for the user after a refresh.
Resolution
Set "enable cache file" to "off."
This setting is found in the "preferences" section of the SecureLogin plugin, and can be set for users, containers or groups using the appropriate directory management tool (iManager, SLManager, Users and Computers ). With this setting "off," any existing cache files present on the workstation will be ignored.
This setting is found in the "preferences" section of the SecureLogin plugin, and can be set for users, containers or groups using the appropriate directory management tool (iManager, SLManager, Users and Computers ). With this setting "off," any existing cache files present on the workstation will be ignored.
Additional Information
By default, a local cache file will be created for a user wherever that user logs in and launches SecureLogin. In an environment where users login to multiple workstations, multiple instances of their cache will exist - one on each workstation where the user has logged in. If the cache file is deleted from one workstation, the directory can still be populated from another workstation.
The local cache works especially well in environments where users login to only one or two workstations, but it can be problematic in environments where users login to many workstations - particularly if the cache data ever needs to be deleted.
Also, the local cache allows single sign on access when the network is not available. This is not needed in environments where all sso enabled applications are on-line.
Note that the local workstation cache file is created based on the Windows login. If all users login to the workstation with the same Windows account (as in the typical "kiosk" workstation use case) there will only be one cache file containing data for all users. This is ok, and as designed. It does not mean that User A will see credentials belonging to User B; the file is created and encrypted such that users only see their own data. The implication, however, is that when the cache refresh happens on a workstation and the cache is synchronized to the directory, the data for all users in the workstation cache will be synchronized to the directory.
The local cache works especially well in environments where users login to only one or two workstations, but it can be problematic in environments where users login to many workstations - particularly if the cache data ever needs to be deleted.
Also, the local cache allows single sign on access when the network is not available. This is not needed in environments where all sso enabled applications are on-line.
Note that the local workstation cache file is created based on the Windows login. If all users login to the workstation with the same Windows account (as in the typical "kiosk" workstation use case) there will only be one cache file containing data for all users. This is ok, and as designed. It does not mean that User A will see credentials belonging to User B; the file is created and encrypted such that users only see their own data. The implication, however, is that when the cache refresh happens on a workstation and the cache is synchronized to the directory, the data for all users in the workstation cache will be synchronized to the directory.