Administration Page

This chapter introduces the Administration surface of MetaDefender NDR. The Administration page is the single place where system administrators configure the Manager, adopt and govern sensors, manage users, schedule updates, wire in integrations, and set data-retention policy. Every subsequent chapter in this section drills into one of those surfaces; this overview explains the shape of the page, who reaches it, and how a change made here becomes a running configuration on a sensor or on the Manager itself.

This chapter is written for system administrators, Site Reliability Engineers (SREs), and analyst leads who own configuration of a MetaDefender NDR deployment. It assumes an installed Manager with at least one adopted sensor and an administrator account.

First-use acronym expansions in this chapter: SRE (Site Reliability Engineer), UI (user interface), RBAC (role-based access control), DNS (Domain Name System), NTP (Network Time Protocol), SMTP (Simple Mail Transfer Protocol), SSL (Secure Sockets Layer), SNMP (Simple Network Management Protocol), MOTD (Message of the Day), SIEM (Security Information and Event Management), MVP (Minimum Viable Product).

The Administration Page

The Administration page is the central configuration surface of the Manager. It consolidates every system-wide setting, per-sensor configuration control, and administrative workflow behind a single tabbed page optimized for large desktop monitors. Administrators open it from the main sidebar; the default landing tab is the Manager Configuration section. All changes applied here are version-controlled, confirmed before they take effect, and recorded in the audit trail.

📷 INSERT IMAGE HERE

Subject: The Administration page top-level layout showing the Manager Configuration and Sensor Management sections side by side.

Suggested capture: /administration/configuration at 1440×900, full viewport, with the left-rail navigation expanded so the section grouping is visible.

Two-Section Layout

The Administration Functional Requirements Document (FRD) defines two primary sections. Both are reachable from the Administration page's top-level tabs.

• Manager Configuration. Global settings for the Manager itself — hostname, MOTD, notice and consent banner, retention settings, syslog forwarding, automatic update settings, upstream Hypertext Transfer Protocol (HTTP) proxy, SMTP, DNS, NTP, timezone, password complexity, account logon controls, integration settings, SSL certificate, and SNMP. Sixteen distinct settings in total. Every setting in this section applies to the Manager first and, where inheritance is supported, propagates down to every sensor the Manager governs.
• Sensor Management. Configuration of individual sensors and sensor groups — the sensor list view with filter and search, group creation and management, per-sensor Suricata configuration surfaces (Detect Engine, Basic Global Settings, AF_PACKET, Threading and CPU Affinity, Stream and Flow, File Extraction, Logging and Stats, Output), and bulk operations that apply a single configuration or policy change across every member of a group. Most sensor configuration is completed automatically during the adoption process; administrators reach this section for ongoing governance and for the edge cases where per-sensor overrides are needed.

A third administrative surface, the Access page, is co-located with the two FRD sections in the UI and hosts user, group, and role management. It is covered under (Link Removed) in the chapters that follow.

Who Can Access Administration

The Administration page is gated to administrative roles. Non-administrator users (Security Operations Center (SOC) analysts, hunters, compliance auditors) have no link to it and no Uniform Resource Locator (URL) path into it.

• Super Administrator. Full administrative authority across every Manager section, every sensor, every group, every user, and every integration. Created during installation; at least one Super Administrator account is required for the deployment to function.
• Tenant Administrator. Administrative authority scoped to the tenant's assets — sensors, groups, users, and integrations that the tenant owns. Tenant Administrators cannot configure Manager-global settings that cross tenant boundaries.

The full seven-role matrix (Super Administrator, Tenant Administrator, Group Administrator, SOC Analyst, Security Engineer, Read-Only Analyst, Compliance Auditor) with its page-by-page permission map is documented in (Link Removed).

Audit Trail

Every change made on the Administration page is recorded in an immutable audit log. The log captures the actor, the setting changed, the prior and new values, the timestamp, and a correlation identifier that ties the change to any downstream propagation events. Audit records are tamper-proof, searchable, and exportable; the chapter on (Link Removed) describes the audit viewer and its filters in detail. Configuration changes are also version-controlled at the storage layer so that an earlier state can be reconstructed if a change needs to be reverted. Because every change is confirmed before it is applied, the audit log distinguishes intended changes from accidents — the confirmation dialog is the last gate before the log entry is written.

How Configuration Changes Propagate

The Administration page is the entry point; the underlying configuration pipeline is what actually delivers a change to the Manager process or to a sensor. At a high level the pipeline has three stages: validation, persistence, and broadcast. When an administrator confirms a change, the server validates it against the schema and bounds defined in the product ontology, persists the new value to the configuration store, and broadcasts the change to every service the setting affects. Affected services apply the new value live where possible and report their health back to the configuration store; the UI reflects that health in the status of each setting.

A small subset of settings require a service restart to take effect. Those settings are called out on each form and tabulated in the Manager Configuration chapter. The remainder apply in place within seconds of confirmation.

The step-by-step rules for how a value is validated, how it is propagated, and how health is reported are documented in the dedicated configuration guide. Administrators read that guide when they need to debug a configuration that did not take effect, trace a health-report failure, or understand the precedence rules that apply when a group-level setting and a sensor-level setting disagree.

See Also

• (Link Removed) — the operational view that complements the configuration view, used after a configuration change to confirm services are healthy.
• Manager Configuration — the deep dive on configuration validation, propagation, precedence, and troubleshooting.