Why a Group exists on a proxy at all
The upstream RADIUS server — an eduroam federation tier, a peer Organization’s RADIUS — decides who gets in. But the upstream’s Access-Accept might not include the RADIUS attributes your WLAN needs:- A specific VLAN ID your network engineers require for visitors.
- A Security Group Tag to drive ACLs on your campus fabric.
- A tunnel-private-group-ID that’s specific to your network design.
Configuring the Default Device Group
Open the Context's Basic Configuration tab
On the tab, a card refers to the Default Attribute Group —
that’s the same Default Device Group, under its UI label.
Click the Default Device Group link
Lands on the Group detail page. The Group has a Statistics card
(which is mostly empty on a proxy — no user or device
membership is tracked here) and a Settings area.
Attach an Attribute Profile
On Group Settings, attach a Profile from the dropdown. If no
Profile exists yet, create one at Context → Configuration →
Attribute Profiles first. See
Attribute Profiles.
Typical Attribute Profile shapes
- Visitor VLAN. Three tunnel attributes that assign a dedicated guest VLAN to eduroam visitors — common VLAN choices are 800, 900, or a federated-visitor-specific ID. Exactly what you’d do on a Dot1x Group, with the difference being that the upstream federation is the authorization authority.
- SGT for egress ACL. A Cisco AV-pair setting the Security Group Tag that your campus fabric uses to apply egress restrictions. Useful when visitors share physical infrastructure with internal users.
- URL redirect / splash page. A Cisco AV-pair that redirects authenticated visitors to a welcome page. Optional — many eduroam deployments skip this in favour of letting visitors’ own supplicant configurations drive their connection.
Why you don’t manage membership here
The Default Device Group doesn’t have a Users tab, doesn’t carry a Self-Service portal, and doesn’t have a device list. Deliberately:- Users aren’t yours. They’re federation identities; attribution lives upstream.
- Devices aren’t yours. Visiting students’ laptops come and go; EntryPoint doesn’t enrol them.
- Delegation doesn’t apply. Nobody is a “Group Administrator” on eduroam — the federation itself is the authority.
showSelfServiceUsers logic in the UI explicitly
returns false for Radius Proxy Contexts; the Users tab isn’t
rendered. That’s not an oversight — it’s the variant’s shape.
Compared with the Dot1x and iPSK variants
For a quick mental check:| Dot1x (PEAP / EAP-TLS) | iPSK | Radius Proxy | |
|---|---|---|---|
| Number of Groups | Many (one per audience) | Many (one per device class) | Exactly one (Default Device Group) |
| Group membership | Local accounts, Entra mapping, cert lookups | MAC lists | Nothing — the upstream decides |
| Self-Service portal | Yes (PEAP users) | Yes (Group admins + PSK admins + users) | No |
| Attribute Profile attachment | Per Group | Per Group | On the Default Device Group only |
Day-to-day operations
- Edit the Attribute Profile when your VLAN / SGT strategy changes on the campus side.
- Swap the attached Profile if you want to change the VLAN treatment without editing the existing Profile (some Organizations prefer to keep Profiles immutable and swap them at the Group).
- Nothing else. The proxy runs itself; maintenance happens on Remote Radius Server (upstream changes) and on RADIUS clients (your WLAN side).
Related
Attribute Profiles
How Profiles are defined and what attributes they carry.
Remote Radius Server
Where the upstream is configured.
Radius Proxy overview
The variant at a glance.
RADIUS clients
Your WLAN side.