The Routing and Remote Access service in Windows
server 2003 provides routing capabilities that enable the computer to
forward traffic between LANs, whether they are at the same or distant
locations. However, RRAS can also give individual computers at remote
locations access to a network, enabling users on the road or working at
home to connect to network resources. While remote access can be a
tremendous convenience, both to users and to network administrators, it
can also be a serious security hazard. Unless you protect your network
from unauthorized access, any user with a modem and a telephone line can
gain access to your data.
Determining Security Requirements
Before you implement
a remote access solution, you should consider what security measures
are necessary to grant users the access they need while preventing them
from accessing resources for which they lack authorization. To determine
what security measures you should use, you must ask questions like the
following:
Which users require remote access?
In most organizations, not every user needs remote access, and you
should take steps to limit that access to users who need it. You can
specify users who are permitted remote access by authenticating them as
they log on and by using remote access policies to dictate conditions
that users must meet. Do users require different levels of remote access?
Depending on users’ standing in the organization and the resources they
need, you can use permissions to assign different levels of remote
access. Do users need access to the network?
In the case of users whose needs can be met by access to the remote
access server, you can prevent them from accessing the entire network. What applications must users run?
You can limit users to specific applications by creating packet filters
that permit only traffic using specific protocols and port numbers onto
the network.
Controlling Access Using Dial-In Properties
The
most basic method for securing remote access to your network through a
Routing and Remote Access server is to use the properties of the
individual accounts that clients use to connect to the network. When you
display the Properties dialog box for a user account in the Active
Directory Users And Computers console and click the Dial-In tab, you see
the interface shown in Figure 1.
The security-related options in this tab are as follows:
Remote Access Permission (Dial-in Or VPN)
In this group box, you can specify whether the individual user is
allowed or denied remote access, or you can specify that remote access
be controlled by using group memberships, as specified in remote access
policies. Verify Caller ID
This check box option enables you to specify the user’s telephone
number, which the system will verify during the connection process using
caller ID. If the number the user calls from does not match the number
supplied, the system denies the connection. Callback Options This
group box enables you to specify that the user cannot use callback,
that the user sets the callback options, or that the user must use
callback. The callback options cause the Routing and Remote Access
server to break the connection after it authenticates a user and then
dial the user to reconnect. You can use this mechanism to save on long
distance charges by having the remote access calls originate at the
server’s location, but it can also function as a security mechanism if
you select the Always Callback To option and then furnish a specific
callback number in this option’s text box. If you select the Always
Callback To option, the user must be dialing in from the location you
specify to connect to the server.
Planning Authentication
Authentication is the
most basic form of remote access security. Without it, anyone can
connect to your remote access server and gain access to the network. In
addition, many of the other remote access security measures that Windows
Server 2003 provides are keyed off the user’s identity, which is
confirmed by the authentication process.
When you display the
Properties dialog box of a Routing and Remote Access server and select
the Security tab, you can select the authentication protocol you want to
use by clicking Authentication Methods, as shown in Figure 2.
You should base your selection of an authentication protocol on the
amount of security your network needs and the capabilities of your
remote access clients, which must be able to support the same protocol.
|
In
addition to supporting multiple authentication protocols, RRAS enables
you to use the Remote Authentication Dial-In User Service (RADIUS), a
standard defining a service that provides authentication, authorization,
and accounting for remote access installations. RADIUS proxy and server
support is a new feature in Windows Server 2003. You can install and
use the Microsoft Internet Authentication Service (IAS) server for both
RADIUS servers and RADIUS proxies. (You install IAS using Network
Services in the Add/Remove Windows Components tool.)
Connection request
processing determines how the IAS processes a RADIUS request. When you
use an IAS server as a RADIUS server, the server attempts to
authenticate and authorize the connection request. If it determines that
the request’s credentials are authentic, the RADIUS server authorizes
the user’s connection attempt and access, and then logs the remote
access connection as an accounting event. When you use IAS as a RADIUS
proxy, the proxy forwards the connection request to a member of a remote
RADIUS server group for authentication and authorization.
Changing the
Authentication Provider setting in the Security tab in the Routing and
Remote Access server’s Properties dialog box to RADIUS Authentication
activates the Configure button, which enables you to specify the RADIUS
server you want to use for remote access authentication.
One
you have configured a Routing and Remote Access server to use RADIUS,
RRAS transmits all authentication traffic to the RADIUS server for
confirmation. The RADIUS server stores all the user accounts and
passwords, as well as other account information. The real advantage of
RADIUS is that you can run multiple remote access servers and configure
them all to use a single RADIUS server for authentication. This way,
remote users can access any remote access server, and you have to
maintain only a single set of user accounts on the RADIUS server.
Organizations that use RADIUS typically have large remote access
installations, for example, ISPs.
|
The Authentication Methods dialog box, shown in Figure 3,
lists the authentication protocols that Windows Server 2003 RRAS
supports. The characteristics of the authentication protocols are as
follows:
Extensible Authentication Protocol (EAP) An
open-ended system that allows RRAS to use third-party authentication
protocols as well as those supplied with Windows Server 2003. To use
EAP, you select the Extensible Authentication Protocol (EAP) check box
in the Authentication Methods dialog box and then click EAP Methods to
display the EAP Methods dialog box. This dialog box contains a list of
the EAP methods currently installed on the system. EAP is the only
authentication protocol supported by Windows Serve r2003 RRAS that
enables you to use mechanisms other than passwords (such as digital
certificates stored on smart cards) to verify a user’s identity. In
addition to providing the infrastructure to support third-party
authentication mechanisms, Windows Server 2003 RRAS supports the
following EAP types: Extensible Authentication Protocol–Message Digest 5 Challenge Handshake Authentication Protocol (EAP–MD5 CHAP)—
Uses the same authentication mechanism as CHAP (explained later in this
list), but packages the authentication messages in EAP packets Extensible Authentication Protocol–Transport Level Security (EAP–TLS)— Required to authenticate remote access users with smart cards or other security mechanisms based on certificates Protected EAP (PEAP)— A password-based EAP type designed for wireless networks EAP–RADIUS—
Not a true EAP type, but a mechanism that enables the Routing and
Remote Access server to encapsulate EAP authentication messages in the
RADIUS message formation and send them to a RADIUS server
Microsoft Encrypted Authentication Version 2 (MS-CHAP v2)
A password-based authentication protocol that enables the client and
the server to mutually authenticate each other using encrypted
passwords. This makes it all but impossible for potential intruders to
compromise passwords by capturing packets. Microsoft Challenge Handshake
Authentication Protocol Version 2 (MS-CHAP v2) is the simplest and most
secure option to use when your clients are running Microsoft Windows 98
or later. Microsoft Encrypted Authentication (MS-CHAP)
An earlier version of the Microsoft Challenge Handshake Authentication
Protocol (MS-CHAP) that uses oneway authentication and a single
encryption key for transmitted and received messages. The security that
MS-CHAP v1 provides is inferior to that of version 2, but RRAS includes
it as well to support remote access clients running Windows 95 and
Windows NT 3.51, which cannot use MS-CHAP v2. Encrypted Authentication (CHAP)
A standard authentication protocol included in RRAS to support
non-Microsoft remote access clients that cannot use MS-CHAP or EAP. Less
secure than either version of MS-CHAP, Challenge Handshake
Authentication Protocol (CHAP) requires access to users’ passwords, and
by default, Windows Server 2003 does not store the passwords in a form
that CHAP can use. To authenticate users with CHAP, you must open the
group policy governing users and enable the Store Passwords Using
Reversible Encryption password policy. Then you must have every user’s
password reset or changed, so that it is stored in the reversible form
that CHAP can use. Shiva Password Authentication Protocol (SPAP) A relatively insecure authentication protocol designed for use with Shiva remote access products. Unencrypted Password (PAP) A
password-based authentication protocol that transmits passwords in
clear text, leaving them open to interception by packet captures. Some
RRAS administrators use Password Authentication Protocol (PAP) as a
fallback authentication mechanism for clients that support none of the
more secure authentication protocols. Using PAP is better than no
authentication at all, but you should be careful not to use it for
accounts that have administrative access to servers or other resources,
as it can compromise the passwords for these accounts. Allow Remote Systems To Connect Without Authentication
Enables remote access clients to connect to the Routing and Remote
Access server with no authentication at all, enabling anyone to access
the network. The use of this option is strongly discouraged.
Tip You
should understand the differences among these authentication protocols
and how they provide their respective levels of security. |
Using Remote Access Policies
After a
Routing and Remote Access server successfully authenticates remote
access users and verifies their identities, it attempts to authorize the
users. Authorization
is the process of determining whether the server should permit the
connection to proceed. Even though the server might have successfully
authenticated a user, that user must also satisfy a set of conditions
before the server can grant the connection. To specify these conditions,
you create remote access policies in the Routing And Remote Access
console.
Note The
use of remote access policies is limited to the Windows Server 2003
family or to Windows 2000 native-mode domains. Mixed-mode and Windows NT
domains cannot use them. |
Remote access policies
are sets of conditions that users must meet before RRAS authorizes them
to access the server or the network. You can create policies that limit
user access based on group memberships, day and time restrictions, and
many other criteria. Remote access policies can also specify what
authentication protocol and what type of encryption clients must use.
You can also create different policies for different types of
connections, such as dial-up, VPN, and wireless.
Remote Access Policy Components
Remote access policies consist of three elements, as follows:
Conditions
Specific attributes that the policy uses to grant or deny authorization
to a user. A policy can have one or more conditions. If there is more
than one condition, the user must meet all the conditions before the
server can grant access. Some of the conditions that RRAS remote access policies can require clients to meet are as follows: Authentication type— Specifies the authentication protocol that the client must use Day and time restrictions— Specifies the time of day and the day of the week when users must connect Framed protocol— Specifies the data-link layer protocol that the client must be using Tunnel type— Specifies the tunneling protocol that a VPN client must be using to connect to the server Windows groups— Specifies the groups to which the user must belong
Remote access permission
Clients receive permission to access the remote network either by
satisfying the conditions of the Routing and Remote Access server’s
remote policies, or by an administrator explicitly granting them the
permission in the Dial-in tab in each user’s Properties dialog box. Remote access profile
A set of attributes associated with a remote access policy that the
Routing and Remote Access server applies to a client once it has
authenticated and authorized it. The profile can consist of any of the
following elements: Dial-in constraints—
You can use a profile to set limitations to a dial-in connection, such
as a time limit for the duration of the connection, an idle time limit
before the server terminates the connection, and the hours and days when
the client can connect. You can also limit client access to specific
server telephone numbers or specific media types. IP—
You can specify whether the clients or the server should supply the IP
addresses the clients use, or you can specify a static IP address that
the server should assign to the client. You can also create input and
output filters that limit the types of traffic exchanged by the clients
and the server, based on IP addresses, port numbers, or both. Multilink—
Grants the client permission to use the Windows Multilink feature,
which enables the client to combine the bandwidth of multiple modem
connections into a single data pipe. You can also limit the number of
connections you permit a client to use, and you can specify Bandwidth
Allocation Protocol (BAP) settings. Authentication—
Enables you to specify the authentication protocol the client must use
to connect to the server, using the same selection of protocols as in
the Authentication Methods dialog box, described earlier in this lesson. Encryption— Enables you to specify the types of encryption that clients can use when connecting to the server. Advanced— Enables
you to set values for special attributes that RADIUS servers use when
communicating with the Routing and Remote Access server.
Creating Remote Access Policies
To create a remote
access policy, you open the Routing And Remote Access console, expand
the icon for your Routing and Remote Access server, and click the Remote
Access Policies subheading (see Figure 4).
In the details pane is a list of the policies that already exist on the
server. You can modify these policies or add new ones.
Important Before
RRAS can use remote access policies to regulate access to the server by
group membership, you must configure the user’s account by selecting
the Control Access Through Remote Access Policy option button in the
Dial-in tab in the user’s Properties dialog box in the Active Directory
Users And Computers console. |
When you select New
Remote Access Policy from the console’s Action menu, the New Remote
Access Policy Wizard launches and walks you through the steps of
creating the new policy by specifying values for the conditions
described earlier. Once you finish using the wizard, the console adds
the new policy to the bottom of the list in the details pane.
Tip Administrators
can configure remote access policies to either grant or deny user
access based on the specified conditions. In some cases, it is easier to
deny access based on a smaller set of conditions than it is to grant
them based on a larger set. For example, if nine groups should receive
permission to access the network remotely, and one group should be
denied permission, it is easier to grant all users permission by default
and explicitly deny permission to that one group, rather than grant
permission to nine different groups. |
When
multiple policies are listed in the details pane, you can control the
order of the list by clicking a policy and choosing Move Up or Move Down
from the Action menu. The order of the policies is important, because
the RRAS applies them in order to each connection attempt. The logic
sequence for the connection process is as follows:
1. | RRAS
checks the incoming connection against the first remote access policy
in the list. If there are no policies in the list, RRAS rejects the
connection attempt.
| 2. | If
the incoming connection does not satisfy all the conditions in the
first policy, RRAS proceeds to check the connection against the next
policy in the list.
If the incoming connection does not satisfy all the conditions
in any one of the policies in the list, RRAS rejects the connection
attempt.
| 3. | When
the incoming connection does satisfy all the conditions of one of the
policies in the list, RRAS checks the value of the user’s
Ignore-User-Dialin-Properties attribute, which you set in the Advanced
tab of the profile settings for a remote access policy.
| 4. | If
the Ignore-User-Dialin-Properties attribute is set to False, RRAS
checks the remote access permission setting for the user account
attempting to connect.
If the Deny Access option is selected, RRAS rejects the connection attempt.
If the Allow Access option is selected, RRAS applies the user
account and profile properties to the connection. If the connection
attempt does not match the settings of the user account and profile
properties, RRAS rejects the connection attempt. If the connection
attempt matches the settings of the user account and profile properties,
RRAS accepts the connection attempt.
If the Control Access Through Remote Access Policy option is
selected, RRAS checks the remote access permission setting of the
policy. If Deny Access is selected, RRAS rejects the connection attempt.
If Allow Access is selected, RRAS applies the user account and profile
properties, accepting the connection attempt if it matches the user
account and profile properties settings, and rejecting the attempt if it
does not.
| 5. | If the Ignore-User-Dialin-Properties attribute is set to True, RRAS checks the remote access permission setting of the policy.
If Deny Access is selected, RRAS rejects the connection attempt.
If Allow Access is selected, RRAS applies the profile
properties, accepting the connection attempt if it matches the profile
properties settings, and rejecting the attempt if it does not. |
|
