The Client
The client is installed on each client computer to enforce file authorization and device permissions policies.
You can install the client on the same computer as the Management Console when you are using Device Control. Each protected computer can maintain local authorization and device permission files, so that routine application requests do not have to traverse the network. Only log files and periodic differential updates are sent from client computers to the using the Management Console.
When a client requests a connection to the Application Server listed by DNS name, the name is resolved and the first IP address returned is selected, as required by round-robin DNS conventions for a server-client connection attempt. This behavior is controlled by the FirstServer registry key.
If the connection attempt fails, the client selects the next server name from the list and repeats the process. After reaching the end of the list and no server-client connection is established, the client uses the locally cached user access and device permission list. The first connected server receives client logs and shadow files in a compressed format that is stored in the DataFileDirectory (DFD) defined during installation.
When you are using Device Control, the client:
- Ensures that only removable storage devices and media that the user is authorized for can be accessed. Any attempt to access unauthorized devices or media is denied, regardless of the computer the user logs into.
When you are using Application Control, the client performs the following:
- Calculates the digital signature, or hash, for files requiring authorization.
- Checks the digital signature against the locally stored authorization list for a matching digital signature.
- Denies and logs any user attempts to run unauthorized files.
- Allows, when expressly permitted, a user to locally authorize a denied file.
- Generates log records of all application access attempts, approved and denied. The Log Access Denied option is enabled by default.
The client is composed of the following components:
- Kernel driver (Sk.sys), that runs on supported operating systems to enforce defined policies for determining which applications and/or devices users can access.
- Communication service (scomc.exe), which provides communication with the Application Server(s). This component, Ivanti Device and Application Control Command & Control (SCC), runs as a service, that sends log data to the Application Server that can be viewed via the Management Console.
- User interface (RtNotify), which informs the user of updated policy changes completed by the administrator (these messages can be deactivated). RtNotify is used by the client to retrieve user certificates on demand.
- Auxiliary dynamically linked library (DLL) files, which provide additional features to the core components. These files contain support for RtNotify localization information, 16-bit application control, and macro and script protection.
The following illustrates the relationships between the client component layers.
After the client is installed, RtNotify appears as an icon in the system tray. Through RtNotify the user receives information about permission changes via pop-up messages. End-users can interact with the client to:
- Locally authorize software application files
- Manage user access to removable storage devices
- Update permissions changes when the client receives event notifications
Important: A user cannot change any Application Control or Device Control administrative settings or permissions.
The administrator can query the client to obtain the salt value used for endpoint maintenance, when the computer is not connected to the network and this value cannot be obtained using the Management Console.
When an Application Server is unavailable at login, the client uses the locally cached permission list from the last successful Application Server connection. If no permission list exists, the client denies user access to all device and application requests. Permissions lists can be imported to a computer, as necessary, when no server connection is available or the computer is disconnected from the network.
A key security principle of Application Control or Device Control is that, even when the communication service or user interface is disabled, the kernel driver always protects the client computer. Protection remains in force and the least privilege principle applies. This principle denies user access to applications or devices that are not expressly permitted. Client components use client hardening functionality as described in the Ivanti Device and Application Control help to protect against user tampering.