One of the most effective ways to improve the success rate of 1Password Device Trust (Kolide) checks across your fleet is to select a remediation strategy.
Kolide offers four distinct strategies:
Do Nothing
The Do Nothing strategy, also known as Report Only, is the default strategy for all checks in Kolide.
When you choose this strategy, the check still runs on devices but the end user has no knowledge of their passing or failing state. The end user will never receive notifications or have their authentication interrupted, regardless of the check’s status.
Users can see a list of all checks that will run on their device in the Privacy Center.
Notify Only
The Notify Only strategy offers end users a gentle introduction to Kolide. If you choose this strategy, Kolide will be able to interrupt the authentication flow and produce notifications through the Kolide Menu Bar App without the consequences of blocking.
With Notify Only, users are always able to bypass notifications when they sign in to apps protected by Kolide.
While the Notify Only strategy will increase the compliance percentage of a check by promoting user awareness, it’s likely to have reduced efficacy in comparison to a blocking strategy, due to the lack of consequences for ignoring the notifications.
How to defer notifications
By default, Notify Only will immediately send an end user a notification as soon as Kolide determines that the device is failing the check. In some cases, you may wish to delay when this initial notification is sent. For example, when it’s likely that a large percentage of failing devices will resolve a problem on their own without the extra end user notification, such as an out-of-date operating system which prompts users to perform an update.
To defer notifications:
- Sign in to Kolide and select Checks from the dashboard to access the checks page.
- Select Configure Check for the check you want to update.
- From the Remediation Strategy section, select Configure.
- Select the dropdown, then select After a delay of and enter the desired number of days.
When a check fails, it will still produce an issue. However, an end user will have no knowledge of the check failure until the deferment window has elapsed.
Warn then Block
Warn then Block is the recommended remediation strategy for checks that you wish to achieve a high degree of compliance, while also giving users adequate time to resolve problems on their own before they’re blocked.
When you choose Warn then Block, users can bypass the warning until the warning period expires.
The Kolide Menu Bar App will display a yellow warning badge when the device fails a check that uses the Warn then Block strategy.
The Kolide Menu Bar App will display a red “x” when the device fails a check that’s set Warn then Block and the warning grace period has expired.
About Warn then Block timing
With the Warn then Block remediation strategy, Kolide will first warn a user about a failing check, then subsequently block them if that check failure has not been resolved within the specified time period.
You can control the precise timing of both the warning and blocking phases. Delay intervals can be configured for each, so you can fine-tune how long the warning will persist, and when blocking will begin. This allows you to create blocking schedules such as:
- When a check fails, start warning users immediately and block after 4 days.
- When a check fails, start warning users after 5 days and block after 8 days.
Delaying when Kolide sends the initial warning can be helpful in situations when it’s likely that a large percentage of failing devices will resolve a problem on their own without explicit end user intervention.
Delays configured for both warning and blocking are calculated from the same starting point: when the check initially fails. This means the blocking delay cannot be set to a lower time interval than the warning delay. Helper text is displayed alongside the delay dropdowns to show how long the warning period will last with your configured delays.
Block Immediately
Block Immediately is the most extreme remediation strategy and should only be used in situations that require an immediate response by end users. Unlike Warn then Block, end users will receive no prior warning of an issue before they are unable to access any applications protected by Kolide.
When you choose Block Immediately, users can’t proceed with authentication unless you turn on snoozing.
The Kolide Menu Bar App will display a red “x” when the device fails a check that’s set to Block Immediately.
Optional: Do Not Block Until
When using either the Block Immediately or the Warn then Block strategies, there are situations where some devices may become immediately blocked. You can set a specific date when blocking begins with the Warn Only (Do Not Block) Until setting, even if the device would otherwise have been blocked based on your remediation strategy configuration.
This is a great way to make sure users don’t have a negative experience or feel needlessly punished the first time you enable blocking for a check.
Once set, blocking will start on eligible registered devices at midnight in the UTC timezone.
How to preview strategy changes
As you make changes to the remediation strategy, a pop-up box will appear to the left of the sidebar to summarize how the remediation options will impact the current population of registered devices.
This pop-up is organized into four columns:
Remediation Stage: Can be one of the four stages:
- Pre-Warn/Pre-Notify: The device is failing the check, but the end user has not been notified/warned about it as they are still within the grace period.
- Warn/Notify: The device is actively failing the check, and the end user is being actively notified/warned about it by the Menu Bar app or as they authenticate to a Kolide-protected app.
- Blocks < 24h: Equivalent to Warn/Notify except the device will transition to a blocked state within 24 hours.
- Blocked: The device is currently blocked from authenticating to apps protected by Kolide.
Current: The outcome of the pre-existing remediation strategy on registered devices across the remediation stages.
Proposed: The outcome of the proposed remediation strategy on registered devices across the remediation stages.
Net: The difference between Current and Proposed.
In addition to viewing the counts, you can also select any count within the Current and Proposed columns to see a listing of devices that the count represents.
Advanced settings
Limit blocking to a subset of devices
Similarly to check targeting, you can control which devices the device trust settings apply to. You can control the scope of blocking by platform, or by groups.
To set remediation strategy groups:
- Under the Remediation Strategy section of the Configuration sidebar, select Limit remediation strategy to a subset of devices.
- From the first dropdown, select groups to include in the selected remediation strategy.
- From the second dropdown, select groups, if any, you want to exclude.
- Select Save.
After checking the box, choose the platforms, Okta Groups, or Device Groups you’d like the check to be in-scope for blocking target (or out of scope for blocking if they are selected in the Unless It Is Also In The Following Groups section).
Check shelf life
When you enable blocking on a check another dropdown will appear asking you to configure when you want to require a live recheck during authentication. This setting controls the check run’s shelf life – the amount of time Kolide will consider data fresh enough to use for a Device Trust authentication decision.
If the shelf life of the check result has expired at the time of authentication, Kolide will require the user to wait for a fresh check result to come back before proceeding.
In an effort to reduce the chances of your end users having to wait for a check to complete at sign in, Kolide employs a number of methods to make sure data is always fresh. For example:
Kolide adjusts the frequency a check will run on the device so that an online device generally always has fresh data.
The Kolide agent will immediately re-run checks related to the operating system version when the device starts up so that this information will be up to date when the user attempts to sign in.
If a device has been offline for many hours and suddenly comes back online, the Kolide agent will immediately attempt to refresh all check data ASAP.
We recommend that, as the default, 3 days is a reasonable compromise between freshness and performance. Checks are run much more frequently than this, but their results will be less than 3 days old when used for an authentication decision. This could happen, for example, when a device is offline for a long weekend and is then used to authenticate first thing Monday morning.
Snoozing
By default, end users are allowed to receive extra time to fix a check that is blocking their device from authenticating. This is called snoozing. The goal of snoozing is to make sure that, if an end user has an emergency, they can still sign in temporarily. Here are some facts about snoozing:
Snoozing extends the time a check will block a device by an additional 8 hours.
A check can only be snoozed at most once a week. This prevents the feature from being abused to avoid fixing issues regularly.
An end user snoozes an entire check at once, not individual issues failing the check. This makes sure that if new blocking issues are generated for that check during the snooze window, they will also be granted extra time.
End users can access the Snooze feature by selecting a failing check and choosing Snooze Blocking from the Other Options dropdown menu at the top of the Kolide toolbar.
You can turn off the ability to snooze a block on a per-check basis. To turn off Snoozing, select the option Do Not Permit Users to Snooze a Blocking Check and select Save.
Global settings
Administrators can also control end user remediation strategy behaviors. For example by controlling how often an end user has their authentication interrupted by the same failing check in End User Remediation Settings.