PDF

Managing NetCrunch Access Profiles

Access Profiles in NetCrunch define what users can see and do in the system. They form the foundation of role-based access control and allow scalable, high-performance delegation of privileges to individuals and groups. This topic explains how to design and apply Access Profiles to achieve the right balance between security and usability.

Overview

Access Profiles in NetCrunch represent reusable, role-based permission sets that define access to:

  • Program features (like dashboards, settings, server operations)
  • Atlas views (containers, dashboards, maps)
  • Specific nodes and their functions

Unlike many systems that tie permissions directly to users (and slow down as the number of users increases), NetCrunch applies permissions through shared profiles. This makes access evaluation extremely fast, even in large environments, and simplifies administration.

Each user—whether local or AD-authenticated—can have one access profile, either assigned directly or inherited through group membership.

Two Strategies for Assigning Access

NetCrunch supports two core strategies for designing access:

Deny by Default (Recommended)

This is the default model:

  • Start with no access to anything
  • Explicitly add access only to required views, nodes, or features

This approach is safer, easier to audit, and minimizes accidental overexposure.

Allow by Default

In this model:

  • Grant access to all views and nodes initially
  • Selectively deny access to sensitive or restricted elements

This approach can be useful in smaller environments or for quick setup, but it's less secure by nature.

Both strategies can be implemented in the same UI by adjusting the Atlas Defaults and View/Node Overrides in the profile editor.

Role-Based Model

Access Profiles should be treated as roles, not per-user settings.

  • You create roles like "NOC Operator", "Tier 2 Support", or "Server Admin"
  • Assign those profiles to multiple users or AD groups
  • This ensures consistency and centralizes permission changes

Changing access rights in one profile instantly affects all assigned users, avoiding duplication and misalignment.

Profile Assignment

  • For local users: assign the Access Profile directly in their account settings
  • For Active Directory users: assign the profile to an AD group
    • When the user logs in, NetCrunch checks group membership
    • If multiple groups match, the first matched profile (based on order) is applied
    • If the user loses group membership, access is revoked

There is no limit to the number of access profiles you can define.

Access Rights Structure

NetCrunch uses a hierarchical, path-based access model. Each object or operation can be granted:

  • Deny – Block access to the item or function
  • Access – Allow viewing, reading, or executing
  • Manage – Allow configuration or editing

Access rules are evaluated from longest path to shortest. This means more specific rules override broader defaults.

Examples:

  • Node → basic access to the node
  • Node > Events → access specifically to the node’s event view
  • Atlas View > Nodes → access to all nodes within a view, but not necessarily to the view itself

Access Scope

Access profiles can define rights in three scopes:

Program

Controls access to core system features:

  • Server settings
  • Monitoring tools
  • Logs and system info
  • Desktop Console access (via "Server Administration" right)

Atlas Defaults

Set default rights for all nodes or views unless overridden.

  • Useful for “Allow by default” strategy
  • Can grant view access without node access (or vice versa)

Views & Nodes

Here you define specific overrides—either granting or denying access at the element or feature level.

  • Override default behavior from the Atlas Defaults
  • Restrict access to sensitive views or critical nodes
  • Allow visibility to a view but hide specific nodes in it

This distinction is key: having access to a view doesn't mean the user can see every node inside it.

Desktop Console and Web Console

Both consoles now share a unified security model. The Desktop Console functions exactly like the Web Console regarding permissions, fully honoring granular access profiles. This means the Desktop Console is no longer restricted to users with Server Administration rights; it adapts to the specific view and node-level permissions assigned to the logged-in user.

Summary

Access Profiles in NetCrunch are lightweight, scalable, and built for performance. Designed around roles, not individuals, they allow fast permission evaluation even in large user environments. Whether you're using a deny-first model for strict control or an allow-all model with exceptions, NetCrunch keeps access control simple, auditable, and efficient—with no artificial limits on how many profiles you define.

access controlaccess profileaccess scopeactive directory integrationatlas accessnetcrunch permissionsnode accessrole-based accessserver rightsuser permissionsuser rightsview access