How Permissions Actually Work (and Why Additive Logic Matters)
Before you configure a single permission, you need to understand how Central
resolves them. This is one of the most misunderstood aspects of the platform.
The Additive Permission Model
A group member's effective permissions are the combination of their individual
user permissions plus the permissions of every user group they belong to.
Permissions are additive — you cannot use a group to restrict an individual's
existing permissions.
This means that if a user has "Remote Control" permission individually, placing
them in a group that doesn't include that permission won't remove it.
This has a critical practical implication: keep individual user permissions
minimal or empty and manage everything through groups. If you grant
permissions at both the individual and group level, you'll spend considerable time
debugging unexpected access — especially when users are in multiple groups.
The two levels of access control to get right
Central Account Permissions
What a user can do inside your LogMeIn Central account — things like Computer
Group Management, User Management, Configuration Management. These
control administrative capability within the platform.
Host-Level Access Permissions
What a user can do once connected to a specific host — Remote Control, File
Transfer, Remote Printing, etc. These are set per group or per computer. Don't
confuse having account access with having host access.
A Common Confusion Point
A user may be able to see a computer listed in their Central account but still be
unable to access it if User Access Control (UAC) on the host itself doesn't allow
their Windows or Mac credentials. Central account permissions and host operating
system permissions are separate layers. Both need to be right.
Attempted logins that fail UAC on the host will surface as Error 4320 ("Operator or
Administrator has refused the request"). At scale, this becomes a support ticket
flood if host-level UAC hasn't been configured through your Host Preference
Packages before rollout.
At-Install Checklist: The Decisions You Can't Easily
Undo
Here's a prioritized checklist of what to lock down before or at the time you deploy
hosts. Revisiting these retroactively across 100+ machines is a significant
operational burden.
Define your Computer Group taxonomy before first deployment
Sketch out your groups on paper or a whiteboard first. Name them with consistency (region,
function, tier). Your naming convention will be your navigation system once you exceed 1,000
groups and "Show All Groups" is no longer available.
Build your User Groups and define their permissions before inviting users
Create your role-based User Groups — e.g., "Help Desk Tier 1", "IT Admin", "Read-Only
Auditor" — and set their Computer Group and feature permissions. Then invite users into the
right groups from day one, not after the fact.
Configure Host Preference Packages and assign them at installation
Host Preference Packages let you define and push security settings — including remote
control consent behavior, User Access Control, and connection settings — to Windows hosts
centrally. Assign the appropriate package when you create or deploy to a computer group, not
post-deployment.
Specify the target Computer Group in your deployment package
When using Central's Deployment page for mass installation, you can configure where newly
installed hosts land. Use this to avoid the Default Group accumulation problem from the start.
Apply the principle of least privilege from day one
Don't give users access to all computers in your account unless it's absolutely necessary. Scope
access at the Computer Group level, not the "All Computers" level. It's far easier to expand
access than to audit and restrict it retroactively across a 100+ host estate.
Helpful Resources from Central Support
