Skip to main content
Groups are the main policy layer in the RADIUS UI. You attach attributes to a group, then assign users to that group directly or through a realm. This keeps user records simple while giving you a consistent place to manage shared access behavior.

​
Prerequisites

Before you build groups, confirm that:
  • You know the RADIUS attributes your NAS devices expect.
  • The required attributes are available in the attribute picker.
  • You understand whether an attribute belongs in the authentication check or the successful authentication reply.
  • You have at least one user or realm ready for testing.

​
What A Group Contains

A group includes:
  • Group name.
  • Check attributes.
  • Reply attributes.
  • Member users.
  • Metadata.
The group dashboard lets you rename the group inline, edit check and reply attributes, add or remove members, update metadata, and delete the group.

​
Check Attributes

Check attributes are used during authentication. Use them for conditions or values that must be evaluated before the RADIUS server accepts the request. The group dashboard describes check attributes as attributes sent to the RADIUS server during authentication.

​
Reply Attributes

Reply attributes are returned after successful authentication. Use them for values the NAS needs after access is granted, such as session behavior, authorization hints, network policy, or vendor-specific values. The group dashboard describes reply attributes as attributes sent back from the RADIUS server upon successful authentication.

​
Attribute Rows

Each attribute row has:
  • Attribute: selected from the RADIUS attribute dictionary.
  • Operator: limited to the operators allowed for that selected attribute.
  • Value: rendered with the correct input style for the attribute, such as text, number, password, IP address, select option, duration, bandwidth, storage, or URL.
  • Presence: shown when quota-aware behavior is available.
The UI fetches the attribute dictionary and uses it to show descriptions, allowed operators, validation hints, vendor grouping, and value input types. Use the picker rather than typing attribute names from memory. The current dictionary includes 51 attributes across Standard, MikroTik, WISPr, Ubiquiti, Cisco, Aruba, Ruckus, Juniper, Microsoft, and Altostrat System attributes. See Supported Dictionaries for the full vendor breakdown.

​
Presence Modes

Presence controls when an attribute is sent. The UI supports these modes:
ModeWhen the attribute is sent
AlwaysSent regardless of usage or status.
Normal (within quota)Sent only if the user has not reached quota and is not suspended.
Quota exceededSent only when quota has been reached or exceeded.
SuspendedAvailable for policy modeling in the UI. Suspended users are normally rejected before ordinary success reply attributes are returned.
Presence modes are especially useful when you need different reply behavior for normal access and quota exhaustion. For manual suspension, expect the account status to block access rather than grant a normal success reply.

​
Quota Attributes

Quota behavior is configured with System attributes on groups:
  • X-Octet-Quota
  • X-Quota-TTL
  • X-Quota-Reset-After
  • X-Quota-Carry-Over-Cycles
  • X-Quota-Expire-TTL
Quota attributes are group policy, not user-specific policy. During authorization, Altostrat checks whether the user belongs to quota-enabled groups and reads the current quota state. Scheduled quota workers refresh usage from accounting metrics, factor in active top-ups, and can trigger disconnect workflows when a user first exceeds quota. When multiple assigned groups define quota, the lowest quota is used as the effective limit. If no reset schedule is configured, quota calculations default to a monthly period. Top-ups add temporary allowance and cause the exceeded flag to be recalculated.

​
Create A Group

1

Open Groups

Go to Settings, then select Groups.
2

Create the group

Add a group and enter a clear group name.
3

Add check attributes

Add only the authentication-time attributes required for the policy.
4

Add reply attributes

Add the values the NAS should receive after successful authentication.
5

Add metadata

Add operational context when it helps operators understand the group.
6

Assign members

Add users from the group dashboard, from a user detail page, or through a realm.

​
Inheritance

Users inherit attributes from their groups. When you open a user, inherited attributes are displayed with their source group so you can trace policy back to the object that defined it. Realms can also apply groups automatically. If a user authenticates with a username that matches a realm, the selected realm groups are applied in addition to directly assigned user groups. Group reply attributes are merged first, then user-specific reply attributes are applied. User-specific attributes are best for exceptions because they override group values unless the operator is +=, which appends another value for multi-value attributes such as routes.
When a user has multiple groups, review the effective attribute display on the user detail page before assuming the final policy. The UI is the best place to confirm what will be applied for that user.
  • Keep common policy on groups instead of repeating user-specific attributes.
  • Give groups operational names that describe intent, not only implementation details.
  • Use user-specific attributes for exceptions and short-lived overrides.
  • Review inherited attributes on a test user before assigning a group broadly.
  • Use metadata to connect groups to billing, CRM, support, or customer records.
  • Keep quota-exceeded behavior explicit when those users should receive different reply attributes, and document suspension behavior as an access block.
  • Use CoA and PoD when quota exhaustion should disconnect active sessions instead of only changing future reply attributes.