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.
Installing IAS
You can install and use IAS on both Win2K Server and NT Server 4.0Âbased systems. For Win2K, IAS comes as part of the core OS; with NT 4.0, IAS is one of several components that ships with the NT 4.0 Option Pack, which you can download from the Microsoft Web site at http://www.microsoft.com/ntserver/nts/downloads/recommended/nt4optpk/default.asp. Although the Option Pack is quite large and includes many applications, IAS installation requires the installation of only the Common Program Files and Internet Service Manager (ISM) 4.0 components. As is the case when you install core components from the NT CD-ROM, you must reinstall the appropriate service pack after you install any Option Pack components.
In Win2K, you need to select IAS as a subcomponent of Networking Services in the Windows Components section of the Control Panel Add/Remove Programs applet. After you install IAS, you use the Microsoft Management Console (MMC) Internet Authentication Service snap-in. The system adds a shortcut to this snap-in (i.e., ias.msc) in the Programs\Administrative Tools folder during installation.
One of the first tasks following the installation of IAS on Win2K is to configure IAS to interact with AD. To do so, select Register Service in Active Directory from the Action menu in the Internet Authentication Service snap-in. By registering IAS with AD, IAS can access user and group information in AD; otherwise, IAS would only be able to verify user and group membership information that the server maintains in its local accounts database.
Performing these steps will register IAS in AD in the default domain. To let IAS access AD information in another domain, simply place the computer account for the IAS server into the RAS and IAS Servers group in the target domain. The RAS and IAS Servers group must have a specific set of permissions in AD. To verify these permissions, launch the MMC Active Directory Users and Computers snap-in, and select Advanced Features from the View menu to view the RAS and IAS Servers Access Check object in the left pane, as Figure 2 shows. Right-click the object, choose Properties from the context menu, then select the Security tab to verify that the RAS and IAS Servers group has Read, Write, Create All Child Objects, and Delete All Child Objects permissions, as Figure 3 shows. If not, configure the permissions to match these settings to permit proper IAS operation.
Configuring IAS to Communicate with a Cisco NAS Device
Before IAS will accept authentication requests from a RADIUS-enabled NAS, you must use the Internet Authentication Service snap-in to define the NAS as a RADIUS client. To define the RADIUS client, right-click the Clients container, then choose New Client. An Add Client dialog box will appear and prompt you for the friendly name and protocol to use for this client (at present, the only protocol option is RADIUS). Enter a friendly name for the NAS, then click Next (the friendly name doesn't have to match the NAS hostname). The system will prompt you for the IP or DNS hostname of the NAS, as Figure 4 shows.
The Shared secret option in Figure 4 lets you enter a shared encryption key for the two-way authentication of the NAS-to-IAS server communication and to encrypt passwords as they traverse the network. You must configure this shared key identically on the IAS server and the NAS.
If your remote access solution requires Challenge Handshake Authentication Protocol (CHAP) support (such as when you require password encryption and have a NAS or remote access clients that don't support Microsoft Challenge Handshake Authentication Protocol—MSCHAP), you must store passwords in a format that the IAS server can decrypt. To properly store the passwords, open the Active Directory Users and Computers snap-in, right-click the domain, select Properties from the context menu, and edit the Default Domain Policy Group Policy under the Group Policy tab. Within this policy, enable the Store password using reversible encryption for all users in the domain option. Alternatively, you can select the user properties Account tab and set Store password using reversible encryption to store passwords on a per-user basis. To facilitate the first-time storage of passwords by using reversible encryption, each user must change his or her password after you select one of these options.
To avoid having to store passwords in reversible encryption, configure the NAS and the remote access policy that I describe a little later to use MSCHAP whenever possible. An extension to RFC 1994, MSCHAP was designed to be compatible with NT and AD, and it doesn't require you to store clear text or reversible encryption user passwords.
Logging and Accounting
IAS can log authentication requests and capture accounting data from the NAS. To view the current log settings or to change the settings, open the Internet Authentication Service snap-in, right-click the Local File item in the Remote Access Logging container, then choose Properties. From this window, select the Log account requests and Log authentication requests check boxes. To capture information from a Cisco NAS, you must add the command
aaa accounting network default start-stop group radius
when you configure the NAS.
After you enable logging, you can select the Local File tab on the Local File properties page to control the creation and format of the IAS log files. From this page, you can specify where the IAS server stores the log files, how often it creates the log files, and what file format it uses to create the log files. I recommend creating log files daily or weekly, depending on the server workload, and storing the log files on a volume separate from the system volume.
Restricting Network Access with Per-User ACLs
Because IAS, the RADIUS protocol, and the AAA framework are all flexible, together they present many configuration possibilities. For these options to function properly, you must include the command
aaa authorization network default group radius
in the NAS configuration. This command tells the router to use and enforce the options that you configured on the authentication server when authenticating users.
The RADIUS protocol includes a vendor-specific attribute (number 26) that permits extensive vendor support. One of the most interesting and useful applications of this extensibility is the implementation of per-user ACLs. Per-user ACLs let you restrict any dial-up or VPN user to a specific subset of network resources at the network layer. For example, you can use this functionality to restrict vendor access to only the equipment for which the vendor is responsible or to ensure that your corporate dial-up connection isn't used for Internet access. Figure 5 illustrates this flexibility by showing how a per-user ACL limits the remote access of one user, Henry, but doesn't interfere with the remote access of another user, Mary.
To incorporate per-user ACLs, IAS leverages remote access policies that apply settings based on AD group information. IAS checks the remote access policy conditions in the order in which the policies are listed in the Internet Authentication Service snap-in; users will use the first policy that applies to them regardless of whether the policy grants or denies remote access. To change the order in which the policies are listed, simply right-click a particular remote access policy, then choose Move up or Move down from the context menu.
To configure per-user ACLs, use the Internet Authentication Service snap-in to create a new remote access policy. Right-click the Remote Access Policies container in the left pane, then choose New. Enter the name of the policy, then click Next. In the next screen that appears, specify the conditions that you want to apply to this policy. For example, by clicking Add and selecting Windows-Groups, you can apply this policy to any group that exists in AD. Note that you can't apply remote access policies directly to individual users. You can, however, place a user in a new group and apply the policy to that group. Although per-user ACLs is a bit of a misnomer in this situation, all Cisco documentation uses that name to refer to this capability.
After you specify the conditions for the new policy, choose Next and select Grant remote access permission in the next screen. Click Edit Profile to open the Edit Profile dialog box, then select the Advanced tab. In the tab's Parameters portion, you'll see the default settings for Point-to-Point Protocol (PPP) connections. Click Add to add the per-user ACLs. In the Add Attribute window, choose Cisco-AV-Pair. The Cisco-AV-Pair option is preconfigured in IAS to use attribute 26 with Cisco's vendor code of 9. In the Multivalued Attribute Information window, click Add to create an ACL entry. To list the ACLs, you must use the following format:
ip:inacl#N=permit <prot> <source> <smask> <destination> <dmask>
where N must increment, prot is the protocol to control, source is the source network, smask is the wildcard mask (or inverse mask), destination is the destination network, and dmask is the wildcard mask. For example
ip:inacl#1=permit ip 192.168.254.0 0.0.0.255 192.168.200.0 0.0.0.255 ip:inacl#2=permit ip 192.168.254.0 0.0.0.255 192.168.201.0 0.0.0.255
permits access to the 192.168.200.0 and 192.168.201.0 networks from dial-up clients given IP addresses from the 192.168.254.0 subnet. Although this example configures an inbound ACL, you can also configure an outbound ACL. Simply replace the inacl keyword with outacl. When you configure any ACL for use with Cisco IOS, it's important to remember that all traffic not explicitly permitted is implicitly denied. After you add all the desired ACL entries, confirm each dialog box to complete the creation of the remote access policy. For more information about basic ACL configuration for Cisco IOS, see http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_c/scprt3/scdacls.htm.
Applying Time-Based Restrictions
After you create and name a new remote access policy, you can set conditions on that policy to control when remote users can connect. From the Conditions dialog box, click Add to add a new condition. From the Select Attribute dialog box, choose Day-And-Time-Restrictions to open the Time of Day Constraints dialog box. Select the time ranges during which remote users can connect. Make sure that you add the Windows-Group or another condition so that your policy will apply only to the users you choose to affect.
Endless Possibilities
IAS and AAA are both flexible tools. When combined correctly as a RADIUS-based authentication server and NAS, they can increase the security and manageability of deployed dial-up and VPN solutions. Although I can't detail all the potential scenarios in this article, I hope this exposure will give you a taste of the many possibilities and help you further leverage IAS and AAA within your network.
