With the widespread adoption of remote access and VPN software in almost every organization, Microsoft recognizes the need to provide seamless user authentication for non-Microsoft remote access products that operate within a Microsoft network. Microsoft Internet Authentication Service (IAS) fulfills this need for Windows 2000 and Windows NT 4.0 environments. Through support for Remote Authentication Dial-In User Service (RADIUS), IAS can authenticate users from most remote access platforms, including Cisco Systems' Cisco IOS dial-up and VPN products. Basic IAS configuration offers a variety of implementation possibilities. Let's look at integrating IAS with one popular solution, Cisco's authentication, authorization, and accounting (AAA) framework.

Reviewing RADIUS
Before we dive into IAS, let's review the RADIUS technology. As defined in Internet Engineering Task Force (IETF) Request for Comments (RFC) 2138 and RFC 2139, RADIUS provides a means for a network access server (NAS) to communicate with an authentication server (e.g., Win2K Server with IAS configured). RADIUS also defines the method in which the authentication server receives accounting information. This accounting information includes the connection duration and username, as well as several other pertinent traffic statistics. (This use of the term NAS might be unfamiliar to some readers. Although interchangeable with the term RAS, the term NAS is preferred within the context of RADIUS; as such, I've used NAS wherever possible.)

As defined in RFC 2138 and RFC 2139, the authentication server uses UDP ports 1812 and 1813 to receive authentication and accounting information, respectively; however, some authentication server implementations use pre-RFC UDP ports 1645 and 1646. By default, IAS on Win2K accepts requests on both sets of ports; however, you can configure IAS to use any port to communicate.

Basic NAS-to-authentication server communications are simple. After the NAS receives the username and password from a remote access client, the NAS sends an Access-Request message containing username and password data to the authentication server. The server then checks this account information against its internal database. This database can be structured in any format the server understands, such as a text file, UNIX password file, or the Windows accounts database; in the case of IAS, the IAS server compares the account information against its account database or Active Directory (AD). After the authentication server performs this check, it sends either an Access-Reject or Access-Accept packet to the NAS or it sends an Access-Challenge packet to the NAS to request additional information from the user. You typically use the Access-Challenge packet to implement two-factor authentication schemes that incorporate smart cards or soft tokens. Figure 1 shows a dial-up user's successful authentication attempt.

The NAS and authentication server must both use the same shared key. This shared key is never sent over the network as clear text, and both devices use it to encrypt passwords and authenticate requests and responses. The shared key consists of as many as 255 case-sensitive characters. As with passwords, when you create this shared key, you should include special characters (e.g., non-alphanumeric characters) to increase security.

Discovering the AAA Framework
With an understanding of the RADIUS technology, let's turn our attention to the other part of the equation: the AAA framework. Cisco IOS software provides a feature-rich AAA framework that you can use to authenticate users over RADIUS or the Terminal Access Controller Access Control System Plus (TACACS+) protocol. Outside the context of authentication, AAA can also authorize specific commands for particular users and log commands and accounting information. AAA is very flexible and can control individual router access methods (e.g., Telnet) or all methods (e.g., Telnet, PPP, serial connections).

AAA uses method lists that let you specify multiple protocols or other means for the system to attempt to authenticate a user. Valid list entries include RADIUS, TACACS+, and local usernames and passwords, as well as the router's enable password. When users attempt authentication, AAA tries to apply the first authentication method in the list. AAA attempts the remaining entries in the list if, and only if, the first method ends in an error state. If the authentication method that AAA attempts returns a FAIL message (to indicate a failed authentication attempt), authentication stops. Multiple entries on the method list can facilitate Telnet and console access to a router by using the enable password when the RADIUS or TACACS+ server is unavailable or unreachable.

You apply the method list to a router interface or line. Each interface and line can use a different method list, which lets you use a different authentication protocol or combination of protocols for each access type. If a method list named "default" exists, AAA automatically applies it to all relevant lines or interfaces.

   Prev. page   [1] 2 3 4     next page



You must log on before posting a comment.

If you don't have a username & password, please register now.

Reader Comments

Very useful

leandro.jorge

Article Rating 5 out of 5

It does not address IPSec VPN dial-in. I am having a hard time finding an article that addresses this with IAS (just with other RADIUS servers). I followed a cisco example and still get bad username or password (even when storing in reverse encryption).

robertevanmartin

Article Rating 3 out of 5

No real config examples. Too little Information.

jhenriks

Article Rating 1 out of 5

good introduction to the topic but no specific configuration commands. I am looking for somthing start to finish commands.

claudcutler

Article Rating 2 out of 5

Readers, your suggestions are good ones. We will work on publishing some follow-up articles that provide specific configuration steps as well as the request for information on configuring IPsec VPN.

AnneG_editor

Article Rating 4 out of 5