Infoblox DDI Security: Secure Grid Admin, APIs and DNS Firewall

An Infoblox Grid holds the DNS, DHCP and IP address data that every other system depends on, so its admin groups, API access and DNS firewall policy carry enterprise-wide reach. This guide explains how to secure Infoblox NIOS Grids and the Infoblox Portal cloud services (Universal DDI and Infoblox Threat Defense) from the customer side. It covers the NIOS admin group and permission model, the authentication policy and remote directories, allowed interfaces for GUI, API and CLI, Grid security properties, Response Policy Zones (RPZ) and threat feeds, Portal user and service API keys, access policies, logging and a phased hardening rollout. It is written for DDI administrators, network security engineers and identity teams. For the discipline as a whole see the DNS Security Guide; this page goes deeper on Infoblox settings.

This is an independent guide from NHI Mgmt Group, based on Infoblox's public documentation as of November 2026. It is not sponsored or reviewed by Infoblox. Product features change, so confirm settings against Infoblox's current documentation.

Key takeaways

• Deny is the starting point. In NIOS, Deny is the default permission for every resource, so limited-access admin groups see only what you grant with Read-Only or Read/Write, globally or per object.
• Keep superusers few and named. Superusers in admin-group have unlimited access; keep the required local admin account for break-glass use when remote directories are unreachable, and give everyone else limited-access groups.
• Limit how each group connects. Allowed interfaces (GUI, API, CLI) are set per admin group, and Restrict GUI/API Access limits the source addresses for all of them; turn on Redirect HTTP to HTTPS (off by default).
• Treat API keys as identities. In the Infoblox Portal, give each integration its own service user with a named service API key, use the 14-day expiry reminders to rotate, and check LAST USED AT for unexpected activity.
• RPZ is both a control and a signal. Response Policy Zones block or redirect known-bad names, and their syslog hits, mapped to threat severity, are some of the best DNS detections you can feed to the SOC.

How identity and access work in Infoblox DDI

NIOS authorises every administrator through admin groups. A group is either a superuser group, with unlimited access, or a limited-access group whose members hold permissions on specific resources. Infoblox documents three permission levels:

Permissions can be global (all objects of a resource type) or object-level, scoped to a Grid member, DNS zone, Response Policy Zone, network or resource record. Child objects inherit from parents, and a more specific setting overrides, so a fixed address can be Read-Only inside a Read/Write network. Permission categories cover Grid, IPAM, DHCP, DNS, File Distribution, Reporting, Administration, GLB, DHCP Fingerprint, Named ACL, Cloud and Super Host. Permissions can be placed in admin roles and roles assigned to groups; the factory default roles, such as DHCP Admin, cannot be edited, so build custom roles when you need a different shape. Grid Manager warns when permissions overlap and shows which one it applies.

Authentication policy

The authentication policy lists the services NIOS checks, in order, under "Authenticate users against these services in this order". Local Admin is the default service and cannot be modified or deleted; RADIUS, Active Directory and TACACS+ can be added and reordered, and the documentation also describes LDAP, SAML and OCSP-based certificate options for remote admins. Remote users are mapped to the first matching local group in "Map the remote admin group to the local group in this order", and "Assign User to this Group if Remote Admin Group cannot be found" sets a fallback group. Point that fallback at a read-only or empty group, never a writable one, so that a directory change cannot silently grant write access.

For Active Directory, Infoblox strongly recommends setting Encryption to SSL, which moves authentication to port 636 and needs the AD server's CA certificate uploaded under CA Certificates (port 389 is the unencrypted default). "Connect through Management Interface" keeps admin authentication on the MGMT port. Group names must match exactly between NIOS and the domain controller. Use your directory's MFA (through RADIUS, SAML or your identity provider) for named administrators; see the Phishing-Resistant MFA Guide.

Infoblox Portal (Universal DDI and Threat Defense)

