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.
Previous
Register
