Section 6.3: Connecting to RRAS

In Windows Server 2003 RAS, remote access clients are either connected to the remote access server's resources or to the RAS server's resources and the resources in the network to which the remote access server is attached. The latter type of connection type allows remote access clients to access resources as if they were physically attached to the network. A Windows Server 2003 remote access server provides two remote access connection methods:

• Dial-up remote access allows a remote access client to use the telephone network infrastructure to create a connection to a port on a remote access server. Once the connection is created, the rest of the connection parameters can be negotiated.

• VPN remote access allows a VPN client to use an IP internetwork to create a virtual point-to-point connection with a RAS server acting as the VPN server. Once the virtual point-to-point connection is created, the rest of the connection parameters can be negotiated.

When a user attempts to connect attempt to a RRAS server, the connection must be authenticated and authorized. If a connection attempt is authenticated but not authorized, the connection is denied. If RRAS is configured to use Windows authentication, Windows Server 2003 security verifies the username and password credentials for authentication while the dial-up properties of the user account, and locally stored remote access policies authorize the connection. If the connection attempt is both

Authentication

Authentication is the process of verifying of the username and password credentials of the user that is attempting to connect to RRAS. This process consists of sending the username and password from the remote access client to the remote access server in either a clear text or encrypted form.

authenticated and authorized, the connection attempt is accepted. If RRAS is configured to use Remote Authentication Dial-In User Service (RADIUS) authentication, the username and password credentials of the user attempting to connect to RRAS is 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 RAS server and the connection process is denied. In Windows Server 2003, the RADIUS server is a Windows Server 2003-based computer running the Internet Authentication Service (IAS).

Authorization

Authorization is the process of verifying that the user that is attempting to connect to RRAS is allowed to do so, or is allowed to connect using that computer or dial-in line. This authorization occurs after authentication has been passed.

Note: Each computer that is served by the RRAS server on the intranet should use a private IP address. The Internet Assigned Numbers Authority (IANA) has reserved the following IP addresses for private network use:

10.0. 0.0 - 10.255.255.255 Class A IP Addresses

172.16.0. 0 - 172.31.255.255 Class B IP Addresses

192.168.0. 0 - 192.168.255.255 Class C IP Addresses

6.3.1: Remote Access Protocols

Remote access protocols are used to control the establishment of connections and the transmission of data over WAN links. There are three types of remote access protocols that are supported by Windows Server 2003 remote access:

• Point-to-Point Protocol (PPP), which is an industry-standard set of protocols providing the best security, multi-protocol support, and interoperability.

• Serial Line Internet Protocol (SLIP), which is used by older remote access servers. A Windows Server 2003 RAS server does not support SLIP dial-up connections.

• Microsoft remote access protocol, which is also known as Asynchronous NetBEUI (AsyBEUI) and is used by legacy remote access clients, such as Windows NT 3.1, Windows for Workgroups, MS-DOS, and LAN Manager clients.

6.3.2: The PPP Authentication Process

The Point-to-Point protocol (PPP) provides encapsulation capabilities for higher layer protocols like TCP/IP and IPX/SPX as well as multilink and authentication capabilities. It uses four phases of negotiation to establish a connection. These phases are: PPP Link Establishment; User Authentication; PPP Callback Control; and Invocation of Network Layer Protocol.

• During the PPP Link Establishment phase, authentication protocols are negotiated. Also, the agreement between the client and server to use compression and encryption also occurs during this phase. However, this phase does not involve the implementation of the authentication protocols that are selected, nor does it involve the selection of compression or encryption algorithms. The decision to use authentication and the type of authentication to use is negotiated, and the agreement to use compression and/or encryption completes the steps processed in the PPP Link Establishment phase.

• The User Authentication phase of the PPP negotiations involves authentication protocol implementation. During this phase, the implementation of the authentication protocol selected in the PPP Link Establishment phase. This phase of PPP negotiations involves collection of authentication data and comparison, either locally or remotely, of the data against stored authentication information.

• The PPP Callback Control phase provides additional security by requiring the remote access server to call the client back at a specific number. This is a dial-up feature that is not used in VPN connections.

• The Invocation of Network Layer Protocol phase invokes the upper layer network control protocols. Typically, TCP/IP upper layer connectivity is provided through the Internet Protocol Control Protocol (IPCP). Also, Microsoft compression and encryption features are implemented during this phase.