RADIUS Authentication Process Overview
Applies To: Windows Server 2008, Windows Server 2008 R2
This section contains overview information about the Remote Authentication Dial-In User Service (RADIUS) authentication process, from when a RADIUS client sends an Access-Request message to a RADIUS server to when the RADIUS server sends the Access-Accept or Access-Reject message. In addition, detail about how Network Policy Server (NPS) processes Access-Request messages under different configurations is provided.
In this section
The RADIUS authentication process begins when a user attempts to access a network by using a computer or other device, such as a personal digital assistant (PDA), through a network access server (NAS) that is configured as a RADIUS client to a RADIUS server.
For example, when the user sends credentials by using Challenge Handshake Authentication Protocol (CHAP), the RADIUS client creates a RADIUS Access-Request message containing such attributes as the Port ID the user is accessing and the results of the CHAP authentication process (the user name, the challenge string, and the response of the access client).
The RADIUS Access-Request message is sent from the RADIUS client to the RADIUS server. If a response is not received within a specific length of time, the request is re-sent. The RADIUS client can also be configured to forward requests to an alternate server or servers in the event that the primary server is unreachable. An alternate server can be used either after a specified number of non-responses from the primary server, or the RADIUS client can take turns sending the connection request to both the alternate and primary RADIUS server.
Note
If you are using the Routing and Remote Access service (RRAS), you can add and prioritize multiple RADIUS servers using a scoring mechanism. If a primary RADIUS server does not respond within three seconds, RRAS 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 message is sent from a RADIUS client that is configured on the RADIUS server. If the Access-Request message is sent by a valid RADIUS client, and if the Message-Authenticator attribute is required for the RADIUS client, the value of the Message-Authenticator attribute is verified by using the RADIUS shared secret. If the Message-Authenticator attribute is either missing or contains an incorrect value, the RADIUS message is silently discarded — that is, the message is discarded without logging an event in the Event Log or making an entry in the NPS accounting log. For more information, see Incoming RADIUS Message Validation.
If the RADIUS client is valid, the RADIUS server consults a database of users to find the user whose name matches the User-Name attribute in the connection request. The user account contains a list of requirements that must be met to allow access for the user. This list of requirements can include verification of the password, and it can also specify whether the user is allowed access.
If any condition of authentication or authorization is not met, the RADIUS server sends a RADIUS Access-Reject message in response, indicating that this user request is not valid.
If all conditions are met, the list of configuration settings for the user is placed into a RADIUS Access-Accept message that is sent back to the RADIUS client. These settings include a list of RADIUS attributes and all necessary values to deliver the desired service. For Serial Line Internet Protocol (SLIP) and Point-to-Point Protocol (PPP) service types, this can include values such as encryption types, the Class attribute, Maximum Transmission Unit (MTU), and the desired compression and packet filter identifiers.
For more details about how NPS processes connection requests under different configurations, see Access-Request Message Processing.