Using Windows 2000 IAS for Remote Access Solutions

Versatile IAS works with Win2K and NT 4.0 RAS servers

Microsoft and many Windows 2000 users seem to view Win2K's Internet Authentication Service (IAS) as suitable for ISPs but not for corporate networks. But you can use IAS on your corporate network as a central configuration point for multiple Win2K RAS servers, as part of a system in which Windows NT 4.0 RAS servers use Win2K remote access policies, and as part of your outsourcing solution.

IAS is Microsoft's implementation of a Remote Authentication Dial-In User Service (RADIUS) server. RADIUS is an industry-standard protocol (based on Internet Engineering Task Force—IETF—Request for Comments—RFC—2138 and RFC 2139) for authenticating, authorizing, and providing accounting information for remote connections. Accounting information is usually unnecessary for corporate networks because network administrators typically don't require detailed information about users who connect to the system, the connection duration, or the services requested. You don't need to use IAS's accounting side if you don't want such information.

Win2K RAS and NT 4.0 RAS servers can perform their own authentication and authorization, or they can off-load this duty to a RADIUS server. A RADIUS server can be a non-Microsoft RADIUS server (which is most likely for ISPs) or a server running Win2K IAS. You can run Win2K IAS on your corporate network to authenticate and authorize remote access clients. (For more information about using RADIUS in Win2K and NT 4.0, see Tao Zhou, "Remote Access Management with RADIUS," June 1999, InstantDoc ID 5377.)

Central Configuration and Control
Win2K's remote access policies give you fine granular control over who connects to the network and under which conditions they connect. After a user connects, remote access policies can also apply specific settings to the connection (e.g., disconnecting idle links may be applicable for Point-to-Point Protocol—PPP—connections in networks with a limited number of modem banks). For example, for users who connect to your network over the Internet, you could enforce Layer Two Tunneling Protocol (L2TP)/IP Security (IPSec) and allow access at any time, but you might accept dial-up connections only during office hours and use lower security settings and no data encryption for those connections.

A benefit of using IAS to authenticate your remote access users is the reporting in the Windows event log. The Windows event log lists the remote access policy in use when a user connects, the username, the addresses or names of the RAS server and remote access client, the type of port (i.e., PPP or VPN) used for the connection, and the authentication type. This log information is a particularly helpful troubleshooting tool when you have multiple remote access policies because discovering which remote access policy is in use for each connection when you're using Win2K RAS can be difficult.

Remote access policies let you consolidate RAS servers because you can apply different settings simultaneously on one server. However, you still might occasionally want to run multiple RAS servers because of your network topology. You should place RAS servers near the resources that users need. For example, placing a RAS server in your IT department wouldn't be an ideal arrangement if remote users need to access other servers that connect to the RAS server over a slow WAN link. To improve speed (and possibly reduce phone charges), you need to place the RAS server on the same remote site and subnet as the resources that users need.

When you have multiple RAS servers dispersed over your network, configuring and maintaining consistent remote access policies is difficult. A centrally located IAS server can help in this situation; the IAS server holds the remote access policies, and you configure each RAS server to defer authentication and authorization to the IAS server. Some traffic will still occur over remote links, but the amount of traffic will be relatively small and will occur only at connection and disconnection time.

When you set up a centrally located IAS server, Win2K RAS servers become RADIUS clients configured to send their authentication requests to the IAS server. The IAS server is responsible for looking up dial-up permissions and applying remote access policies. To enable RAS servers as RADIUS clients, open the Microsoft Management Console (MMC) RRAS snap-in, right-click your server name and select Properties, then click the Security tab, which Figure 1 shows. In the Authentication provider drop-down list, select RADIUS Authentication. This configuration disables remote access policies on the RAS server. Complete this process for each RAS server.

As I mentioned, you probably won't need to use the IAS accounting information. You can disable the accounting function from the server properties Security tab. To do so, in the Accounting provider drop-down list, select None.

Next to both the Authentication provider and Accounting provider drop-down lists are Configure buttons, which bring up the Add RADIUS Server dialog box, which Figure 2 shows, in which you specify the IP addresses (or DNS names) of your IAS servers. You also need to specify the Secret, which is simply a shared password between the RAS server and the IAS server. (You need to complete this process for each RAS server.) The Secret is case sensitive and can include as many as 255 characters. If the passwords don't match, the connection between the RAS server and the IAS server will fail.

