Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Remote access enables remote clients such as mobile
users with laptops to connect to the corporate network and access
shared resources. Routing enables traffic on one network to pass to
another. In WS2003, both of these functions are configured using a
single tool: the Routing and Remote Access Server (RRAS) console.
This section covers the different types of remote access supported by
RRAS, including dedicated versus dial-up remote access, Internet
access, and virtual private networking (VPN). It also includes using
RRAS for direct computer connection using a null-modem cable. For an
explanation of client-side remote access, see

Connections earlier in this chapter.

How Remote Access Works

Apart from LAN connections,
which are created automatically by WS2003, and direct computer
connections, which are temporary connections used to transfer files
between two machines, all other forms of connections establish or
provide remote access to computers, networks, or the Internet. Remote
access typically works as follows:

1. A remote access client attempts to connect to a remote access server
   (or remote access device) using a WAN connection such as a dial-up
   connection over a phone line using a modem.

2. The remote access server responds to the connection attempt from the
   client and negotiates a suitable WAN protocol, such as PPP, that both
   the client and server can understand. WAN protocols are discussed
   later in this section.

3. The client uses the WAN protocol to encapsulate the network-level
   data packets (usually IP packets). Typically, both client and server
   need to use the same LAN protocol, unless the server is performing
   LAN protocol conversion in addition to providing remote access to the
   client.

4. The server provides the client with access to its own resources only,
   or it acts as a gateway to allow the client to access resources on
   the server's connected network, depending on how
   remote access is configured on the server.

Implementing Remote Access

To implement remote access, you basically
need to do two things:

• Configure a server to receive inbound connections from remote clients.

• Configure client computers with outbound connections for connecting
  to the server.

In addition, you need to:

• Grant the users of your client computers suitable permission to
  connect to your remote access server. This can be allowed or denied
  on a per-user basis by configuring each user's
  account, but it can also be managed by creating and implementing a
  remote access policy (see

  Remote Access Policies
  later in this section).

• Specify whether the clients can access only resources on the remote
  access server or also resources on the LAN connected to the server
  (gateway function of remote access server).

You can implement the server side of a remote access solution using a
WS2003 computer in two primary ways: standalone and domain-based.
Both types of remote access servers can accept dial-up, demand-dial,
direct cable, or VPN connections from remote clients. You create and
configure connections on WS2003 computers using Network Connections
in the Control Panel; see

Connections earlier in
this chapter for more information.

Remote Access Terminology

Various kinds of protocols are associated with remote access; they
include LAN, WAN, multilink, authentication, and encryption
protocols. The following is a brief summary of the different types
and functions of these protocols.

LAN Protocols

TCP/IP is the default LAN protocol on WS2003, and RRAS
supports remote access to corporate IP networks and the Internet
using TCP/IP over PPP or SLIP. The phrase

TCP/IP over
PPP means TCP/IP is the LAN protocol, PPP is the WAN
protocol, and IP packets are encapsulated into PPP frames in order to
send them over the WAN link between the client and server.

WS2003 also supports remote access connectivity for additional LAN
protocols:

AppleTalk

Supports remote access
connections to
Macintosh file and print servers using the AppleTalk Control Protocol
(ATCP) over dial-up PPP connections.

IPX/SPX

Supports remote access
connections to
legacy NetWare file and print servers using the IPX Control Protocol
(IPXCP) over PPP.

NetBEUI

Supports remote
access connections to NT RAS and legacy LAN Manager servers
configured as NetBIOS gateways. Note that NetBEUI is not available on
WS2003 by default, but a workaround allows it to be installed by
extracting appropriate files from the product CD.

For more information on LAN protocols, see

TCP/IP later in this chapter.

WAN Protocols

Also called remote access
protocols, the following WAN
protocols are supported by WS2003:

PPP (Point-to-Point Protocol)

The most common WAN protocol in use today. PPP
is suitable for establishing WAN connectivity between different
platforms such as Microsoft Windows, Unix, or Macintosh. PPP supports
several methods for authenticating clients (discussed later) and
supports data encryption and compression. WS2003 supports PPP for
both inbound and outbound connections and for any LAN protocol, and
PPP is the standard WAN protocol used in most RRAS implementations.

SLIP (Serial Line Internet Protocol)

A legacy WAN protocol that is not used much
anymore. WS2003 can function as a SLIP client but not as a SLIP
server. WS2003 SLIP clients must use TCP/IP and communicate with SLIP
servers via a serial COM port on the client machine.

Microsoft RAS (Microsoft Remote Access Service)

A legacy WAN protocol used on NT 3.1, Windows
for Workgroups 3.11, MS-DOS, and Microsoft LAN Manager. Microsoft RAS
protocol requires that these clients use NetBEUI. WS2003 supports
both client and server implementation of Microsoft RAS.

ARAP (AppleTalk Remote Access Protocol)

ARAP can be used by Macintosh clients to connect to WS2003
remote access servers. WS2003 doesn't include an
ARAP client.

Multilink Protocols