In the Infoblox Portal, permissions come from access policies under System, Administration, User Access, Access Policy. Each policy joins a user group, a role and an access view; the documentation lists DDI IPAM Manager, Operator, Auditor and User roles for access views in the current release. Start teams on the Auditor or User role and promote only where change rights are needed.

Admin roles and privileged access

A workable NIOS role model separates the Grid platform from the data it serves:

Allowed interfaces are set per group: GUI (Grid Manager), CLI and API (WAPI and PAPI), plus Cloud API options when Cloud Network Automation is licensed. Superusers can use the console, GUI and API; limited-access groups can use GUI, API or CLI but not the console, and for them CLI rights can be granted by command group or individual command. Clear CLI for every group that does not need it, and clear GUI for automation groups so an API credential cannot be used interactively.

The local superuser admin must always exist so an administrator can log in if RADIUS, AD, TACACS+, LDAP or OCSP responders are unreachable. Give it a long random password held in your PAM vault, test it each quarter and alert on every use. Do not create groups that reuse reserved names such as admin-group, and remember that cloud-api-only appears when cloud licences are present and carries full authority over delegated objects.

Integrations, API tokens and service accounts

• NIOS WAPI and PAPI: integrations such as IPAM automation, configuration management and ticketing authenticate as NIOS admins. Create one admin account per integration in an API-only limited-access group, grant object permissions only on what it manages, add its source address to Restrict GUI/API Access, and keep its password in a secrets manager. See the Service Account Security Guide.
• Portal service API keys: service users are accounts for applications and cannot sign in to the Portal. Each can hold up to 10 service API keys. Creating service users needs the Administrator role or a custom role with User Manage, and creating keys needs Service API Keys Create, so keep those rights with the identity team. Infoblox's own guidance is a separate service user per purpose, clear names and access views, checking LAST USED AT, rotating inside the 14-day reminder window and deleting keys you no longer need.
• Portal user API keys: any user who can sign in can create an Interactive key for themselves. Keys show STATE (Enabled, Disabled, Expired), EXPIRES AT and LAST USED AT, and the ID column shows only the first 32 characters. Infoblox notes Legacy keys are slated for deprecation and documents migrating them to service API keys. Our recommendation: allow Interactive keys for short-lived personal use only, and move every scheduled job to a service key.
• Threat feed transfers: an RPZ feed reaches Grid secondaries by zone transfer from an external primary that Infoblox provides, and Infoblox recommends a TSIG key, using the algorithm its feed documentation specifies. Store that key like any other shared secret.

For the full lifecycle of these credentials, see the API Key Management Guide.

DNS firewall with Response Policy Zones

RPZs let recursive Grid members rewrite answers for known-bad domains. Infoblox threat intelligence feeds are a subscription delivered by zone transfer to at least one Grid secondary, and the Grid name server or DNS view must be recursive. Each feed has a threat severity (Critical, Major, Warning or Informational; Major by default). Policy overrides decide what clients receive:

Rollout: add a feed in Log Only, review hits for two weeks (our recommendation), add a local Passthru zone for business-critical false positives, then switch to blocking. Use Substitute with a sinkhole you monitor, so infected hosts can be identified. For the wider design see the Protective DNS Guide.

Logging and detection

NIOS records administrator actions in its audit log (the admin group documentation notes that actions and commands by non-superusers can be tracked in audit.log), and RPZ matches go to syslog with severity mapped to threat level, from 8 (Critical) down to 4 (Informational). In the Portal, API key records show CREATED BY, UPDATED BY and LAST USED AT. Forward NIOS syslog and audit data to your SIEM, and add DNS query and response logging where volume allows. See the DNS Logging and Detection Guide.

Metrics that show the controls are working:

• Number of named superusers (target: a small, reviewed list) and local admin logins per quarter.
• Percentage of admin groups with only the interfaces they need.
• Percentage of integrations using a dedicated service user or API-only admin account.
• Service API keys within their expiry window, rotated on time, and keys with no use in 90 days deleted.
• RPZ blocks per week that lead to an endpoint investigation.

Hardening baseline

These Grid security properties are documented in the NIOS admin guide. Apply them in order and test each on a lab Grid or during a change window, since several end the current session.

1. Restrict GUI/API Access: list admin subnets and integration hosts. The appliance ignores requests from other sources, and adding an address other than your own ends your session on save, so include your own address first.
2. Redirect HTTP to HTTPS: turn it on (off by default). It restarts the application.
3. Session Timeout: the default is 600 seconds; keep it at or below that for administrators.
4. Password security: set the minimum length for local admin passwords (our starting point is 14 or more), and rely on the directory's policy for remote admins.
5. SSH access: Enable Remote Console Access (SSH v2) and Enable Support Access are off by default; keep them off unless needed, use "Restrict Remote Console and Support Access to the MGMT Port" when you turn them on, and turn Support Access off after each support case. "Permanently Disable Remote Console and Support Access" cannot be reversed, even by a factory reset, so use it only after deliberate review.
6. Authentication: move named admins to RADIUS, AD over SSL, TACACS+ or SAML with MFA; set the remote group fallback to a read-only group.
7. Admin groups: rebuild groups on the role model above, clearing unused interfaces.
8. DNS controls: sign zones with DNSSEC where you are authoritative (see the DNSSEC Deployment Guide), restrict zone transfers and recursion with Named ACLs, and deploy RPZ as above.
9. Updates: apply vendor security updates promptly through Infoblox's support channels and track Grid member versions.

Rollback: take a Grid backup before each phase. If an access list locks out administrators, recover from the console or MGMT port. Make permission changes on a new group first, move one test user, confirm, then move the rest.

Small and large estates: a single-site Grid gains most from steps 1, 2, 5 and 6. Large, multi-region Grids should add per-member DNS and DHCP permissions, a role catalogue reviewed each quarter, centralised syslog, a feed per threat category and an owner for every service user.

Framework mapping

Common misconfigurations

• Everyone in the superuser group: convenient during deployment and rarely undone. Move day-to-day work into limited-access groups.
• Remote group fallback set to a writable group: a user whose directory groups do not match lands with write access. Point the fallback at a read-only group.
• Automation accounts with GUI and CLI enabled: an API credential that also opens Grid Manager widens its use. Allow API only.
• Restrict GUI/API Access left empty: the management interface answers any reachable source. List admin and integration networks.
• One shared Portal key across tools: rotation breaks everything at once and LAST USED AT cannot tell tools apart. Use a service user per purpose.
• Feeds switched straight to block: false positives erode trust in RPZ. Start in Log Only and add a Passthru zone.

Practitioner checklist

• List all superusers, confirm each is named and needed, and vault the local admin password.
• Rebuild limited-access groups on Deny by default with object-level RW and RO.
• Set allowed interfaces per group and API-only for every integration account.
• Populate Restrict GUI/API Access and turn on Redirect HTTP to HTTPS.
• Keep SSH console and support access off unless needed, and on the MGMT port when used.
• Use AD over SSL, RADIUS, TACACS+ or SAML with MFA, and a read-only fallback group.
• Create a Portal service user per integration, rotate keys inside the 14-day window and delete unused keys.
• Deploy RPZ feeds in Log Only first, then block, with a Passthru zone and monitored sinkhole.
• Forward audit and RPZ syslog to the SIEM and alert on local admin use and permission changes.

Standards and references

• Infoblox: NIOS administrative permissions
• Infoblox: NIOS superuser admin groups
• Infoblox: Defining the Authentication Policy
• Infoblox: Managing Security Operations
• Infoblox: Response Policy Zone feeds
• Infoblox: Configuring Service API Keys
• Infoblox: Configuring User API Keys
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: DNS Security Guide · Protective DNS Guide · DNS Logging and Detection Guide · API Key Management Guide · Privileged Access Management Guide