RADIUS Authentication Operation
The RADIUS authentication process begins when a remote access user presents authentication information to the RADIUS client. After the RADIUS client has obtained such information, it might authenticate by using RADIUS.
For example, when the remote access user sends their credentials using the Challenge Handshake Authentication Protocol (CHAP), the RADIUS client creates a RADIUS Access-Request packet containing such attributes as the user's name, the user's password, the ID of the client and the Port ID the user is accessing. When a password is present, CHAP encrypts the password using a method based on Rivest-Shamir-Adleman (RSA) Message Digest 5 (MD5).
The RADIUS Access-Request packet is sent to the RADIUS server. If no response is returned within a length of time, the request can be re-sent a number of times. The RADIUS client can also forward requests to an alternate server or servers in the event that the primary server is down or unreachable. An alternate server can be used either after a number of tries to the primary server fail, or in a round-robin fashion.
In the case of Routing and Remote Access service, multiple RADIUS servers can be added and prioritized as authentication providers. If a primary RADIUS server does not respond within a three-second time period, the Routing and Remote Access service automatically switches to the RADIUS server with the next highest score.
After the RADIUS server receives the request, it validates the sending RADIUS client. Validation occurs by verifying that the RADIUS Access-Request packet is sent from a configured RADIUS client. If the Access-Request packet was sent by a valid RADIUS client, and if digital signatures are enabled for the RADIUS client, the digital signature in the packet is checked using the shared secret.
A request from a RADIUS client for which the RADIUS server does not have a shared secret is silently discarded. If the RADIUS client is valid, the RADIUS server consults a database of users to find the user whose name matches the request. The user account contains a list of requirements that must be met to allow access for the user. This can include verification of the password, but can also specify whether the user is allowed access.
If any condition where the authentication or authorization is not met, the RADIUS server sends a RADIUS Access-Reject packet in response, indicating that this user request is invalid.
If all conditions are met, the list of configuration values for the user are placed into a RADIUS Access-Accept packet that is sent back to the RADIUS client. These values include a list of RADIUS attributes and all necessary values to deliver the desired service. For SLIP and PPP service types, this can include values such as IP address, subnet mask, MTU, desired compression, and desired packet filter identifiers.