Programming4us
         
 
 
Windows Server

Windows Server 2003 : Centralizing Authentication and Authorization with Internet Authentication Server - The RADIUS Protocol

5/2/2011 5:50:43 PM

Microsoft's Internet Authentication Service (IAS) supports the RADIUS protocol as defined in RFC 2865, Remote Authentication Dial-in User Service (RADIUS), and RFC 2866, RADIUS Accounting. IAS can interoperate with other RADIUS servers. However, any Microsoft-specific functionality (for example, using the IAS server as a central authority for Remote Access policies) is available only with Microsoft's ISA Server. Knowledge of the RADIUS protocol is necessary to correctly configure and use RADIUS. There are two areas to consider:

  • What RADIUS does (the authentication, authorization, and accounting processes)

  • How RADIUS communicates (RADIUS messages)

1. Authentication, Authorization, and Accounting RADIUS Processes

The RADIUS protocol is the de facto standard for remote user authentication and has been used since the early days of dial-up remote access. The protocol was originally written to provide authentication, authorization, and accounting services for dial-up communications, but it has been adapted to provide these services for use with VPN servers, wireless access points, authenticating Ethernet switches, DSL, and other network access methods. Let's examine the authentication, authorization, and accounting services provided by RADIUS.

1.1. Authentication

Authentication is the process of validating identity. In the RADIUS RFC (RFC 2865, Remote Authentication Dial-in User Service), the authentication process is described as two parts. In the first step, an end user's computer or access client uses the Point-to-Point protocol (PPP) over a dial-up connection to a Network Access Server (NAS). The NAS is often referred to simply as the access server. The NAS does not authenticate the client; instead the NAS acts as a RADIUS client and connects to the RADIUS server. In this second step, a RADIUS authentication request is sent by the NAS to the RADIUS server. The RADIUS server uses a user database to check the user credentials. The user database is traditionally resident on the RADIUS server but does not have to be. A separate device can store the user database and this is the case when IAS is integrated with Active Directory (AD). (IAS uses AD instead of its own local database.) If the client can be authenticated, the RADIUS server returns authorizations, which includes configuration information to the NAS server that authorizes network service for the user. Once network service is approved, the RADIUS server is no longer part of the user's network connection. The authentication request, authorizations, and other RADIUS messages are defined in the RADIUS protocol and use UDP port 1645 for authentication messages and UDP port 1813 for accounting messages. (Older RADIUS ports, 1645 and 1646, may be used by older RADIUS servers.) Figure 10-1 illustrates a successful RADIUS authentication. In the figure, communication is forwarded by the NAS to the RADIUS server, but once authentication has occurred, client communications do not use the RADIUS server.

Don't get confused between the access client (which is the computer used to request a connection to the intranet) and the access server (which can be a RRAS server, a wireless access point, or some other NAS).


Figure 1. When RADIUS is used for authentication, the NAS acts as an intermediary

It is also possible to use a RADIUS proxy to further centralize authentication. In this scenario, the NAS contacts a RADIUS proxy that, in turn, becomes the RADIUS client of another RADIUS server. The final RADIUS server is used for authentication. This is particularly useful when a service provider is used at many remote locations to allow an organization's employees to connect locally, but when the authentication should be done at the organization's central location. Figure 2 illustrates this variation. In the figure, a service provider's RADIUS proxy accepts connection requests from users. The proxy forwards these requests to the RADIUS server located at the organization's headquarters in Atlanta. The Atlanta RADIUS server authenticates the user requests and provides them access to the organization's LAN.

Figure 2. A RADIUS Proxy forwards authentication requests to a RADIUS server

In the Microsoft implementation, an RRAS server becomes the RADIUS client (or NAS) and the IAS server user database (or AD) can be used to store user credentials. A Windows Server 2003 server can also become a RADIUS proxy.

