Role Networks
Restrict which roles can be used from where.
Administration → Role Networks (/admin/networks), gated on ADMIN.NETWORKS (migration 291).
Overview
A user who holds a role cannot necessarily act under it from every address. Each role carries a rule per network — ALLOW or DENY — and the server checks the request's source address against those rules on every request:
- If the address is in a network the role DENYs, the role is refused.
- Otherwise, if the address is in a network the role ALLOWs, the role is permitted.
- Otherwise the role is refused.
A DENY always wins. And because rule 3 refuses by default, a role with no ALLOW at all cannot be used from anywhere — every new role needs at least one ALLOW rule before anyone can act under it.
The rules decide which role a session may act under, not whether someone can sign in or reach the server. The permissions of a role are unchanged; only where it can be worn changes.
What is seeded
Migration 291 seeded two tiers:
| Roles | Allowed from |
|---|---|
STUDENT, PROXY, FACULTY, ADVISOR, ADMITTED_STUDENT | Anywhere (0.0.0.0/0 and ::/0) |
Every other role — SUPER_ADMIN, REGISTRAR, ACADEMIC_ADMIN and every office role | Campus 10.0.50.0/24, Campus 10.0.75.0/24, Campus 10.0.90.0/24 and ZPA |
The ZPA network was seeded empty
People who connect over Zscaler Private Access do not arrive from their own address: the server sees the ZPA App Connector's address. Those connector addresses were not known when the feature shipped, so ZPA has no ranges yet. Until it does, an administrator working off campus over ZPA has no administrative role once enforcement is switched on. Fill it in from the log-mode warnings (see Rolling it out) before enforcing.
Only roles that had no rules at all were seeded, so re-running the migration never puts back a rule an administrator deliberately removed.
The screen
The page has three tabs, and a banner at the top showing the current enforcement mode and your own address as the server sees it.
Role access
A grid of roles against networks. Set each cell to ALLOW, DENY or nothing, then save the role. A role left with no ALLOW is flagged Unusable: the save is allowed, but nobody can act under that role from anywhere until it has one.
Changes reach signed-in users on their next request — there is no need for anyone to sign out.
Networks
A network is a named set of address ranges in CIDR form. Enter one range per line; a single host is a /32 (a bare address such as 10.0.9.9 is accepted and stored as one). Text after # on a line is kept as a note on that range.
| Field | Notes |
|---|---|
| Name | Unique |
| Description | Optional |
| Ranges | The complete set. A range left out of the list is removed |
| Active | An inactive network matches nothing, so its ALLOW rules stop permitting and its DENY rules stop refusing |
A network that any role's rules still name cannot be deleted — remove it from those roles first. Deleting it out from under them would silently widen or narrow a role.
Test an address
Enter an IP address (or leave it blank to test your own) to see which defined networks contain it, and for every role whether someone at that address could use it and which rule decided:
| Result | Meaning |
|---|---|
| Allowed by network | An ALLOW network contains the address and no DENY does |
| Denied by network | A DENY network contains the address |
| No ALLOW network contains this address | Refused by default |
| Break-glass range | The address is in ROLE_NETWORK_BREAKGLASS_CIDRS; every role is permitted |
Use this before saving a rule you are unsure of, and whenever someone reports being refused.
What users see
When the role a user last chose is not permitted from where they are, nothing about their stored choice is changed. For that request they act under their highest-priority role that is permitted (priority is the Priority field on the Roles screen; lower is higher), and a banner explains that their usual role is not available from this network. When they return to an allowed network, their chosen role comes back by itself.
The role switcher shows unavailable roles disabled, and switching to one is refused.
When none of a user's roles is permitted from their address:
- Signing in is refused, with a message that their role is not available from the network they are connecting from. (A user who holds no roles yet — a first SSO sign-in, whose roles are derived after the session exists — is let in, and the per-request check then applies.)
- An existing session is refused on every request except reading their own account, signing out and ending an impersonation.
Impersonation uses the administrator's address
While impersonating, the roles of the person being impersonated are checked against the administrator's source address. Impersonating a registrar from off campus does not grant registrar access.
Requests with no client address at all — background jobs and the nightly import — are not filtered.
Enforcement mode
The rules only refuse anything when the server runs with ROLE_NETWORK_ENFORCEMENT=enforce. The setting is part of the server's environment, not of this screen; see Environment Configuration.
| Mode | Effect |
|---|---|
off | Rules are ignored entirely |
log (default) | Rules are evaluated, and what would be refused is written to the server log as role_network_would_deny; nothing is refused |
enforce | A role is refused from any address its rules do not permit |
ROLE_NETWORK_BREAKGLASS_CIDRS lists addresses from which every role is usable whatever the rules say — a designated administrator workstation, for example. It exists so that a bad rule edit cannot lock every administrator out for good.
Rolling it out
- Leave the server in
logmode. - Watch the server log for
role_network_would_denywarnings. Each carries the user, the role and the client address. Addresses that belong to the ZPA App Connectors are the ones to add to theZPAnetwork. - Use Test an address to confirm a known administrator's on-campus and ZPA addresses are permitted their roles.
- Set a break-glass range.
- Switch the server to
enforce.
Under enforce, a new role is unusable until it has a rule
Creating a role does not give it any network rule. Add an ALLOW for it here as part of creating it, or nobody will be able to act under it.
What is not carried elsewhere
Network rules are institution policy edited in production. They are not part of a Permission Transfer bundle, and they survive role and permission imports untouched. Every change to a network, a range or a rule is written to the Audit Trail.
The sanitized demo and CI databases replace production's networks with a single Anywhere network that every role ALLOWs, and the demo runs with enforcement off.