This document provides a high level overview of how credentials work in Shavlik Protect.
There are several sections to this article, each pertaining to agentless operations in Protect.
A more in depth explanation, as well as how Agents use credentials and helpful visuals, is available here: How Credentials Work in Protect
When scanning, Protect will use a failover sequence to determine where it should get credentials from. The order is:
- Individual Machine’s Lower Panel Credentials > Machine Group’s Credentials > Default Credentials > Currently Logged On Under Credentials (CLOUC)
- If scanned from View > Machines: If no credentials are specified in a Machine's Properties, Protect will check the Machine group that machine was last scanned successfully from.
- If no credentials are specified in the Properties or Machine Group, Protect will use the CLOUC.
- If the CLOUC fails, Protect will use the Default Credentials, if a set of credentials has been specified as Default.
While scanning in Protect utilizes a failover sequence, deployments do not.
If no credentials are available, or they fail, the deployment fails. Deployments will not attempt to use CLOUC or default credentials. Because of this, it's possible to scan successfully, but receive an access denied error upon deployment.
If you supply bad Individual Machine’s Lower Panel Credentials, it will fail over to CLOUC to get the machine resolution, but it will fail to copy the files over during the installation. The file copy happens in the Console Service and will use the Individual Machine’s Lower Panel Credentials.
When scheduling a scan, Protect requires a "Scheduler Credential". This credential is not set in the Credentials Manager, but under Manage > Scheduled Console Tasks.
The scan uses the credentials associated to Scheduler Credential, not your currently logged on user or default credential
This credential is the identity Protect will assume to kick off the scan. As such, it must be a local Administrator, and it must be allowed to run scans under User Role Assignment.
This credential needs to be set while logged in as the user specified.
-Example: If the credential is domain\user1, then domain\user1 needs to log in to the Protect server, open the console, create the credentials, and assign them.
Scheduled Deployments will use credentials in the same manner as normal deployments.
Individual Machine’s Lower Panel Credentials >
Currently Logged On Under Credentials(CLOUC) (Copy will fail, because it is done in the service and it will use the Machine account)
Default Credentials (Individual Machine’s Lower Panel Credentials NOT supplied)
Multiple Protect Administrators
When multiple users are given Administrator access to Protect, there are some considerations to take into account regarding credentials:
- Administrators can overwrite shared credentials, which can interfere with tasks scheduled by another admin.
- An admin who edits a credential, also takes "ownership" of the credential.
One particular part of credentials many people have issues with is Scheduled Scans. This is because scheduled scans are a scheduled console task, and require the scheduler credential to be properly set.
Of course, people want to know why things must be set the way they are. Here's the technical background behind why:
- When the time comes for Protect to run the scheduled scan, it's operating under the LocalSystem account. It uses the system account to "impersonate", or act as, the scheduler credential.
- When a user creates credentials in Protect, those credentials are encrypted in a manner that only allows the user that created the credentials to decrypt them.
- So, if the scheduler credentials are set by a different user, when Protect tries to decrypt the scheduler credentials using the scheduler user profile, it will fail. Similarly, if the scheduler credentials have never been used to log onto the server, there will be no profile for Protect to login under. Protect tries to find the credential associated to that different user and it will not be able to find them, because they were never entered.
For more detailed information regarding credentials in Protect, please see How Credentials Work in Protect .