A number of authentication protocols can be specified for remote access authentication to the IAS server. The IAS server, RRAS server, and the computer used by the end user requesting a connection must be configured to use the same protocol(s). Configure the RRAS server to use the approved protocols and configure it to use the RADIUS server as its authentication provider. When a connection request is received, the strongest available authentication selection will be made among those available on the RRAS server.

When EAP is used, the RRAS server does not process the EAP messages , but merely passes them to the RADIUS server for processing. However, the RRAS server must support negotiation of EAP types and the passing of the messages to the RADIUS server.


1.2. Authorization

Authorization specifies what the authenticated user may do. The RADIUS server also evaluates authorization information. Authorization information is stored in a policy that defines criteria that must be met before access is allowed. The criteria can be time of day, phone number used, and so on. As a result of this evaluation, even if a user can successfully be authenticated, he or she may be denied network access, or provided limited access based on other criteria such as the phone number his connection originated from, the type of remote connection (for example, dial-up, VPN, or wireless), and so on. Because RADIUS can evaluate these criteria, it can help administrators use technical controls to enforce security policy. For example, remote employees may be authorized to work from home. To prevent an attacker who obtains an account ID and password from connecting to the network, remote access can be restricted for that account. Only if the connection originates with the correct phone number will the access be authorized.

1.3. Accounting

Accounting records the activities of systems and users. RADIUS collects information on remote access communications with clients, so you can generate reports on network activity for accounting purposes. The RADIUS client uses accounting request messages to provide user logon and logoff as well as other usage information to the RADIUS server (which it stores either in its own local database, or if configured to do so, in a centralized database). These messages, as well as other messages passed by the RADIUS protocol , are described in the following section.

2. RADIUS Messages

To accomplish authentication, authorization, and accounting processes, messages are exchanged between the RADIUS client and the RADIUS server. Table 1 defines these messages.

Table 1. RADIUS messages
MessageSent byIn response toDefinition
Access-RequestRADIUS clientUser request for network accessRequests authentication and authorization for network access
Access-AcceptRADIUS serverAccess-RequestInforms the client that the connection is authenticated and authorized
Access-RejectRADIUS serverAccess-RequestInforms the client that the connection is rejected either because of authentication or authorization failure
Access-ChallengeRADIUS serverAccess-RequestRequests information from the client such as user credentials or other details about the connection
Accounting-RequestRADIUS clientN/AProvides accounting information for an accepted connection
Accounting-ResponseRADIUS serverAccounting-RequestAcknowledges receipt and processes an Accounting-Request message

Each RADIUS message includes a RADIUS header and RADIUS attributes. The RADIUS attributes in the Access-Request messages specify information about the connection attempt such as IP address of the NAS server, the connection protocol, or user information that may be used during the authorization process. The RRAS Remote Access policies define attributes on which authorization is based. Access-Accept messages use the RADIUS attributes that define the type of connection that can be made, as well as any connection constraints and vendor-specific attributes. This information can also be part of the RRAS Remote Access policy.

Dozens of RADIUS attributes are defined in multiple RFCs and Internet drafts.

When a client attempts a connection attempt via RADIUS, the following steps take place:

  1. The client requests a connection to the NAS.

  2. The NAS attempts to negotiate a connection with the client using the most secure protocol first, then the next secure, and so on. For example, if all authentication protocols are approved, the NAS will try them in the following order: EAP, MS-Chap v2, MS-CHAP, CHAP, and PAP.

  3. The authentication request is forwarded by the NAS to the RADIUS server in a RADIUS Access-Request message.

  4. The IAS server sends a RADIUS Access-Challenge message requesting information from the client, and the request is passed to the client by the NAS.

  5. The client returns information to the NAS, and it is forwarded to the IAS server.

  6. The IAS server validates the message. The message is discarded and the connection attempt fails in the following cases:

    1. The digital signatures are enabled and verification fails.

    2. The connection times out.

    3. The IAS server cannot reach its domain controller and, therefore, cannot validate the user's credentials.

  7. If digital signatures are enabled and verification succeeds, the IAS server contacts AD to validate the user's logon credentials.

  8. If the user logon credentials are validated, the connection request is evaluated against the remote access policies and the dial-in properties of the user's account.

  9. If the request matches at least one Remote Access policy and the dial-in properties, the Remote Access properties and profile properties of that policy are evaluated.

  10. If the evaluation authorizes the user, a RADIUS Access-Accept message is returned to the NAS, and the client is authorized to access the remote network.

  11. If the evaluation does not authorize the request, other Remote Access policies will be evaluated in order. If none of them authorizes the connection, the IAS server returns a RADIUS Access-Reject message to the NAS, which disconnects the client.

