NPS RADIUS Proxy Message Processing

Updated: October 21, 2008

Applies To: Windows Server 2008, Windows Server 2008 R2

This section provides information about how Network Policy Server (NPS) processes an incoming Access-Request message when NPS is configured as a Remote Authentication Dial-In User Service (RADIUS) proxy.

When you configure NPS as a RADIUS proxy, Access-Request messages that the proxy receives from RADIUS clients are forwarded to a remote RADIUS server for processing.

When you map external user accounts to a local Windows user account, authentication is performed remotely and authorization is performed locally. In this process, NPS does the following tasks:

  1. Validates the RADIUS message. The incoming Access-Request message is validated for source IP address, the digital signature, valid attributes, and so on. If the RADIUS message is not valid, an event is logged in the system event log and the RADIUS Access-Request message is discarded. An Access-Reject message is not sent.

  2. Checks for Auto Reject. Auto Reject, also called Ping User-Name for the corresponding registry entry, is used to send an immediate Access-Reject message when the User-Name attribute in the Access-Request message matches the registry entry value.

    Some RADIUS clients (RADIUS proxy servers and network access servers) periodically send artificial authentication and accounting requests, called ping requests, to verify that the NPS server is present on the network. These ping requests include fictional user names and do not represent an actual connection request by a real user or computer. When NPS processes these requests, the event and accounting logs become filled with access reject records, making it difficult to keep track of records for valid connection attempts by real users. When you configure a registry entry for Ping User-Name, NPS matches the registry entry value against the value of the User-Name attribute in ping requests that other servers make. If the registry entry and the user name value match, NPS automatically rejects the request and does not create an event or accounting log entry.

  3. Performs connection request policy evaluation. Connection request policies configured on the NPS server are evaluated to find a policy that matches the parameters of the connection. If a policy is found that matches the connection request, the name of the remote RADIUS server group to which the Access-Request should be forwarded is injected into the message.

    If a matching policy is not found, an Access-Reject message is sent and an event is logged.

  4. Applies realm stripping rules. NPS determines or defines the domain name and the user identity for the Access-Request message. If the User-Name attribute in the Access-Request message is not the Auto Reject name, then the user identity is determined. User identity is the value that NPS uses to identify the user for the purposes of authentication and authorization. Typically, the user identity is the string value of the User-Name RADIUS attribute. If the User-Name attribute is not present, the user identity is set to the Guest account or the account specified by the Default User Identity registry entry.

    NPS can use any RADIUS attribute to identify the user. The RADIUS attribute that NPS uses to identify the user is configurable by setting the User Identity Attribute registry entry.

  5. Determines whether to authenticate locally or forward to a remote RADIUS server group. Based on the realm portion of the user name, the NPS proxy determines whether to forward the message or continue to process it locally.

  6. Checks for authentication plug-ins. Authentication plug-ins are optional components created by using the NPS SDK; each plug-in can return Accept, Reject, or Continue. If an authentication plug-in returns an Accept, the user is authenticated and the account is validated. If the authentication plug-in returns a Reject, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings. If the authentication plug-in returns a Continue, the next plug-in is checked. If there are no more plug-ins, the user still needs to be authenticated.

    The authentication plug-in can also return RADIUS attributes to be included in the Access-Accept message.

  7. Forwards the Access-Request message to a remote RADIUS server group. NPS creates a RADIUS message, which includes the attributes received from the RADIUS client, with the exception of the Proxy-State attribute. NPS forwards the message to the remote RADIUS server group specified in the request. When a valid reply is received from the remote server, attributes from the RADIUS message are merged with the attributes in the request. Attributes returned by the remote RADIUS server are not added if the same attribute has already been added by the connection request policy. In other words, local settings override remote settings.

  8. Maps a remote user account to a local Windows account. If the NPS proxy server is configured to map an external user account to a local Windows account, and if the remote RADIUS server has performed authentication and returned an Access-Accept, mapping of the accounts is performed.

    If mapping is not configured, the NPS proxy proceeds to step 12 in this process, Checks for authorization plug-ins.

  9. Validates user account. Based on the user or computer account determined by means of name cracking, the user account is validated to check whether the account is locked out (which is not the same as remote access account lockout), whether the account is disabled, and whether the user account password has expired. If the user account is not valid, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings.

  10. Performs network policy evaluation. Network policies configured on the NPS server are evaluated to find a policy that matches the parameters of the connection. If a matching policy is not found, an Access-Reject message is sent and an event is logged.

  11. Checks user properties and network policy properties. If the Ignore-User-Dialin-Properties attribute is set to 0, the dial-in properties of the user account and the properties of the matching network policy are evaluated against the parameters of the connection attempt to ensure that the connection attempt is allowed. If the Ignore-User-Dialin-Properties attribute is set to 1, the properties from the matching policy become the set of properties for the connection.

    If the connection attempt is not allowed, an Access-Reject message is sent, and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings.

  12. Checks for authorization plug-ins. Authorization plug-ins are optional components created by using the NPS SDK. Each plug-in can return either Reject or Continue. If an authorization plug-in is installed and it returns a Reject, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the NPS authentication log, depending on the configured logging settings. If the authorization plug-in returns a Continue, the next plug-in is checked. If there are no more plug-ins, the user is authorized.

    An authorization plug-in can also return RADIUS attributes to be included in the Access-Accept message.

  13. Sends an Access-Accept. If the dial-in properties of the user account, the properties of the matching network policy, and the conditions imposed by authorization plug-ins allow the connection attempt, an Access-Accept message is sent back to the NAS. Included with the Access-Accept message is the set of RADIUS attributes for the restrictions on the connection. In addition, an authentication success event is logged in the system event log or the NPS authentication log, depending on the configured logging settings.

Community Additions

ADD
Show: