Users and Role Based Access Controls
To add users as an admin:
- Select Settings->Users.
- Under the User Management tab, click on the Add User button in the right corner.
- Enter the essential details of the user, including Name, Username, email, and password. You can enable or disable the login for this particular user. Set Yes to enable the login. Enable the TOTP login for the user to add an extra layer of security.
- Finally, Assign the appropriate role for the user.
- DDI provides six different roles: Super admin, Admin, Operator, Operator⁺, Guest and Auditor. The Admin role has unrestricted access, while the Operator role has limited access, which can be extended by granting specific permissions for each cluster or zone as needed.
- Click Save.
- Provide the Username, Password, and URL for the other users you've added. Make sure they login using the URL from their web browser.
- Once they login they'll be prompted to reset their password and login to the DDI system.
Users with the Operator role do not have permission to configure DHCP failover on the server. Only users with the Admin role can create, update, or delete failover configurations.
Enabling Two-factor authentication for the users
DDI Central enhances user account security by mandating two-factor authentication (2FA) for all users associated with your organization. This additional security layer requires verification through a time-sensitive code generated by a compatible mobile authenticator application. The following steps outline the 2FA process.
- Users need a mobile device capable of running a TOTP-enabled authenticator mobile app.
- DDI Central is compatible with various mobile authenticator apps, including Google Authenticator, Zoho's OneAuth, Authy, and others.
- Install your chosen authenticator app on your smartphone.
- Link DDI Central to the authenticator app either by scanning the QR secret code displayed on the DDI Central login page or by entering the code manually. This is a one-time process.
- On subsequent logins, enter the TOTP displayed in your authenticator app. The OTP adds an extra layer of security and can be generated without an internet connection.
- Upon first accessing DDI Central, all users including the Admin who managed the installation process will need to reset their password.
This two-factor authentication approach ensures that access to your DDI Central account is secure, combining something the user knows (their password) with something they have (a TOTP from the authenticator app).
User permissions
| Admin can | Operator can |
|---|---|
| Create, update, and delete user | - |
| Add, update, and delete zones | Update zone if operator has zone permission |
| Create update and delete cluster | - |
| Giving cluster and zone permission to the operator | - |
| Add, update, and delete servers | - |
| Add SMTP details | - |
| Able to see login and logout details of the user | - |
| Able to see DHCP and DNS audit report | - |
| Reset client credentials | Reset client credentials |
| Enable TOTP for an user | - |
| Delete TOTP device | - |
| Add, update, and delete records in zone | Add, update, and delete records in zone if the operator has zone permission |
| Add, update, and delete named options | Add, update, and delete named options if the operator has cluster permission |
| Add, update and delete dhcp options | Add, update and delete dhcp options if operator has cluster permission |
| Add, update, and delete custom options | Add, update, and delete custom options if the operator has cluster permission |
| Add, update, and delete subnet, shared network, client class, host, host group and vlan | Add, update and delete subnets, shared network, client classes, host, host group and vlan if the operator has cluster permission |
| Add, update and delete supernet | Add, update and delete supernet if operator has cluster permission |
| Add, update, and delete failover configurations | Add, update, and delete failover if the operator has cluster permission |
| Enable, add, update, and delete named views | update named_view if operator has cluster permission |
| Add, update and delete DHCP Zone | Add, update, and delete DHCP Zone if operator has cluster permission |
| Add, update, and delete records in views | Update view if operator has zone permission |
The Superadmin, the first mover, or the first user who installs the product must replace the default email address, "ddiadmin@manageengine.com", with their preferred or official email address under their user profile within the DDI Central app immediately after logging in. This is essential because DDI Central sends notifications only via email. Registering their email address ensures they receive timely notifications.
The Superadmin steps into DDI Central with the default username: "admin" and password "admin" during the installation process. Therefore, it is mandatory for this user to not avoid DDI Central's prompts to reset their password to continue accessing the app.
If TOTP authentication is configured instead of SAML, the TOTP login session is valid for only two minutes. If the login is not attempted within this time, the user must re-enter their login credentials to avoid potential attacks.
When a user has been added and granted an admin role in the application, a small supervisor icon appears next to the username in the User Management section.
Roles in RBAC
Admin
The Admin role has unrestricted access across the network — Admin users can view and manage all DNS and DHCP objects without any scoping or configuration required. Since access is inherently full, there's no separate access control setup for the Admin role; it's granted in full the moment the role is assigned.
Operator
The Operator role grants access at the module level. When configuring cluster permissions for an Operator, you first choose which module the role applies to:
- DNS only
- DHCP only
- DDI — both DNS and DHCP
Once a module is selected, the Operator's access within it is defined by simple resource scoping — either All resources of a type, or a manually selected subset — with no finer access-level control (no View/Manage/Manage & Configure tiers, no per-object type breakdown).
Upon selecting the Operator role, the user's access to the IPAM, Threat Intelligence, and Anomaly Detection dashboards can be allowed or restricted from viewing the insights, by selecting View or Restrict.
DNS Configuration
- DNS Domains — grants access to either All domains, or a specific set selected individually from the domain list.
That's the full extent of DNS scoping for the Operator role — there's no separate control for DNS Views, DNS Records (or individual record types), or DNS Configuration settings the way Operator Plus offers.
DHCP Configuration
- Select Supernets — a multi-select field to scope which supernets the role's subnet access is drawn from.
- Manage Subnets — grants access to either All subnets, or a specific set selected individually.
- Manage Hosts — access is set by one of four scopes:
- All — every host across the cluster
- Assigned Subnets — hosts under the subnets already scoped above
- Assigned Supernets — hosts under the supernets already scoped above
- Restrict — no host access
As with DNS, there's no equivalent here for Multicast Subnets, Static Subnets, Shared Networks, Policies, Client Classes, or DHCP Configuration settings as independently controlled resources — the Operator role's DHCP access is defined entirely through Supernets, Subnets, and Hosts scoping.
Operator⁺
Compared to the standard Operator role, which grants access at the module level only — DNS, DHCP, or both, with no further scoping — the Operator+ role provides object-level control within each module. Access can be granted or restricted for individual domains, subnets, views, policies, and other DNS and DHCP objects, rather than the module as a whole.
Permissions for DNS, DHCP, Analytics, Audit Trails, and Servers are configured independently per cluster. A complete permission configuration can also be saved as a template and reused when provisioning additional users with similar access requirements.
Upon selecting the Operator ⁺ role, the user's access to the IPAM, Threat Intelligence, and Anomaly Detection dashboards can be allowed or restricted from viewing the insights, by selecting View or Restrict.
Access levels
| Level | What it means |
|---|---|
| None | Hidden from the user entirely. |
| View | Read-only. |
| Manage | Create, edit, and update. |
| Manage & Configure | Full control, including delete. |
A few resources use a shorter scale — DNS Configuration, DHCP Configuration, and DNS Records cap at Manage; Analytics and Audit Trails offer only None/View. Servers uses its own four tiers with different labels: None, View, Add & Edit, and Add, Edit & Delete.
Where access can be set to All or Select Specific, choosing Select Specific opens a picker to name exactly which resources the permission applies to.
The +Add Cluster Permissions option takes you to a separate page where you can select the cluster and provide all the access control configuration for specific DNS and DHCP Objects, and analytics permissions.
DNS permissions
- Domains — the top-level control (Restrict / View / Manage / Manage & Configure) sets the overall access ceiling. Once access is granted beyond Restrict, an Applies To scope appears — All or Select Specific — letting you name exactly which domains the permission covers.
- DNS Records — the top-level control here is simpler, just View or Manage, setting the blanket record access level. Below it, each individual record type — A, AAAA, NAPTR, HINFO, HTTPS, and others — gets its own independent Restrict/View toggle, letting you fine-tune visibility per record type beyond the blanket setting. These per-type controls only offer View or Restrict, since editing is governed by the overall DNS Records permission above them, not by type.
- DNS Configuration — covers DNS server settings as a single control, capped at Restrict/View/Manage — no Manage & Configure tier.
- Analytics — Just like the IPAM, Threat and Anomaly Detection, the visibility to the Domain Query Analytics can also be allowed or restricted to specific users.
DHCP permissions
- Supernets — access here is simpler than the other DHCP resources: it's a two-way toggle, Restrict or Assign, used purely to scope which subnets fall under a given supernet for permission purposes, rather than granting direct access levels like View or Manage.
- Subnets — the top-level control (Restrict / View / Manage / Manage & Configure) sets the overall access ceiling. Choosing Manage & Configure unlocks:
- Applies To — All or Select Specific subnets
- Subnet Pool / Range — View or Manage
- Subnet Exclusion — View or Manage
- Subnet Options — View or Manage
So Manage & Configure isn't a single blanket permission — it's the gate that exposes finer, independently-set controls over each part of a subnet's configuration.
- Multicast Subnets — follows the same pattern as Subnets. Setting it to Manage & Configure reveals:
- Applies To — All or Select Specific
- Multicast Range — View or Manage
- Multicast Exclusion Range — View or Manage
- Static Subnets — also a Restrict/View/Manage/Manage & Configure control, but simpler: Manage & Configure only reveals an Applies To (All / Select Specific) scope, with no further sub-permissions underneath.
- Hosts — same top-level scale. At Manage & Configure, the Hosts Apply To scope offers three options instead of two: All, Assigned Subnets, or Assigned Supernets — letting host access follow either the subnets or supernets a user is already scoped to, rather than only an All-or-specific choice.
- Policies & Client Classes — Policies and Client Classes remain independent Restrict/View/Manage/Manage & Configure controls, each scoped to Windows and Linux clusters respectively.
- DHCP Configuration — covers failover, filters, and DHCP options as a single setting, capped at Restrict/View/Manage — no Manage & Configure tier, consistent with the earlier screenshots.
Analytics, Audit & Servers
- Audit Trails — access to the DNS and DHCP audit trails, set independently for each:
- DNS Audit — Restrict or View
- DHCP Audit — Restrict or View
- Servers — controls who can add, edit, or delete servers, using four tiers: Restrict, View, Add & Edit, and Add, Edit & Delete.
Guest
Similar to the Operator role, the Guest role scopes access by cluster type — DNS only, DHCP only, or DDI — with DNS Domains access (All or Select Domains) and DHCP access (Select Supernets, Manage Subnets, Manage Hosts) configured the same way.
The key difference is that Guest access is view-only throughout: the role allows a user to monitor network activity across DNS and DHCP clusters, but not configure settings or policies. This is useful for giving individual users visibility into network services for review purposes, without granting them any ability to make changes.
In addition to cluster permissions, the Guest role includes:
- IPAM Permission — View
- Threat Intelligence Permission — Restrict or View
- Anomaly Detection Permission — Restrict or View
Auditor
The Auditor role enables the user to view only the audits of the networks services in the DNS and DHCP clusters, and they won't have access to view the network activities, and can't configure the settings. This helps in reviewing the actions executed on each of the clusters added in DDI Central.
The Guest role is available in both Professional and Essential editions, whereas the Auditor user role is only available in the Professional edition.
Both these user roles help with the auditing and compliance purposes. Higher officials and supervisors can effortlessly review the network activities and audit logs in the respective DDI clusters, by adding them as Guest or Auditor in the DDI Central application.
Enabling other stakeholders to review prevents errors and misinformation in the network data, and administrators can be alerted for troubleshooting the network error. This also helps provide an all around visibility to other teams like the compliance team to have verification over the network data in case anything is misplaced or missed.
User Audits
The User Audit tab can be accessed by selecting the Audit menu from the left menu bar. The User audit tab helps you monitor your users' login activities by capturing the username, date, and timestamp of the latest login activities.