Now that we understand how the RADIUS protocol operates, let's take a look at how to install and configure IAS.

Other -----------------
- Windows Server 2008 R2 : Optimizing Performance by Server Roles
- Windows Server 2008 : Monitoring System Performance (part 2)
- Windows Server 2008 : Monitoring System Performance (part 1) - Key Elements to Monitor for Bottlenecks
- Windows Server 2008 : Using Capacity-Analysis Tools (part 4) - Other Microsoft Assessment and Planning Tools
- Windows Server 2008 : Using Capacity-Analysis Tools (part 3) - Windows Performance Monitor
- Windows Server 2008: Using Capacity-Analysis Tools (part 2) - Network Monitor
- Windows Server 2008: Using Capacity-Analysis Tools (part 1) - Task Manager
- Windows Server 2008: Defining Capacity Analysis
- Windows Server 2008: Performance and Reliability Monitoring (part 3) - Reports
- Windows Server 2008: Performance and Reliability Monitoring (part 2)
- Windows Server 2008: Performance and Reliability Monitoring (part 1)
- Windows Server 2008: Using Event Viewer for Logging and Debugging (part 3) - Conducting Additional Event Viewer Management Tasks
- Windows Server 2008: Using Event Viewer for Logging and Debugging (part 2)
- Windows Server 2008: Using Event Viewer for Logging and Debugging (part 1)
- Windows Server 2008: Using the Task Manager for Logging and Debugging (part 2)
- Windows Server 2008: Using the Task Manager for Logging and Debugging (part 1)
- Windows Server 2008: Enhancing Replication and WAN Utilization at the Branch Office
- Windows Server 2008: Understanding and Deploying BranchCache (part 3)
- Windows Server 2008: Understanding and Deploying BranchCache (part 2)
- Windows Server 2008: Understanding and Deploying BranchCache (part 1)
 
 
Most View
- Windows Phone 7 : Image and ImageSource
- Using Non-Windows Systems to Access Exchange Server 2007 : Outlook Express
- SQL Azure : Securing Your Data (part 1) - Encryption
- Windows Server 2012 : Backup and Recovery (part 7) - Backing up and recovering your data - Recovering data stored on another server, Recovering the system state
- Exchange Server 2007: Monitor Your Exchange Environment (part 4) - Microsoft Operations Manager (MOM 2005)
- SharePoint 2007 : Add Totals Calculations to the Datasheet View
- SharePoint 2010 : Use the Picture Editing Control in a Page
- Windows Vista : Installing Windows Deployment Services (part 2) - Configuring Windows Deployment Services
- Windows 7 : Understanding User Account Control (part 1) - Elevating Privileges
- BizTalk 2010 Recipes: Business Rules Framework - Creating Facts
Top 10
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 3) - Configuring Recipient Filtering
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 2)
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 1)
- Implementing Edge Services for an Exchange Server 2007 Environment : Installing and Configuring the Edge Transport Server Components
- What's New in SharePoint 2013 (part 7) - BCS
- What's New in SharePoint 2013 (part 6) - SEARCH
- What's New in SharePoint 2013 (part 6) - WEB CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 5) - ENTERPRISE CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 4) - WORKFLOWS
- What's New in SharePoint 2013 (part 3) - REMOTE EVENTS