70-240 in 15 minutes a week: Windows 2000 ICS, NAT and IAS Page 3

Windows 2000 implements a powerful centralized authentication, authorizations and accounting service (often referred to as AAA) in the form of
IAS, its implementation of the Remote Access Dial-in Authentication Service (RADIUS). Used for both dial-in and VPN connections, IAS allows you to control in a more centralized manner the authentication of users, accounting of their connection start and stop times, as well as a way to centralize the application of remote access policies (authorization).

Not installed by default, IAS must be added via Add/Remove programs in Control Panel, as shown below:

Once installed, IAS is accessed using the associated Internet Authentication Services administrative tool.

Many people get confused about the purpose and configuration of IAS, so lets consider the basics. First of all, a big reason for using IAS is to centralize the authentication requests sent to remote access servers. For example, consider an environment that consists of a variety of remote access solutions (these are sometimes referred to as a NAS, or Network Access Server), such as Windows NT RAS, Windows 2000 RRAS, Cisco routers, various VPN and dial-in hardware solutions, and so forth. Maintaining accounts on those various platforms could be difficult, if not impossible. What RADIUS allows you to do is have all requests from the various remote access servers forwarded to the RADIUS server for authentication instead. As such, it is important to remember that a RADIUS client is actually a remote access server. The remote access server has client connections as well, but these are not RADIUS clients. I repeat, a RADIUS client is a remote access server. The remote access server does not authenticate client requests when RADIUS is used; instead it forwards them to the RADIUS server for processing. 

This centralization provides a number of other benefits as well, including the ability to centralize the distribution of remote access policies. Remember that by default, remote access policies are local to the server on which they are created. In instances where you choose to set up a remote access server as a RADIUS client, all remote access policies on the server are ignored in favor of those configured on the RADIUS server. This presents a powerful way to control the application of remote access policy settings, especially in large distributed environments. 

The actual configuration of IAS is quite simple, but there are a few things that you will need to be aware of. For starters, if you want a remote access server to act as a RADIUS client, it must be capable of authenticating to RADIUS. Most vendors add this functionality to their remote access servers, since RADIUS is an industry standard. Windows 2000 RRAS can act as a RADIUS client if correctly configured both in the RRAS settings and IAS setting. In RRAS, the setting are configured from the Security tab in the properties of the RRAS server, as shown below:

By default, an RRAS-based server will authenticate to the
Windows provide, either Active Directory or the local SAM
database, depending on your setup. If RADIUS is chosen,
further configuration is required, including the address
of the server and a shared secret, which will be used
between the RADIUS client and server for authentication
purposes.

Simply configuring the RADIUS client is not enough. The settings
for the RADIUS server must be configured via IAS, as shown
below:

Note the three sections that exist – Clients, Remote Access
Logging, and Remote Access Policies. The Clients sections
will allow you to add remote access server addresses and
the corresponding shared secret that you originally set
up. You will need to do this for each and every remote
access server that you wish to act as a RADIUS client. The
remote access logging pages allows you to configure what
type information you wish log (and the associated format),
as shown below:

Note that by default, nothing is logged, but recommendations are provided.

The last section allows you to configure the centralized remote access policies that I discussed earlier. These policies are configured and work in exactly the same manner as explained in the earlier remote access article.

You should understand that if you want IAS to be able to access a user’s dial-in properties in Active Directory, you must configure it to do so. This is accomplished choosing ‘Register Service in Active Directory’ from the Action menu of the snap-in (if the server is not a member of an AD domain, this option will be grayed out). Note that IAS will authenticate users against Active Directory or the local SAM database, as applicable. Note also that if you want redundant IAS servers, you should configure them similarly, being sure to copy the remote access policies to the second server, while configuring the RADIUS clients appropriately to account for the second server as well.

And there again is another week complete. As I mentioned in earlier articles, it looks at though the series will be completed within only another article or two. The largest determining factor will be the amount of time that I have to dedicate to the articles. If I have a little more time than usual (unlikely), expect one larger article. If my time is a little leaner, you can expect two. The topics left to be covered include Certificate Services as well as IPSec. Thanks to all those who continue to support the series, I as always look forward to your comments and feedback. Remember that all technical questions should be posted to my message board. Until next week, best of luck with your studies.

Dan