A multilink connection consists of multiple physical connections
combined into a single logical connection. For example, you could use
multilink to combine two 56 kbps dial-up modem connections into a
single 112 kbps connection to provide increased bandwidth for remote
access. WS2003 supports two protocols for multilink connections:

PPP Multilink (MP)

Allows one or more dial-up PPP connections to be combined into a
single logical connection. PPP Multilink can be used with modems,
ISDN adapters, or X.25 cards to provide additional bandwidth for
these connections.

BAP (Bandwidth Allocation Protocol)

BAP is a dynamic multilink protocol that allows physical links to be
added or dropped as needed. This is particularly useful if
service-carrier charges depend on bandwidth utilization by clients.

WAN Authentication Protocols

WAN connections can use
any of several
authentication protocols to authenticate remote access clients that
are attempting to connect to a remote access server. The
authentication protocols supported by outbound dial-up connections on
WS2003 are (in order of increasing security):

PAP (Password Authentication Protocol)

An older scheme that transmits passwords as clear text.

SPAP (Shiva Password Authentication Protocol)

A variant of PAP developed by the Shiva Corporation that uses two-way
(reversible) encryption for securely transmitting passwords. However,
SPAP doesn't support data encryption, only password
encryption.

CHAP (Challenge Handshake Authentication Protocol)

Uses the secure one-way hashing scheme, Message Digest 5. CHAP lets
the client prove its identity to the server without actually
transmitting the password over the WAN link, so it is more secure
than the reversible scheme used in SPAP.

MS-CHAP (Microsoft Challenge Handshake Authentication Protocol)

A version of CHAP specifically tailored for Microsoft Windows remote
access clients and servers. A newer version, MS-CHAP v2, requires
both the client and the server to prove their identities to each
other before allowing a connection. MS-CHAP v2 is supported only by
WS2003, W2K, NT 4.0, and Windows 98 clients and servers.

In addition to these authentication protocols, WS2003 also supports
Extensible Authentication Protocol (EAP), an extension to PPP that
supports a wide range of additional security mechanisms including
token cards, smart cards, MD5-CHAP, and TLS/SSL.

WS2003 also supports Remote Authentication Dial-in User Service (RADIUS), a client/server authentication protocol widely used by ISPs. RADIUS is implemented on WS2003 using the Internet Authentication Service (IAS) and provides a way of centrally managing user authentication, authorization, and accounting functions.

Table 4-48 summarizes which multilink and
authentication protocols are supported by different Microsoft Windows
dial-up clients.

Encryption Protocols

In addition to the encrypted
authentication protocols described
earlier, WS2003 supports several protocols for encrypting data
transmitted over remote access connections, including:

MPPE (Microsoft Point-to-Point Encryption)

A data encryption scheme that uses a 40-, 56-, or 128-bit RSA RC4
encryption algorithm (depending on export requirements for your
country)

IPSec (Internet Protocol Security)

A scheme that uses a 56 bit DES or 168 bit Triple DES encryption
algorithm

Be aware that data encryption is not supported for the following authentication protocols: PAP, SPAP, and CHAP.

Virtual Private Network (VPN)

WS2003 RRAS allows
you to set
up a VPN that provides secure remote access services to clients
without the need to purchase additional hardware such as modems or
multiport adapters. Instead, a VPN utilizes an Internet connection
such as a DSL connection or T1 line to provide secure remote access
services to clients. VPNs work by encapsulating LAN protocol packets,
such as TCP/IP packets, into PPP frames. These PPP frames are then
transported using a secure VPN protocol, such as PPTP or L2TP, over
the WAN link. A common scenario for implementing a VPN is as follows:

1. Mobile users with laptops running XP Professional have an outbound
   dial-up VPN connection configured on their machines. These users want
   to securely access their company's intranet using an
   insecure Internet connection. From a remote location, a user dials up
   a regional ISP to gain access to the Internet to establish a VPN with
   their corporate intranet.

2. On the company side, a WS2003 system with a dedicated T1 connection
   to the Internet has an inbound VPN connection configured on it. This
   remote access server will use the insecure Internet for servicing
   remote clients, rather than using the traditional remote access
   solutiona modem bank (which typically adds the additional
   expense of leasing a number of additional phone lines for remote
   access purposes, and since our company already has a T1 line anyway
   to provide LAN users with Internet access, then why not make use of
   it for remote access as well?).

3. The client dials up his ISP and connects to the Internet. Once
   connected, the client uses PPTP or L2TP to establish a secure,
   encrypted communications session with the VPN server at corporate
   headquarters. In effect, the client securely becomes part of the
   corporate LAN by tunneling through the insecure Internet between
   them.

VPN connections can even be used within a LAN to provide secure network communications between a VPN client and a VPN server.

Here are the two WAN protocols supported by WS2003 for creating
VPNs:

PPTP (Point-to-Point Tunneling Protocol)

Derived from PPP. It uses PPP encryption for data and works only with
TCP/IP as the underlying network protocol. PPTP is generally viewed
as less secure than L2TP but is easier to implement.

L2TP (Layer 2 Tunneling Protocol)

