Dante Domain Manager Roles and Permissions: Plan Safe Access

TL;DR — Dante Domain Manager access should follow the job, domain, and time window—not convenience. Separate site-wide administration, domain management, media routing, and read-only inspection; give each user the lowest role that completes the task; and test the account in Dante Controller before production. Record who can enroll devices, alter clocking, create subscriptions, or only inspect status. Keep emergency access controlled, review logs after changes, and remove temporary access when the handoff ends.

Access control protects a different boundary than Device Lock

Dante Domain Manager (DDM) authenticates users and controls what they can see or change in managed domains. It can separate organization-wide administration, domain configuration, media control, and read-only observation. A user may have different access in different domains.

This is not the same as Dante Device Lock. Device Lock makes one supported device's configuration read-only with a PIN. DDM roles define authenticated user privileges across managed devices and domains. A production design may use both, but each needs a separate owner and recovery plan.

Role names and privilege labels can vary between DDM releases. Use the roles displayed by the installed version and verify the exact privilege list instead of assuming a title grants a particular action.

Start from four operational responsibilities

Current DDM generations provide preset roles that broadly separate site control, domain control, media control, and read-only access; custom roles may also be available. Older documentation may use administrator, operator, user, or guest terminology. Map the installed labels to actions before writing the handoff.

Do not assign site-wide control to solve a single routing task. Conversely, do not give a guest engineer read-only access and discover at soundcheck that the approved job requires creating subscriptions.

Build an access matrix before adding users

List real tasks rather than job titles. A “systems engineer” at one venue may own enrollment and clocking; at another, that work belongs to IT or the resident integrator.

Turn the matrix into an explicit assignment for each domain. If one user needs media control in the stage domain but only inspection in broadcast, assign those boundaries separately instead of raising the default role everywhere.

Use default roles carefully

A default role can apply to domains that do not have a specific override. That is convenient for a permanent administrator but risky for a contractor or touring account: a newly created domain may inherit more access than intended.

For limited users, prefer explicit per-domain assignments and a conservative default. Confirm what None or equivalent means in the installed version; it may prevent the user from seeing the domain at all, while read-only permits visibility without changes.

Review these inheritance cases:

• a new domain is created after the user account;
• a user moves from one team or venue to another;
• a temporary show domain becomes a permanent system;
• a custom role gains a new privilege;
• an identity-provider group changes membership;
• an old account remains active after the work ends.

Give guest engineers a controlled workflow

1. Define the task and window

State which domains, subscriptions, devices, and show dates are in scope. Decide whether the guest only needs to inspect, needs to route media, or must request house staff for protected changes.

2. Use an individual identity

Create or federate an account that identifies the operator. Avoid a shared “guest” password because it weakens audit evidence and makes revocation ambiguous. Use the organization's password and identity-provider policies.

3. Assign the minimum domain role

Grant only the domains and privileges needed for the agreed task. Keep device enrollment, clocking, firmware, user management, and site configuration with their established owners unless the production plan explicitly transfers them.

4. Test from the actual Controller workstation

Log in to Dante Controller, select each intended domain, and confirm that the account can see the correct devices. Perform a safe test of every required action and confirm that prohibited actions remain unavailable. A role configuration is not accepted until the real client workflow is proven.

5. Close the access window

After the show or vendor task, review the action log, record the accepted state, and remove or reduce temporary access. Do not leave elevated rights in place because the person may return next season.

Separate sensitive changes from routine routing

Changing a subscription is operationally different from enrolling a device, changing clocking, upgrading firmware, or editing user roles. Separate those permissions so routine work cannot silently expand into infrastructure administration.

Use an approved change window for:

• enrolling, unenrolling, or forgetting devices;
• moving a device between domains;
• changing boundary-clock or external-sync settings;
• altering sample rate, latency, redundancy, or network configuration;
• upgrading device firmware;
• creating or modifying roles and authentication settings.

Before any high-impact action, save the known-good routes and device state. The Dante Controller presets guide explains scoped configuration capture and rollback; the firmware update guide covers version and recovery evidence.

Verify audit and emergency recovery

DDM records system events and user actions for monitoring and audit. Confirm the retention, export, time synchronization, and review process used by the organization. A log is useful only when timestamps, identities, domains, and change records can be correlated.

Plan emergency access without turning it into everyday access:

• name the owner of the highest-privilege account;
• store recovery material in controlled credential storage;
• require an incident or maintenance reason for use;
• test recovery before a show-critical event;
• rotate or revoke temporary secrets afterward;
• review every action performed during emergency access.

Do not put passwords, recovery secrets, or Device Lock PINs in a public rider. The rider should identify the credential owner, escalation path, access window, and approved communication channel.

Diagnose permission symptoms before changing roles

Do not solve every access error by assigning the highest role. Identify the exact missing action, confirm that it belongs to the user's job, and grant the narrowest suitable privilege.

Roles-and-permissions checklist

• Every account belongs to an identifiable person or controlled service.
• Each production task maps to a required privilege.
• Domain scope is explicit; default-role inheritance is reviewed.
• Site, domain, media, and read-only responsibilities are separated.
• Temporary users have start, review, and removal conditions.
• The actual Dante Controller login and required actions are tested.
• High-impact changes require an approved window and named owner.
• Audit timestamps and user actions can be matched to the change record.
• Emergency access is controlled, tested, and reviewed after use.
• Secrets stay in credential storage, not public production documents.

FAQ

What are the roles in Dante Domain Manager?

Current versions broadly separate site control, domain control, media control, and read-only access, and may support custom roles. Names differ across releases, so verify the exact privileges shown by the installed DDM.

Can a Dante user have different permissions in different domains?

Yes. A user can be assigned different roles per domain. This lets an engineer control media in one system, inspect another, and have no access to unrelated domains.

Why can a user see Dante devices but not change routes?

The account may have read-only access or lack the media-routing privilege in that domain. Confirm the selected domain and installed role details before changing the assignment.

How should I give a guest engineer access to Dante?

Use an individual account, limit it to the required domain and show window, grant the lowest role that completes the agreed work, test it on the actual Controller workstation, then review logs and remove temporary access.

Does Dante Domain Manager keep an audit log?

DDM records system events and user actions for monitoring and auditing. The organization must still define retention, time synchronization, review, export, and escalation so the records remain useful.

Put access ownership in the production handoff

Record domain scope, role assignments, permitted tasks, protected changes, credential owner, access window, audit review, and escalation in Techrider.live. Invite the house and touring leads to edit the same rider, save the approved access plan, and inspect history when responsibilities change.