RADIUS Authentication Packet Processing

This article gives an explanation of how ClearBox Server processes RADIUS authentication request packets. Read more about authentication and authorization concepts, RADIUS concepts.

First, server finds User-Name attribute in the request packet. If it is found, it's treated as actual user name. If it's not present, then EAP-Message attribute is looked for. If it is in the request packet and has EAP/Identity response, then this identity is treated as user name.

Then server checks if user name matches "auto-reject" user name (is set by Server Manager in server configuration and is used to track server's state), and if they are equal, user is rejected without any further packet processing.

Next, server tries to make custom packet processing if IRADIUSProcessor interface is supported by server extension. If interface is not implemented, this step is skipped.

Not only authentication packet can be custom-processed when they are received on the RADIUS authentication port. It depends on result returned by IRADIUSProcessor::CanProcessPacket. If extension can process packet with the type specified in the packet, IRADIUSProcessor::ProcessPacket is called. If extension decides that packet processing is done, it may return response packet, which is sent back to client immediately. If no packet is returned, next step is performed. Response packet MUST be returned for non-authentication request packets (that have non-standard types).

Original user name from the request packet is stored now for later use.

Next, "packet history" is checked. This means that this packet may be a response to a previously issued Challenge-Response packet. If the packet is first Access-Request packet in the authentication session or EAP/Identity response was received, realm stripping is performed if IRADIUSRealmStripping interface is supported by server extension:

First IRADIUSRealmStripping::RADIUSRealmStrip is called.
- If it returns an error or nameOK parameter is set to VARIANT_FALSE, user is rejected immediately.
- If packet proxy-forwarding is disabled ("Enable RADIUS proxy" server configuration parameter is switched off) and forwardPacket was set to VARIANT_TRUE, it's forced to be VARIANT_FALSE.
- If user name is empty after realm stripping and there's no EAP-Message attribute in the request packet, user is rejected immediately.

If server extension instructs server to forward packet after call to IRADIUSRealmStripping::RADIUSRealmStrip (forwardPacket parameter was set to VARIANT_TRUE) , RADIUS proxy manager is started (it is server configuration parameter), "Enable RADIUS proxy" option is on and no loop is detected in chain of servers that has forwarded the packet, it is passed to RADIUS proxy manager, terminating authentication process. (See RADIUS Packet Forwarding.)

If user name is empty at this point:

- If this is the first Access-Request in the authentication session and there's EAP-Start message in the packet, then EAP/Identity request is issued in order to request user name. The packet processing terminates and Challenge-Response packet is sent back to the NAS.
- Otherwise user is rejected as his name is unknown and it was not defined nor by IRADIUSRealmStripping::RADIUSRealmStrip nor by expected EAP/Identity response. Authentication process terminates.

RADIUS authentication is performed then. If user has passed authentication, RADIUS authorization is performed.

If user was accepted, user name was changed (original user name stored earlier is compared with the new user name returned by IRADIUSRealmStripping::RADIUSRealmStrip) and this method instructed server to return changed name, new user name is included in response accept packet.

Finally, IRADIUSProcessor::PostProcessPacket is called if IRADIUSProcessor is implemented. It may make any changes to the packet formed by server.