Other attributes that you can specify in the Add RADIUS Server dialog box include the timeout value (how long the RAS server will wait for a response from the IAS server), which port the IAS server uses (1812 is the default authentication port), whether digital signatures are used for additional security, and the initial score. The score comes into play when you're specifying multiple RADIUS servers and the RAS server must choose which server to use for authentication; the RAS server chooses the server that has the highest score. Each RADIUS server's score dynamically fluctuates according to the server's responsiveness (i.e., how quickly the server responds to authentication). Although you can set the initial score from 0 to 30, this value will automatically adjust for best performance, as well as fault tolerance.

Using Win2K Remote Access Policies with NT 4.0 RAS Servers
You can configure NT 4.0 RAS servers to use RADIUS authentication; as a result, those servers can use Win2K IAS that you've configured with remote access policies. The NT 4.0 RAS server physically accepts connections from a remote user but off-loads authentication to the IAS server. The IAS server, like a Win2K RAS server in an NT 4.0 domain, can authenticate local users, users in an NT 4.0 SAM domain, or users in Active Directory (AD).

Before you configure NT 4.0 RAS servers to use RADIUS authentication, you need to make sure you have installed on the servers the RRAS Routing Update, which isn't included in any service pack. You can download the RRAS Routing Update from Microsoft's Web site (http://www.microsoft.com/ntserver/nts/downloads/winfeatures/rras/rrasdown.asp). After you install the update, your NT 4.0 RAS administration utility will change appearance and look like Figure 3. (However, if you previously installed the RRAS Routing Update and then reinstall it, you won't see a change in the administration utility's appearance.)

If you're interested only in running RAS (rather than routing), you need to use only Active Connections and Ports in the Routing and RAS Administration utility. Click the Active Connections and Ports icon to see details about remote access client connections.

To configure your NT 4.0 RAS server to use IAS for authentication, go to Control Panel, Network, Services. In the resulting dialog box, double-click Routing and Remote Access Service, which takes you to the Remote Access Setup dialog box. Click the Network button, and you'll see the Network Configuration dialog box, which Figure 4 shows. This dialog box lets you configure RAS properties.

Under Authentication provider, select RADIUS, then click Configure to reach the RADIUS Configuration dialog box. Click Add. In the resulting RADIUS Server dialog box, which Figure 5 shows, you need to provide the IAS server's IP address or DNS name, the Secret (i.e., the shared password), the timeout interval, and the initial score. You can enable and disable authentication and accounting separately and specify the ports that those functions use.

If you are using multiple IAS servers for fault tolerance and load balancing, add the servers one by one in the same way. When you finish, click OK on all dialog boxes. Your NT 4.0 RAS server will now use your IAS servers for authentication, which means your remote access clients will be subject to Win2K remote access policies on the IAS server.

Outsourcing Remote Access Services
You or your enterprise might decide that the cost of outsourcing your remote access service is cheaper than keeping the function inhouse. But you can outsource your remote access service and maintain control of dial-up permissions and connections. In such an outsourced scenario, users connect to a remote access server (i.e., network access server—NAS) at your company's ISP, which routes the connection to your corporate network. In the process, the ISP can also enforce a tunneled connection to help secure transferred data and monitor and restrict which applications use the service (e.g., allow access to designated servers only, deny traffic other than FTP or a similar service).

However, the ISP needs to authenticate and authorize the remote access user before allowing the user access to the corporate network. To perform this function, the ISP needs to have a list of user accounts and know which accounts have remote access permission. This information exists on your AD network or in your NT 4.0 SAM database, and you can provide the ISP with access to the information by configuring IAS to communicate with the ISP's NAS. To provide this access, you must configure your firewall to let authentication traffic from the ISP through to your IAS server and define the ports that this traffic will use. Ask your ISP which ports it will use for RADIUS authentication to send traffic to your network; the ports are likely to be UDP 1645 (which NT 4.0 servers use) or UDP port 1812 (which Win2K RRAS servers use). By default, Win2K IAS listens on both ports. If the ISP doesn't use either of those ports, you need to specify an alternative in the firewall and in IAS.

When you're configuring IAS to accept traffic from the ISP, you need to accommodate ping requests and realm names. Ping requests ensure that a RADIUS server (in this case, your IAS server) is available. For example, your ISP will periodically send ping requests to the IAS server with deliberately fictitious names that are intended for rejection (i.e., they will bounce). A bounced request signals to the ISP that the IAS server is online. No response signals an inoperative server or connectivity problem.

Such bounces can unnecessarily stress the IAS server and domain controller (DC) and fill up error log files. To reduce this stress on the IAS server and DC, agree in advance with your ISP on the name that the ISP will use for ping requests. You can then configure your IAS server's registry so that the server sends back an immediate rejection (i.e., Auto Reject) when it receives a ping message with the name you and your ISP have agreed on. Immediate rejection means that the server doesn't pass the ping request on to the DC for authentication, which will fail. Thus, the rejection creates less stress on IAS and the DC. To accomplish this registry change, you need to add a new REG_SZ value called Ping User-Name under the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesIASParameters registry subkey. Set the string to be the same as the username you have agreed to use for ping requests.

ISPs can use realms to group and route users. A realm name can be a prefix (e.g., CompanyName/) or a suffix (e.g., @company.com) added to the username. When an ISP assigns a realm name to a remote user, this value will pass to your IAS server as part of the user authentication. Because Microsoft authentication doesn't use realms, the realm name must be removed (i.e., stripped) from the username before the authentication request reaches the AD or the SAM. Realm stripping creates a standard Microsoft authentication request. To configure realm stripping, open the IAS server's Properties dialog box and select the Realms tab. Click Add to build a list of Find and Replace rules that the system executes in sequential order. To look for and remove a specific realm name, specify the name in the Find text box and leave the Replace text box empty. For the complete list of the pattern-matching syntax, use the online Help and search the topic Pattern matching syntax, which provides several examples.

Configuring Win2K IAS
If IAS isn't installed on your system, you need to add IAS to your Win2K server as a Networking Service. You can add IAS by going to Control Panel, Add/Remove Programs, Add/Remove Windows Components. Select Networking Services, click Details, and select Internet Authentication Service. Click OK, then click Next to finish the Windows Components Wizard. Then, select Internet Authentication Service from Administrative Tools. You'll see options for Clients, Remote Access Logging, and Remote Access Policies.

If IAS runs within an AD environment on your system, you need to register IAS with AD so that IAS has access to user accounts. To register IAS, right-click Internet Authentication Service (Local) in the MMC Internet Authentication Service snap-in and select Register Service in Active Directory. If IAS is running outside AD, Register Service in Active Directory will be shaded and you don't need to register it.

The next step is to define the remote access policies you want to use. If you've installed IAS on the same server as your RRAS service, which has preconfigured remote access policies, these policies will automatically import and you'll see them under the Remote Access Policies in the Internet Authentication Service snap-in. If IAS isn't on the same server as your RRAS service, you need to configure your remote access policies from scratch or use the scripting tool Netsh to import them from an existing Win2K RRAS server. After you configure remote access policies, open the server Properties dialog box and determine whether you need to configure any server properties (e.g., ports to listen on, realm stripping).

To configure the IAS server's clients—which are either the RAS server or your ISP's NAS—right-click Clients in the Internet Authentication Service snap-in, then select New Client. This action brings up the Add Client dialog box, where you need to specify a Friendly name (i.e., the name you'll see on the Internet Authentication Service snap-in). Then click Next to bring up the Add RADIUS Client dialog box, which Figure 6 shows.

In this dialog box, you specify the IP address or DNS name of your RAS server (or ISP's NAS), specify the Secret, and select whether you want to use signatures for greater security. You can ignore the Client-Vendor drop-down list unless you use the special Client-Vendor attribute in your remote access policy. If you want to use Client-Vendor attributes and your IAS client is a Microsoft RAS server, you must change IAS's default RADIUS Standard setting in the Client-Vendor drop-down list to Microsoft. If you want to use Client-Vendor attributes and your IAS client is a NAS, check with the NAS's administrator about which value to use. The Client-Vendor drop-down list contains several vendor implementations, including 3Com, Cisco Systems, Eicon Networks, Shiva, and US Robotics. If you're in doubt about which setting to use, stay with the RADIUS Standard default setting.

You can add as many clients as you have RAS (or NAS) servers. Figure 7 shows an example of IAS configured for two RAS servers. After you define your clients, right-click a client's icon to rename or delete the client or edit its properties. You won't see any indication in the Internet Authentication Service snap-in that the clients are connected, and you won't find an update or refresh option, either.

If you're using multiple IAS servers for fault tolerance, you need to configure the servers identically with the same client details, server details, and remote access policies. The Netsh scripting tool can help you accomplish this identical configuration by exporting settings from one server to a file on a 3.5" disk, from which other IAS servers can import the settings. To use Netsh, type

netsh aaaa show config >A:IAS.txt

from a command prompt on the configured IAS server. This command transfers the output to a file. Then, insert the 3.5" disk with the file on an unconfigured IAS server. From a command prompt on the unconfigured server, type

netsh exec a:IAS.txt

This command executes the saved configuration. A confirmation message will inform you that the server configuration succeeded. Open the Internet Authentication Service snap-in to confirm that the settings imported correctly.

You're now ready to go with your central authentication for remote access clients, whether the authentication is for multiple Win2K RAS servers, NT 4.0 RAS servers, or an ISP's network access server.