Derived from the Layer 2 Forwarding (L2F) protocol. L2TP supports
data encryption and tunneled authentication using IPSec and works
with TCP/IP, X.25, Frame Relay, ATM, and other point-to-point,
packet-oriented WAN links (but the WS2003 version supports only
TCP/IP natively). L2TP also supports header compression for more
efficient transfer of data.

Remote Access Policies

A remote access policy is a
collection of conditions and connection settings. Remote access
policies simplify the administrative task of managing remote access
for users and groups in your enterprise. Using remote access
policies, you can:

• Allow or deny remote access depending on the time or day of the week,
  the group membership of the remote user, the type of connection (VPN
  or dial-up), and so on

• Configure remote access settings to specify authentication protocols
  and encryption schemes used by clients, maximum duration of a remote
  access session, etc.

Remote access policies consist of three parts:

Conditions

These are attributes that are compared to the settings of the remote
connection to determine whether the connection attempt should be
allowed or denied. If multiple conditions are specified in the
policy, they must all match the settings of the client or the
connection attempt will be refused. Examples of conditions include
the phone number of the remote access server, date and time
restrictions, domain-based groups the user belongs to, etc.

Remote access permission

If the specified conditions are met, then remote access permission is
either granted or denied, depending on how you configure this setting
in the policy. (By default, this is set to Deny when a new policy is
created.)

Profile

These are settings applied to the connection once it has been
authorized (in other words, once remote access permission has been
verifiednote that

authorization is
different from

authentication , which has to do
with the user's credentials being accepted at the
server end). Profile settings can include maximum session time
allowed, whether Multilink is enabled, types of authentication
protocols and encryption schemes allowed, and so on. These policy
settings must also match the settings of the client, or the
connection attempt will be finally denied.

Remote access policies are configured using the RRAS console. They
are contained within the Remote Access Policies container under the
server node in the console tree. There is a default remote access
policy created when the RRAS is installed on a computer. This policy
is called "Allow access if dial-in permission is
enabled" and specifies that users will be denied
remote access permission by the policy if:

• Their user account has its remote access controlled by remote access
  policies (the default on a native mode, domain-based, or standalone
  WS2003 remote access server).

• Their account logon restrictions allow them to log on anytime (also
  the default).

In other words, the default remote access policy denies remote access
to all users unless a user account explicitly has remote access
allowed for it.

Remote access policies are stored on their associated remote access servers in WS2003 rather than in Active Directory to facilitate application of these policies to client connections without generating additional network traffic.

How Remote Access Policies Work

Let's start by considering how remote access by
users to a remote access server can be explicitly controlled without
using remote access policies. You explicitly allow or deny a user
remote access permission by using the Dial-in tab of the properties
sheet for the user account, using:

• Local Users and Groups in the Computer Management console on a
  standalone WS2003 computer

• Active Directory Users and Groups on a WS2003 domain controller or a
  member server that belongs to a domain

However, if you want to control remote access for users using remote
access policies, then instead of selecting Allow or Deny on the
Dial-in tab for a user, specify that WS2003 should
"Control access through Remote Access
Policy." (This setting is configured by default for
built-in and new users in WS2003 domains configured to run in native
mode and on standalone WS2003 remote access servers.) In this case,
the permissions setting of the policy will determine whether the user
will be allowed to establish a connection with the remote access
server.

If your WS2003 domain is running in mixed mode, you
don't have the option of selecting
"Control access through Remote Access
Policy"this option is grayed out on the user
account's properties sheet. The reason is that
mixed-mode domains may contain both WS2003 and NT domain controllers,
and NT RAS servers don't support remote access
policies. You should convert your domain from mixed mode to native
mode if you want to use remote access policies on domain-based remote
access servers (standalone WS2003 systems do support remote access
policies, however). If you have a domain-based remote access server
running in a mixed-mode domain, you should delete the default remote
access policy if it is present.

By default, all built-in and new user accounts on native-mode,
domain-based, and standalone remote access servers have
"Control access through Remote Access
Policy" selected in their properties (unless their
setting was previously changed from Deny to Allow, in which case it
becomes Deny). On mixed-mode domain-based servers, all built-in and
new user accounts have Deny as their remote access permission.

Remote access policies are used to control connection attempts in the
following way:

1. The remote client (with the user account set to
   "Control access through Remote Access
   Policy") tries to connect to a remote access server
   (here, a domain-based server where the domain is running in native
   mode).

2. The server checks its list of policies:

   • If there is no remote access policy configured, the connection is
     refused.

   • If there is only one policy, all conditions in the policy must match
     the user's connection settings in order to move on
     to Step 3.

   • If there are multiple policies, these are tested in order, one at a
     time, until one matches and you move on to Step 3, or all fail and
     the connection is refused.

3. If a policy whose conditions match the user is found, the server
   checks the remote access permission of the policy. If this is set to
   Deny, then connection is refused; otherwise, move on to Step 4.

4. If remote access permission has been allowed to the user through a
   policy, the server checks the profiles associated with the policy. If
   these profile settings match the user, the connection is established
   and the user connects to the server; otherwise, no other untried
   policies are tried, and the connection is finally refused.