To begin, go to your server's 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.
Brien M. Posey is an MCSE and freelance writer.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.
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? 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. 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. 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. 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.
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.