A rchive Date
[ 27-03-2001 ]
Category
[ Information Technologies ]
sub-Categoy
[ Microsoft ]
|
[Implement RRAS wisely
Brien M. Posey, ZDNet Business & Technology
March 8, 2001 12:06 PM ET
Windows 2000's Routing and Remote Access Services (RRAS) allows remote users to connect through a traditional dial-up connection as well as a virtual private network. In this article, I'll discuss how you can begin implementing RRAS on your network.
You have to enable RRAS before you can start using it. Begin by selecting Routing and Remote Access from your server's Administrative Tools menu to start the Routing and Remote Access Console. Navigate through the console tree to Routing and Remote Access › your server. Right-click on your server and select the Configure and Enable Routing and Remote Access command from the resulting context menu. Windows launches the Routing and Remote Access Server Setup Wizard. Skip the introductory screen and you'll be presented with several choices of roles that your RRAS server can perform, including acting as an Internet Connection Server, a Remote Access Server, a VPN Server, or a Network Router. Since we're configuring the server as a remote access server, select the Remote Access Server radio button.
The next screen asks if the server is set to use all the protocols the remote access clients require. If your clients require a protocol that isn't listed, you can add it now.
You're then asked how you want the RRAS services to assign IP addresses to remote clients. If you have a functional DHCP server online, it can assign IP addresses to remote clients in the same way it assigns addresses to local users. If you don't have a DHCP server, or prefer not to use it for remote clients, you can manually enter an IP address range for remote client use.
The following screen asks if you want to configure RRAS to use a RADIUS server to collect information about remote connections. RADIUS, which stands for Remote Access Dial In User Service, is used by ISPs that don't use Windows servers. Most of the RRAS implementations I've seen don't use a RADIUS server, but there's no reason not to use RADIUS if you're comfortable supporting it.
When you're done with this screen, the Wizard is finished and your RRAS server is installed.
Remote access policies
Though the service may be running, RRAS requires you to establish a remote access policy before users can dial in.
If you navigate through the RRAS console to Routing and Remote Access › your server › Remote Access Policies, you'll see that the console contains a default policy called Allow Access If Dial-In Permission Is Enabled. This default policy functions similarly to Windows NT dial-up security. In essence, if you've granted dial-up permissions to an individual user, this policy allows the user to dial in.
While such a policy scheme may seem redundant, it provides a framework you can modify to make more restrictive rules. For example, you could limit a user to dialing in only during certain times of the day.
Regardless of the restrictions imposed by a policy, a user won't be allowed to dial in unless you give him permission to do so. Only then does the policy go into effect.
There are a couple of ways to allow users to dial in. As with Windows NT, the most obvious method of granting dial-up access is directly through user accounts. To grant access to a user, open the Active Directory Users and Computers console and double-click on the user you want to grant access to. When you do, you'll see the user's properties sheet. Select the Dial-in tab and you'll see the dial-up options that are available on a per-user basis. From this tab you can allow or deny dial-up access, set Windows to require a callback or to verify the user's caller ID information, or assign a specific IP address or a static route to the user.
Unless you're assigning dial-up access to a small group of people, granting permissions on a per-user basis is a bad administrative practice. As with almost every other security permission in Windows 2000, it's better to assign dial-up privileges on a group basis than on an individual basis because it's easier to manage one group rather than dozens of users.
However, if you look at a group's properties sheet you won't see a place where you can establish dial-up permissions on a group basis. You have to go through the list of users and grant dial-up access to each user.
Once you've modified all the users, create a group for the users you want to give dial-up access to, then go back into the Routing and Remote Access Console. Using the console, replace the default policy with a policy named Accept If Member of Selected Groups and add your desired groups to this policy.
Now you can go back and modify the default policy. Right-click on the policy and select the Properties command from the context menu. Notice that the context menu contains a Delete command you can use if you decide to get rid of the default policy and start from scratch. You can use the Add, Remove, and Edit buttons to change the policy's conditions. You can set the policy to restrict users by conditions such as the time of day, the phone number the user dialed into, the phone number the user called from, the groups the user belongs to, and a wide variety of other factors.
You can use the console's Grant Remote Access Permissions and Deny Remote Access Permissions radio buttons to permit or deny dial-up access based on the conditions you've set. For example, suppose you set the policy to check to see if the user is a member of the RAS group. You can use the radio buttons to set Windows 2000 to either allow members of this group to dial in to the server, or to block members of the RAS group from dialing in to the server.
At this point RRAS will work, but to make the server secure you must define some server-level RRAS settings, such as which protocols are allowed and what type of encryption is required for RRAS sessions.
Administrative Tools menu and open the Routing and Remote Access console. Navigate through the console tree to Routing and Remote Access › your server › Remote Access Policies. When you do, you'll see the policy you created in Part 1 in the column on the right. Double-click on the policy and you'll see the policy's properties sheet, which contains the settings you established in Part 1. You can gain tighter access control over your RRAS server with this sheet.
Start securing your RRAS server by implementing day and time restrictions. Select Day And Time Restrictions Match from the Specify The Conditions To Match list and click Edit. If you don't have this option, you can add it to the list by clicking the Add button, Selecting Day And Time Restrictions from the list, and clicking the OK button.
You should now see a dialog box containing a calendar. You can use this calendar to block out days or hours when you want to prohibit login access through the RRAS server. For example, if your users don't need to log in after business hours, there's no reason to permit access at 3 a.m. Unnecessary 24-hour access is an open invitation for an off-hours break in.
Years ago, dial-in restrictions were an all-or-nothing situation, but you don't have this limitation with Windows 2000. You can grant all-hours access to a limited group of people by creating separate dial-in policies. One policy should grant access based on a group name and contain those users who need 24-hour access. The other policy should also allow access on a group basis, but should be configured to allow access only during business hours.
Now that you've implemented security based on login time, let's move on to more advanced protection. Click the Edit Profile button in your policy's properties sheet to set a variety of advanced RRAS security settings.
Dial-in constraints
By default, when you open this properties sheet, the Dial-In Constraints tab is selected. At the top of this tab you can limit users' maximum connection times and tell the program to disconnect users if their sessions are idle for a specified length of time. If you want to set different options for different groups, simply create multiple policies.
Beneath the dial-in and idle time restrictions is a section you can use to limit the days and times when users are allowed to login. This section works identically to the time restrictions I discussed above. At the bottom of the tab are options to restrict dial-in based on a phone number or dial-in media. Restricting by phone number allows you to point all users through a common number, leaving the administrative phone line free for your use.
I strongly recommend allowing RRAS access only to dial-in users. You can even go so far as to restrict access to asynchronous (modem) connections, thus preventing strangers from exploiting possible weaknesses in your RRAS server through an Internet connection. I've never heard of someone going through the Internet and exploiting RRAS to gain access to a server, but why take chances?
IP
Another tab on each profile's property sheet lets you restrict access based on users' network addresses. The first option on the IP tab dictates where the client's IP address must come from. You can mandate that the server supply the IP address via DHCP, or you can allow clients to supply their own IP addresses.
The IP Packet Filters section lets you dictate the types of IP traffic flowing between the client and the server in both directions. For example, you can allow the server to send certain types of IP packets to a client, but not allow a client to send that type of packet to the server. You'll probably want to block just about every type of packet other than what's typically used. Doing this adds capabilities similar to a firewall to your RRAS server.
Click on the From Client or To Client buttons to display a dialog box that allows you to specify the filters you want to use. I recommend restricting IP traffic on the From Client side to prevent clients from exploiting IP security holes.
Multilink
The next tab, Multilink, refers to Multilink Protocol, which lets users attach to a dial-up server simultaneously through multiple phone lines. By doubling the number of phone lines and modems, users can nearly double their bandwidth. Depending upon your business needs and resources, you may or may not want to allow Multilink.
Multilink allows users to be more efficient by increasing their bandwidth, but your organization may not be able to spare the extra phone lines required by a Multilink session.
If you decide to allow Multilink, you can use the Multilink tab to restrict the number of phone lines users can consume during their session, and force callers to use Multilink sessions effectively. Consider the case of a user who logs in using three phone lines only to run a low-bandwidth application. You can set Windows 2000 to disconnect a multilinked phone line if it's not being used much. The default setting is to disconnect a phone line if it's running below 50 percent capacity for at least two minutes.
Authentication
One of the nicest security features included in Windows 2000 Remote Access Services is found on the Authentication tab. Here you can choose to allow unencrypted authentication (PAP or SPAP), encrypted authentication (CHAP), Microsoft encrypted authentication (MS-CHAP), and Microsoft encrypted authentication version 2 (MS-CHAP v2). You can also use Extensible Authentication Protocol, which requires a smart card for the authentication process. Unauthenticated PPP access is available, but allowing it opens your server to unnecessary security risks.
Encryption
The Encryption tab contains three check boxes that let you choose which encryption levels to allow through an RRAS session. You can choose No Encryption, Basic, and Strong. Levels are 56-bit and 128-bit, unless you're using an international version in which case only 40-bit is available. For dial-up connections, MPPE encryption is used.
Advanced
Finally, the Advanced tab lets you specify which (if any) RADIUS attributes you want to be returned to the Remote Access Services. As I explained in Part 1, RADIUS servers are typically used to authenticate remote logins in non-Microsoft environments. Unless you've got a RADIUS server in your organization, you'll probably never have to use the Advanced tab.
Once you've finished setting your security attributes, your users can start accessing your Windows 2000 servers remotely.]
Cross-Indexed:
|
|