Device access

By default, any technician in your organization can work on any device. That is fine for a small MSP, but it stops being fine when there is a junior who should not touch servers, an external contractor who only covers one customer, or a customer who insists their infrastructure is handled by two people rather than twelve.

This module defines who can do what on each device.

Getting in

Settings, Security section, Device access. You need the organization settings permission, which Owner and Admin have by default.

The card is shown to everyone, but anyone without the permission gets an error on opening it.

The three pieces

For a technician to do anything to a machine, three things have to line up:

1. Their role's permission. If they do not have the remote control permission, no access rule will grant it. Rules narrow, never widen.
2. Your organization's mode. What happens when no rule says anything.
3. That technician's rules. The specifics.

The two modes

Permissive (the default): with no matching rule, the technician can. Deny rules narrow things down.

Restrictive: with no matching rule, the technician cannot. Allow rules grant access, one at a time.

The mode is changed with Save mode. Every change is audited.

Think it through before switching to restrictive. In that mode, a technician with no rules loaded is left with access to nothing. If you are going to switch, load the allow rules first and change the mode afterwards.

The four capabilities

Each rule allows or blocks a specific capability, not the whole device:

They are ordered from most invasive to least. A technician can have patching on a server and not remote control: they are separate decisions.

Watch out for one combination in particular. The device appears in the list if the technician has at least one capability, but opening the record requires Monitoring. A technician with Execution and without Monitoring will see the device in their list, click it and get an error. If you grant any capability on a device, grant Monitoring too.

The five scopes

A rule applies to one of these five:

The two Active Directory scopes only appear if you have already run an AD discovery. If nothing has been discovered, the form tells you and suggests running one.

What does not exist as a scope: a rule cannot be defined over a panel device group, a site, or a tag. Those five are all there is.

Rules are per person

A rule applies to one user and one only. There are no rules by role, by team, or by user group.

If you want ten technicians to have the same restriction, you need ten rules. It is the module's most awkward limitation, and it is worth knowing before designing your scheme.

You get there from the technician list, View rules. Rules are added with Add rule and removed with Delete rule. Both are audited.

Which rule wins

This is the part to get right, because it does not work the way most people expect.

Deny does not always win. The most specific rule wins, regardless of its effect.

Specificity order, most to least:

1. Device
2. AD group
3. Organizational unit
4. Customer
5. All devices

An allow on a specific device beats a deny across the whole customer. That is intentional: it lets you write "deny the whole customer, allow this device" and have it do exactly what it reads.

Deny only wins on an exact tie, meaning when both rules have the same scope and the same priority.

Priority

Every rule has a priority number, from 1 to 9999, defaulting to 100. Lower number wins, and it only breaks ties between rules of the same scope.

Three examples

Specificity beats effect. Deny Execution on customer 5, and allow Execution on device 42, which belongs to that customer. Result on 42: allowed.

Exact tie: deny wins. Allow Patching on device 42, and deny Patching on device 42, both at priority 100. Result: denied.

Priority breaks ties within the same scope. Two rules on the same customer, one at priority 50 and one at 100. The 50 wins.

Why AD group ranks above OU: a group is deliberately built to bring machines together ("Critical servers"), whereas an OU reflects structure inherited from the domain. The group expresses intent better.

When an AD rule cannot be evaluated

A device may have no Active Directory data for several reasons: the domain was never discovered, the discovery is old, the device is not domain-joined, or it could not be matched.

In those cases KairosLink does not guess. AD group and OU rules are skipped, because treating "I have no data" as "belongs to no group" would turn a permission into a denial, or the other way round.

A practical consequence worth keeping in mind: an AD rule on a device with no discovered data does not apply, and today the screen does not say so. If you loaded a group rule and do not see the effect you expected, check that the device has a recent AD discovery.

What a technician without access sees

In the Devices list, the machine does not appear. It is not crossed out or greyed: it is not there. And that screen's automatic refresh respects the same filter.

If they go in by direct address, they get an error with the reason, and it is recorded in the audit trail.

Actions are blocked everywhere. They cannot connect, run commands, patch or touch that device's monitoring from any screen in the panel. That is what the module guarantees.

What they still see

The visibility filter applies to the Devices list, not to the other grids. In patching, monitoring, antivirus, security posture, DLP, certificates, the screen wall, reports and the device selector on a ticket, that device is still readable: name, customer, status and its counters.

They cannot act on it from there, but they see it.

Put plainly: the module controls the action, not the visibility of the name. If your use case is that an external contractor should not even see the names of other customers' machines, that falls outside what this module solves.

The buttons do not disappear

The only one that reflects access is Connect, which is shown greyed out with the reason in the tooltip. All the others (console, files, services, processes, patch) are drawn regardless and fail when used.

The control is there; the visual cue is not.

Roles

The Owner is never left without access. They are exempt from rules by design: there is no way to lock the owner out of their own fleet.

An Admin can be restricted. If you load rules for them, they apply. That is intentional: it allows administrators scoped to a set of customers.

Technician and Read-only are governed entirely by their role permissions plus their rules.

Where to see who has access to what

You can see which devices a person can touch, by opening their rules from the technician list.

The reverse view does not exist. There is no screen that answers "who can touch this device". If you need to audit that, you have to go through each technician.

What is recorded: mode changes, rule additions and removals, and every denied attempt.

What it does not do today

• There are no rules by role or by user group. One rule, one person.
• A rule cannot be defined over a panel device group, a site or a tag.
• The visibility filter only applies to the Devices list. On the other grids the device is still readable.
• There is no screen showing who has access to a given device.
• Buttons are not hidden based on access, apart from Connect.
• An AD rule that cannot be evaluated gives no warning on any screen.

Frequently asked questions

Where do I start if I want to restrict someone? Load their rules first, then change the mode if needed. Switching to restrictive with no rules loaded leaves everyone without access.

I set a deny on the customer and the technician still gets into a device. Check whether there is an allow on that specific device: the most specific rule wins, regardless of effect.

Doesn't deny always win? No. It only wins when it ties with an allow on both scope and priority.

I granted access to a device and clicking it gives an error. Opening the record requires the Monitoring capability. Grant it alongside the one they already had.

I want the same restriction for ten technicians. Today that takes ten rules. There are no rules by role or by group.

I loaded an AD group rule and nothing happens. If the device has no discovered Active Directory data, that rule is skipped. Run an AD discovery.

Can I lock the Owner out? No. They are exempt by design.

Can I scope an Admin? Yes. Admins can be restricted with rules.

How do I find out who has access to one particular server? There is no screen for that today: you have to check each technician's rules.

I removed their access and they still see it under Patching. The filter that hides the device applies to the Devices list. On the other grids they see it, but cannot act on it.