What Is Dial-up Remote Access?
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
What Is Dial-up Remote Access?
In this section
Dial-up Remote Access vs. VPN
Components of a Dial-up Remote Access Connection
Components of Secure Remote Access
Dial-up Remote Access Dependencies
Related Information
Dial-up remote access is a remote access technology that is available as part of Routing and Remote Access that is included in Microsoft Windows Server 2003.
Organizations require a simple solution that allows employees to remotely access their corporate e-mail accounts and shared files from home or from other locations outside the corporate network. Dial-up remote access provides the solution by enabling a remote access client to use the wide area network (WAN) infrastructure to connect to a remote access server.
Dial-up Remote Access vs. VPN
Windows Server 2003 remote access provides two different types of remote access connectivity: dial-up remote access and virtual private network (VPN) remote access.
With dial-up remote access, a remote access client uses the telecommunications infrastructure to create a temporary physical circuit or a virtual circuit to a port on a remote access server. After the physical or virtual circuit is created, the rest of the connection parameters can be negotiated.
With virtual private network remote access, a VPN client uses an IP internetwork to create a virtual point-to-point connection with a remote access server acting as the VPN server. After the virtual point-to-point connection is created, the rest of the connection parameters can be negotiated.
Demand-Dial Routing
Demand-dial routing is not a technology, but a process by which packets are forwarded across a Point-to-Point Protocol (PPP) link. Demand-dial routing is used by remote access technologies—dial-up remote access and VPN, as well as routing technologies—unicast routing, multicast routing, and network address translation (NAT). For more information about demand-dial routing, see “Demand Dial Routing Technical Reference.”
Components of a Dial-up Remote Access Connection
A dial-up remote access connection contains the following components:
Remote access client
Remote access server
WAN infrastructure.
Components of a Dial-up Remote Access Connection
Remote Access Client
Remote access clients running Windows Server 2003, Windows XP, Windows 2000, Windows NT 4.0, Windows Millennium Edition, and Windows 98 can connect to a Windows Server 2003 remote access server. Almost any PPP remote access client, including UNIX and Macintosh, can connect to a Windows Server 2003 remote access server.
Remote Access Server
The Windows Server 2003 remote access server accepts dial-up connections and forwards packets between remote access clients and the network to which the remote access server is attached.
Note
- The term remote access server as it is used in this section refers to a Windows Server 2003 computer running Routing and Remote Access and configured to provide remote access.
Dial-up Equipment and the WAN Infrastructure
The physical or logical connection between the remote access server and the remote access client is facilitated by dial-up equipment installed at the remote access client, the remote access server, and the WAN infrastructure. The nature of the dial-up equipment and WAN infrastructure varies, depending on the type of connection.
The following telecommunications technologies can make up the WAN infrastructure:
Public Switched Telephone Network (PSTN)
Integrated Services Digital Network (ISDN)
X.25
Asynchronous Transfer Mode (ATM) over asymmetric digital subscriber line (ADSL)
PSTN
PSTN, also known as Plain Old Telephone Service (POTS), is the most common network used for dial-up remote access. PSTN is the analog phone system designed to carry the minimum frequencies required to distinguish human voices.
Dial-up equipment consists of an analog modem at the remote access client and at least one analog modem at the remote access server. For large organizations, the remote access server is attached to a modem bank containing up to hundreds of modems. Because PSTN was not designed for data transmission, there are limits to the maximum bit rate of a PSTN connection. The maximum bit rate supported by PSTN connections is 33,600 bits per second or 33.6 kilobits per second (Kbps).
Standard PSTN Connection
Digital Links and V.90
The maximum bit rate of PSTN depends on the range of frequencies being passed by PSTN switches and the signal-to-noise ratio of the connection. The modern-day analog phone system is only analog on the local loop, the set of wires that connect the customer to the central office (CO) PSTN switch. After the analog signal reaches the PSTN switch, it is converted to a digital signal. The analog-to-digital conversion introduces noise on the connection known as quantization noise.
When a remote access server is connected to a CO by using a digital switch based on T-Carrier or ISDN rather than an analog PSTN switch, there is no analog-to-digital conversion when the remote access server sends information to the remote access client. Because there is no quantization noise in the path back to the remote access client, there is a higher signal-to-noise ratio and, therefore, a higher maximum bit rate.
With this technology, called V.90, remote access clients can send data at 33.6 Kbps and receive data at 56 Kbps. In North America, the maximum receive bit rate is 53 Kbps due to Federal Communications Commission (FCC) power rules.
To obtain V.90 speeds, the following must be true:
The remote access client must be using a V.90 modem.
The remote access server must be using a V.90 digital switch and be connected to PSTN using a digital link, such as T-Carrier or ISDN.
There cannot be any analog-to-digital conversions in the path from the remote access server to the remote access client.
PSTN Connection with V.90
ISDN
ISDN is a set of international specifications for a digital replacement of PSTN. ISDN provides a single digital network to handle voice, data, fax, and other services over existing local loop wiring. ISDN behaves like an analog phone line except that it is a digital technology with higher data rates and a much lower connection time. ISDN offers multiple channels, with each channel operating at 64 Kbps. Because the network is digital from end to end, there are no analog-to-digital conversions.
Dial-up equipment consists of an ISDN adapter for the remote access client and the remote access server. Remote access clients typically use Basic Rate ISDN (BRI) with two 64-Kbps channels; large organizations typically use Primary Rate ISDN (PRI) with 23 64-Kbps channels.
ISDN Connection
X.25
X.25 is an international standard for sending data across public packet-switching networks. Windows Server 2003 remote access supports X.25 in the following ways:
The remote access client supports the use of X.25 smart cards, which can connect directly to the X.25 data network and use the X.25 protocol to establish connections and send and receive data. The remote access client also supports dialing into a packet assembler and disassembler (PAD) of an X.25 carrier using an analog modem.
A remote access server only supports direct connections to X.25 networks by using an X.25 smart card.
Note
- X.25 smart cards are adapters that use the X.25 protocol and can directly connect to an X.25 public data network. X.25 smart cards are not related to smart cards used for authentication and secure communications. For more information about smart cards used for authentication, see “IAS Technical Reference.”
X.25 Connection
ATM over ADSL
ATM is a fixed-length, cell-based, packet-switching technology that transmits data across an ATM network. Routing and Remote Access supports PPP connections over switched virtual circuit (SVC) or permanent virtual circuit (PVC) ATM connections. PPP connections over ATM require an ATM adapter with support for the physical connection to the ATM network. After it is installed, the ATM adapter appears as a dial-up device.
ADSL is a local loop technology for small business and residential customers. Although ADSL provides higher bit rates than PSTN and ISDN connections, the bit rate is not the same in the upstream and downstream directions. Typical ADSL connections offer 64 Kbps from the customer and 1.544 megabits per second (Mbps) to the customer. The asymmetric nature of the connection fits well with typical Internet use. Most Internet users receive a lot more information than they send.
ADSL equipment can appear to Windows Server 2003 as either an Ethernet interface or a dial-up interface. When an ADSL adapter appears as an Ethernet interface, the ADSL connection operates in the same way as an Ethernet connection to the Internet.
When an ADSL adapter appears as a dial-up device, ADSL provides a physical connection and the individual local area network (LAN) protocol packets are sent using ATM. An ATM adapter with an ADSL port is installed in both the remote access client and remote access server.
ATM over ADSL Connection
Remote Access Protocols
Windows Server 2003 supports the following remote access protocols:
PPP
SLIP
PPP
PPP is an industry standard method of using point-to-point links to transport multi-protocol datagrams. A PPP-enabled connection can dial into remote networks through any industry-standard PPP server. PPP also permits a remote access server to receive calls from, and provide network access to, other vendors’ remote access software that complies with the PPP standards. For more information about PPP, see “How Dial-up Remote Access Works.” PPP is documented in RFC 1661.
SLIP
Serial Line Internet Protocol (SLIP) is an older remote access standard typically used by UNIX remote access servers. Routing and Remote Access supports SLIP for dial-up connections. Support for SLIP is included in the Windows remote access client to ensure interoperability with other remote access software. For more information about SLIP, see RFC 1055, A Nonstandard for Transmission of IP Datagrams Over Serial Lines: SLIP and RFC 1144, “Compressing TCP/IP Headers for Low-Speed Serial Links.”
Notes
Windows Server 2003 and Microsoft Windows XP do not support SLIP for incoming connections.
You must use the TCP/IP protocol and a serial COM port to connect to a SLIP server.
LAN Protocols
LAN protocols are the protocols used by the remote access client to access resources on the network connected to the remote access server. Windows Server 2003 remote access supports TCP/IP and AppleTalk. For more information about these protocols, see “How Dial-up Remote Access Works.”
Components of Secure Remote Access
Because remote access is designed to transparently connect a remote access client to a network and its potentially sensitive data, the security of remote access connections is an important consideration. Windows Server 2003 remote access offers security features, such as secure user authentication, mutual authentication, data encryption, callback, caller ID, and smart card authentication. For more information about smart card authentication, see “IAS Technical Reference.”
Authentication vs. Authorization
To understand why connection attempts are either accepted or denied, it is important to understand the distinction between authentication and authorization:
Authentication is the verification of the credentials of the connection attempt. This process consists of sending the credentials from the remote access client to the remote access server in either plain text or an encrypted form by using an authentication protocol.
Authorization is the determination that the connection attempt is allowed. Authorization occurs after successful authentication.
To be accepted, the connection attempt must be both authenticated and authorized. It is possible for the connection attempt to be authenticated by using valid credentials, but not authorized. In this case, the connection attempt is denied.
If a remote access server is configured for Windows Authentication, the security features of Windows Server 2003 are used to verify the credentials for authentication, and the dial-in properties of the user account and locally stored remote access policies are used to authorize the connection. If the connection attempt is both authenticated and authorized, the connection attempt is accepted. For more information, see “Remote Access Policies” later in this section.
If the remote access server is configured for Remote Authentication Dial-In User Service (RADIUS) authentication, the credentials of the connection attempt are passed to the RADIUS server for authentication and authorization. If the connection attempt is both authenticated and authorized, the RADIUS server sends an accept message back to the remote access server and the connection attempt is accepted. If the connection attempt is either not authenticated or not authorized, the RADIUS server sends a reject message back to the remote access server and the connection attempt is rejected.
If the RADIUS server is a computer running Internet Authentication Service (IAS), the IAS server performs authentication through selected authentication features and authorization through the dial-in properties of the user account and remote access policies stored on the IAS server.
Secure User Authentication
Secure user authentication is obtained through the encrypted exchange of user credentials. This is possible with the PPP remote access protocol using either the Challenge Handshake Authentication Protocol (CHAP), Shiva Password Authentication Protocol (SPAP), Microsoft Challenge Handshake Authentication Protocol version 1 (MS-CHAP), Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2), or Extensible Authentication Protocol (EAP) authentication protocols. MS-CHAP, MS-CHAP v2, and EAP offer the most security. The remote access server can be configured to require a secure authentication method; if the remote access client cannot perform the required secure authentication, the connection is denied.
For more information about PPP authentication protocols, see “PPP Authentication Protocols” in How Dial-up Remote Access Works.
Secure Authentication Scheme
A secure authentication scheme provides protection against replay attacks, remote access client impersonation, and remote access server impersonation.
A replay attack occurs when a person captures the packets of a successful connection attempt and then replays those packets in an attempt to obtain an authenticated connection.
Remote access client impersonation occurs when a person takes over an existing authenticated connection. The intruder waits until the connection is authenticated and then obtains the connection parameters, disconnects the user, and takes control of the authenticated connection.
Remote server impersonation occurs when a computer appears as the remote access server to the remote access client. The impersonator appears to verify the remote access client credentials and then captures all of the traffic from the remote access client.
Mutual Authentication
Mutual authentication is obtained by authenticating both ends of the connection through the encrypted exchange of user credentials. This is possible with the PPP remote access protocol using either the EAP-Transport Level Security (EAP-TLS) or MS-CHAP v2 authentication protocols. If smart cards are used for remote access authentication, EAP-TLS is the required authentication method. During mutual authentication, the remote access client authenticates itself to the remote access server, and then the remote access server authenticates itself to the remote access client.
For more information about smart card authentication, see “IAS Technical Reference.”
A remote access server does not always request authentication from the remote access client. However, in the case of a Windows Server 2003 remote access client configured for MS-CHAP v2 only or EAP-TLS only, the remote access client will force the mutual authentication of the client and server. If the remote access server does not respond to the authentication request, the connection is terminated by the client.
For more information about EAP-TLS, see “How Dial-up Remote Access Works.”
Data Encryption
Data encryption protects the data sent between the remote access client and the remote access server. Remote access data encryption does not provide end-to-end data encryption. End-to-end encryption is data encryption between the client application and the server that hosts the resource or service being accessed by the client application. If end-to-end encryption is required, use Internet Protocol security (IPSec) to create an encrypted end-to-end connection after the remote access connection has been made.
Note
- IPSec can also be used for encrypting a Layer Two Tunneling Protocol (L2TP) virtual private network connection. For more information, see “VPN Technical Reference.”
Data encryption on a remote access connection is based on a secret encryption key known to the remote access server and remote access client. This shared secret key is generated during the user authentication process.
Data encryption is possible over dial-up remote access links when using the PPP remote access protocol and the EAP-TLS or MS-CHAP authentication protocols.
The remote access server can be configured to require data encryption. The remote access client can be configured to request the following levels of data encryption:
No encryption (the server disconnects if it requires encryption).
Optional encryption (connect even if there is no encryption).
Require encryption (disconnect if the server declines).
Maximum-strength encryption (disconnect if the server declines).
If the remote access client cannot perform the required encryption, the connection attempt is rejected.
Remote access clients and remote access servers running Windows Server 2003, Windows 2000, Windows NT 4.0, Windows 98, and Windows 95 use the Microsoft Point-to-Point Encryption (MPPE) Protocol. MPPE uses the Rivest-Shamir-Adleman (RSA) RC4 stream cipher and either 40-bit, 56-bit, or 128-bit secret keys. MPPE keys are generated from the MS-CHAP and EAP-TLS user authentication process.
Callback
With callback, the remote access server calls the remote access client after the user credentials have been verified. Callback is configured as part of the dial-in properties of the user account. Callback can also be configured on the server to call the remote access client back at a number specified by the user during the time of the call. A traveling user can reduce phone charges by dialing in and having the remote access server call back at the user’s current location. Callback can also be configured to always call the remote access client back at a specific location, which is the secure form of callback.
Caller ID
Caller ID can be used to verify that the incoming call is coming from a specified phone number. Caller ID is configured as part of the dial-in properties of the user account. If the Caller ID number of the incoming connection for that user does not match the configured Caller ID, the connection is denied.
Caller ID requires that the caller’s phone line, the phone system, the remote access server’s phone line, and the Windows Server 2003 driver for the dial-up equipment all support Caller ID. If a Caller ID is configured for a user account and the Caller ID is not being passed from the caller to Routing and Remote Access, then the connection is denied.
Caller ID is a feature designed to provide a higher degree of security for networks that support telecommuters. The disadvantage of configuring Caller ID is that the user can dial in from a single phone line only.
Secure Remote Access and IAS
Internet Authentication Service (IAS) is the Microsoft implementation of a Remote Authentication Dial-In User Service (RADIUS) server and proxy. RADIUS is an industry standard for the client-server protocol. For more information about RADIUS, see RFC 2865, “Remote Authentication Dial-In User Service (RADIUS)” and RFC 2866, “RADIUS Accounting.”
As a RADIUS server, IAS performs centralized connection authentication, authorization, accounting, and auditing (AAAA) for network access types that include dial-up remote access, VPN, wireless, and authenticating switch connections.
Network Access Quarantine Control
IAS Network Access Quarantine Control provides phased network access, which restricts remote clients to quarantine mode until each client is either verified as meeting, or configured according to, organization network access policy. Quarantine control can be applied when:
The user connects directly to a dial-up remote access server on a private network.
The user connects to an Internet Service Provider (ISP) through a modem, and then connects to a private network through a VPN connection over the Internet.
To implement Network Access Quarantine Control, you must use Connection Manager Administration Kit (CMAK), Routing and Remote Access, and additional components that include servers that perform name resolution (such as Domain Name System [DNS] servers), obtain the latest version of the Connection Manager profile, or access instructions and components required to make the remote access client comply with network policies.
For more information about Network Access Quarantine Control, see Network Access Quarantine Control in Windows Server 2003.
Remote Access Policies
In Windows Server 2003, remote access connections are accepted based on the dial-in properties of a user account and remote access policies. A remote access policy is a set of conditions and connection parameters that define the characteristics of the incoming connection and the set of constraints imposed on it. Remote access policies can be used to specify allowed connections conditioned by the time of day and day of the week, the Windows Server 2003 group to which the dial-in user belongs, the type of remote access client (dial-up or VPN), and so on. Remote access policies can be used to impose connection parameters such as maximum session time, idle disconnect time, required secure authentication methods, required encryption, and so on.
For information about how the processing of connection attempts involves remote access policies, see “How Dial-up Remote Access Works.”
With multiple remote access policies, different sets of conditions can be applied to different remote access clients or different requirements can be applied to the same remote access client based on the parameters of the connection attempt. For example, multiple remote access policies can be used to:
Allow or deny connections if the user account belongs to a specified group.
Define different days and times for different user accounts based on group membership.
Configure different authentication methods for dial-up and VPN remote access clients.
Configure different authentication or encryption settings for Point-to-Point Tunneling Protocol (PPTP) or L2TP connections.
Configure different maximum session times for different user accounts based on group membership.
Send network access server-specific RADIUS attributes to a RADIUS client.
When you have multiple Windows Server 2003 remote access or VPN servers and you want all of the servers to use a centralized set of remote access policies to authorize incoming connections, you must configure a computer to run Windows Server 2003 and IAS and then configure each remote access or VPN server as a RADIUS client to the IAS server computer.
For more information about remote access policies, see “IAS Technical Reference.”
Unauthenticated Connections
Windows Server 2003 also supports unauthenticated PPP connections. In an unauthenticated PPP connection, the authentication phase of the PPP connection establishment is skipped. Neither the remote access client nor the remote access server exchange credentials. The use of unauthenticated PPP connections must be carefully considered because connections are allowed without verification of the identity of the remote access client.
There are two common cases in which unauthenticated connections are desired:
When using Automatic Number Identification/Calling Line Identification (ANI/CLI) authentication, the authentication of a connection attempt is based on the phone number of the caller. ANI/CLI service returns the number of the caller to the receiver of the call and is provided by most standard telephone companies.
ANI/CLI authentication is different from caller ID authorization. In caller ID authorization, the caller sends a valid user name and password. The caller ID that is configured for the dial-in property on the user account must match the connection attempt; otherwise, the connection attempt is rejected. In ANI/CLI authentication, a user name and password are not sent.
When using guest authentication, the Guest account is used as the identity of the caller.
Dial-up Remote Access Dependencies
Dial-up remote access requires one of the following operating systems for the remote access server:
Windows 2000 Server
Windows Server 2003
Windows XP (appropriately configured for incoming connections)
Dial-up remote access requires one of the following operating systems for the remote access client:
Windows 98
Windows Millennium Edition
Windows 2000
Windows 2000 Server
Windows XP
Windows Server 2003
Dial-up remote access requires the following protocols and interfaces:
PPP
Either TCP/IP or AppleTalk
Related Information
The following resources contain additional information that is relevant to this section.
RFC 1055, RFC 1144, RFC 1661, RFC 2865, and RFC 2866 in the IETF RFC Database